1. 27 9月, 2017 2 次提交
    • D
      bpf, nfp: add meta data support · 65d88fd0
      Daniel Borkmann 提交于
      Implement support for transferring XDP meta data into skb for
      nfp driver; before calling into the program, xdp.data_meta points
      to xdp.data, where on program return with pass verdict, we call
      into skb_metadata_set().
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NJohn Fastabend <john.fastabend@gmail.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      65d88fd0
    • D
      bpf: add meta pointer for direct access · de8f3a83
      Daniel Borkmann 提交于
      This work enables generic transfer of metadata from XDP into skb. The
      basic idea is that we can make use of the fact that the resulting skb
      must be linear and already comes with a larger headroom for supporting
      bpf_xdp_adjust_head(), which mangles xdp->data. Here, we base our work
      on a similar principle and introduce a small helper bpf_xdp_adjust_meta()
      for adjusting a new pointer called xdp->data_meta. Thus, the packet has
      a flexible and programmable room for meta data, followed by the actual
      packet data. struct xdp_buff is therefore laid out that we first point
      to data_hard_start, then data_meta directly prepended to data followed
      by data_end marking the end of packet. bpf_xdp_adjust_head() takes into
      account whether we have meta data already prepended and if so, memmove()s
      this along with the given offset provided there's enough room.
      
      xdp->data_meta is optional and programs are not required to use it. The
      rationale is that when we process the packet in XDP (e.g. as DoS filter),
      we can push further meta data along with it for the XDP_PASS case, and
      give the guarantee that a clsact ingress BPF program on the same device
      can pick this up for further post-processing. Since we work with skb
      there, we can also set skb->mark, skb->priority or other skb meta data
      out of BPF, thus having this scratch space generic and programmable
      allows for more flexibility than defining a direct 1:1 transfer of
      potentially new XDP members into skb (it's also more efficient as we
      don't need to initialize/handle each of such new members). The facility
      also works together with GRO aggregation. The scratch space at the head
      of the packet can be multiple of 4 byte up to 32 byte large. Drivers not
      yet supporting xdp->data_meta can simply be set up with xdp->data_meta
      as xdp->data + 1 as bpf_xdp_adjust_meta() will detect this and bail out,
      such that the subsequent match against xdp->data for later access is
      guaranteed to fail.
      
      The verifier treats xdp->data_meta/xdp->data the same way as we treat
      xdp->data/xdp->data_end pointer comparisons. The requirement for doing
      the compare against xdp->data is that it hasn't been modified from it's
      original address we got from ctx access. It may have a range marking
      already from prior successful xdp->data/xdp->data_end pointer comparisons
      though.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      de8f3a83
  2. 14 9月, 2017 3 次提交
  3. 04 9月, 2017 5 次提交
  4. 30 8月, 2017 1 次提交
  5. 29 8月, 2017 3 次提交
  6. 26 8月, 2017 2 次提交
  7. 24 8月, 2017 4 次提交
  8. 19 8月, 2017 14 次提交
  9. 17 8月, 2017 2 次提交
  10. 12 8月, 2017 3 次提交
    • S
      nfp: send control message when MAC representors are created · 12acb133
      Simon Horman 提交于
      The firmware expects a MAC_REPR control message when a MAC representor
      is created. The driver should expect a PORTMOD message to follow which
      will provide the link states of the physical port associated with the MAC
      representor.
      Signed-off-by: NSimon Horman <simon.horman@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      12acb133
    • S
      nfp: do not update MTU from BH in flower app · bb3afda4
      Simon Horman 提交于
      The Flower app may receive a request to update the MTU of a representor
      netdev upon receipt of a control message from the firmware. This requires
      the RTNL lock which needs to be taken outside of the packet processing
      path.
      
      As a handling of this correctly seems a little to invasive for a fix simply
      skip setting the MTU for now.
      
      Relevant backtrace:
       [ 1496.288489] BUG: scheduling while atomic: kworker/0:3/373/0x00000100
       [ 1496.294911]  dca syscopyarea sysfillrect sysimgblt fb_sys_fops ptp drm mxm_wmi ahci pps_core libahci i2c_algo_bit wmi [last unloaded: nfp]
       [ 1496.294918] CPU: 0 PID: 373 Comm: kworker/0:3 Tainted: G           OE   4.13.0-rc3+ #3
       [ 1496.294919] Hardware name: Supermicro X10DRi/X10DRi, BIOS 2.0 12/28/2015
       [ 1496.294923] Workqueue: events work_for_cpu_fn
       [ 1496.294924] Call Trace:
       [ 1496.294927]  <IRQ>
       [ 1496.294931]  dump_stack+0x63/0x82
       [ 1496.294935]  __schedule_bug+0x54/0x70
       [ 1496.294937]  __schedule+0x62f/0x890
       [ 1496.294941]  ? intel_unmap_sg+0x90/0x90
       [ 1496.294942]  schedule+0x36/0x80
       [ 1496.294943]  schedule_preempt_disabled+0xe/0x10
       [ 1496.294945]  __mutex_lock.isra.2+0x445/0x4a0
       [ 1496.294947]  ? device_is_rmrr_locked+0x12/0x50
       [ 1496.294950]  ? kfree+0x162/0x170
       [ 1496.294952]  ? device_is_rmrr_locked+0x12/0x50
       [ 1496.294953]  ? iommu_should_identity_map+0x50/0xe0
       [ 1496.294954]  __mutex_lock_slowpath+0x13/0x20
       [ 1496.294955]  ? iommu_no_mapping+0x48/0xd0
       [ 1496.294956]  ? __mutex_lock_slowpath+0x13/0x20
       [ 1496.294957]  mutex_lock+0x2f/0x40
       [ 1496.294960]  rtnl_lock+0x15/0x20
       [ 1496.294979]  nfp_flower_cmsg_rx+0xc8/0x150 [nfp]
       [ 1496.294986]  nfp_ctrl_poll+0x286/0x350 [nfp]
       [ 1496.294989]  tasklet_action+0xf6/0x110
       [ 1496.294992]  __do_softirq+0xed/0x278
       [ 1496.294993]  irq_exit+0xb6/0xc0
       [ 1496.294994]  do_IRQ+0x4f/0xd0
       [ 1496.294996]  common_interrupt+0x89/0x89
      
      Fixes: 948faa46 ("nfp: add support for control messages for flower app")
      Signed-off-by: NSimon Horman <simon.horman@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb3afda4
    • J
      net: sched: use newly added classid identity helpers · a2e8da93
      Jiri Pirko 提交于
      Instead of checking handle, which does not have the inner class
      information and drivers wrongly assume clsact->egress as ingress, use
      the newly introduced classid identification helpers.
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a2e8da93
  11. 10 8月, 2017 1 次提交