#
7aaa0f31 |
| 22-Jul-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: seed the buffer pool after allocating the swp
Any interraction with the buffer pool (seeding a buffer, acquire one) is made through a software portal (SWP, a DPIO object). There are ci
dpaa2-switch: seed the buffer pool after allocating the swp
Any interraction with the buffer pool (seeding a buffer, acquire one) is made through a software portal (SWP, a DPIO object). There are circumstances where the dpaa2-switch driver probes on a DPSW before any DPIO devices have been probed. In this case, seeding of the buffer pool will lead to a panic since no SWPs are initialized.
To fix this, seed the buffer pool after making sure that the software portals have been probed and are ready to be used.
Fixes: 0b1b71370458 ("staging: dpaa2-switch: handle Rx path on control interface") Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
4e51bf44 |
| 21-Jul-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: bridge: move the switchdev object replay helpers to "push" mode
Starting with commit 4f2673b3a2b6 ("net: bridge: add helper to replay port and host-joined mdb entries"), DSA has introduced some
net: bridge: move the switchdev object replay helpers to "push" mode
Starting with commit 4f2673b3a2b6 ("net: bridge: add helper to replay port and host-joined mdb entries"), DSA has introduced some bridge helpers that replay switchdev events (FDB/MDB/VLAN additions and deletions) that can be lost by the switchdev drivers in a variety of circumstances:
- an IP multicast group was host-joined on the bridge itself before any switchdev port joined the bridge, leading to the host MDB entries missing in the hardware database. - during the bridge creation process, the MAC address of the bridge was added to the FDB as an entry pointing towards the bridge device itself, but with no switchdev ports being part of the bridge yet, this local FDB entry would remain unknown to the switchdev hardware database. - a VLAN/FDB/MDB was added to a bridge port that is a LAG interface, before any switchdev port joined that LAG, leading to the hardware database missing those entries. - a switchdev port left a LAG that is a bridge port, while the LAG remained part of the bridge, and all FDB/MDB/VLAN entries remained installed in the hardware database of the switchdev port.
Also, since commit 0d2cfbd41c4a ("net: bridge: ignore switchdev events for LAG ports which didn't request replay"), DSA introduced a method, based on a const void *ctx, to ensure that two switchdev ports under the same LAG that is a bridge port do not see the same MDB/VLAN entry being replayed twice by the bridge, once for every bridge port that joins the LAG.
With so many ordering corner cases being possible, it seems unreasonable to expect a switchdev driver writer to get it right from the first try. Therefore, now that DSA has experimented with the bridge replay helpers for a little bit, we can move the code to the bridge driver where it is more readily available to all switchdev drivers.
To convert the switchdev object replay helpers from "pull mode" (where the driver asks for them) to a "push mode" (where the bridge offers them automatically), the biggest problem is that the bridge needs to be aware when a switchdev port joins and leaves, even when the switchdev is only indirectly a bridge port (for example when the bridge port is a LAG upper of the switchdev).
Luckily, we already have a hook for that, in the form of the newly introduced switchdev_bridge_port_offload() and switchdev_bridge_port_unoffload() calls. These offer a natural place for hooking the object addition and deletion replays.
Extend the above 2 functions with: - pointers to the switchdev atomic notifier (for FDB replays) and the blocking notifier (for MDB and VLAN replays). - the "const void *ctx" argument required for drivers to be able to disambiguate between which port is targeted, when multiple ports are lowers of the same LAG that is a bridge port. Most of the drivers pass NULL to this argument, except the ones that support LAG offload and have the proper context check already in place in the switchdev blocking notifier handler.
Also unexport the replay helpers, since nobody except the bridge calls them directly now.
Note that: (a) we abuse the terminology slightly, because FDB entries are not "switchdev objects", but we count them as objects nonetheless. With no direct way to prove it, I think they are not modeled as switchdev objects because those can only be installed by the bridge to the hardware (as opposed to FDB entries which can be propagated in the other direction too). This is merely an abuse of terms, FDB entries are replayed too, despite not being objects. (b) the bridge does not attempt to sync port attributes to newly joined ports, just the countable stuff (the objects). The reason for this is simple: no universal and symmetric way to sync and unsync them is known. For example, VLAN filtering: what to do on unsync, disable or leave it enabled? Similarly, STP state, ageing timer, etc etc. What a switchdev port does when it becomes standalone again is not really up to the bridge's competence, and the driver should deal with it. On the other hand, replaying deletions of switchdev objects can be seen a matter of cleanup and therefore be treated by the bridge, hence this patch.
We make the replay helpers opt-in for drivers, because they might not bring immediate benefits for them:
- nbp_vlan_init() is called _after_ netdev_master_upper_dev_link(), so br_vlan_replay() should not do anything for the new drivers on which we call it. The existing drivers where there was even a slight possibility for there to exist a VLAN on a bridge port before they join it are already guarded against this: mlxsw and prestera deny joining LAG interfaces that are members of a bridge.
- br_fdb_replay() should now notify of local FDB entries, but I patched all drivers except DSA to ignore these new entries in commit 2c4eca3ef716 ("net: bridge: switchdev: include local flag in FDB notifications"). Driver authors can lift this restriction as they wish, and when they do, they can also opt into the FDB replay functionality.
- br_mdb_replay() should fix a real issue which is described in commit 4f2673b3a2b6 ("net: bridge: add helper to replay port and host-joined mdb entries"). However most drivers do not offload the SWITCHDEV_OBJ_ID_HOST_MDB to see this issue: only cpsw and am65_cpsw offload this switchdev object, and I don't completely understand the way in which they offload this switchdev object anyway. So I'll leave it up to these drivers' respective maintainers to opt into br_mdb_replay().
So most of the drivers pass NULL notifier blocks for the replay helpers, except: - dpaa2-switch which was already acked/regression-tested with the helpers enabled (and there isn't much of a downside in having them) - ocelot which already had replay logic in "pull" mode - DSA which already had replay logic in "pull" mode
An important observation is that the drivers which don't currently request bridge event replays don't even have the switchdev_bridge_port_{offload,unoffload} calls placed in proper places right now. This was done to avoid unnecessary rework for drivers which might never even add support for this. For driver writers who wish to add replay support, this can be used as a tentative placement guide: https://patchwork.kernel.org/project/netdevbpf/patch/20210720134655.892334-11-vladimir.oltean@nxp.com/
Cc: Vadym Kochan <vkochan@marvell.com> Cc: Taras Chornyi <tchornyi@marvell.com> Cc: Ioana Ciornei <ioana.ciornei@nxp.com> Cc: Lars Povlsen <lars.povlsen@microchip.com> Cc: Steen Hegelund <Steen.Hegelund@microchip.com> Cc: UNGLinuxDriver@microchip.com Cc: Claudiu Manoil <claudiu.manoil@nxp.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Ioana Ciornei <ioana.ciornei@nxp.com> # dpaa2-switch Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
2f5dc00f |
| 21-Jul-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: bridge: switchdev: let drivers inform which bridge ports are offloaded
On reception of an skb, the bridge checks if it was marked as 'already forwarded in hardware' (checks if skb->offload_fwd_
net: bridge: switchdev: let drivers inform which bridge ports are offloaded
On reception of an skb, the bridge checks if it was marked as 'already forwarded in hardware' (checks if skb->offload_fwd_mark == 1), and if it is, it assigns the source hardware domain of that skb based on the hardware domain of the ingress port. Then during forwarding, it enforces that the egress port must have a different hardware domain than the ingress one (this is done in nbp_switchdev_allowed_egress).
Non-switchdev drivers don't report any physical switch id (neither through devlink nor .ndo_get_port_parent_id), therefore the bridge assigns them a hardware domain of 0, and packets coming from them will always have skb->offload_fwd_mark = 0. So there aren't any restrictions.
Problems appear due to the fact that DSA would like to perform software fallback for bonding and team interfaces that the physical switch cannot offload.
+-- br0 ---+ / / | \ / / | \ / | | bond0 / | | / \ swp0 swp1 swp2 swp3 swp4
There, it is desirable that the presence of swp3 and swp4 under a non-offloaded LAG does not preclude us from doing hardware bridging beteen swp0, swp1 and swp2. The bandwidth of the CPU is often times high enough that software bridging between {swp0,swp1,swp2} and bond0 is not impractical.
But this creates an impossible paradox given the current way in which port hardware domains are assigned. When the driver receives a packet from swp0 (say, due to flooding), it must set skb->offload_fwd_mark to something.
- If we set it to 0, then the bridge will forward it towards swp1, swp2 and bond0. But the switch has already forwarded it towards swp1 and swp2 (not to bond0, remember, that isn't offloaded, so as far as the switch is concerned, ports swp3 and swp4 are not looking up the FDB, and the entire bond0 is a destination that is strictly behind the CPU). But we don't want duplicated traffic towards swp1 and swp2, so it's not ok to set skb->offload_fwd_mark = 0.
- If we set it to 1, then the bridge will not forward the skb towards the ports with the same switchdev mark, i.e. not to swp1, swp2 and bond0. Towards swp1 and swp2 that's ok, but towards bond0? It should have forwarded the skb there.
So the real issue is that bond0 will be assigned the same hardware domain as {swp0,swp1,swp2}, because the function that assigns hardware domains to bridge ports, nbp_switchdev_add(), recurses through bond0's lower interfaces until it finds something that implements devlink (calls dev_get_port_parent_id with bool recurse = true). This is a problem because the fact that bond0 can be offloaded by swp3 and swp4 in our example is merely an assumption.
A solution is to give the bridge explicit hints as to what hardware domain it should use for each port.
Currently, the bridging offload is very 'silent': a driver registers a netdevice notifier, which is put on the netns's notifier chain, and which sniffs around for NETDEV_CHANGEUPPER events where the upper is a bridge, and the lower is an interface it knows about (one registered by this driver, normally). Then, from within that notifier, it does a bunch of stuff behind the bridge's back, without the bridge necessarily knowing that there's somebody offloading that port. It looks like this:
ip link set swp0 master br0 | v br_add_if() calls netdev_master_upper_dev_link() | v call_netdevice_notifiers | v dsa_slave_netdevice_event | v oh, hey! it's for me! | v .port_bridge_join
What we do to solve the conundrum is to be less silent, and change the switchdev drivers to present themselves to the bridge. Something like this:
ip link set swp0 master br0 | v br_add_if() calls netdev_master_upper_dev_link() | v bridge: Aye! I'll use this call_netdevice_notifiers ^ ppid as the | | hardware domain for v | this port, and zero dsa_slave_netdevice_event | if I got nothing. | | v | oh, hey! it's for me! | | | v | .port_bridge_join | | | +------------------------+ switchdev_bridge_port_offload(swp0, swp0)
Then stacked interfaces (like bond0 on top of swp3/swp4) would be treated differently in DSA, depending on whether we can or cannot offload them.
The offload case:
ip link set bond0 master br0 | v br_add_if() calls netdev_master_upper_dev_link() | v bridge: Aye! I'll use this call_netdevice_notifiers ^ ppid as the | | switchdev mark for v | bond0. dsa_slave_netdevice_event | Coincidentally (or not), | | bond0 and swp0, swp1, swp2 v | all have the same switchdev hmm, it's not quite for me, | mark now, since the ASIC but my driver has already | is able to forward towards called .port_lag_join | all these ports in hw. for it, because I have | a port with dp->lag_dev == bond0. | | | v | .port_bridge_join | for swp3 and swp4 | | | +------------------------+ switchdev_bridge_port_offload(bond0, swp3) switchdev_bridge_port_offload(bond0, swp4)
And the non-offload case:
ip link set bond0 master br0 | v br_add_if() calls netdev_master_upper_dev_link() | v bridge waiting: call_netdevice_notifiers ^ huh, switchdev_bridge_port_offload | | wasn't called, okay, I'll use a v | hwdom of zero for this one. dsa_slave_netdevice_event : Then packets received on swp0 will | : not be software-forwarded towards v : swp1, but they will towards bond0. it's not for me, but bond0 is an upper of swp3 and swp4, but their dp->lag_dev is NULL because they couldn't offload it.
Basically we can draw the conclusion that the lowers of a bridge port can come and go, so depending on the configuration of lowers for a bridge port, it can dynamically toggle between offloaded and unoffloaded. Therefore, we need an equivalent switchdev_bridge_port_unoffload too.
This patch changes the way any switchdev driver interacts with the bridge. From now on, everybody needs to call switchdev_bridge_port_offload and switchdev_bridge_port_unoffload, otherwise the bridge will treat the port as non-offloaded and allow software flooding to other ports from the same ASIC.
Note that these functions lay the ground for a more complex handshake between switchdev drivers and the bridge in the future.
For drivers that will request a replay of the switchdev objects when they offload and unoffload a bridge port (DSA, dpaa2-switch, ocelot), we place the call to switchdev_bridge_port_unoffload() strategically inside the NETDEV_PRECHANGEUPPER notifier's code path, and not inside NETDEV_CHANGEUPPER. This is because the switchdev object replay helpers need the netdev adjacency lists to be valid, and that is only true in NETDEV_PRECHANGEUPPER.
Cc: Vadym Kochan <vkochan@marvell.com> Cc: Taras Chornyi <tchornyi@marvell.com> Cc: Ioana Ciornei <ioana.ciornei@nxp.com> Cc: Lars Povlsen <lars.povlsen@microchip.com> Cc: Steen Hegelund <Steen.Hegelund@microchip.com> Cc: UNGLinuxDriver@microchip.com Cc: Claudiu Manoil <claudiu.manoil@nxp.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Ioana Ciornei <ioana.ciornei@nxp.com> # dpaa2-switch: regression Acked-by: Ioana Ciornei <ioana.ciornei@nxp.com> # dpaa2-switch Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com> # ocelot-switch Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
45035feb |
| 21-Jul-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dpaa2-switch: refactor prechangeupper sanity checks
Make more room for some extra code in the NETDEV_PRECHANGEUPPER handler by moving what already exists into a dedicated function.
Cc: Ioana C
net: dpaa2-switch: refactor prechangeupper sanity checks
Make more room for some extra code in the NETDEV_PRECHANGEUPPER handler by moving what already exists into a dedicated function.
Cc: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
123338d7 |
| 21-Jul-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dpaa2-switch: use extack in dpaa2_switch_port_bridge_join
We need to propagate the extack argument for dpaa2_switch_port_bridge_join to use it in a future patch, and it looks like there is alre
net: dpaa2-switch: use extack in dpaa2_switch_port_bridge_join
We need to propagate the extack argument for dpaa2_switch_port_bridge_join to use it in a future patch, and it looks like there is already an error message there which is currently printed to the console. Move it over netlink so it is properly transmitted to user space.
Cc: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Ioana Ciornei <ioana.ciornei@nxp.com> Acked-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13 |
|
#
69bfac96 |
| 27-Jun-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: switchdev: add a context void pointer to struct switchdev_notifier_info
In the case where the driver asks for a replay of a certain type of event (port object or attribute) for a bridge port th
net: switchdev: add a context void pointer to struct switchdev_notifier_info
In the case where the driver asks for a replay of a certain type of event (port object or attribute) for a bridge port that is a LAG, it may do so because this port has just joined the LAG.
But there might already be other switchdev ports in that LAG, and it is preferable that those preexisting switchdev ports do not act upon the replayed event.
The solution is to add a context to switchdev events, which is NULL most of the time (when the bridge layer initiates the call) but which can be set to a value controlled by the switchdev driver when a replay is requested. The driver can then check the context to figure out if all ports within the LAG should act upon the switchdev event, or just the ones that match the context.
We have to modify all switchdev_handle_* helper functions as well as the prototypes in the drivers that use these helpers too, because these helpers hide the underlying struct switchdev_notifier_info from us and there is no way to retrieve the context otherwise.
The context structure will be populated and used in later patches.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31 |
|
#
2c4eca3e |
| 14-Apr-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: bridge: switchdev: include local flag in FDB notifications
As explained in bugfix commit 6ab4c3117aec ("net: bridge: don't notify switchdev for local FDB addresses") as well as in this discussi
net: bridge: switchdev: include local flag in FDB notifications
As explained in bugfix commit 6ab4c3117aec ("net: bridge: don't notify switchdev for local FDB addresses") as well as in this discussion: https://lore.kernel.org/netdev/20210117193009.io3nungdwuzmo5f7@skbuf/
the switchdev notifiers for FDB entries managed to have a zero-day bug, which was that drivers would not know what to do with local FDB entries, because they were not told that they are local. The bug fix was to simply not notify them of those addresses.
Let us now add the 'is_local' bit to bridge FDB entries, and make all drivers ignore these entries by their own choice.
Co-developed-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.10.30 |
|
#
16617954 |
| 13-Apr-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: reuse dpaa2_switch_acl_entry_add() for STP frames trap
Since we added the dpaa2_switch_acl_entry_add() function in the previous patches to hide all the details of actually adding the A
dpaa2-switch: reuse dpaa2_switch_acl_entry_add() for STP frames trap
Since we added the dpaa2_switch_acl_entry_add() function in the previous patches to hide all the details of actually adding the ACL entry by issuing a firmware command, let's use it also for adding a CPU trap for the STP frames.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
4ba28c1a |
| 13-Apr-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: add tc matchall filter support
Add support TC_SETUP_CLSMATCHALL by using the same ACL table entries framework as for tc flower. Adding a matchall rule is done by installing an entry wh
dpaa2-switch: add tc matchall filter support
Add support TC_SETUP_CLSMATCHALL by using the same ACL table entries framework as for tc flower. Adding a matchall rule is done by installing an entry which has a mask of all zeroes, thus matching on any packet.
This can be used as a catch-all type of rule if used correctly, ie the priority of the matchall filter should be kept as the lowest one in the entire filter block.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
1110318d |
| 13-Apr-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: add tc flower hardware offload on ingress traffic
This patch adds support for tc flower hardware offload on the ingress path. Shared filter blocks are supported by sharing a single ACL
dpaa2-switch: add tc flower hardware offload on ingress traffic
This patch adds support for tc flower hardware offload on the ingress path. Shared filter blocks are supported by sharing a single ACL table between multiple ports.
The following flow keys are supported: - Ethernet: dst_mac/src_mac - IPv4: dst_ip/src_ip/ip_proto/tos - VLAN: vlan_id/vlan_prio/vlan_tpid/vlan_dei - L4: dst_port/src_port
As per flow actions, the following are supported: - drop - mirred egress redirect - trap Each ACL entry (filter) can be setup with only one of the listed actions.
A sorted single linked list is used to keep the ACL entries by their order of priority. When adding a new filter, this enables us to quickly ascertain if the new entry has the highest priority of the entire block or if we should make some space in the ACL table by increasing the priority of the filters already in the table.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
2bf90ba5 |
| 13-Apr-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: install default STP trap rule with the highest priority
Change the default ACL trap rule for STP frames to have the highest priority.
In the same ACL table will reside both default ru
dpaa2-switch: install default STP trap rule with the highest priority
Change the default ACL trap rule for STP frames to have the highest priority.
In the same ACL table will reside both default rules added by the driver for its internal use as well as rules added with tc flower. In this case, the default rules such as the STP one that we already have should have the highest priority.
Also, remove the check for a full ACL table since we already know that it's sized so that we don't hit this case. The last thing changes is that default trap filters will not be counted in the acl_tbl's num_rules variable since their number doesn't change.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
1b0f14b6 |
| 13-Apr-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: create a central dpaa2_switch_acl_tbl structure
Introduce a new structure - dpaa2_switch_acl_tbl - to hold all data related to an ACL table: number of rules added, ACL table id, etc. T
dpaa2-switch: create a central dpaa2_switch_acl_tbl structure
Introduce a new structure - dpaa2_switch_acl_tbl - to hold all data related to an ACL table: number of rules added, ACL table id, etc. This will be used more in the next patches when adding support for sharing an ACL table between ports.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
bc96781a |
| 30-Mar-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: setup learning state on STP state change
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
dpaa2-switch: setup learning state on STP state change
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: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
1a64ed12 |
| 30-Mar-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: trap STP frames to the CPU
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-
dpaa2-switch: trap STP frames to the CPU
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: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
62734c74 |
| 30-Mar-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: keep track of the current learning state per port
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
dpaa2-switch: keep track of the current learning state per port
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: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
90f07102 |
| 30-Mar-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: create and assign an ACL table per port
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
dpaa2-switch: create and assign an ACL table per port
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: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
6aa6791d |
| 30-Mar-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: fix the translation between the bridge and dpsw STP states
The numerical values used for STP states are different between the bridge and the MC ABI therefore, the direct usage of the B
dpaa2-switch: fix the translation between the bridge and dpsw STP states
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: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.10.27, v5.10.26 |
|
#
b175dfd7 |
| 22-Mar-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: mark skbs with offload_fwd_mark
If a switch port is under a bridge, the offload_fwd_mark should be setup before sending the skb towards the stack so that the bridge does not try to flo
dpaa2-switch: mark skbs with offload_fwd_mark
If a switch port is under a bridge, the offload_fwd_mark should be setup before sending the skb towards the stack so that the bridge does not try to flood the packet on the other switch ports.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
6253d5e3 |
| 22-Mar-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: add support for configuring per port unknown flooding
Add support for configuring per port unknown flooding by accepting both BR_FLOOD and BR_MCAST_FLOOD as offloadable bridge port fla
dpaa2-switch: add support for configuring per port unknown flooding
Add support for configuring per port unknown flooding by accepting both BR_FLOOD and BR_MCAST_FLOOD as offloadable bridge port flags.
The DPAA2 switch does not support at the moment configuration of unknown multicast flooding independently of unknown unicast flooding, therefore check that both BR_FLOOD and BR_MCAST_FLOOD have the same state.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
b54eb093 |
| 22-Mar-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: add support for configuring per port broadcast flooding
The BR_BCAST_FLOOD bridge port flag is now accepted by the driver and a change in its state will determine a reconfiguration of
dpaa2-switch: add support for configuring per port broadcast flooding
The BR_BCAST_FLOOD bridge port flag is now accepted by the driver and a change in its state will determine a reconfiguration of the broadcast egress flooding list on the FDB associated with the port.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
1e7cbabf |
| 22-Mar-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: add support for configuring learning state per port
Add support for configuring the learning state of a switch port. When the user requests the HW learning to be disabled, a fast-age p
dpaa2-switch: add support for configuring learning state per port
Add support for configuring the learning state of a switch port. When the user requests the HW learning to be disabled, a fast-age procedure on that specific port is run so that previously learnt addresses do not linger.
At device probe as well as on a bridge leave action, the ports are configured with HW learning disabled since they are basically a standalone port.
At the same time, at bridge join we inherit the bridge port BR_LEARNING flag state and configure it on the switch port.
There were already some MC firmware ABI functions for changing the learning state, but those were per FDB (bridging domain) and not per port so we need to adjust those to use the new MC fw command which is per port.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
f054e3e2 |
| 22-Mar-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: refactor the egress flooding domain setup
Extract the code that determines the list of egress flood interfaces for a specific flood type into a new function - dpaa2_switch_fdb_get_floo
dpaa2-switch: refactor the egress flooding domain setup
Extract the code that determines the list of egress flood interfaces for a specific flood type into a new function - dpaa2_switch_fdb_get_flood_cfg().
This will help us to not duplicate code when the broadcast and unknown ucast/mcast flooding domains will be individually configurable.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
c7e856c8 |
| 22-Mar-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
dpaa2-switch: move the dpaa2_switch_fdb_set_egress_flood function
In order to avoid a forward declaration in the next patches, move the dpaa2_switch_fdb_set_egress_flood() function to the top of the
dpaa2-switch: move the dpaa2_switch_fdb_set_egress_flood function
In order to avoid a forward declaration in the next patches, move the dpaa2_switch_fdb_set_egress_flood() function to the top of the file.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.10.25, v5.10.24, v5.10.23 |
|
#
f48298d3 |
| 10-Mar-2021 |
Ioana Ciornei <ioana.ciornei@nxp.com> |
staging: dpaa2-switch: move the driver out of staging
Now that the dpaa2-switch driver has basic I/O capabilities on the switch port net_devices and multiple bridging domains are supported, move the
staging: dpaa2-switch: move the driver out of staging
Now that the dpaa2-switch driver has basic I/O capabilities on the switch port net_devices and multiple bridging domains are supported, move the driver out of staging.
The dpaa2-switch driver is placed right next to the dpaa2-eth driver since, in the near future, they will be sharing most of the data path. I didn't implement code reuse in this patch series because I wanted to keep it as small as possible.
Also, the README is removed from staging with the intention to add proper rst documentation afterwards to actually match was is supported by the driver.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|