1. 01 Mar, 2022 18 commits
    • Dust Li's avatar
      net/smc: send directly on setting TCP_NODELAY · b70a5cc0
      Dust Li authored
      In commit ea785a1a("net/smc: Send directly when
      TCP_CORK is cleared"), we don't use delayed work
      to implement cork.
      
      This patch use the same algorithm, removes the
      delayed work when setting TCP_NODELAY and send
      directly in setsockopt(). This also makes the
      TCP_NODELAY the same as TCP.
      
      Cc: Tony Lu <tonylu@linux.alibaba.com>
      Signed-off-by: default avatarDust Li <dust.li@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b70a5cc0
    • Dust Li's avatar
      net/smc: add sysctl for autocorking · 12bbb0d1
      Dust Li authored
      This add a new sysctl: net.smc.autocorking_size
      
      We can dynamically change the behaviour of autocorking
      by change the value of autocorking_size.
      Setting to 0 disables autocorking in SMC
      Signed-off-by: default avatarDust Li <dust.li@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      12bbb0d1
    • Dust Li's avatar
      net/smc: add autocorking support · dcd2cf5f
      Dust Li authored
      This patch adds autocorking support for SMC which could improve
      throughput for small message by x3+.
      
      The main idea is borrowed from TCP autocorking with some RDMA
      specific modification:
      1. The first message should never cork to make sure we won't
         bring extra latency
      2. If we have posted any Tx WRs to the NIC that have not
         completed, cork the new messages until:
         a) Receive CQE for the last Tx WR
         b) We have corked enough message on the connection
      3. Try to push the corked data out when we receive CQE of
         the last Tx WR to prevent the corked messages hang in
         the send queue.
      
      Both SMC autocorking and TCP autocorking check the TX completion
      to decide whether we should cork or not. The difference is
      when we got a SMC Tx WR completion, the data have been confirmed
      by the RNIC while TCP TX completion just tells us the data
      have been sent out by the local NIC.
      
      Add an atomic variable tx_pushing in smc_connection to make
      sure only one can send to let it cork more and save CDC slot.
      
      SMC autocorking should not bring extra latency since the first
      message will always been sent out immediately.
      
      The qperf tcp_bw test shows more than x4 increase under small
      message size with Mellanox connectX4-Lx, same result with other
      throughput benchmarks like sockperf/netperf.
      The qperf tcp_lat test shows SMC autocorking has not increase any
      ping-pong latency.
      
      Test command:
       client: smc_run taskset -c 1 qperf smc-server -oo msg_size:1:64K:*2 \
      			-t 30 -vu tcp_{bw|lat}
       server: smc_run taskset -c 1 qperf
      
      === Bandwidth ====
      MsgSize(Bytes)  SMC-NoCork           TCP                      SMC-AutoCorking
            1         0.578 MB/s       2.392 MB/s(313.57%)        2.647 MB/s(357.72%)
            2         1.159 MB/s       4.780 MB/s(312.53%)        5.153 MB/s(344.71%)
            4         2.283 MB/s      10.266 MB/s(349.77%)       10.363 MB/s(354.02%)
            8         4.668 MB/s      19.040 MB/s(307.86%)       21.215 MB/s(354.45%)
           16         9.147 MB/s      38.904 MB/s(325.31%)       41.740 MB/s(356.32%)
           32        18.369 MB/s      79.587 MB/s(333.25%)       82.392 MB/s(348.52%)
           64        36.562 MB/s     148.668 MB/s(306.61%)      161.564 MB/s(341.89%)
          128        72.961 MB/s     274.913 MB/s(276.80%)      325.363 MB/s(345.94%)
          256       144.705 MB/s     512.059 MB/s(253.86%)      633.743 MB/s(337.96%)
          512       288.873 MB/s     884.977 MB/s(206.35%)     1250.681 MB/s(332.95%)
         1024       574.180 MB/s    1337.736 MB/s(132.98%)     2246.121 MB/s(291.19%)
         2048      1095.192 MB/s    1865.952 MB/s( 70.38%)     2057.767 MB/s( 87.89%)
         4096      2066.157 MB/s    2380.337 MB/s( 15.21%)     2173.983 MB/s(  5.22%)
         8192      3717.198 MB/s    2733.073 MB/s(-26.47%)     3491.223 MB/s( -6.08%)
        16384      4742.221 MB/s    2958.693 MB/s(-37.61%)     4637.692 MB/s( -2.20%)
        32768      5349.550 MB/s    3061.285 MB/s(-42.77%)     5385.796 MB/s(  0.68%)
        65536      5162.919 MB/s    3731.408 MB/s(-27.73%)     5223.890 MB/s(  1.18%)
      ==== Latency ====
      MsgSize(Bytes)   SMC-NoCork         TCP                    SMC-AutoCorking
            1          10.540 us      11.938 us( 13.26%)       10.573 us(  0.31%)
            2          10.996 us      11.992 us(  9.06%)       10.269 us( -6.61%)
            4          10.229 us      11.687 us( 14.25%)       10.240 us(  0.11%)
            8          10.203 us      11.653 us( 14.21%)       10.402 us(  1.95%)
           16          10.530 us      11.313 us(  7.44%)       10.599 us(  0.66%)
           32          10.241 us      11.586 us( 13.13%)       10.223 us( -0.18%)
           64          10.693 us      11.652 us(  8.97%)       10.251 us( -4.13%)
          128          10.597 us      11.579 us(  9.27%)       10.494 us( -0.97%)
          256          10.409 us      11.957 us( 14.87%)       10.710 us(  2.89%)
          512          11.088 us      12.505 us( 12.78%)       10.547 us( -4.88%)
         1024          11.240 us      12.255 us(  9.03%)       10.787 us( -4.03%)
         2048          11.485 us      16.970 us( 47.76%)       11.256 us( -1.99%)
         4096          12.077 us      13.948 us( 15.49%)       12.230 us(  1.27%)
         8192          13.683 us      16.693 us( 22.00%)       13.786 us(  0.75%)
        16384          16.470 us      23.615 us( 43.38%)       16.459 us( -0.07%)
        32768          22.540 us      40.966 us( 81.75%)       23.284 us(  3.30%)
        65536          34.192 us      73.003 us(113.51%)       34.233 us(  0.12%)
      
      With SMC autocorking support, we can archive better throughput
      than TCP in most message sizes without any latency trade-off.
      Signed-off-by: default avatarDust Li <dust.li@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dcd2cf5f
    • Dust Li's avatar
      net/smc: add sysctl interface for SMC · 462791bb
      Dust Li authored
      This patch add sysctl interface to support container environment
      for SMC as we talk in the mail list.
      
      Link: https://lore.kernel.org/netdev/20220224020253.GF5443@linux.alibaba.comCo-developed-by: default avatarTony Lu <tonylu@linux.alibaba.com>
      Signed-off-by: default avatarTony Lu <tonylu@linux.alibaba.com>
      Signed-off-by: default avatarDust Li <dust.li@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      462791bb
    • David S. Miller's avatar
      Merge branch 'vxlan-vnifiltering' · 1e385c08
      David S. Miller authored
      Roopa Prabhu says:
      
      ====================
      vxlan metadata device vnifiltering support
      
      This series adds vnifiltering support to vxlan collect metadata device.
      
      Motivation:
      You can only use a single vxlan collect metadata device for a given
      vxlan udp port in the system today. The vxlan collect metadata device
      terminates all received vxlan packets. As shown in the below diagram,
      there are use-cases where you need to support multiple such vxlan devices in
      independent bridge domains. Each vxlan device must terminate the vni's
      it is configured for.
      Example usecase: In a service provider network a service provider
      typically supports multiple bridge domains with overlapping vlans.
      One bridge domain per customer. Vlans in each bridge domain are
      mapped to globally unique vxlan ranges assigned to each customer.
      
      This series adds vnifiltering support to collect metadata devices to
      terminate only configured vnis. This is similar to vlan filtering in
      bridge driver. The vni filtering capability is provided by a new flag on
      collect metadata device.
      
      In the below pic:
      	- customer1 is mapped to br1 bridge domain
      	- customer2 is mapped to br2 bridge domain
      	- customer1 vlan 10-11 is mapped to vni 1001-1002
      	- customer2 vlan 10-11 is mapped to vni 2001-2002
      	- br1 and br2 are vlan filtering bridges
      	- vxlan1 and vxlan2 are collect metadata devices with
      	  vnifiltering enabled
      
      ┌──────────────────────────────────────────────────────────────────┐
      │  switch                                                          │
      │                                                                  │
      │         ┌───────────┐                 ┌───────────┐              │
      │         │           │                 │           │              │
      │         │   br1     │                 │   br2     │              │
      │         └┬─────────┬┘                 └──┬───────┬┘              │
      │     vlans│         │               vlans │       │               │
      │     10,11│         │                10,11│       │               │
      │          │     vlanvnimap:               │    vlanvnimap:        │
      │          │       10-1001,11-1002         │      10-2001,11-2002  │
      │          │         │                     │       │               │
      │   ┌──────┴┐     ┌──┴─────────┐       ┌───┴────┐  │               │
      │   │ swp1  │     │vxlan1      │       │ swp2   │ ┌┴─────────────┐ │
      │   │       │     │  vnifilter:│       │        │ │vxlan2        │ │
      │   └───┬───┘     │   1001,1002│       └───┬────┘ │ vnifilter:   │ │
      │       │         └────────────┘           │      │  2001,2002   │ │
      │       │                                  │      └──────────────┘ │
      │       │                                  │                       │
      └───────┼──────────────────────────────────┼───────────────────────┘
              │                                  │
              │                                  │
        ┌─────┴───────┐                          │
        │  customer1  │                    ┌─────┴──────┐
        │ host/VM     │                    │customer2   │
        └─────────────┘                    │ host/VM    │
                                           └────────────┘
      
      v2:
        - remove stale xstats declarations pointed out by Nikolay Aleksandrov
        - squash selinux patch with the tunnel api patch as pointed out by
          benjamin poirier
        - Fix various build issues:
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      
      v3:
        - incorporate review feedback from Jakub
      	- move rhashtable declarations to c file
      	- define and use netlink policy for top level vxlan filter api
      	- fix unused stats function warning
      	- pass vninode from vnifilter lookup into stats count function
      		to avoid another lookup (only applicable to vxlan_rcv)
      	- fix missing vxlan vni delete notifications in vnifilter uninit
      	  function
      	- misc cleanups
        - remote dev check for multicast groups added via vnifiltering api
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e385c08
    • Nikolay Aleksandrov's avatar
      drivers: vxlan: vnifilter: add support for stats dumping · 445b2f36
      Nikolay Aleksandrov authored
      Add support for VXLAN vni filter entries' stats dumping
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      445b2f36
    • Nikolay Aleksandrov's avatar
      drivers: vxlan: vnifilter: per vni stats · 4095e0e1
      Nikolay Aleksandrov authored
      Add per-vni statistics for vni filter mode. Counting Rx/Tx
      bytes/packets/drops/errors at the appropriate places.
      
      This patch changes vxlan_vs_find_vni to also return the
      vxlan_vni_node in cases where the vni belongs to a vni
      filtering vxlan device
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarRoopa Prabhu <roopa@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4095e0e1
    • Roopa Prabhu's avatar
      selftests: add new tests for vxlan vnifiltering · 3edf5f66
      Roopa Prabhu authored
      This patch adds a new test script test_vxlan_vnifiltering.sh
      with tests for vni filtering api, various datapath tests.
      Also has a test with a mix of traditional, metadata and vni
      filtering devices inuse at the same time.
      Signed-off-by: default avatarRoopa Prabhu <roopa@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3edf5f66
    • Roopa Prabhu's avatar
      vxlan: vni filtering support on collect metadata device · f9c4bb0b
      Roopa Prabhu authored
      This patch adds vnifiltering support to collect metadata device.
      
      Motivation:
      You can only use a single vxlan collect metadata device for a given
      vxlan udp port in the system today. The vxlan collect metadata device
      terminates all received vxlan packets. As shown in the below diagram,
      there are use-cases where you need to support multiple such vxlan devices in
      independent bridge domains. Each vxlan device must terminate the vni's
      it is configured for.
      Example usecase: In a service provider network a service provider
      typically supports multiple bridge domains with overlapping vlans.
      One bridge domain per customer. Vlans in each bridge domain are
      mapped to globally unique vxlan ranges assigned to each customer.
      
      vnifiltering support in collect metadata devices terminates only configured
      vnis. This is similar to vlan filtering in bridge driver. The vni filtering
      capability is provided by a new flag on collect metadata device.
      
      In the below pic:
      	- customer1 is mapped to br1 bridge domain
      	- customer2 is mapped to br2 bridge domain
      	- customer1 vlan 10-11 is mapped to vni 1001-1002
      	- customer2 vlan 10-11 is mapped to vni 2001-2002
      	- br1 and br2 are vlan filtering bridges
      	- vxlan1 and vxlan2 are collect metadata devices with
      	  vnifiltering enabled
      
      ┌──────────────────────────────────────────────────────────────────┐
      │  switch                                                          │
      │                                                                  │
      │         ┌───────────┐                 ┌───────────┐              │
      │         │           │                 │           │              │
      │         │   br1     │                 │   br2     │              │
      │         └┬─────────┬┘                 └──┬───────┬┘              │
      │     vlans│         │               vlans │       │               │
      │     10,11│         │                10,11│       │               │
      │          │     vlanvnimap:               │    vlanvnimap:        │
      │          │       10-1001,11-1002         │      10-2001,11-2002  │
      │          │         │                     │       │               │
      │   ┌──────┴┐     ┌──┴─────────┐       ┌───┴────┐  │               │
      │   │ swp1  │     │vxlan1      │       │ swp2   │ ┌┴─────────────┐ │
      │   │       │     │  vnifilter:│       │        │ │vxlan2        │ │
      │   └───┬───┘     │   1001,1002│       └───┬────┘ │ vnifilter:   │ │
      │       │         └────────────┘           │      │  2001,2002   │ │
      │       │                                  │      └──────────────┘ │
      │       │                                  │                       │
      └───────┼──────────────────────────────────┼───────────────────────┘
              │                                  │
              │                                  │
        ┌─────┴───────┐                          │
        │  customer1  │                    ┌─────┴──────┐
        │ host/VM     │                    │customer2   │
        └─────────────┘                    │ host/VM    │
                                           └────────────┘
      
      With this implementation, vxlan dst metadata device can
      be associated with range of vnis.
      struct vxlan_vni_node is introduced to represent
      a configured vni. We start with vni and its
      associated remote_ip in this structure. This
      structure can be extended to bring in other
      per vni attributes if there are usecases for it.
      A vni inherits an attribute from the base vxlan device
      if there is no per vni attributes defined.
      
      struct vxlan_dev gets a new rhashtable for
      vnis called vxlan_vni_group. vxlan_vnifilter.c
      implements the necessary netlink api, notifications
      and helper functions to process and manage lifecycle
      of vxlan_vni_node.
      
      This patch also adds new helper functions in vxlan_multicast.c
      to handle per vni remote_ip multicast groups which are part
      of vxlan_vni_group.
      
      Fix build problems:
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarRoopa Prabhu <roopa@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9c4bb0b
    • Roopa Prabhu's avatar
      vxlan_multicast: Move multicast helpers to a separate file · a498c595
      Roopa Prabhu authored
      subsequent patches will add more helpers.
      Signed-off-by: default avatarRoopa Prabhu <roopa@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a498c595
    • Roopa Prabhu's avatar
      rtnetlink: add new rtm tunnel api for tunnel id filtering · 7b8135f4
      Roopa Prabhu authored
      This patch adds new rtm tunnel msg and api for tunnel id
      filtering in dst_metadata devices. First dst_metadata
      device to use the api is vxlan driver with AF_BRIDGE
      family.
      
      This and later changes add ability in vxlan driver to do
      tunnel id filtering (or vni filtering) on dst_metadata
      devices. This is similar to vlan api in the vlan filtering bridge.
      
      this patch includes selinux nlmsg_route_perms support for RTM_*TUNNEL
      api from Benjamin Poirier.
      Signed-off-by: default avatarRoopa Prabhu <roopa@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7b8135f4
    • Roopa Prabhu's avatar
      vxlan_core: add helper vxlan_vni_in_use · efe0f94b
      Roopa Prabhu authored
      more users in follow up patches
      Signed-off-by: default avatarRoopa Prabhu <roopa@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      efe0f94b
    • Roopa Prabhu's avatar
      vxlan_core: make multicast helper take rip and ifindex explicitly · a9508d12
      Roopa Prabhu authored
      This patch changes multicast helpers to take rip and ifindex as input.
      This is needed in future patches where rip can come from a pervni
      structure while the ifindex can come from the vxlan device.
      Signed-off-by: default avatarRoopa Prabhu <roopa@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a9508d12
    • Roopa Prabhu's avatar
      vxlan_core: move some fdb helpers to non-static · c63053e0
      Roopa Prabhu authored
      This patch moves some fdb helpers to non-static
      for use in later patches. Ideally, all fdb code
      could move into its own file vxlan_fdb.c.
      This can be done as a subsequent patch and is out
      of scope of this series.
      Signed-off-by: default avatarRoopa Prabhu <roopa@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c63053e0
    • Roopa Prabhu's avatar
      vxlan_core: move common declarations to private header file · 76fc217d
      Roopa Prabhu authored
      This patch moves common structures and global declarations
      to a shared private headerfile vxlan_private.h. Subsequent
      patches use this header file as a common header file for
      additional shared declarations.
      Signed-off-by: default avatarRoopa Prabhu <roopa@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      76fc217d
    • Roopa Prabhu's avatar
      vxlan_core: fix build warnings in vxlan_xmit_one · fba55a66
      Roopa Prabhu authored
      Fix the below build warnings reported by kernel test robot:
         - initialize vni in vxlan_xmit_one
         - wrap label in ipv6 enabled checks in vxlan_xmit_one
      
      warnings:
      static
         drivers/net/vxlan/vxlan_core.c:2437:14: warning: variable 'label' set
      but not used [-Wunused-but-set-variable]
                 __be32 vni, label;
                             ^
      
      >> drivers/net/vxlan/vxlan_core.c:2483:7: warning: variable 'vni' is
      used uninitialized whenever 'if' condition is true
      [-Wsometimes-uninitialized]
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarRoopa Prabhu <roopa@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fba55a66
    • Roopa Prabhu's avatar
      vxlan: move to its own directory · 67653936
      Roopa Prabhu authored
      vxlan.c has grown too long. This patch moves
      it to its own directory. subsequent patches add new
      functionality in new files.
      Signed-off-by: default avatarRoopa Prabhu <roopa@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      67653936
    • Jakub Kicinski's avatar
      Merge branch 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux · f2b77012
      Jakub Kicinski authored
      Saeed Mahameed says:
      
      ====================
      mlx5-next 2022-22-02
      
      The following PR includes updates to mlx5-next branch:
      
      Headlines:
      ==========
      
      1) Jakub cleans up unused static inline functions
      
      2) I did some low level firmware command interface return status changes to
      provide the caller with full visibility on the error/status returned by
      the Firmware.
      
      3) Use the new command interface in RDMA DEVX usecases to avoid flooding
      dmesg with some "expected" user error prone use cases.
      
      4) Moshe also uses the new command interface to grab the specific error
      code from MFRL register command to provide the exact error reason for
      why SW reset couldn't perform internally in FW.
      
      5) From Mark Bloch: Lag, drop packets in hardware when possible
      
      In active-backup mode the inactive interface's packets are dropped by the
      bond device. In switchdev where TC rules are offloaded to the FDB
      this can lead to packets being hit in the FDB where without offload
      they would have been dropped before reaching TC rules in the kernel.
      
      Create a drop rule to make sure packets on inactive ports are dropped
      before reaching the FDB.
      
      Listen on NETDEV_CHANGEUPPER / NETDEV_CHANGEINFODATA events and record
      the inactive state and offload accordingly.
      
      * 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux:
        net/mlx5: Add clarification on sync reset failure
        net/mlx5: Add reset_state field to MFRL register
        RDMA/mlx5: Use new command interface API
        net/mlx5: cmdif, Refactor error handling and reporting of async commands
        net/mlx5: Use mlx5_cmd_do() in core create_{cq,dct}
        net/mlx5: cmdif, Add new api for command execution
        net/mlx5: cmdif, cmd_check refactoring
        net/mlx5: cmdif, Return value improvements
        net/mlx5: Lag, offload active-backup drops to hardware
        net/mlx5: Lag, record inactive state of bond device
        net/mlx5: Lag, don't use magic numbers for ports
        net/mlx5: Lag, use local variable already defined to access E-Switch
        net/mlx5: E-switch, add drop rule support to ingress ACL
        net/mlx5: E-switch, remove special uplink ingress ACL handling
        net/mlx5: E-Switch, reserve and use same uplink metadata across ports
        net/mlx5: Add ability to insert to specific flow group
        mlx5: remove unused static inlines
      ====================
      
      Link: https://lore.kernel.org/r/20220223233930.319301-1-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f2b77012
  2. 28 Feb, 2022 17 commits
  3. 27 Feb, 2022 5 commits
    • David S. Miller's avatar
      Merge branch 'dsa-fdb-isolation' · b42a738e
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      DSA FDB isolation
      
      There are use cases which need FDB isolation between standalone ports
      and bridged ports, as well as isolation between ports of different
      bridges. Most of these use cases are a result of the fact that packets
      can now be partially forwarded by the software bridge, so one port might
      need to send a packet to the CPU but its FDB lookup will see that it can
      forward it directly to a bridge port where that packet was autonomously
      learned. So the source port will attempt to shortcircuit the CPU and
      forward autonomously, which it can't due to the forwarding isolation we
      have in place. So we will have packet drops instead of proper operation.
      
      Additionally, before DSA can implement IFF_UNICAST_FLT for standalone
      ports, we must have control over which database we install FDB entries
      corresponding to port MAC addresses in. We don't want to hinder the
      operation of the bridging layer.
      
      DSA does not have a driver API that encourages FDB isolation, so this
      needs to be created. The basis for this is a new struct dsa_db which
      annotates each FDB and MDB entry with the database it belongs to.
      
      The sja1105 and felix drivers are modified to observe the dsa_db
      argument, and therefore, enforce the FDB isolation.
      
      Compared to the previous RFC patch series from August:
      https://patchwork.kernel.org/project/netdevbpf/cover/20210818120150.892647-1-vladimir.oltean@nxp.com/
      
      what is different is that I stopped trying to make SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE
      blocking, instead I'm making use of the fact that DSA waits for switchdev FDB work
      items to finish before a port leaves the bridge. This is possible since:
      https://patchwork.kernel.org/project/netdevbpf/patch/20211024171757.3753288-7-vladimir.oltean@nxp.com/
      
      Additionally, v2 is also rebased over the DSA LAG FDB work.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b42a738e
    • Vladimir Oltean's avatar
      net: mscc: ocelot: enforce FDB isolation when VLAN-unaware · 54c31984
      Vladimir Oltean authored
      Currently ocelot uses a pvid of 0 for standalone ports and ports under a
      VLAN-unaware bridge, and the pvid of the bridge for ports under a
      VLAN-aware bridge. Standalone ports do not perform learning, but packets
      received on them are still subject to FDB lookups. So if the MAC DA that
      a standalone port receives has been also learned on a VLAN-unaware
      bridge port, ocelot will attempt to forward to that port, even though it
      can't, so it will drop packets.
      
      So there is a desire to avoid that, and isolate the FDBs of different
      bridges from one another, and from standalone ports.
      
      The ocelot switch library has two distinct entry points: the felix DSA
      driver and the ocelot switchdev driver.
      
      We need to code up a minimal bridge_num allocation in the ocelot
      switchdev driver too, this is copied from DSA with the exception that
      ocelot does not care about DSA trees, cross-chip bridging etc. So it
      only looks at its own ports that are already in the same bridge.
      
      The ocelot switchdev driver uses the bridge_num it has allocated itself,
      while the felix driver uses the bridge_num allocated by DSA. They are
      both stored inside ocelot_port->bridge_num by the common function
      ocelot_port_bridge_join() which receives the bridge_num passed by value.
      
      Once we have a bridge_num, we can only use it to enforce isolation
      between VLAN-unaware bridges. As far as I can see, ocelot does not have
      anything like a FID that further makes VLAN 100 from a port be different
      to VLAN 100 from another port with regard to FDB lookup. So we simply
      deny multiple VLAN-aware bridges.
      
      For VLAN-unaware bridges, we crop the 4000-4095 VLAN region and we
      allocate a VLAN for each bridge_num. This will be used as the pvid of
      each port that is under that VLAN-unaware bridge, for as long as that
      bridge is VLAN-unaware.
      
      VID 0 remains only for standalone ports. It is okay if all standalone
      ports use the same VID 0, since they perform no address learning, the
      FDB will contain no entry in VLAN 0, so the packets will always be
      flooded to the only possible destination, the CPU port.
      
      The CPU port module doesn't need to be member of the VLANs to receive
      packets, but if we use the DSA tag_8021q protocol, those packets are
      part of the data plane as far as ocelot is concerned, so there it needs
      to. Just ensure that the DSA tag_8021q CPU port is a member of all
      reserved VLANs when it is created, and is removed when it is deleted.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54c31984
    • Vladimir Oltean's avatar
      net: dsa: sja1105: enforce FDB isolation · 219827ef
      Vladimir Oltean authored
      For sja1105, to enforce FDB isolation simply means to turn on
      Independent VLAN Learning unconditionally, and to remap VLAN-unaware FDB
      and MDB entries towards the private VLAN allocated by tag_8021q for each
      bridge.
      
      Standalone ports each have their own standalone tag_8021q VLAN. No
      learning happens in that VLAN due to:
      - learning being disabled on standalone user ports
      - learning being disabled on the CPU port (we use
        assisted_learning_on_cpu_port which only installs bridge FDBs)
      
      VLAN-aware ports learn FDB entries with the bridge VLANs.
      
      VLAN-unaware bridge ports learn with the tag_8021q VLAN for bridging.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      219827ef
    • Vladimir Oltean's avatar
      net: dsa: pass extack to .port_bridge_join driver methods · 06b9cce4
      Vladimir Oltean authored
      As FDB isolation cannot be enforced between VLAN-aware bridges in lack
      of hardware assistance like extra FID bits, it seems plausible that many
      DSA switches cannot do it. Therefore, they need to reject configurations
      with multiple VLAN-aware bridges from the two code paths that can
      transition towards that state:
      
      - joining a VLAN-aware bridge
      - toggling VLAN awareness on an existing bridge
      
      The .port_vlan_filtering method already propagates the netlink extack to
      the driver, let's propagate it from .port_bridge_join too, to make sure
      that the driver can use the same function for both.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06b9cce4
    • Vladimir Oltean's avatar
      net: dsa: request drivers to perform FDB isolation · c2693363
      Vladimir Oltean authored
      For DSA, to encourage drivers to perform FDB isolation simply means to
      track which bridge does each FDB and MDB entry belong to. It then
      becomes the driver responsibility to use something that makes the FDB
      entry from one bridge not match the FDB lookup of ports from other
      bridges.
      
      The top-level functions where the bridge is determined are:
      - dsa_port_fdb_{add,del}
      - dsa_port_host_fdb_{add,del}
      - dsa_port_mdb_{add,del}
      - dsa_port_host_mdb_{add,del}
      
      aka the pre-crosschip-notifier functions.
      
      Changing the API to pass a reference to a bridge is not superfluous, and
      looking at the passed bridge argument is not the same as having the
      driver look at dsa_to_port(ds, port)->bridge from the ->port_fdb_add()
      method.
      
      DSA installs FDB and MDB entries on shared (CPU and DSA) ports as well,
      and those do not have any dp->bridge information to retrieve, because
      they are not in any bridge - they are merely the pipes that serve the
      user ports that are in one or multiple bridges.
      
      The struct dsa_bridge associated with each FDB/MDB entry is encapsulated
      in a larger "struct dsa_db" database. Although only databases associated
      to bridges are notified for now, this API will be the starting point for
      implementing IFF_UNICAST_FLT in DSA. There, the idea is to install FDB
      entries on the CPU port which belong to the corresponding user port's
      port database. These are supposed to match only when the port is
      standalone.
      
      It is better to introduce the API in its expected final form than to
      introduce it for bridges first, then to have to change drivers which may
      have made one or more assumptions.
      
      Drivers can use the provided bridge.num, but they can also use a
      different numbering scheme that is more convenient.
      
      DSA must perform refcounting on the CPU and DSA ports by also taking
      into account the bridge number. So if two bridges request the same local
      address, DSA must notify the driver twice, once for each bridge.
      
      In fact, if the driver supports FDB isolation, DSA must perform
      refcounting per bridge, but if the driver doesn't, DSA must refcount
      host addresses across all bridges, otherwise it would be telling the
      driver to delete an FDB entry for a bridge and the driver would delete
      it for all bridges. So introduce a bool fdb_isolation in drivers which
      would make all bridge databases passed to the cross-chip notifier have
      the same number (0). This makes dsa_mac_addr_find() -> dsa_db_equal()
      say that all bridge databases are the same database - which is
      essentially the legacy behavior.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c2693363