1. 01 Mar, 2022 15 commits
    • 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 8 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
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: rename dsa_8021q_bridge_tx_fwd_offload_vid · b6362bdf
      Vladimir Oltean authored
      The dsa_8021q_bridge_tx_fwd_offload_vid is no longer used just for
      bridge TX forwarding offload, it is the private VLAN reserved for
      VLAN-unaware bridging in a way that is compatible with FDB isolation.
      
      So just rename it dsa_tag_8021q_bridge_vid.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6362bdf
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: merge RX and TX VLANs · 04b67e18
      Vladimir Oltean authored
      In the old Shared VLAN Learning mode of operation that tag_8021q
      previously used for forwarding, we needed to have distinct concepts for
      an RX and a TX VLAN.
      
      An RX VLAN could be installed on all ports that were members of a given
      bridge, so that autonomous forwarding could still work, while a TX VLAN
      was dedicated for precise packet steering, so it just contained the CPU
      port and one egress port.
      
      Now that tag_8021q uses Independent VLAN Learning and imprecise RX/TX
      all over, those lines have been blurred and we no longer have the need
      to do precise TX towards a port that is in a bridge. As for standalone
      ports, it is fine to use the same VLAN ID for both RX and TX.
      
      This patch changes the tag_8021q format by shifting the VLAN range it
      reserves, and halving it. Previously, our DIR bits were encoding the
      VLAN direction (RX/TX) and were set to either 1 or 2. This meant that
      tag_8021q reserved 2K VLANs, or 50% of the available range.
      
      Change the DIR bits to a hardcoded value of 3 now, which makes tag_8021q
      reserve only 1K VLANs, and a different range now (the last 1K). This is
      done so that we leave the old format in place in case we need to return
      to it.
      
      In terms of code, the vid_is_dsa_8021q_rxvlan and vid_is_dsa_8021q_txvlan
      functions go away. Any vid_is_dsa_8021q is both a TX and an RX VLAN, and
      they are no longer distinct. For example, felix which did different
      things for different VLAN types, now needs to handle the RX and the TX
      logic for the same VLAN.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      04b67e18
    • Vladimir Oltean's avatar
      net: dsa: felix: delete workarounds present due to SVL tag_8021q bridging · 08f44db3
      Vladimir Oltean authored
      The felix driver, which also has a tagging protocol implementation based
      on tag_8021q, does not care about adding the RX VLAN that is pvid on one
      port on the other ports that are in the same bridge with it. It simply
      doesn't need that, because in its implementation, the RX VLAN that is
      pvid of a port is only used to install a TCAM rule that pushes that VLAN
      ID towards the CPU port.
      
      Now that tag_8021q no longer performs Shared VLAN Learning based
      forwarding, the RX VLANs are actually segregated into two types:
      standalone VLANs and VLAN-unaware bridging VLANs. Since you actually
      have to call dsa_tag_8021q_bridge_join() to get a bridging VLAN from
      tag_8021q, and felix does not do that because it doesn't need it, it
      means that it only gets standalone port VLANs from tag_8021q. Which is
      perfect because this means it can drop its workarounds that avoid the
      VLANs it does not need.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      08f44db3