1. 16 7月, 2021 1 次提交
  2. 15 6月, 2021 3 次提交
  3. 26 4月, 2021 1 次提交
  4. 09 2月, 2021 1 次提交
    • N
      ice: Implement flow for IPv6 next header (extension header) · d40e0a80
      Nick Nunley 提交于
      stable inclusion
      from stable-5.10.13
      commit 35c50e69af15e1cbcfbbca4ba7c0f8ed7fb8566c
      bugzilla: 47995
      
      --------------------------------
      
      [ Upstream commit 1b0b0b58 ]
      
      This patch is based on a similar change to i40e by Slawomir Laba:
      "i40e: Implement flow for IPv6 next header (extension header)".
      
      When a packet contains an IPv6 header with next header which is
      an extension header and not a protocol one, the kernel function
      skb_transport_header called with such sk_buff will return a
      pointer to the extension header and not to the TCP one.
      
      The above explained call caused a problem with packet processing
      for skb with encapsulation for tunnel with ICE_TX_CTX_EIPT_IPV6.
      The extension header was not skipped at all.
      
      The ipv6_skip_exthdr function does check if next header of the IPV6
      header is an extension header and doesn't modify the l4_proto pointer
      if it points to a protocol header value so its safe to omit the
      comparison of exthdr and l4.hdr pointers. The ipv6_skip_exthdr can
      return value -1. This means that the skipping process failed
      and there is something wrong with the packet so it will be dropped.
      
      Fixes: a4e82a81 ("ice: Add support for tunnel offloads")
      Signed-off-by: NNick Nunley <nicholas.d.nunley@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
      d40e0a80
  5. 10 12月, 2020 1 次提交
  6. 01 9月, 2020 1 次提交
  7. 27 8月, 2020 1 次提交
  8. 01 8月, 2020 3 次提交
  9. 29 7月, 2020 1 次提交
  10. 31 5月, 2020 1 次提交
  11. 23 5月, 2020 2 次提交
  12. 22 5月, 2020 3 次提交
  13. 15 5月, 2020 1 次提交
    • J
      ice: Add XDP frame size to driver · d4ecdbf7
      Jesper Dangaard Brouer 提交于
      This driver uses different memory models depending on PAGE_SIZE at
      compile time. For PAGE_SIZE 4K it uses page splitting, meaning for
      normal MTU frame size is 2048 bytes (and headroom 192 bytes). For
      larger MTUs the driver still use page splitting, by allocating
      order-1 pages (8192 bytes) for RX frames. For PAGE_SIZE larger than
      4K, driver instead advance its rx_buffer->page_offset with the frame
      size "truesize".
      
      For XDP frame size calculations, this mean that in PAGE_SIZE larger
      than 4K mode the frame_sz change on a per packet basis. For the page
      split 4K PAGE_SIZE mode, xdp.frame_sz is more constant and can be
      updated once outside the main NAPI loop.
      
      The default setting in the driver uses build_skb(), which provides
      the necessary headroom and tailroom for XDP-redirect in RX-frame
      (in both modes).
      
      There is one complication, which is legacy-rx mode (configurable via
      ethtool priv-flags). There are zero headroom in this mode, which is a
      requirement for XDP-redirect to work. The conversion to xdp_frame
      (convert_to_xdp_frame) will detect this insufficient space, and
      xdp_do_redirect() call will fail. This is deemed acceptable, as it
      allows other XDP actions to still work in legacy-mode. In
      legacy-mode + larger PAGE_SIZE due to lacking tailroom, we also
      accept that xdp_adjust_tail shrink doesn't work.
      Signed-off-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Cc: intel-wired-lan@lists.osuosl.org
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Alexander Duyck <alexander.duyck@gmail.com>
      Link: https://lore.kernel.org/bpf/158945347002.97035.328088795813704587.stgit@firesoul
      d4ecdbf7
  14. 16 2月, 2020 2 次提交
  15. 13 2月, 2020 2 次提交
  16. 04 1月, 2020 2 次提交
  17. 07 11月, 2019 1 次提交
  18. 05 11月, 2019 6 次提交
  19. 05 9月, 2019 3 次提交
  20. 24 8月, 2019 1 次提交
  21. 21 8月, 2019 3 次提交