1. 31 Mar, 2021 15 commits
    • Ioana Ciornei's avatar
      dpaa2-switch: setup learning state on STP state change · bc96781a
      Ioana Ciornei authored
      Depending on what STP state a port is in, the learning on that port
      should be enabled or disabled.
      
      When the STP state is DISABLED, BLOCKING or LISTENING no learning should
      be happening irrespective of what the bridge previously requested. The
      learning state is changed to be the one setup by the bridge when the STP
      state is LEARNING or FORWARDING.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc96781a
    • Ioana Ciornei's avatar
      dpaa2-switch: trap STP frames to the CPU · 1a64ed12
      Ioana Ciornei authored
      Add an ACL entry in each port's ACL table to redirect any frame that
      has the destination MAC address equal to the STP dmac to the control
      interface.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a64ed12
    • Ioana Ciornei's avatar
      dpaa2-switch: keep track of the current learning state per port · 62734c74
      Ioana Ciornei authored
      Keep track of the current learning state per port so that we can
      reference it in the next patches when setting up a STP state.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      62734c74
    • Ioana Ciornei's avatar
      dpaa2-switch: create and assign an ACL table per port · 90f07102
      Ioana Ciornei authored
      In order to trap frames to the CPU, the DPAA2 switch uses the ACL table.
      At probe time, create an ACL table for each switch port so that in the
      next patches we can use this to trap STP frames and redirect them to the
      control interface.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90f07102
    • Ioana Ciornei's avatar
      dpaa2-switch: fix the translation between the bridge and dpsw STP states · 6aa6791d
      Ioana Ciornei authored
      The numerical values used for STP states are different between the
      bridge and the MC ABI therefore, the direct usage of the
      BR_STATE_* macros directly in the structures passed to the firmware is
      incorrect.
      
      Create a separate function that translates between the bridge STP states
      and the enum that holds the STP state as seen by the Management Complex.
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6aa6791d
    • Vlad Buslov's avatar
      tc-testing: add simple action change test · e48792a9
      Vlad Buslov authored
      Use act_simple to verify that action created with 'tc actions change'
      command exists after command returns. The goal is to verify internal action
      API reference counting to ensure that the case when netlink message has
      NLM_F_REPLACE flag set but action with specified index doesn't exist is
      handled correctly.
      Signed-off-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e48792a9
    • David S. Miller's avatar
      Merge branch 'udp-gro-L4' · df82e9c6
      David S. Miller authored
      Paolo Abeni says:
      
      ====================
      udp: GRO L4 improvements
      
      This series improves the UDP L4 - either 'forward' or 'frag_list' -
      co-existence with UDP tunnel GRO, allowing the first to take place
      correctly even for encapsulated UDP traffic.
      
      The first for patches are mostly bugfixes, addressing some GRO
      edge-cases when both tunnels and L4 are present, enabled and in use.
      
      The next 3 patches avoid unneeded segmentation when UDP GRO
      traffic traverses in the receive path UDP tunnels.
      
      Finally, some self-tests are included, covering the relevant
      GRO scenarios.
      
      Even if most patches are actually bugfixes, this series is
      targeting net-next, as overall it makes available a new feature.
      
      v2 -> v3:
       - no code changes, more verbose commit messages and comment in
         patch 1/8
      
      v1 -> v2:
       - restrict post segmentation csum fixup to the only the relevant pkts
       - use individual 'accept_gso_type' fields instead of whole gso bitmask
         (Willem)
       - use only ipv6 addesses from test range in self-tests (Willem)
       - hopefully clarified most individual patches commit messages
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df82e9c6
    • Paolo Abeni's avatar
      selftests: net: add UDP GRO forwarding self-tests · a062260a
      Paolo Abeni authored
      Create a bunch of virtual topologies and verify that
      NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD-enabled
      devices aggregate the ingress packets as expected.
      Additionally check that the aggregate packets are
      segmented correctly when landing on a socket
      
      Also test SKB_GSO_FRAGLIST and SKB_GSO_UDP_L4 aggregation
      on top of UDP tunnel (vxlan)
      
      v1 -> v2:
       - hopefully clarify the commit message
       - moved the overlay network ipv6 range into the 'documentation'
         reserved range (Willem)
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a062260a
    • Paolo Abeni's avatar
      bareudp: allow UDP L4 GRO passthrou · b03ef676
      Paolo Abeni authored
      Similar to the previous commit, let even geneve
      passthrou the L4 GRO packets
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b03ef676
    • Paolo Abeni's avatar
      geneve: allow UDP L4 GRO passthrou · 61630c4f
      Paolo Abeni authored
      Similar to the previous commit, let even geneve
      passthrou the L4 GRO packets
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61630c4f
    • Paolo Abeni's avatar
      vxlan: allow L4 GRO passthrough · d18931a9
      Paolo Abeni authored
      When passing up an UDP GSO packet with L4 aggregation, there is
      no need to segment it at the vxlan level. We can propagate the
      packet untouched and let it be segmented later, if needed.
      
      Introduce an helper to allow let the UDP socket to accept any
      L4 aggregation and use it in the vxlan driver.
      
      v1 -> v2:
       - updated to use the newly introduced UDP socket 'accept*' fields
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d18931a9
    • Paolo Abeni's avatar
      udp: never accept GSO_FRAGLIST packets · 78352f73
      Paolo Abeni authored
      Currently the UDP protocol delivers GSO_FRAGLIST packets to
      the sockets without the expected segmentation.
      
      This change addresses the issue introducing and maintaining
      a couple of new fields to explicitly accept SKB_GSO_UDP_L4
      or GSO_FRAGLIST packets. Additionally updates  udp_unexpected_gso()
      accordingly.
      
      UDP sockets enabling UDP_GRO stil keep accept_udp_fraglist
      zeroed.
      
      v1 -> v2:
       - use 2 bits instead of a whole GSO bitmask (Willem)
      
      Fixes: 9fd1ff5d ("udp: Support UDP fraglist GRO/GSO.")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78352f73
    • Paolo Abeni's avatar
      udp: properly complete L4 GRO over UDP tunnel packet · e0e3070a
      Paolo Abeni authored
      After the previous patch, the stack can do L4 UDP aggregation
      on top of a UDP tunnel.
      
      In such scenario, udp{4,6}_gro_complete will be called twice. This function
      will enter its is_flist branch immediately, even though that is only
      correct on the second call, as GSO_FRAGLIST is only relevant for the
      inner packet.
      
      Instead, we need to try first UDP tunnel-based aggregation, if the GRO
      packet requires that.
      
      This patch changes udp{4,6}_gro_complete to skip the frag list processing
      when while encap_mark == 1, identifying processing of the outer tunnel
      header.
      Additionally, clears the field in udp_gro_complete() so that we can enter
      the frag list path on the next round, for the inner header.
      
      v1 -> v2:
       - hopefully clarified the commit message
      Reviewed-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0e3070a
    • Paolo Abeni's avatar
      udp: skip L4 aggregation for UDP tunnel packets · 18f25dc3
      Paolo Abeni authored
      If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there
      are UDP tunnels available in the system, udp_gro_receive() could end-up
      doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at
      the outer UDP tunnel level for packets effectively carrying and UDP
      tunnel header.
      
      That could cause inner protocol corruption. If e.g. the relevant
      packets carry a vxlan header, different vxlan ids will be ignored/
      aggregated to the same GSO packet. Inner headers will be ignored, too,
      so that e.g. TCP over vxlan push packets will be held in the GRO
      engine till the next flush, etc.
      
      Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the
      current packet could land in a UDP tunnel, and let udp_gro_receive()
      do GRO via udp_sk(sk)->gro_receive.
      
      The check implemented in this patch is broader than what is strictly
      needed, as the existing UDP tunnel could be e.g. configured on top of
      a different device: we could end-up skipping GRO at-all for some packets.
      
      Anyhow, that is a very thin corner case and covering it will add quite
      a bit of complexity.
      
      v1 -> v2:
       - hopefully clarify the commit message
      
      Fixes: 9fd1ff5d ("udp: Support UDP fraglist GRO/GSO.")
      Fixes: 36707061 ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets")
      Reviewed-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      18f25dc3
    • Paolo Abeni's avatar
      udp: fixup csum for GSO receive slow path · 000ac44d
      Paolo Abeni authored
      When UDP packets generated locally by a socket with UDP_SEGMENT
      traverse the following path:
      
      UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) ->
      	UDP tunnel (rx) -> UDP socket (no UDP_GRO)
      
      ip_summed will be set to CHECKSUM_PARTIAL at creation time and
      such checksum mode will be preserved in the above path up to the
      UDP tunnel receive code where we have:
      
       __iptunnel_pull_header() -> skb_pull_rcsum() ->
      skb_postpull_rcsum() -> __skb_postpull_rcsum()
      
      The latter will convert the skb to CHECKSUM_NONE.
      
      The UDP GSO packet will be later segmented as part of the rx socket
      receive operation, and will present a CHECKSUM_NONE after segmentation.
      
      Additionally the segmented packets UDP CB still refers to the original
      GSO packet len. Overall that causes unexpected/wrong csum validation
      errors later in the UDP receive path.
      
      We could possibly address the issue with some additional checks and
      csum mangling in the UDP tunnel code. Since the issue affects only
      this UDP receive slow path, let's set a suitable csum status there.
      
      Note that SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST packets lacking an UDP
      encapsulation present a valid checksum when landing to udp_queue_rcv_skb(),
      as the UDP checksum has been validated by the GRO engine.
      
      v2 -> v3:
       - even more verbose commit message and comments
      
      v1 -> v2:
       - restrict the csum update to the packets strictly needing them
       - hopefully clarify the commit message and code comments
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      000ac44d
  2. 30 Mar, 2021 25 commits