#
1267f722 |
|
26-Jan-2024 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Use refcount_t for reference counting mlxsw driver uses 'unsigned int' for reference counters in several structures. Instead, use refcount_t type which allows us to catch overflow and underflow issues. Change the type of the counters and use the appropriate API. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
#
9793a5a9 |
|
11-Aug-2023 |
Ido Schimmel <idosch@nvidia.com> |
mlxsw: spectrum: Stop ignoring learning notifications from redirected traffic As explained in the previous patch, with the ignore action prepended to the redirect action, it is not longer possible for redirected traffic to generate learning notifications. Therefore, remove the workaround that was added in commit 577fa14d2100 ("mlxsw: spectrum: Do not process learned records with a dummy FID") as it is no longer needed. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
a76ca8af |
|
08-Aug-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: Set port STP state on bridge enslavement When the first port joins a LAG that already has a bridge upper, an instance of struct mlxsw_sp_bridge_port is created for the LAG to keep track of it as a bridge port. The bridge_port's STP state is initialized to BR_STATE_DISABLED. This made sense previously, because mlxsw would only ever allow a port to join a LAG if the LAG had no uppers. Thus if a bridge_port was instantiated, it must have been because the LAG as such is joining a bridge, and the STP state is correspondingly disabled. However as of commit 2c5ffe8d7226 ("mlxsw: spectrum: Permit enslavement to netdevices with uppers"), mlxsw allows a port to join a LAG that is already a member of a bridge. The STP state may be different than disabled in that case. Initialize it properly by querying the actual state. This bug may cause an issue as traffic on ports attached to a bridged LAG gets dropped on ingress with discard_ingress_general counter bumped. Fixes: c6514f3627a0 ("Merge branch 'mlxsw-enslavement'") Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/39f4a5781050866b4132f350d7d8cf7ab23ea070.1691498735.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
99ecd6d0 |
|
08-Aug-2023 |
Ruan Jinjie <ruanjinjie@huawei.com> |
mlxsw: spectrum_switchdev: Use is_zero_ether_addr() instead of ether_addr_equal() Use is_zero_ether_addr() instead of ether_addr_equal() to check if the ethernet address is all zeros. Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20230808133528.4083501-1-ruanjinjie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
1ae489ab |
|
27-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_switchdev: Use tracker helpers to hold & put netdevices Using the tracking helpers makes it easier to debug netdevice refcount imbalances when CONFIG_NET_DEV_REFCNT_TRACKER is enabled. Convert dev_hold() / dev_put() to netdev_hold() / netdev_put() in the switchdev module. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/774c3d7b5b0231f1435df2ec9dd660192e382756.1690471774.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
31618b22 |
|
19-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_router: Replay IP NETDEV_UP on device enslavement Enslaving of front panel ports (and their uppers) to netdevices that already have uppers is currently forbidden. When this is permitted, any uppers with IP addresses need to have the NETDEV_UP inetaddr event replayed, so that any RIFs are created. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ec4643ca |
|
19-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_switchdev: Replay switchdev objects on port join Currently it never happens that a netdevice that is already a bridge slave would suddenly become mlxsw upper. The only case where this might be possible as far as mlxsw is concerned, is with LAG netdevices. But if a LAG has any upper (e.g. is enslaved), enlaving mlxsw port to that LAG is forbidden. Thus the only way to install a LAG between a bridge and a mlxsw port is by first enslaving the port to the LAG, and then enslaving that LAG to a bridge. At that point there are no bridge objects (such as port VLANs) to replay. Those are added afterwards, and notified as they are created. This holds even for the PVID. However in the following patches, the requirement that ports be only enslaved to masters without uppers, is going to be relaxed. It will therefore be necessary to replay the existing bridge objects. Without this replay, e.g. the mlxsw bridge_port_vlan objects are not instantiated, which causes issues later, as a lot of code relies on their presence. To that end, add a new notifier block whose sole role is to filter out events related to the one relevant upper, and forward those to the existing switchdev notifier block. Pass the new notifier block to switchdev_bridge_port_offload() when the bridge port is created. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
a5b52692 |
|
13-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_switchdev: Manage RIFs on PVID change Currently, mlxsw has several shortcomings with regards to RIF handling due to PVID changes: - In order to cause RIF for a bridge device to be created, the user is expected first to set PVID, then to add an IP address. The reverse ordering is disallowed, which is not very user-friendly. - When such bridge gets a VLAN upper whose VID was the same as the existing PVID, and this VLAN netdevice gets an IP address, a RIF is created for this netdevice. The new RIF is then assigned to the 802.1Q FID for the given VID. This results in a working configuration. However, then, when the VLAN netdevice is removed again, the RIF for the bridge itself is never reassociated to the VLAN. - PVID cannot be changed once the bridge has uppers. Presumably this is because the driver does not manage RIFs properly in face of PVID changes. However, as the previous point shows, it is still possible to get into invalid configurations. In this patch, add the logic necessary for creation of a RIF as a result of PVID change. Moreover, when a VLAN upper is created whose VID matches lower PVID, do not create RIF for this netdevice. These changes obviate the need for ordering of IP address additions and PVID configuration, so stop forbidding addition of an IP address to a PVID-less bridge. Instead, bail out quietly. Also stop preventing PVID changes when the bridge has uppers. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
352be882 |
|
13-Jul-2023 |
Petr Machata <petrm@nvidia.com> |
mlxsw: spectrum_switchdev: Pass extack to mlxsw_sp_br_ban_rif_pvid_change() Currently the reason for rejection of PVID manipulation is dumped to syslog, and a generic -EBUSY is returned to the userspace. But switchdev_handle_port_obj_add(), through which we get to mlxsw_sp_port_vlans_add(), handles extack just fine, and we can pass the message this way. This improves visibility into reasons why the request to change PVID was rejected. Before the change: # bridge vlan add dev br vid 2 self pvid untagged RTNETLINK answers: Device or resource busy (plus a syslog line) After the change: # bridge vlan add dev br vid 2 self pvid untagged Error: mlxsw_spectrum: Can't change PVID, it's used by router interface. Note that this particular error message is going away in the following patches. However the ability to pass error messages through extack will be useful more broadly for communicating in particular reasons why a RIF failed to be created. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
25ed8088 |
|
08-Nov-2022 |
Ido Schimmel <idosch@nvidia.com> |
mlxsw: spectrum_switchdev: Add locked bridge port support Add locked bridge port support by reacting to changes in the 'BR_PORT_LOCKED' flag. When set, enable security checks on the local port via the previously added SPFSR register. When security checks are enabled, an incoming packet will trigger an FDB lookup with the packet's source MAC and the FID it was classified to. If an FDB entry was not found or was found to be pointing to a different port, the packet will be dropped. Such packets increment the "discard_ingress_general" ethtool counter. For added visibility, user space can trap such packets to the CPU by enabling the "locked_port" trap. Example: # devlink trap set pci/0000:06:00.0 trap locked_port action trap Unlike other configurations done via bridge port flags (e.g., learning, flooding), security checks are enabled in the device on a per-port basis and not on a per-{port, VLAN} basis. As such, scenarios where user space can configure different locking settings for different VLANs configured on a port need to be vetoed. To that end, veto the following scenarios: 1. Locking is set on a bridge port that is a VLAN upper 2. Locking is set on a bridge port that has VLAN uppers 3. VLAN upper is configured on a locked bridge port Examples: # bridge link set dev swp1.10 locked on Error: mlxsw_spectrum: Locked flag cannot be set on a VLAN upper. # ip link add link swp1 name swp1.10 type vlan id 10 # bridge link set dev swp1 locked on Error: mlxsw_spectrum: Locked flag cannot be set on a bridge port that has VLAN uppers. # bridge link set dev swp1 locked on # ip link add link swp1 name swp1.10 type vlan id 10 Error: mlxsw_spectrum: VLAN uppers are not supported on a locked port. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
136b8dfb |
|
08-Nov-2022 |
Ido Schimmel <idosch@nvidia.com> |
mlxsw: spectrum_switchdev: Use extack in bridge port flag validation Propagate extack to mlxsw_sp_port_attr_br_pre_flags_set() in order to communicate error messages related to bridge port flag validation. Example: # bridge link set dev swp1 locked on Error: mlxsw_spectrum: Unsupported bridge port flag. More error messages will be added in subsequent patches. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
5a660e43 |
|
08-Nov-2022 |
Ido Schimmel <idosch@nvidia.com> |
mlxsw: spectrum_switchdev: Add support for locked FDB notifications In Spectrum, learning happens in parallel to the security checks. Therefore, regardless of the result of the security checks, a learning notification will be generated by the device and polled later on by the driver. Currently, the driver reacts to learning notifications by programming corresponding FDB entries to the device. When a port is locked (i.e., has security checks enabled), this can no longer happen, as otherwise any host will blindly gain authorization. Instead, notify the learned entry as a locked entry to the bridge driver that will in turn notify it to user space, in case MAB is enabled. User space can then decide to authorize the host by clearing the "locked" flag, which will cause the entry to be programmed to the device. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
b72cb660 |
|
08-Nov-2022 |
Ido Schimmel <idosch@nvidia.com> |
mlxsw: spectrum_switchdev: Prepare for locked FDB notifications Subsequent patches will need to report locked FDB entries to the bridge driver. Prepare for that by adding a 'locked' argument to mlxsw_sp_fdb_call_notifiers() according to which the 'locked' bit is set in the FDB notification info. For now, always pass 'false'. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
30f5312d |
|
11-Nov-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Avoid warnings when not offloaded FDB entry with IPv6 is removed FDB entries that perform VXLAN encapsulation with an IPv6 underlay hold a reference on a resource - the KVDL entry where the IPv6 underlay destination IP is stored. For that, the driver maintains two hash tables: 1. Maps IPv6 to KVDL index 2. Maps {MAC, FID index} to IPv6 address When a FDB entry is removed, the second table is used to find the relevant IPv6 address and the first table is used to remove the reference count and free the index if is not used anymore. In order for a packet to be forwarded to a single remote VTEP, FDB entries need to be configured at both the bridge and VXLAN devices' FDB tables. Both entries are squashed into one {MAC, VLAN/VNI} -> IP entry in the hardware. Therefore, in case one entry is removed, the entry will be removed from the hardware and the remaining entry will be unmarked with 'offload' flag since it is not offloaded anymore. For example, the two FDB entries should be added to allow packets to be forwarded via vx10: $ bridge fdb add dev vx10 aa:bb:cc:dd:ee:ff self static dst 2001:db8:5::1 $ bridge fdb add dev vx10 aa:bb:cc:dd:ee:ff master static vlan 10 When one entry will be removed, the second one will not be offloaded anymore. When the first entry (in VXLAN FDB) will be removed / will not be offloaded anymore, the two mappings in IPv6 hash tables will be removed. In case that the second entry is removed before the first one, unexpected warnings[1][2] will be shown in user space as a result of removing the first entry. The issue is that not offloaded entry is removed, the driver tries to search the relevant entries in the hash tables, does not find them and therefore warns. Do not handle removing of not offloaded VXLAN FDB entries, as they were already removed when the offload flag was removed. [1]: WARNING: CPU: 1 PID: 239 at drivers/net/ethernet/mellanox/mlxsw/spectrum_nve.c:914 mlxsw_sp_nve_ipv6_addr_map_del+0x6b/0x80 [mlxsw_spectrum] ... Hardware name: Mellanox Technologies Ltd. Mellanox switch/Mellanox switch, BIOS 4.6.5 05/21/2015 Workqueue: mlxsw_core_ordered mlxsw_sp_switchdev_vxlan_fdb_event_work [mlxsw_spectrum] RIP: 0010:mlxsw_sp_nve_ipv6_addr_map_del+0x6b/0x80 [mlxsw_spectrum] ... Call Trace: <TASK> mlxsw_sp_port_fdb_tunnel_uc_op+0x6cf/0x7b0 [mlxsw_spectrum] mlxsw_sp_switchdev_vxlan_fdb_event_work+0x17c/0x420 [mlxsw_spectrum] ? finish_task_switch.isra.0+0x8c/0x290 process_one_work+0x1cd/0x390 worker_thread+0x48/0x3c0 ? process_one_work+0x390/0x390 kthread+0xe0/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> [2]: WARNING: CPU: 0 PID: 239 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3035 mlxsw_sp_ipv6_addr_put+0x142/0x220 [mlxsw_spectrum] ... Hardware name: Mellanox Technologies Ltd. Mellanox switch/Mellanox switch, BIOS 4.6.5 05/21/2015 Workqueue: mlxsw_core_ordered mlxsw_sp_switchdev_vxlan_fdb_event_work [mlxsw_spectrum] RIP: 0010:mlxsw_sp_ipv6_addr_put+0x142/0x220 [mlxsw_spectrum] ... Call Trace: <TASK> ? mlxsw_sp_port_fdb_tun_uc_op6_sfd_write+0x5c1/0x610 [mlxsw_spectrum] mlxsw_sp_port_fdb_tunnel_uc_op+0x6ec/0x7b0 [mlxsw_spectrum] mlxsw_sp_switchdev_vxlan_fdb_event_work+0x17c/0x420 [mlxsw_spectrum] ? finish_task_switch.isra.0+0x8c/0x290 process_one_work+0x1cd/0x390 worker_thread+0x48/0x3c0 ? process_one_work+0x390/0x390 kthread+0xe0/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Fixes: 0860c7641634 ("mlxsw: spectrum_nve: Keep track of IPv6 addresses used by FDB entries") Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/c186de8cbd28e3eb661e06f31f7f2f2dff30020f.1668184350.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
77b7f83d |
|
04-Jul-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Enable unified bridge model After all the preparations for unified bridge model, finally flip mlxsw driver to use the new model. Change config profile, set 'ubridge' to true and remove the configurations that are relevant only for the legacy model. Set 'flood_mode' to 'controlled' as the current mode is not supported with unified bridge model. Remove all the code which is dedicated to the legacy model. Remove 'struct mlxsw_sp.ubridge' variable which was temporarily added to separate configurations between the models. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
53d7ae53 |
|
04-Jul-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Configure egress VID for unicast FDB entries Using unified bridge model, firmware no longer configures the egress VID "under the hood" and moves this responsibility to software. For layer 2, this means that software needs to determine the egress VID for both unicast (i.e., FDB) and multicast (i.e., MDB and flooding) flows. Unicast FDB records and unicast LAG FDB records have new fields - "set_vid" and "vid", set them. For records which point to router port, do not set these fields. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
e28cd993 |
|
28-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Convert MDB code to use PGT APIs The previous patches added common APIs for maintaining PGT (Port Group Table) table. In the legacy model, software did not interact with this table directly. Instead, it was accessed by firmware in response to registers such as SFTR and SMID. In the new model, software has full control over the PGT table using the SMID register. The configuration of MDB entries is already done via SMID, so the new PGT APIs can be used also using the legacy model, the only difference is that MID index should be aligned to bridge model. See a previous patch which added API for that. The main changes are: - MDB code does not maintain bitmap of ports in MDB entry anymore, instead, it stores a list of ports with additional information. - MDB code does not configure SMID register directly anymore, it will be done via PGT API when port is first added or removed. - Today MDB code does not update SMID when port is added/removed while multicast is disabled. Instead, it maintains bitmap of ports and once multicast is enabled, it rewrite the entry to hardware. Using PGT APIs, the entry will be updated also when multicast is disabled, but the mapping between {MAC, FID}->{MID} will not appear in SFD register. It means that SMID will be updated all the time and disable/enable multicast will impact only SFD configuration. - For multicast router, today only SMID is updated and the bitmap is not updated. Using the new list of ports, there is a reference count for each port, so it can be saved in software also. For such port, 'struct mlxsw_sp_mdb_entry.ports_count' will not be updated and the port in the list will be marked as 'mrouter'. - Finally, `struct mlxsw_sp_mid.in_hw` is not needed anymore. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4c3f7442 |
|
28-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Flush port from MDB entries according to FID index Currently, flushing port from all MDB entries is done when the last VLAN is removed. This behavior is inaccurate, as port can be removed while there is another port which uses the same VLAN, in such case, this is not the last port which uses this VLAN and removed, but this port is supposed to be removed from the MDB entries. Flush the port from MDB when it is removed, regardless the state of other ports. Flush only the MDB entries which are relevant for the same FID index. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
7434ed61 |
|
28-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Add support for getting and putting MDB entry A previous patch added support for init() and fini() for MDB entries. MDB entry can be updated, ports can be added and removed from the entry. Add get() and put() functions, the first one checks if the entry already exists and otherwise initializes the entry. The second removes the entry just in case that there are no more ports in this entry. Use the list of the ports which was added in a previous patch. When the list contains only one port which is not multicast router, and this port is removed, the MDB entry can be removed. Use 'struct mlxsw_sp_mdb_entry.ports_count' to know how many ports use the entry, regardless the use of multicast router ports. When mlxsw_sp_mc_mdb_entry_put() is called with specific port which supposed to be removed, check if the removal will cause a deletion of the entry. If this is the case, call mlxsw_sp_mc_mdb_entry_fini() which first deletes the MDB entry and then releases the PGT entry, to avoid a temporary situation in which the MDB entry points to an empty PGT entry, as otherwise packets will be temporarily dropped instead of being flooded. The new functions will be used in the next patches. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ea0f58d6 |
|
28-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Implement mlxsw_sp_mc_mdb_entry_{init, fini}() The next patches will convert MDB code to use PGT APIs. The change will move the responsibility of allocating MID indexes and writing PGT configurations to hardware to PGT code. As part of this change, most of the MDB code will be changed and improved. As a preparation for the above mentioned change, implement mlxsw_sp_mc_mdb_entry_{init, fini}(). Currently, there is a function __mlxsw_sp_mc_alloc(), which does not only allocate MID. In addition, there is no an equivalent function to free the MID. When mlxsw_sp_port_remove_from_mid() removes the last port, it handles MID removal. Instead, add init() and fini() functions, which use PGT APIs. The differences between the existing and the new functions are as follows: 1. Today MDB code does not update SMID when port is added/removed while multicast is disabled. It maintains a bitmap of ports and once multicast is enabled, it writes the entry to hardware. Instead, using PGT APIs, the entry will be updated also when multicast is disabled, but the mapping between {MAC, FID}->{MID} (is configured using SFD) will be updated according to multicast state. It means that SMID will be updated all the time and disable/enable multicast will impact only SFD configuration. 2. Today the allocation of MID index is done as part of mlxsw_sp_mc_write_mdb_entry(). The fact that the entry will be written in hardware all the time, moves the allocation of the index to be as part of the MDB entry initialization. PGT API is used for the allocation. 3. Today the update of multicast router ports is done as part of mlxsw_sp_mc_write_mdb_entry(). Instead, add functions to add/remove all multicast router ports when entry is first added or removed. When new multicast router port will be added/removed, the dedicated API will be used to add/remove it from the existing entries. 4. A list of ports will be stored per MDB entry instead of the exiting bitmap. The list will contain the multicast router ports and maintain reference counter per port. Add mlxsw_sp_mdb_entry_write() which is almost identical to mlxsw_sp_port_mdb_op(). Use more clear name and align the MID index to bridge model using PGT API. The existing function will be removed in the next patches. Note that PGT APIs configure the firmware using SMID register, like the driver already does today for MDB entries, so PGT APIs can be used also using legacy bridge model. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d2994e13 |
|
28-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Add support for maintaining list of ports per MDB entry As part of converting MDB code to use PGT APIs, PGT code stores which ports are mapped to each PGT entry. PGT code is not aware of the type of the port (multicast router or not), as it is not relevant there. To be able to release an MDB entry when the there are no ports which are not multicast routers, the entry should be aware of the state of its ports. Add support for maintaining list of ports per MDB entry. Each port will hold a reference count as multiple MDB entries can use the same hardware MDB entry. It occurs because MDB entries in the Linux bridge are keyed according to their multicast IP, when these entries are notified to device drivers via switchdev, the multicast IP is converted to a multicast MAC. This conversion might cause collisions, for example, ff0e::1 and ff0e:1234::1 are both mapped to the multicast MAC 33:33:00:00:00:01. Multicast router port will take a reference once, and will be marked as 'mrouter', then when port in the list is multicast router and its reference value is one, it means that the entry can be removed in case that there are no other ports which are not multicast routers. For that, maintain a counter per MDB entry to count ports in the list, which were added to the multicast group, and not because they are multicast routers. When this counter is zero, the entry can be removed. Add mlxsw_sp_mdb_entry_port_{get,put}() for regular ports and mlxsw_sp_mdb_entry_mrouter_port_{get,put}() for multicast router ports. Call PGT API to add or remove port from PGT entry when port is first added or removed, according to the reference counting. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
5d0512e5 |
|
28-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Add support for maintaining hash table of MDB entries Currently MDB entries are stored in a list as part of 'struct mlxsw_sp_bridge_device'. Storing them in a hash table in addition to the list will allow finding a specific entry more efficiently. Add support for the required hash table, the next patches will insert and remove MDB entries from the table. The existing code which adds and removes entries will be removed and replaced by new code in the next patches, so there is no point to adjust the existing code. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0ac98543 |
|
28-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Save MAC and FID as a key in 'struct mlxsw_sp_mdb_entry' The next patch will add support for storing all the MDB entries in a hash table. As a preparation, save the MAC address and the FID in a separate structure. This structure will be used later as a key for the hash table. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
eaa0791a |
|
28-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Rename MIDs list Currently, the list which stores the MDB entries for a given bridge instance is called 'mids_list'. This name is not accurate as a MID entry stores a bitmap of ports to which a packet needs to be replicated and a MDB entry stores the mapping from {MAC, FID} to PGT index (MID) Rename it to 'mdb_list'. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
eede53a4 |
|
28-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Rename MID structure Currently the structure which represents MDB entry is called 'struct mlxsw_sp_mid'. This name is not accurate as a MID entry stores a bitmap of ports to which a packet needs to be replicated and a MDB entry stores the mapping from {MAC, FID} to PGT index (MID). Rename the structure to 'struct mlxsw_sp_mdb_entry'. The structure 'mlxsw_sp_mid' is defined as part of spectrum.h. The only file which uses it is spectrum_switchdev.c, so there is no reason to expose it to other files. Move the definition to spectrum_switchdev.c. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d7a7b697 |
|
27-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Add a dedicated structure for bitmap of ports Currently when bitmap of ports is needed, 'unsigned long *' type is used. The functions which use the bitmap assume its length according to its name, i.e., each function which gets a bitmap of ports queries the maximum number of ports and uses it as the size. As preparation for the next patch which will use bitmap of ports, add a dedicated structure for it. Refactor the existing code to use the new structure. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
#
0100f840 |
|
21-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Handle error in mlxsw_sp_bridge_mdb_mc_enable_sync() The above mentioned function calls two functions which return values, but it ignores them. Check if the return value is an error, handle it in such case and return an error back to the caller. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
fd66f518 |
|
21-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Convert mlxsw_sp_mc_write_mdb_entry() to return int The function returns 'false' upon failure and 'true' upon success. Convert it to the usual scheme of returning integer error codes and align the callers. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c96a9919 |
|
21-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Add error path in mlxsw_sp_port_mc_disabled_set() The above mentioned function just returns an error in case that mlxsw_sp_bridge_ports_flood_table_set() fails. That means that the previous configurations are not cleaned. Fix it by adding error path to clean the configurations in case of error. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
a6f43b1d |
|
21-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Simplify mlxsw_sp_port_mc_disabled_set() The above mentioned function is called for each port in bridge when the multicast behavior is changed. Currently, it updates all the relevant MID entries only for the first call, but the update of flooding per port is done only for the port that it was called for it. To simplify this behavior, it is possible to handle flooding for all the ports in the first call, then, the other calls will do nothing. For that, new functions are required to set flooding for all ports, no 'struct mlxsw_sp_port' is required. This issue was found while extending this function for unified bridge model, the above mentioned change will ease the extending later. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
6e66d2e4 |
|
21-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Do not set 'multicast_enabled' twice The function mlxsw_sp_port_mc_disabled_set() sets 'bridge_device->multicast_enabled' twice. Remove the unnecessary setting. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
21c795f8 |
|
21-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Pass 'struct mlxsw_sp' to mlxsw_sp_bridge_mdb_mc_enable_sync() Currently the above mentioned function gets 'struct mlxsw_sp_port', while the only use of this structure is to get 'mlxsw_sp_port->mlxsw_sp'. Instead, pass 'struct mlxsw_sp'. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
22aae520 |
|
21-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Remove lag_vid_valid indication Currently 'struct mlxsw_sp_fid_family' has a field which indicates if 'lag_vid' is valid for use in SFD register. This is a leftover from using .1Q FIDs instead of emulating them using .1D FIDs. Currently when .1Q FIDs are emulated using .1D FIDs, this field is true for both families, so there is no reason to maintain it. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
894b98d5 |
|
19-Jun-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Add SMPE related fields to SMID2 register SMID register maps multicast ID (MID) into a list of local ports. As preparation for unified bridge model, add some required fields for future use. The device includes two main tables to support layer 2 multicast (i.e., MDB and flooding). These are the PGT (Port Group Table) and the MPE (Multicast Port Egress) table. - PGT is {MID -> (bitmap of local_port, SPME index)} - MPE is {(Local port, SMPE index) -> eVID} In Spectrum-1, both indexes into the MPE table (local port and SMPE) are derived from the PGT table. Therefore, the SMPE index needs to be programmed as part of the PGT entry via new fields in SMID - 'smpe_valid' and 'smpe'. Add the two mentioned fields for future use and align the callers of mlxsw_reg_smid2_pack() to pass zeros for SMPE fields. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b8950003 |
|
04-May-2022 |
Ido Schimmel <idosch@nvidia.com> |
mlxsw: spectrum_switchdev: Only query FDB notifications when necessary The driver periodically queries the device for FDB notifications (e.g., learned, aged-out) in order to update the bridge driver. These notifications can only be generated when bridges are offloaded to the device. Avoid unnecessary queries by starting to query upon installation of the first bridge and stop querying upon removal of the last bridge. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ddaff504 |
|
16-Feb-2022 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
mlxsw: spectrum: remove guards against !BRIDGE_VLAN_INFO_BRENTRY Since commit 3116ad0696dd ("net: bridge: vlan: don't notify to switchdev master VLANs without BRENTRY flag"), the bridge no longer emits switchdev notifiers for VLANs that don't have the BRIDGE_VLAN_INFO_BRENTRY flag, so these checks are dead code. Remove them. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
bcdfd615 |
|
27-Jan-2022 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum: Guard against invalid local ports When processing events generated by the device's firmware, the driver protects itself from events reported for non-existent local ports, but not for the CPU port (local port 0), which exists, but does not have all the fields as any local port. This can result in a NULL pointer dereference when trying access 'struct mlxsw_sp_port' fields which are not initialized for CPU port. Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware") already handled such issue by bailing early when processing a PUDE event reported for the CPU port. Generalize the approach by moving the check to a common function and making use of it in all relevant places. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
06c08f86 |
|
14-Dec-2021 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Add support for VxLAN with IPv6 underlay Currently, mlxsw driver supports VxLAN with IPv4 underlay only. Add support for IPv6 underlay. The main differences are: * Learning is not supported for IPv6 FDB entries, use static entries and do not allow 'learning' flag for IPv6 VxLAN. * IPv6 addresses for FDB entries should be saved as part of KVDL. Use the new API to allocate and release entries for IPv6 addresses. * Spectrum ASICs do not fill UDP checksum, while in software IPv6 UDP packets with checksum zero are dropped. Force the relevant flags which allow the VxLAN device to generate UDP packets with zero checksum and also receive them. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1fd85416 |
|
14-Dec-2021 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Split handling of FDB tunnel entries between address families Currently, the function which adds/removes unicast tunnel FDB entries is shared between IPv4 and IPv6, while for IPv6 it warns because there is no support for it. The code for IPv6 will be more complicated because it needs to allocate/release a KVDL pointer for the underlay IPv6 address. As a preparation for IPv6 underlay support, split the code according to address family. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
51ef6b00 |
|
01-Dec-2021 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Use Switch Multicast ID Register Version 2 The SMID-V2 register maps Multicast ID (MID) into a list of local ports. It is a new version of SMID in order to support 1024 bits of local_port. Add SMID-V2 register and use it instead of SMID. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c934757d |
|
01-Dec-2021 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Use u16 for local_port field instead of u8 Currently, local_port field is saved as u8, which means that maximum 256 ports can be used. As preparation for Spectrum-4, which will support more than 256 ports, local_port field should be extended. Save local_port as u16 to allow use of additional ports. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
2c087dfc |
|
24-Oct-2021 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
mlxsw: spectrum: Use 'bitmap_zalloc()' when applicable Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some open-coded arithmetic in allocator arguments. Also change the corresponding 'kfree()' into 'bitmap_free()' to keep consistency. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
47211192 |
|
22-Jul-2021 |
Tobias Waldekranz <tobias@waldekranz.com> |
net: bridge: switchdev: allow the TX data plane forwarding to be offloaded Allow switchdevs to forward frames from the CPU in accordance with the bridge configuration in the same way as is done between bridge ports. This means that the bridge will only send a single skb towards one of the ports under the switchdev's control, and expects the driver to deliver the packet to all eligible ports in its domain. Primarily this improves the performance of multicast flows with multiple subscribers, as it allows the hardware to perform the frame replication. The basic flow between the driver and the bridge is as follows: - When joining a bridge port, the switchdev driver calls switchdev_bridge_port_offload() with tx_fwd_offload = true. - The bridge sends offloadable skbs to one of the ports under the switchdev's control using skb->offload_fwd_mark = true. - The switchdev driver checks the skb->offload_fwd_mark field and lets its FDB lookup select the destination port mask for this packet. v1->v2: - convert br_input_skb_cb::fwd_hwdoms to a plain unsigned long - introduce a static key "br_switchdev_fwd_offload_used" to minimize the impact of the newly introduced feature on all the setups which don't have hardware that can make use of it - introduce a check for nbp->flags & BR_FWD_OFFLOAD to optimize cache line access - reorder nbp_switchdev_frame_mark_accel() and br_handle_vlan() in __br_forward() - do not strip VLAN on egress if forwarding offload on VLAN-aware bridge is being used - propagate errors from .ndo_dfwd_add_station() if not EOPNOTSUPP v2->v3: - replace the solution based on .ndo_dfwd_add_station with a solution based on switchdev_bridge_port_offload - rename BR_FWD_OFFLOAD to BR_TX_FWD_OFFLOAD v3->v4: rebase v4->v5: - make sure the static key is decremented on bridge port unoffload - more function and variable renaming and comments for them: br_switchdev_fwd_offload_used to br_switchdev_tx_fwd_offload br_switchdev_accels_skb to br_switchdev_frame_uses_tx_fwd_offload nbp_switchdev_frame_mark_tx_fwd to nbp_switchdev_frame_mark_tx_fwd_to_hwdom nbp_switchdev_frame_mark_accel to nbp_switchdev_frame_mark_tx_fwd_offload fwd_accel to tx_fwd_offload Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> 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>
|
#
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 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>
|
#
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_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>
|
#
a99f030b |
|
14-Jul-2021 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
net: switchdev: Simplify 'mlxsw_sp_mc_write_mdb_entry()' Use 'bitmap_alloc()/bitmap_free()' instead of hand-writing it. This makes the code less verbose. Also, use 'bitmap_alloc()' instead of 'bitmap_zalloc()' because the bitmap is fully overridden by a 'bitmap_copy()' call just after its allocation. While at it, remove an extra and unneeded space. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c35b57ce |
|
10-Aug-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: switchdev: zero-initialize struct switchdev_notifier_fdb_info emitted by drivers towards the bridge The blamed commit added a new field to struct switchdev_notifier_fdb_info, but did not make sure that all call paths set it to something valid. For example, a switchdev driver may emit a SWITCHDEV_FDB_ADD_TO_BRIDGE notifier, and since the 'is_local' flag is not set, it contains junk from the stack, so the bridge might interpret those notifications as being for local FDB entries when that was not intended. To avoid that now and in the future, zero-initialize all switchdev_notifier_fdb_info structures created by drivers such that all newly added fields to not need to touch drivers again. Fixes: 2c4eca3ef716 ("net: bridge: switchdev: include local flag in FDB notifications") Reported-by: Ido Schimmel <idosch@idosch.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Tested-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Karsten Graul <kgraul@linux.ibm.com> Link: https://lore.kernel.org/r/20210810115024.1629983-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
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 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>
|
#
837ec05c |
|
17-May-2021 |
Danielle Ratson <danieller@nvidia.com> |
mlxsw: Verify the accessed index doesn't exceed the array length There are few cases in which an array index queried from a fw register, is accessed without any validation that it doesn't exceed the array length. Add a proper length validation, so accessing memory past the end of an array will be forbidden. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
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 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>
|
#
bf677bd2 |
|
16-Mar-2021 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Allow 802.1d and .1ad VxLAN bridges to coexist on Spectrum>=2 Currently only one EtherType can be configured for pushing in tunnels because EtherType is configured using SPVID.et_vlan for tunnel port. This behavior is forbidden by comparing mlxsw_sp_nve_config struct for each new tunnel, the struct contains 'ethertype' field which means that only one EtherType is legal at any given time. Remove 'ethertype' field to allow creating VxLAN devices with different bridges. To allow using several types of VxLAN bridges at the same time, the EtherType should be determined at the egress port. This behavior is achieved by setting SPVID to decide which EtherType to push at egress and for each local_port which is member in 802.1ad bridge, set SPEVET.et_vlan to ether_type1 (i.e., 0x88A8). Use switchdev_ops->init() to set different mlxsw_sp_bridge_ops for different ASICs in order to be able to split the behavior when port joins / leaves an 802.1ad bridge in different ASICs. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0f74fa56 |
|
16-Mar-2021 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Add struct mlxsw_sp_switchdev_ops per ASIC A subsequent patch will need to implement different set of operations when a port joins / leaves an 802.1ad bridge, based on the ASIC type. Prepare for this change by allowing to initialize the bridge module based on the ASIC type via 'struct mlxsw_sp_switchdev_ops'. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
e18f4c18 |
|
12-Feb-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: switchdev: pass flags and mask to both {PRE_,}BRIDGE_FLAGS attributes This switchdev attribute offers a counterproductive API for a driver writer, because although br_switchdev_set_port_flag gets passed a "flags" and a "mask", those are passed piecemeal to the driver, so while the PRE_BRIDGE_FLAGS listener knows what changed because it has the "mask", the BRIDGE_FLAGS listener doesn't, because it only has the final value. But certain drivers can offload only certain combinations of settings, like for example they cannot change unicast flooding independently of multicast flooding - they must be both on or both off. The way the information is passed to switchdev makes drivers not expressive enough, and unable to reject this request ahead of time, in the PRE_BRIDGE_FLAGS notifier, so they are forced to reject it during the deferred BRIDGE_FLAGS attribute, where the rejection is currently ignored. This patch also changes drivers to make use of the "mask" field for edge detection when possible. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4c08c586 |
|
12-Feb-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: switchdev: propagate extack to port attributes When a struct switchdev_attr is notified through switchdev, there is no way to report informational messages, unlike for struct switchdev_obj. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Nikolay Aleksandrov <nikolay@nvidia.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4b400fea |
|
08-Jan-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
mlxsw: spectrum_switchdev: remove transactional logic for VLAN objects As of commit 457e20d65924 ("mlxsw: spectrum_switchdev: Avoid returning errors in commit phase"), the mlxsw driver performs the VLAN object offloading during the prepare phase. So conversion just seems to be a matter of removing the code that was running in the commit phase. Ido Schimmel explains that the reason why mlxsw_sp_span_respin is called unconditionally is because the bridge driver will ignore -EOPNOTSUPP and actually add the VLAN on the bridge device - see commit 9c86ce2c1ae3 ("net: bridge: Notify about bridge VLANs") and commit ea4721751977 ("mlxsw: spectrum_switchdev: Ignore bridge VLAN events"). Since the VLAN was successfully added on the bridge device, mlxsw_sp_span_respin_work() should be able to resolve the egress port for a packet that is mirrored to a gre tap and passes through the bridge device. Therefore keep the logic as it is. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
bae33f2b |
|
08-Jan-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: switchdev: remove the transaction structure from port attributes Since the introduction of the switchdev API, port attributes were transmitted to drivers for offloading using a two-step transactional model, with a prepare phase that was supposed to catch all errors, and a commit phase that was supposed to never fail. Some classes of failures can never be avoided, like hardware access, or memory allocation. In the latter case, merely attempting to move the memory allocation to the preparation phase makes it impossible to avoid memory leaks, since commit 91cf8eceffc1 ("switchdev: Remove unused transaction item queue") which has removed the unused mechanism of passing on the allocated memory between one phase and another. It is time we admit that separating the preparation from the commit phase is something that is best left for the driver to decide, and not something that should be baked into the API, especially since there are no switchdev callers that depend on this. This patch removes the struct switchdev_trans member from switchdev port attribute notifier structures, and converts drivers to not look at this member. In part, this patch contains a revert of my previous commit 2e554a7a5d8a ("net: dsa: propagate switchdev vlan_filtering prepare phase to drivers"). For the most part, the conversion was trivial except for: - Rocker's world implementation based on Broadcom OF-DPA had an odd implementation of ofdpa_port_attr_bridge_flags_set. The conversion was done mechanically, by pasting the implementation twice, then only keeping the code that would get executed during prepare phase on top, then only keeping the code that gets executed during the commit phase on bottom, then simplifying the resulting code until this was obtained. - DSA's offloading of STP state, bridge flags, VLAN filtering and multicast router could be converted right away. But the ageing time could not, so a shim was introduced and this was left for a further commit. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek Reviewed-by: Linus Walleij <linus.walleij@linaro.org> # RTL8366RB Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
ffb68fc5 |
|
08-Jan-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: switchdev: remove the transaction structure from port object notifiers Since the introduction of the switchdev API, port objects were transmitted to drivers for offloading using a two-step transactional model, with a prepare phase that was supposed to catch all errors, and a commit phase that was supposed to never fail. Some classes of failures can never be avoided, like hardware access, or memory allocation. In the latter case, merely attempting to move the memory allocation to the preparation phase makes it impossible to avoid memory leaks, since commit 91cf8eceffc1 ("switchdev: Remove unused transaction item queue") which has removed the unused mechanism of passing on the allocated memory between one phase and another. It is time we admit that separating the preparation from the commit phase is something that is best left for the driver to decide, and not something that should be baked into the API, especially since there are no switchdev callers that depend on this. This patch removes the struct switchdev_trans member from switchdev port object notifier structures, and converts drivers to not look at this member. Where driver conversion is trivial (like in the case of the Marvell Prestera driver, NXP DPAA2 switch, TI CPSW, and Rocker drivers), it is done in this patch. Where driver conversion needs more attention (DSA, Mellanox Spectrum), the conversion is left for subsequent patches and here we only fake the prepare/commit phases at a lower level, just not in the switchdev notifier itself. Where the code has a natural structure that is best left alone as a preparation and a commit phase (as in the case of the Ocelot switch), that structure is left in place, just made to not depend upon the switchdev transactional model. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
b7a9e0da |
|
08-Jan-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: switchdev: remove vid_begin -> vid_end range from VLAN objects The call path of a switchdev VLAN addition to the bridge looks something like this today: nbp_vlan_init | __br_vlan_set_default_pvid | | | | | br_afspec | | | | | | | v | | | br_process_vlan_info | | | | | | | v | | | br_vlan_info | | | / \ / | | / \ / | | / \ / | | / \ / v v v v v nbp_vlan_add br_vlan_add ------+ | ^ ^ | | | / | | | | / / / | \ br_vlan_get_master/ / v \ ^ / / br_vlan_add_existing \ | / / | \ | / / / \ | / / / \ | / / / \ | / / / v | | v / __vlan_add / / | / / | / v | / __vlan_vid_add | / \ | / v v v br_switchdev_port_vlan_add The ranges UAPI was introduced to the bridge in commit bdced7ef7838 ("bridge: support for multiple vlans and vlan ranges in setlink and dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec) have always been passed one by one, through struct bridge_vlan_info tmp_vinfo, to br_vlan_info. So the range never went too far in depth. Then Scott Feldman introduced the switchdev_port_bridge_setlink function in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink"). That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made full use of the range. But switchdev_port_bridge_setlink was called like this: br_setlink -> br_afspec -> switchdev_port_bridge_setlink Basically, the switchdev and the bridge code were not tightly integrated. Then commit 41c498b9359e ("bridge: restore br_setlink back to original") came, and switchdev drivers were required to implement .ndo_bridge_setlink = switchdev_port_bridge_setlink for a while. In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op first in __vlan_vid_add/del") finally made switchdev penetrate the br_vlan_info() barrier and start to develop the call path we have today. But remember, br_vlan_info() still receives VLANs one by one. Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit 29ab586c3d83 ("net: switchdev: Remove bridge bypass support from switchdev") so that drivers would not implement .ndo_bridge_setlink any longer. The switchdev_port_bridge_setlink also got deleted. This refactoring removed the parallel bridge_setlink implementation from switchdev, and left the only switchdev VLAN objects to be the ones offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add (the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about bridge VLANs")). That is to say, today the switchdev VLAN object ranges are not used in the kernel. Refactoring the above call path is a bit complicated, when the bridge VLAN call path is already a bit complicated. Let's go off and finish the job of commit 29ab586c3d83 by deleting the bogus iteration through the VLAN ranges from the drivers. Some aspects of this feature never made too much sense in the first place. For example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID flag supposed to mean, when a port can obviously have a single pvid? This particular configuration _is_ denied as of commit 6623c60dc28e ("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API perspective, the driver still has to play pretend, and only offload the vlan->vid_end as pvid. And the addition of a switchdev VLAN object can modify the flags of another, completely unrelated, switchdev VLAN object! (a VLAN that is PVID will invalidate the PVID flag from whatever other VLAN had previously been offloaded with switchdev and had that flag. Yet switchdev never notifies about that change, drivers are supposed to guess). Nonetheless, having a VLAN range in the API makes error handling look scarier than it really is - unwinding on errors and all of that. When in reality, no one really calls this API with more than one VLAN. It is all unnecessary complexity. And despite appearing pretentious (two-phase transactional model and all), the switchdev API is really sloppy because the VLAN addition and removal operations are not paired with one another (you can add a VLAN 100 times and delete it just once). The bridge notifies through switchdev of a VLAN addition not only when the flags of an existing VLAN change, but also when nothing changes. There are switchdev drivers out there who don't like adding a VLAN that has already been added, and those checks don't really belong at driver level. But the fact that the API contains ranges is yet another factor that prevents this from being addressed in the future. Of the existing switchdev pieces of hardware, it appears that only Mellanox Spectrum supports offloading more than one VLAN at a time, through mlxsw_sp_port_vlan_set. I have kept that code internal to the driver, because there is some more bookkeeping that makes use of it, but I deleted it from the switchdev API. But since the switchdev support for ranges has already been de facto deleted by a Mellanox employee and nobody noticed for 4 years, I'm going to assume it's not a biggie. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
745f73de |
|
08-Dec-2020 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Allow joining VxLAN to 802.1ad bridge The previous patches added support for VxLAN device enslaved to 802.1ad bridge in Spectrum-2 ASIC and vetoed it in Spectrum-1. Do not veto VxLAN with 802.1ad bridge. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
7e9c72a5 |
|
08-Dec-2020 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Use ops->vxlan_join() when adding VLAN to VxLAN device Currently mlxsw_sp_switchdev_vxlan_vlan_add() always calls mlxsw_sp_bridge_8021q_vxlan_join() because VLANs were only ever added to a VLAN-filtering bridge, which is only 802.1q bridge. This set adds support for VxLAN with 802.1ad bridge, so VLAN-filtering bridge is not only 802.1q. Call ops->vxlan_join(), so mlxsw_sp_bridge_802{1q, 1ad}_vxlan_join() will be called according to bridge type. This is needed to ensure that VxLAN with 802.1ad bridge will be vetoed in Spectrum-1 with the next patch. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0913a24b |
|
08-Dec-2020 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Save EtherType as part of mlxsw_sp_nve_params Add EtherType field to mlxsw_sp_nve_params struct. Set it when VxLAN device is added to bridge device. This field is needed to configure which EtherType will be used when VLAN is pushed at ingress of the tunnel port. Use ETH_P_8021Q for tunnel port enslaved to 802.1d and 802.1q bridges. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
e2c777d7 |
|
08-Dec-2020 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Create common function for joining VxLAN to VLAN-aware bridge The code in mlxsw_sp_bridge_8021q_vxlan_join() can be used also for 802.1ad bridge. Move the code to function called mlxsw_sp_bridge_vlan_aware_vxlan_join() and call it from mlxsw_sp_bridge_8021q_vxlan_join() to enable code reuse. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
09139f67 |
|
29-Nov-2020 |
Danielle Ratson <danieller@nvidia.com> |
mlxsw: Add QinQ configuration vetoes After adding support for QinQ, a.k.a 802.1ad protocol, there are a few scenarios that should be vetoed. The vetoes are motivated by various ASIC limitations. For example, a port that is member in a 802.1ad bridge cannot have 802.1q uppers as the port needs to be configured to treat 802.1q packets as untagged packets. Veto all those unsupported scenarios and return suitable messages. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
80dfeafd |
|
29-Nov-2020 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Add support of QinQ traffic 802.1ad, also known as QinQ is an extension to the 802.1q standard, which is concerned with passing possibly 802.1q-tagged packets through another VLAN-like tunnel. The format of 802.1ad tag is the same as 802.1q, except it uses the EtherType of 0x88a8, unlike 802.1q's 0x8100. Add support for 802.1ad protocol. Most of the configuration is the same as 802.1q. The difference is that before a port joins an 802.1ad bridge it needs to be configured to recognize 802.1ad packets as tagged and other packets (e.g., 802.1q) as untagged. VXLAN is not currently supported with 802.1ad bridge, so return an error with an appropriate extack message. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
773ce33a |
|
29-Nov-2020 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: spectrum_switchdev: Create common functions for VLAN-aware bridge The code in mlxsw_sp_bridge_8021q_port_{join, leave}() can be used also for 802.1ad bridge. Move the code to functions called mlxsw_sp_bridge_vlan_aware_port_{join, leave}() and call them from mlxsw_sp_bridge_8021q_port_{join, leave}() respectively to enable code reuse. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
3ae7a65b |
|
29-Nov-2020 |
Amit Cohen <amcohen@nvidia.com> |
mlxsw: Make EtherType configurable when pushing VLAN at ingress Currently, when pushing a PVID at ingress, mlxsw always uses 802.1q EtherType. Make this EtherType configurable by extending mlxsw_sp_port_pvid_set() with an EtherType argument. This is a preparation for QinQ support, that needs to push a PVID with 802.1ad EtherType. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
eff74233 |
|
25-Sep-2020 |
Taehee Yoo <ap420073@gmail.com> |
net: core: introduce struct netdev_nested_priv for nested interface infrastructure Functions related to nested interface infrastructure such as netdev_walk_all_{ upper | lower }_dev() pass both private functions and "data" pointer to handle their own things. At this point, the data pointer type is void *. In order to make it easier to expand common variables and functions, this new netdev_nested_priv structure is added. In the following patch, a new member variable will be added into this struct to fix the lockdep issue. Signed-off-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
df561f66 |
|
23-Aug-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
|
#
648e53ca |
|
26-Feb-2020 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: spectrum_switchdev: Optimize SFN records processing Currently, only one SFN query is done from repetitive work at a time, processing 64 entries. Another work iteration is scheduled in 100ms, that means that the max rate of learned FDB entries is limited to 6400/s. That is slow. Fix this by doing 2 optimizations: 1) Run 10 SFN queries at a time. 2) In case the SFN is not drained, schedule work with 0 delay to allow to continue processing rest of the records. On a testing setup with 500K entries the time to process decreased from 870secs to 10secs. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Tested-by: Alex Kushnarov <alexanderk@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
5e9a664d |
|
20-Feb-2020 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Prevent RIF access outside of routing code There are currently 5 users of mlxsw_sp_rif_find_by_dev() outside of the routing code. Only one call site actually needs to dereference the router interface (RIF). The rest merely need to know if a RIF exists for the provided netdev. Convert this call site to query the needed information directly from the routing code instead of dereferencing the RIF. This will later allow us to replace mlxsw_sp_rif_find_by_dev() with a function that checks if a RIF exist. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
622110f2 |
|
20-Feb-2020 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Convert callers to use new mirroring API Previous patch added a work item in the mirroring code that will take care of updating the active mirroring agents in response to different events. Change the mirroring agents update function - mlxsw_sp_span_respin() - to invoke this work item when called. Therefore there is no need for callers to schedule a work item themselves. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
da1f9f8c |
|
17-Feb-2020 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Reduce dependency between bridge and router code Commit f40be47a3e40 ("mlxsw: spectrum_router: Do not force specific configuration order") added a call from the routing code to the bridge code in order to handle the case where VNI should be set on a FID following the joining of the router port to the FID. This is no longer required, as previous patches made VXLAN devices explicitly take a reference on the FID and set VNI on it. Therefore, remove the unnecessary call and simply have the RIF take a reference on the FID without checking if VNI should also be set on it. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
578e5512 |
|
17-Feb-2020 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Remove VXLAN checks during FID membership As explained in previous patch, VXLAN devices now take a reference on the FID and not only local ports. Therefore, there is no need for local ports to check if they need to set a VNI on the FID when they join the FID. Remove these unnecessary checks. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
71afb45a |
|
17-Feb-2020 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Have VXLAN device take reference on FID Up until now only local ports and the router port (which is also a local port) took a reference on the corresponding FID (Filtering Identifier) when joining a bridge. For example: 192.0.2.1/24 br0 | +------+------+ | | swp1 vxlan0 In this case the reference count of the FID will be '2'. Since the VXLAN device does not take a reference on the FID, whenever a local port joins the bridge it needs to check if a VXLAN device is already enslaved. If the VXLAN device should be mapped to the FID in question, then the VXLAN device's VNI is set on the FID. Beside the fact that this scheme special-cases the VXLAN device, it also creates an unnecessary dependency between the routing and bridge code: 1. [R] IP address is added on 'br0', which prompts the creation of a RIF and a backing FID 2. [B] VNI is enabled on backing FID 3. [R] Host route corresponding to VXLAN device's source address is promoted to perform NVE decapsulation [R] - Routing code [B] - Bridge code This back and forth dependency will become problematic when a lock is added in the routing code instead of relying on RTNL, as it will result in an AA deadlock. Instead, have the VXLAN device take a reference on the FID just like all the other netdev members of the bridge. In order to correctly handle the case where VXLAN devices are already enslaved to the bridge when it is offloaded, walk the bridge's slaves and replay the configuration. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
23a1a0b3 |
|
17-Feb-2020 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Propagate extack to bridge creation function Propagate extack to bridge creation function so that error messages could be passed to user space via netlink instead of printing them to kernel log. A subsequent patch will pass the new extack argument to more functions. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
053e92aa |
|
03-Oct-2019 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: spectrum: Take devlink net instead of init_net Follow-up patch is going to allow to reload devlink instance into different network namespace, so use devlink_net() helper instead of init_net. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
577fa14d |
|
17-Jul-2019 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Do not process learned records with a dummy FID The switch periodically sends notifications about learned FDB entries. Among other things, the notification includes the FID (Filtering Identifier) and the port on which the MAC was learned. In case the driver does not have the FID defined on the relevant port, the following error will be periodically generated: mlxsw_spectrum2 0000:06:00.0 swp32: Failed to find a matching {Port, VID} following FDB notification This is not supposed to happen under normal conditions, but can happen if an ingress tc filter with a redirect action is installed on a bridged port. The redirect action will cause the packet's FID to be changed to the dummy FID and a learning notification will be emitted with this FID - which is not defined on the bridged port. Fix this by having the driver ignore learning notifications generated with the dummy FID and delete them from the device. Another option is to chain an ignore action after the redirect action which will cause the device to disable learning, but this means that we need to consume another action whenever a redirect action is used. In addition, the scenario described above is merely a corner case. Fixes: cedbb8b25948 ("mlxsw: spectrum_flower: Set dummy FID before forward action") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reported-by: Alex Kushnarov <alexanderk@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Tested-by: Alex Kushnarov <alexanderk@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d4d0e409 |
|
10-Apr-2019 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Add MDB entries in prepare phase The driver cannot guarantee in the prepare phase that it will be able to write an MDB entry to the device. In case the driver returned success during the prepare phase, but then failed to add the entry in the commit phase, a WARNING [1] will be generated by the switchdev core. Fix this by doing the work in the prepare phase instead. [1] [ 358.544486] swp12s0: Commit of object (id=2) failed. [ 358.550061] WARNING: CPU: 0 PID: 30 at net/switchdev/switchdev.c:281 switchdev_port_obj_add_now+0x9b/0xe0 [ 358.560754] CPU: 0 PID: 30 Comm: kworker/0:1 Not tainted 5.0.0-custom-13382-gf2449babf221 #1350 [ 358.570472] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016 [ 358.580582] Workqueue: events switchdev_deferred_process_work [ 358.587001] RIP: 0010:switchdev_port_obj_add_now+0x9b/0xe0 ... [ 358.614109] RSP: 0018:ffffa6b900d6fe18 EFLAGS: 00010286 [ 358.619943] RAX: 0000000000000000 RBX: ffff8b00797ff000 RCX: 0000000000000000 [ 358.627912] RDX: ffff8b00b7a1d4c0 RSI: ffff8b00b7a152e8 RDI: ffff8b00b7a152e8 [ 358.635881] RBP: ffff8b005c3f5bc0 R08: 000000000000022b R09: 0000000000000000 [ 358.643850] R10: 0000000000000000 R11: ffffa6b900d6fcc8 R12: 0000000000000000 [ 358.651819] R13: dead000000000100 R14: ffff8b00b65a23c0 R15: 0ffff8b00b7a2200 [ 358.659790] FS: 0000000000000000(0000) GS:ffff8b00b7a00000(0000) knlGS:0000000000000000 [ 358.668820] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 358.675228] CR2: 00007f00aad90de0 CR3: 00000001ca80d000 CR4: 00000000001006f0 [ 358.683188] Call Trace: [ 358.685918] switchdev_port_obj_add_deferred+0x13/0x60 [ 358.691655] switchdev_deferred_process+0x6b/0xf0 [ 358.696907] switchdev_deferred_process_work+0xa/0x10 [ 358.702548] process_one_work+0x1f5/0x3f0 [ 358.707022] worker_thread+0x28/0x3c0 [ 358.711099] ? process_one_work+0x3f0/0x3f0 [ 358.715768] kthread+0x10d/0x130 [ 358.719369] ? __kthread_create_on_node+0x180/0x180 [ 358.724815] ret_from_fork+0x35/0x40 Fixes: 3a49b4fde2a1 ("mlxsw: Adding layer 2 multicast support") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reported-by: Alex Kushnarov <alexanderk@mellanox.com> Tested-by: Alex Kushnarov <alexanderk@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3d705f07 |
|
27-Feb-2019 |
Florian Fainelli <f.fainelli@gmail.com> |
net: Remove switchdev_ops Now that we have converted all possible callers to using a switchdev notifier for attributes we do not have a need for implementing switchdev_ops anymore, and this can be removed from all drivers the net_device structure. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
7464251b |
|
27-Feb-2019 |
Florian Fainelli <f.fainelli@gmail.com> |
mlxsw: spectrum_switchdev: Handle SWITCHDEV_PORT_ATTR_SET Following patches will change the way we communicate setting a port's attribute and use a notifier to perform those tasks. Prepare mlxsw to support receiving notifier events targeting SWITCHDEV_PORT_ATTR_SET and utilize the switchdev_handle_port_attr_set() to handle stacking of devices. Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
010c8f01 |
|
20-Feb-2019 |
Florian Fainelli <f.fainelli@gmail.com> |
net: Get rid of switchdev_port_attr_get() With the bridge no longer calling switchdev_port_attr_get() to obtain the supported bridge port flags from a driver but instead trying to set the bridge port flags directly and relying on driver to reject unsupported configurations, we can effectively get rid of switchdev_port_attr_get() entirely since this was the only place where it was called. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
cc0c207a |
|
20-Feb-2019 |
Florian Fainelli <f.fainelli@gmail.com> |
net: Remove SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT Now that we have converted the bridge code and the drivers to check for bridge port(s) flags at the time we try to set them, there is no need for a get() -> set() sequence anymore and SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT therefore becomes unused. Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c19c44f8 |
|
20-Feb-2019 |
Florian Fainelli <f.fainelli@gmail.com> |
mlxsw: spectrum: Handle PORT_PRE_BRIDGE_FLAGS In preparation for getting rid of switchdev_port_attr_get(), have mlxsw check for the bridge flags being set through switchdev_port_attr_set() when the SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS attribute identifier is used. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0f56623d |
|
12-Feb-2019 |
Florian Fainelli <f.fainelli@gmail.com> |
mlxsw: spectrum_switchdev: Remove unused variables After 1ecb195753a1 ("mlxsw: spectrum_switchdev: Remove getting PORT_BRIDGE_FLAGS") we are not accessing any driver private data structure, so the mlxsw_sp_port and mlxsw_sp variables are unused. Fixes: 1ecb195753a1 ("mlxsw: spectrum_switchdev: Remove getting PORT_BRIDGE_FLAGS") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1ecb1957 |
|
11-Feb-2019 |
Florian Fainelli <f.fainelli@gmail.com> |
mlxsw: spectrum_switchdev: Remove getting PORT_BRIDGE_FLAGS There is no code that will query the SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS attribute remove support for that. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
25ba8605 |
|
06-Feb-2019 |
Florian Fainelli <f.fainelli@gmail.com> |
mlxsw: Implement ndo_get_port_parent_id() mlxsw implements SWITCHDEV_ATTR_ID_PORT_PARENT_ID and we want to get rid of switchdev_ops eventually, ease that migration by implementing a ndo_get_port_parent_id() function which returns what switchdev_port_attr_get() would do. Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
2adeb5f1 |
|
27-Jan-2019 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Add more extack messages Add more extack messages that let the user know why VXLAN offload failed. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Suggested-by: David Ahern <dsahern@gmail.com> Cc: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
64254a20 |
|
18-Jan-2019 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Do not treat static FDB entries as sticky The driver currently treats static FDB entries as both static and sticky. This is incorrect and prevents such entries from being roamed to a different port via learning. Fix this by configuring static entries with ageing disabled and roaming enabled. In net-next we can add proper support for the newly introduced 'sticky' flag. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reported-by: Alexander Petrovskiy <alexpe@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
a40313d9 |
|
16-Jan-2019 |
Petr Machata <petrm@mellanox.com> |
mlxsw: spectrum: Add extack messages to VXLAN FDB rejection Annotate the rejections in mlxsw_sp_switchdev_vxlan_work_prepare() with textual reasons. Because this code ends up being invoked for FDB replay as well, drop the default message from there, so that the more accurate error message is not overwritten. Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
6685987c |
|
16-Jan-2019 |
Petr Machata <petrm@mellanox.com> |
switchdev: Add extack argument to call_switchdev_notifiers() A follow-up patch will enable vetoing of FDB entries. Make it possible to communicate details of why an FDB entry is not acceptable back to the user. Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
674bed5d |
|
08-Jan-2019 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Set PVID correctly during VLAN deletion When a VLAN is deleted from a bridge port we should not change the PVID unless the deleted VLAN is the PVID. Fixes: fe9ccc785de5 ("mlxsw: spectrum_switchdev: Don't batch VLAN operations") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
457e20d6 |
|
08-Jan-2019 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Avoid returning errors in commit phase Drivers are not supposed to return errors in switchdev commit phase if they returned OK in prepare phase. Otherwise, a WARNING is emitted. However, when the offloading of a VXLAN tunnel is triggered by the addition of a VLAN on a local port, it is not possible to guarantee that the commit phase will succeed without doing a lot of work. In these cases, the artificial division between prepare and commit phase does not make sense, so simply do the work in the prepare phase. Fixes: d70e42b22dd4 ("mlxsw: spectrum: Enable VxLAN enslavement to VLAN-aware bridges") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0417d25e |
|
20-Dec-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Switch to VID 4095 as default VID There is no need to abuse VID 1 anymore and we can instead use VID 4095 as the default VLAN, which will be configured on the port throughout its lifetime. The OVS join / leave functions are changed to enable VIDs 1-4094 (inclusive) instead of 2-4095. This because VID 4095 is now the default VLAN instead of 1. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
a2d2a205 |
|
20-Dec-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Replace hard-coded default VID with a define Subsequent patches are going to replace the current default VID (1) with VLAN_N_VID - 1 (4095). Prepare for this conversion by replacing the hard-coded '1' with a define. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f40be47a |
|
20-Dec-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_router: Do not force specific configuration order In symmetric routing, the only two members in the VLAN corresponding to the L3 VNI are the router port and the VXLAN tunnel. In case the VXLAN device is already enslaved to the bridge and only later the VLAN interface is configured, the tunnel will not be offloaded. The reason for this is that when the router interface (RIF) corresponding to the VLAN interface is configured, it calls the core fid_get() API which does not check if NVE should be enabled on the FID. Instead, call into the bridge code which will check if NVE should be enabled on the FID. This effectively means that the same code path is used to retrieve a FID when either a local port or a router port joins the FID. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
be2d6f42 |
|
18-Dec-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Properly cleanup LAG uppers when removing port from LAG When a LAG device or a VLAN device on top of it is enslaved to a bridge, the driver propagates the CHANGEUPPER event to the LAG's slaves. This causes each physical port to increase the reference count of the internal representation of the bridge port by calling mlxsw_sp_port_bridge_join(). However, when a port is removed from a LAG, the corresponding leave() function is not called and the reference count is not decremented. This leads to ugly hacks such as mlxsw_sp_bridge_port_should_destroy() that try to understand if the bridge port should be destroyed even when its reference count is not 0. Instead, make sure that when a port is unlinked from a LAG it would see the same events as if the LAG (or its uppers) were unlinked from a bridge. The above is achieved by walking the LAG's uppers when a port is unlinked and calling mlxsw_sp_port_bridge_leave() for each upper that is enslaved to a bridge. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
635c8c8b |
|
18-Dec-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Remove reference count from VLAN entries Commit b3529af6bb0d ("spectrum: Reference count VLAN entries") started reference counting port-VLAN entries in a similar fashion to the 8021q driver. However, this is not actually needed and only complicates things. Instead, the driver should forbid the creation of a VLAN on a port if this VLAN already exists. This would also solve the issue fixed by the mentioned commit. Therefore, remove the get()/put() API and use create()/destroy() instead. One place that needs special attention is VLAN addition in a VLAN-aware bridge via switchdev operations. In case the VLAN flags (e.g., 'pvid') are toggled, then the VLAN entry already exists. To prevent the driver from wrongly returning EEXIST, the driver is changed to check in the prepare phase whether the entry already exists and only returns an error in case it is not associated with the correct bridge port. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
7357eb3d |
|
12-Dec-2018 |
Petr Machata <petrm@mellanox.com> |
mlxsw: spectrum_switchdev: Propagate extack on port VLAN events After switchdev_handle_port_obj_add() was extended in a preceding patch, mlxsw_sp_port_obj_add() now takes an extack argument. Propagate it further by extending a callee chain from mlxsw_sp_port_vlans_add(), via mlxsw_sp_bridge_port_vlan_add() via mlxsw_sp_port_vlan_bridge_join() via mlxsw_sp_port_vlan_fid_join() to mlxsw_sp_bridge_ops.fid_get, adding an extack argument for each of them. This code path is used when a VLAN is added to a port netdevice if there already is an unoffloadable VXLAN device with that VLAN mapped. mlxsw_sp_bridge_8021d_port_join() is updated to obey the new interfaces changed by the abovementioned code, propagating extack ultimately from NETDEV_CHANGEUPPER events. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0a5a2aee |
|
12-Dec-2018 |
Petr Machata <petrm@mellanox.com> |
mlxsw: spectrum_switchdev: Propagate extack on VXLAN VLAN events Now that VLAN port object addition notifications carry an extack, propagate it from mlxsw_sp_switchdev_vxlan_vlans_add() through mlxsw_sp_switchdev_vxlan_vlan_add() to mlxsw_sp_bridge_8021q_vxlan_join(). This code path is used when a VLAN is added to a VXLAN netdevice that cannot be offloaded. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
69213513 |
|
12-Dec-2018 |
Petr Machata <petrm@mellanox.com> |
net: switchdev: Add extack to switchdev_handle_port_obj_add() callback Drivers use switchdev_handle_port_obj_add() to handle recursive descent through lower devices. Change this function prototype to take add_cb that itself takes an extack argument. Decode extack from switchdev_notifier_port_obj_info and pass it to add_cb. Update mlxsw and ocelot drivers which use this helper. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
34139ede |
|
07-Dec-2018 |
Petr Machata <petrm@mellanox.com> |
mlxsw: spectrum_switchdev: Publish mlxsw_sp_switchdev_notifier The notifier block will need to be passed to vxlan_fdb_replay() in a follow-up patch. Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
993107fe |
|
06-Dec-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Fix VLAN device deletion via ioctl When deleting a VLAN device using an ioctl the netdev is unregistered before the VLAN filter is updated via ndo_vlan_rx_kill_vid(). It can lead to a use-after-free in mlxsw in case the VLAN device is deleted while being enslaved to a bridge. The reason for the above is that when mlxsw receives the CHANGEUPPER event, it wrongly assumes that the VLAN device is no longer its upper and thus destroys the internal representation of the bridge port despite the reference count being non-zero. Fix this by checking if the VLAN device is our upper using its real device. In net-next I'm going to remove this trick and instead make mlxsw completely agnostic to the order of the events. Fixes: c57529e1d5d8 ("mlxsw: spectrum: Replace vPorts with Port-VLAN") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f58a83c2 |
|
06-Dec-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Avoid leaking FID's reference count It should never be possible for a user to set a VNI on a FID in case one is already set. The driver therefore returns an error, but fails to drop the reference count taken earlier when calling mlxsw_sp_fid_8021d_lookup(). Drop the reference when this unlikely error is hit. Fixes: 1c30d1836aeb ("mlxsw: spectrum: Enable VxLAN enslavement to bridges") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d70e42b2 |
|
28-Nov-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Enable VxLAN enslavement to VLAN-aware bridges Commit 1c30d1836aeb ("mlxsw: spectrum: Enable VxLAN enslavement to bridges") enabled the enslavement of VxLAN devices to bridges that have mlxsw ports (or their upper) as slaves. This patch extends mlxsw to also support VLAN-aware bridges. The patch is similar in nature to mentioned commit, but there is one major difference. With VLAN-aware bridges, the VxLAN device's VNI is mapped to the VLAN that is configured as PVID and egress untagged on the bridge port. Therefore, the driver is extended to listen to VLAN configuration on VxLAN devices of interest and enable / disable NVE encapsulation on the corresponding 802.1Q FIDs. To prevent ambiguity, the driver makes sure that a given VLAN is not configured as PVID and egress untagged on multiple VxLAN devices. This sanitization takes place both when a port is enslaved to a bridge with existing VxLAN devices and when a VLAN is added to / removed from a VxLAN device of interest. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
48fde466 |
|
28-Nov-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Prepare function for VLAN-aware bridges The vxlan_join() function resolves the FID on which the VNI should be set and then sets the VNI. Currently, the FID is simply resolved according to the ifindex of the bridge device to which the VxLAN device is enslaved. This works because only VLAN-unaware bridges are supported. With VLAN-aware bridges the FID would need to be resolved based on the VLAN to which the VNI is mapped to. Add the VLAN ID to the argument list of the function. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b03fa9e7 |
|
28-Nov-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Unify VxLAN leave function The function mlxsw_sp_bridge_vxlan_leave() is currently split between VLAN-aware and VLAN-unaware bridges, but actually both types can use the same function. The function needs to resolve the FID that corresponds to the VxLAN device and disable NVE encapsulation on it. Instead of looking up the FID differently for VLAN-aware and VLAN-unaware bridges, we can always use the VxLAN's device VNI. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
5a8fb370 |
|
28-Nov-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_fid: Add API to lookup 802.1Q FIDs without creating them In a similar fashion to commit 564c6d727aca ("mlxsw: spectrum_fid: Add APIs to lookup FID without creating it"), add a corresponding API to lookup 802.1Q FIDs. This is a prerequisite to VxLAN support with VLAN-aware bridges and will allow us to resolve a 802.1Q FID by its VLAN when an FDB entry is added on the bridge port of the VxLAN device. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
6502be9f |
|
25-Nov-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Do not set field when it is reserved When configuring an FDB entry pointing to a LAG netdev (or its upper), the driver should only set the 'lag_vid' field when the FID (filtering identifier) is of 802.1D type. Extend the 802.1D FID family with an attribute indicating whether this field should be set and based on its value set the field or leave it blank. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d17d9f5e |
|
22-Nov-2018 |
Petr Machata <petrm@mellanox.com> |
switchdev: Replace port obj add/del SDO with a notification Drop switchdev_ops.switchdev_port_obj_add and _del. Drop the uses of this field from all clients, which were migrated to use switchdev notification in the previous patches. Add a new function switchdev_port_obj_notify() that sends the switchdev notifications SWITCHDEV_PORT_OBJ_ADD and _DEL. Update switchdev_port_obj_del_now() to dispatch to this new function. Drop __switchdev_port_obj_add() and update switchdev_port_obj_add() likewise. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
52a227b3 |
|
22-Nov-2018 |
Petr Machata <petrm@mellanox.com> |
mlxsw: spectrum_switchdev: Handle SWITCHDEV_PORT_OBJ_ADD/_DEL Following patches will change the way of distributing port object changes from a switchdev operation to a switchdev notifier. The switchdev code currently recursively descends through layers of lower devices, eventually calling the op on a front-panel port device. The notifier will instead be sent referencing the bridge port device, which may be a stacking device that's one of front-panel ports uppers, or a completely unrelated device. To handle SWITCHDEV_PORT_OBJ_ADD and _DEL, subscribe to the blocking notifier chain. Dispatch to mlxsw_sp_port_obj_add() resp. _del() to maintain the behavior that the switchdev operation based code currently has. Defer to switchdev_handle_port_obj_add() / _del() to handle the recursive descend, because mlxsw supports a number of upper types. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8b547a60 |
|
21-Nov-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Allow deletion of learned FDB entries Allow users to delete learned FDB entries from the bridge's FDB before enabling VxLAN learning. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
981f084b |
|
21-Nov-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Process learned VxLAN FDB entries Start processing two new entry types in addition to current ones: * Learned unicast tunnel entry * Aged-out unicast tunnel entry In both cases the device reports on a new {MAC, FID, IP address} tuple that was learned / aged-out. Based on this notification, the driver instructs the device to add / delete the entry to / from its database. The driver also makes sure to notify the bridge and VxLAN drivers about the new entry. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ad0b9d94 |
|
29-Oct-2018 |
Petr Machata <petrm@mellanox.com> |
mlxsw: spectrum_switchdev: Don't ignore deletions of learned MACs Demands to remove FDB entries should be honored even if the FDB entry in question was originally learned, and not added by the user. Therefore ignore the added_by_user datum for SWITCHDEV_FDB_DEL_TO_DEVICE. Fixes: 816a3bed9549 ("switchdev: Add fdb.added_by_user to switchdev notifications") Signed-off-by: Petr Machata <petrm@mellanox.com> Suggested-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1231e04f |
|
17-Oct-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Add support for VxLAN encapsulation In the device, VxLAN encapsulation takes place in the FDB table where certain {MAC, FID} entries are programmed with an underlay unicast IP. MAC addresses that are not programmed in the FDB are flooded to the relevant local ports and also to a list of underlay unicast IPs that are programmed using the all zeros MAC address in the VxLAN driver. One difference between the hardware and software data paths is the fact that in the software data path there are two FDB lookups prior to the encapsulation of the packet. First in the bridge's FDB table using {MAC, VID} and another in the VxLAN's FDB table using {MAC, VNI}. Therefore, when a new VxLAN FDB entry is notified, it is only programmed to the device if there is a corresponding entry in the bridge's FDB table. Similarly, when a new bridge FDB entry pointing to the VxLAN device is notified, it is only programmed to the device if there is a corresponding entry in the VxLAN's FDB table. Note that the above scheme will result in a discrepancy between both data paths if only one FDB table is populated in the software data path. For example, if only the bridge's FDB is populated with an entry pointing to a VxLAN device, then a packet hitting the entry will only be flooded by the kernel to remote VTEPs whereas the device will also flood the packets to other local ports member in the VLAN. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1c30d183 |
|
17-Oct-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Enable VxLAN enslavement to bridges Enslavement of VxLAN devices to offloaded bridges was never forbidden by mlxsw, but this patch makes sure the required configuration is performed in order to allow VxLAN encapsulation and decapsulation to take place in the device. The patch handles both the case where a VxLAN device is enslaved to an already offloaded bridge and the case where the first mlxsw port is enslaved to a bridge that already has VxLAN device configured. Invalid configurations are sanitized and an error string is returned via extack. Since encapsulation and decapsulation do not occur when the VxLAN device is down, the driver makes sure to enable / disable these functionalities based on NETDEV_PRE_UP and NETDEV_DOWN events. Note that NETDEV_PRE_UP is used in favor of NETDEV_UP, as the former allows to veto the operation, if necessary. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
e9ba0fbc |
|
17-Oct-2018 |
Ido Schimmel <idosch@mellanox.com> |
bridge: switchdev: Allow clearing FDB entry offload indication Currently, an FDB entry only ceases being offloaded when it is deleted. This changes with VxLAN encapsulation. Devices capable of performing VxLAN encapsulation usually have only one FDB table, unlike the software data path which has two - one in the bridge driver and another in the VxLAN driver. Therefore, bridge FDB entries pointing to a VxLAN device are only offloaded if there is a corresponding entry in the VxLAN FDB. Allow clearing the offload indication in case the corresponding entry was deleted from the VxLAN FDB. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9c73b1d1 |
|
11-Oct-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Do not assume notifier information type VxLAN notifications are going to use a different notifier information type, so cast to the correct type based on the received event. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
5050f6ae |
|
11-Oct-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Check notification relevance based on upper device VxLAN FDB updates are sent with the VxLAN device which is not our upper and will therefore be ignored by current code. Solve this by checking whether the upper device (bridge) is our upper. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ab74c3a1 |
|
11-Oct-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Prepare for VxLAN FDB notifications VxLAN FDB notifications need to be handled differently than bridge FDB notifications, so initialize the work item based on the received notification and rename the invoked function accordingly. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
bf341eb8 |
|
11-Oct-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Remove misuses of private header file The spectrum_router.h header file is private to the router block and should only be included by direct consumers of it, such as dpipe and the multicast routing code. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
602b74ed |
|
24-Aug-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Do not leak RIFs when removing bridge When a bridge device is removed, the VLANs are flushed from each configured port. This causes the ports to decrement the reference count on the associated FIDs (filtering identifier). If the reference count of a FID is 1 and it has a RIF (router interface), then this RIF is destroyed. However, if no port is member in the VLAN for which a RIF exists, then the RIF will continue to exist after the removal of the bridge. To reproduce: # ip link add name br0 type bridge vlan_filtering 1 # ip link set dev swp1 master br0 # ip link add link br0 name br0.10 type vlan id 10 # ip address add 192.0.2.0/24 dev br0.10 # ip link del dev br0 The RIF associated with br0.10 continues to exist. Fix this by iterating over all the bridge device uppers when it is destroyed and take care of destroying their RIFs. Fixes: 99f44bb3527b ("mlxsw: spectrum: Enable L3 interfaces on top of bridge devices") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9948a064 |
|
09-Aug-2018 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: Replace license text with SPDX identifiers and adjust copyrights Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
567ad1a2 |
|
25-Jun-2018 |
Petr Machata <petrm@mellanox.com> |
mlxsw: spectrum_switchdev: Ban PVID change if bridge has a RIF When traffic passes through a router port, it needs to be assigned a FID for ASIC to forward correctly. For bridges, this FID used to be the one corresponding to VLAN 1. In a previous patch, this was changed to instead use the PVID at the time that the RIF is created. This patch guards PVID changes after the RIF was introduced. Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9e25826f |
|
15-Jun-2018 |
Petr Machata <petrm@mellanox.com> |
mlxsw: spectrum_switchdev: Fix port_vlan refcounting Switchdev notifications for addition of SWITCHDEV_OBJ_ID_PORT_VLAN are distributed not only on clean addition, but also when flags on an existing VLAN are changed. mlxsw_sp_bridge_port_vlan_add() calls mlxsw_sp_port_vlan_get() to get at the port_vlan in question, which implicitly references the object. This then leads to discrepancies in reference counting when the VLAN is removed. spectrum.c warns about the problem when the module is removed: [13578.493090] WARNING: CPU: 0 PID: 2454 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2973 mlxsw_sp_port_remove+0xfd/0x110 [mlxsw_spectrum] [...] [13578.627106] Call Trace: [13578.629617] mlxsw_sp_fini+0x2a/0xe0 [mlxsw_spectrum] [13578.634748] mlxsw_core_bus_device_unregister+0x3e/0x130 [mlxsw_core] [13578.641290] mlxsw_pci_remove+0x13/0x40 [mlxsw_pci] [13578.646238] pci_device_remove+0x31/0xb0 [13578.650244] device_release_driver_internal+0x14f/0x220 [13578.655562] driver_detach+0x32/0x70 [13578.659183] bus_remove_driver+0x47/0xa0 [13578.663134] pci_unregister_driver+0x1e/0x80 [13578.667486] mlxsw_sp_module_exit+0xc/0x3fa [mlxsw_spectrum] [13578.673207] __x64_sys_delete_module+0x13b/0x1e0 [13578.677888] ? exit_to_usermode_loop+0x78/0x80 [13578.682374] do_syscall_64+0x39/0xe0 [13578.685976] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix by putting the port_vlan when mlxsw_sp_port_vlan_bridge_join() determines it's a flag-only change. Fixes: b3529af6bb0d ("spectrum: Reference count VLAN entries") Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f07ff014 |
|
02-Jun-2018 |
Petr Machata <petrm@mellanox.com> |
mlxsw: spectrum_switchdev: Postpone respin on object deletion VLAN deletion notifications are emitted before the relevant change is projected to bridge configuration. Thus, like with VLAN addition, schedule SPAN respin for later. Fixes: c520bc698647 ("mlxsw: Respin SPAN on switchdev events") Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
7edcb8ec |
|
29-May-2018 |
Petr Machata <petrm@mellanox.com> |
mlxsw: spectrum_switchdev: Schedule respin during trans prepare Since there's no special support for the bridge events, the driver returns -EOPNOTSUPP, and thus the commit never happens. Therefore schedule respin during the prepare stage: there's no real difference one way or another. This fixes the problem that mirror-to-gretap offload wouldn't adapt to changes in bridge vlan configuration right away and another notification would have to arrive for mlxsw to catch up. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ea472175 |
|
29-May-2018 |
Petr Machata <petrm@mellanox.com> |
mlxsw: spectrum_switchdev: Ignore bridge VLAN events A follow-up patch enables emitting VLAN notifications for the bridge CPU port in addition to the existing slave port notifications. These notifications have orig_dev set to the bridge in question. Because there's no specific support for these VLANs, just ignore the notifications to maintain the current behavior. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
816a3bed |
|
03-May-2018 |
Petr Machata <petrm@mellanox.com> |
switchdev: Add fdb.added_by_user to switchdev notifications The following patch enables sending notifications also for events on FDB entries that weren't added by the user. Give the drivers the information necessary to distinguish between the two origins of FDB entries. To maintain the current behavior, have switchdev-implementing drivers bail out on notifications about non-user-added FDB entries. In case of mlxsw driver, allow a call to mlxsw_sp_span_respin() so that SPAN over bridge catches up with the changed FDB. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Acked-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c520bc69 |
|
29-Apr-2018 |
Petr Machata <petrm@mellanox.com> |
mlxsw: Respin SPAN on switchdev events Changes to switchdev artifact can make a SPAN entry offloadable or unoffloadable. To that end: - Listen to SWITCHDEV_FDB_*_TO_BRIDGE notifications in addition to the *_TO_DEVICE ones, to catch whatever activity is sent to the bridge (likely by mlxsw itself). On each FDB notification, respin SPAN to reconcile it with the FDB changes. - Also respin on switchdev port attribute changes (which currently covers changes to STP state of ports) and port object additions and removals. Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ea93c7b6 |
|
29-Apr-2018 |
Petr Machata <petrm@mellanox.com> |
mlxsw: spectrum_switchdev: Publish two functions Publish the existing function mlxsw_sp_bridge_port_find(), and add another service accessor mlxsw_sp_bridge_port_stp_state(). Publish both in a new file spectrum_switchdev.h. Signed-off-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c7f46cca |
|
26-Apr-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Do not remove mrouter port from MDB's ports list When IGMP snooping is enabled on a bridge, traffic forwarded by an MDB entry should be sent to both ports member in the MDB's ports list and mrouter ports. In case a port needs to be removed from an MDB's ports list, but this port is also configured as an mrouter port, then do not update the device so that it will continue to forward traffic through that port. Fix a copy-paste error that checked that IGMP snooping is enabled twice instead of checking the port's mrouter state. Fixes: ded711c87a04 ("mlxsw: spectrum_switchdev: Consider mrouter status for mdb changes") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reported-by: Colin King <colin.king@canonical.com> Reviewed-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0a8a1bf1 |
|
01-Mar-2018 |
Shalom Toledo <shalomt@mellanox.com> |
mlxsw: spectrum_switchdev: Check success of FDB add operation Until now, we assumed that in case of error when adding FDB entries, the write operation will fail, but this is not the case. Instead, we need to check that the number of entries reported in the response is equal to the number of entries specified in the request. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Reported-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Shalom Toledo <shalomt@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
65b53bfd |
|
20-Feb-2018 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Allow port enslavement to a VLAN-unaware bridge Up until now we only allowed VLAN devices to be put in a VLAN-unaware bridge, but some users need the ability to enslave physical ports as well. This is achieved by mapping the port and VID 1 to the bridge's vFID, instead of the port and the VID used by the VLAN device. The above is valid because as long as the port is not enslaved to a bridge, VID 1 is guaranteed to be configured as PVID and egress untagged. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Tested-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
6c677750 |
|
13-Feb-2018 |
Arkadi Sharshevsky <arkadis@mellanox.com> |
mlxsw: spectrum: Use NL_SET_ERR_MSG_MOD Use NL_SET_ERR_MSG_MOD helper which adds the module name instead of specifying the prefix each time. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
90045fc9 |
|
25-Dec-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Relax sanity checks during enslavement Since commit 25cc72a33835 ("mlxsw: spectrum: Forbid linking to devices that have uppers") the driver forbids enslavement to netdevs that already have uppers of their own, as this can result in various ordering problems. This requirement proved to be too strict for some users who need to be able to enslave ports to a bridge that already has uppers. In this case, we can allow the enslavement if the bridge is already known to us, as any configuration performed on top of the bridge was already reflected to the device. Fixes: 25cc72a33835 ("mlxsw: spectrum: Forbid linking to devices that have uppers") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reported-by: Alexander Petrovskiy <alexpe@mellanox.com> Tested-by: Alexander Petrovskiy <alexpe@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
593bc28a |
|
09-Oct-2017 |
Yotam Gigi <yotamg@mellanox.com> |
mlxsw: spectrum_switchdev: Support bridge mrouter notifications Support the SWITCHDEV_ATTR_ID_BRIDGE_MROUTER port attribute switchdev notification. To do that, add the mrouter flag to struct mlxsw_sp_bridge_device, which indicates whether the bridge device was set to be mrouter port. This field is set when: - A new bridge is created, where the value is taken from the kernel bridge value. - A switchdev SWITCHDEV_ATTR_ID_BRIDGE_MROUTER notification is sent. In addition, change the bridge MID entries to include the router port when the bridge device is configured to be mrouter port. The MID entries are updated in the following cases: - When a new MID entry is created, update the router port according to the bridge mrouter state. - When a SWITCHDEV_ATTR_ID_BRIDGE_MROUTER notification is sent, update all the bridge's MID entries. This is aligned with the case where a bridge slave is configured to be mrouter port. Signed-off-by: Yotam Gigi <yotamg@mellanox.com> Reviewed-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c4db953f |
|
09-Oct-2017 |
Yotam Gigi <yotamg@mellanox.com> |
mlxsw: spectrum_switchdev: Add support for router port in SMID entries In Spectrum, MDB entries point to MID entries, that indicate which ports a packet should be forwarded to. Add the support in creating MID entries that forward the packet to the Spectrum router port. This will be later used to handle the bridge mrouter port switchdev notifications. Signed-off-by: Yotam Gigi <yotamg@mellanox.com> Reviewed-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9b63ef88 |
|
08-Oct-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Propagate extack further for bridge enslavements The code that actually takes care of bridge offload introduces a few more non-trivial constraints with regards to bridge enslavements. Propagate extack there to indicate the reason. $ ip link add link enp1s0np1 name enp1s0np1.10 type vlan id 10 $ ip link add link enp1s0np1 name enp1s0np1.20 type vlan id 20 $ ip link add name br0 type bridge $ ip link set dev enp1s0np1.10 master br0 $ ip link set dev enp1s0np1.20 master br0 Error: spectrum: Can not bridge VLAN uppers of the same port. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ded711c8 |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Consider mrouter status for mdb changes When a mrouter is registered or leaves a mid, don't update the HW. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
01662777 |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Remove mrouter flood in mdb flush In mdb flush the port is being removed from all the mids it is registered to. But if the port is mrouter, all the mids floods to it. This patch remove mrouter ports from mids it is not registered to in the mdb flush. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3ddda117 |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Update the mdb of mrouter port change Whenever a port starts / stops being mrouter, update all the mdb entries in the HW to flood / stop flooding mc packets there. The change should happen only if the port is not in the mid. (If it is, the mid should flood mc packets to this port anyway) Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3fba877c |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Flood all mc packets to mrouter ports When mc is enabled, whenever a mc packet doesn't hit any mdb entry it is being flood to the ports marked as mrouters. However, all mc packets should be flooded to them even if they match an entry in the mdb. This patch adds the mrouter ports to every mdb entry that is being written to the HW. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
bb5355b2 |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Flush the mdb when a port is being removed When a port is being removed from a bridge, flush the bridge mdb to remove the mids of that port. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9dad51bd |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Flood mc when mc is disabled by user flag When multicast is disabled, flood mc packets only to port that are marked BR_MCAST_FLOOD (instead to all). Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
218a8f8a |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Use generic mc flood function Use the generic mc flood function to decide whether to flood mc to a port when mc is being enabled / disabled. Move this function in the file to avoid forward declaration. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
2e3496cd |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Disable mdb when mc is disabled Remove all the mdb entries from the HW when mc is being disabled and re-write them when it is being enabled. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
846fd8a0 |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Don't write mids to the HW when mc is disabled Don't write multicast related data to the HW when mc is disabled. Also, don't allocate mid id to new mids (so the remove function could know that they weren't wrote to the HW) Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
061e55bf |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Break mid deletion into two function Break mid deletion into two function, so it will be possible in the future to delete a mid entry for other reasons then switchdev command (like port deletion). Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
73b433e8 |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Attach mid id allocation to HW write Attach mid getting and releasing mid id to the HW write / remove, and add a flag to indicate whether the mid is in the HW. It is done because mid id is also HW index to this mid. This change allows adding in the following patches the ability to have a mid in the mdb cache but not in the HW. It will be useful for being able to disable the multicast. It means that the mdb is being written / delete to the HW in the mid allocation / removing function, not after them. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
5f9abc59 |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Break smid write function Break the smid write function into two, one that cleans the ports that might be still written there and one that changes an exiting mid entry. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b80888a9 |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Save mids list per bridge device Instead of saving all the mids in the same list, save them per vlan device. This change allows a more efficient mid find. Also, in the next patches, there will be added a lot of loops over all the mids in bridge device for multicast disable, mrouter change and ndb flush. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0161b950 |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Remove reference count from mid Since there is a bitmap for the ports registered to each mid, there is no need for a ref count, since it will always be the number of set bits in this bitmap. Any check of the ref count was replaced with checking if the bitmap is empty. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4cdc35e4 |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Add a ports bitmap to the mid db Add a bitmap of ports to the mid struct to hold the ports that are registered to this mid. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
dff37b58 |
|
20-Sep-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Change mc_router to mrouter Change the naming of mc_router to mrouter to keep consistency. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4eb6a3bd |
|
22-Aug-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum_switchdev: Fix mrouter flag update Update the value of the mrouter flag in struct mlxsw_sp_bridge_port when it is being changed. Fixes: c57529e1d5d8 ("mlxsw: spectrum: Replace vPorts with Port-VLAN") Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
852cfeed |
|
04-Aug-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Release multicast groups during fini Each multicast group (MID) stores a bitmap of ports to which a packet should be forwarded to in case an MDB entry associated with the MID is hit. Since the initial introduction of IGMP snooping in commit 3a49b4fde2a1 ("mlxsw: Adding layer 2 multicast support") the driver didn't correctly free these multicast groups upon ungraceful situations such as the removal of the upper bridge device or module removal. The correct way to fix this is to associate each MID with the bridge ports member in it and then drop the reference in case the bridge port is destroyed, but this will result in a lot more code and will be fixed in net-next. For now, upon module removal, traverse the MID list and release each one. Fixes: 3a49b4fde2a1 ("mlxsw: Adding layer 2 multicast support") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
17b334a8 |
|
04-Aug-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Don't warn about valid situations Some operations in the bridge driver such as MDB deletion are preformed in an atomic context and thus deferred to a process context by the switchdev infrastructure. Therefore, by the time the operation is performed by the underlying device driver it's possible the bridge port context is already gone. This is especially true for removal flows, but theoretically can also be invoked during addition. Remove the warnings in such situations and return normally. Fixes: c57529e1d5d8 ("mlxsw: spectrum: Replace vPorts with Port-VLAN") Fixes: 3922285d96e7 ("net: bridge: Add support for offloading port attributes") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
6f497930 |
|
12-Jul-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Check status of memory allocation We can't rely on kzalloc() always succeeding, so check its return value. Suppresses the following smatch error: mlxsw_sp_switchdev_event() error: potential null dereference 'switchdev_work->fdb_info.addr'. (kzalloc returns null) Fixes: af061378924f ("mlxsw: spectrum_switchdev: Add support for learning FDB through notification") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
a9265b80 |
|
12-Jul-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Remove unused variable Commit 10e23eb299fa ("mlxsw: spectrum: Remove support for bypass bridge port attributes/vlan set") removed statements that used 'bridge_vlan', but didn't remove the variable itself resulting in the following warning with W=1: warning: variable ‘bridge_vlan’ set but not used [-Wunused-but-set-variable] Remove the variable and suppress the warning. Fixes: 10e23eb299fa ("mlxsw: spectrum: Remove support for bypass bridge port attributes/vlan set") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
be7432b9 |
|
08-Jun-2017 |
Arkadi Sharshevsky <arkadis@mellanox.com> |
mlxsw: spectrum: Remove support for bridge bypass FDB add/del The FDB add/del are now done through the notification chain. The FDBs are synced with the bridge and there is no need for extra dumping. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
af061378 |
|
08-Jun-2017 |
Arkadi Sharshevsky <arkadis@mellanox.com> |
mlxsw: spectrum_switchdev: Add support for learning FDB through notification Add support for learning FDB through notification. The driver defers the hardware update via ordered work queue. Support for stacked devices is also provided. In case of a successful FDB add a notification is sent back to bridge. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1b40dc3d |
|
08-Jun-2017 |
Arkadi Sharshevsky <arkadis@mellanox.com> |
mlxsw: spectrum_switchdev: Change switchdev notifier API The current API for sending switchdev notifications implies only FDB add/del. In order to support notification about successful FDB offload the API is changed. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
10e23eb2 |
|
08-Jun-2017 |
Arkadi Sharshevsky <arkadis@mellanox.com> |
mlxsw: spectrum: Remove support for bypass bridge port attributes/vlan set The bridge port attributes/vlan for mlxsw devices should be set only from bridge code. The vlans are synced totally with the bridge so there is no need to special dump support. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c7b566cd |
|
08-Jun-2017 |
Arkadi Sharshevsky <arkadis@mellanox.com> |
mlxsw: spectrum_switchdev: Add support for querying supported bridge flags Add support for querying supported bridge flags. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
a989cdb4 |
|
08-Jun-2017 |
Arkadi Sharshevsky <arkadis@mellanox.com> |
mlxsw: spectrum: Remove support for bridge FDB learning sync Currently the mlxsw driver supports an option for disabling syncing the hardware learned FDBs with the software bridge. This behavior breaks the bridge offload model and thus it is removed. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
6b26b51b |
|
08-Jun-2017 |
Arkadi Sharshevsky <arkadis@mellanox.com> |
net: bridge: Add support for notifying devices about FDB add/del Currently the bridge doesn't notify the underlying devices about new FDBs learned. The FDB sync is placed on the switchdev notifier chain because devices may potentially learn FDB that are not directly related to their ports, for example: 1. Mixed SW/HW bridge - FDBs that point to the ASICs external devices should be offloaded as CPU traps in order to perform forwarding in slow path. 2. EVPN - Externally learned FDBs for the vtep device. Notification is sent only about static FDB add/del. This is done due to fact that currently this is the only scenario supported by switch drivers. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Reviewed-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
a1107487 |
|
26-May-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Implement common FID core The device supports three types of FIDs. 802.1Q and 802.1D FIDs for VLAN-aware and VLAN-unaware bridges (respectively) and rFIDs to transport packets to the router block. The different users (e.g., bridge, router, ACLs) of the FIDs infrastructure need not know about the internal FIDs implementation and can therefore interact with it using a restricted set of exported functions. By encapsulating the entire FID logic and hiding it from the rest of the driver we get a code base that it much simpler and easier to work with and extend. For example, in the current Spectrum ASIC only 802.1D FIDs can be assigned a VNI, but future ASICs will also support 802.1Q FIDs. With this patch in place, support for future ASICs can be easily added by implementing a new FID operations according to their capabilities. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c57529e1 |
|
26-May-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Replace vPorts with Port-VLAN As explained in the cover letter, since the introduction of the bridge offload in the mlxsw driver, information related to the offloaded bridge and bridge ports was stored in the individual port struct, mlxsw_sp_port. This lead to a bloated struct storing both physical properties of the port (e.g., autoneg status) as well as logical properties of an upper bridge port (e.g., learning, mrouter indication). While this might work well for simple devices, it proved to be hard to extend when stacked devices were taken into account and more advanced use-cases (e.g., IGMP snooping) considered. This patch removes the excess information from the above struct and instead stores it in more appropriate structs that represent the bridge port, the bridge itself and a VLAN configured on the bridge port. The membership of a port in a bridge is denoted using the Port-VLAN struct, which points to the bridge port and also member in the bridge VLAN group of the VLAN it represents. This allows us to completely remove the vPort abstraction and consolidate many of the code paths relating to VLAN-aware and unaware bridges. Note that the FID / vFID code is currently duplicated, but this will soon go away when the common FID core will be introduced. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4aafc368 |
|
26-May-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Set port's mode according to FID mappings We currently transition the port to "Virtual mode" upon the creation of its first VLAN upper, as we need to classify incoming packets to a FID using {Port, VID} and not only the VID. However, it's more appropriate to transition the port to this mode when the {Port, VID} are actually mapped to a FID. Either during the enslavement of the VLAN upper to a VLAN-unaware bridge or the configuration of a router port. Do this change now in preparation for the introduction of the FID core, where this operation will be encapsulated. To prevent regressions, this patch also explicitly configures an OVS slave to "Virtual mode". Otherwise, a packet that didn't hit an ACL rule could be classified to an existing FID based on a global VID-to-FID mapping, thus not incurring a FID mis-classification, which would otherwise trap the packet to the CPU to be processed by the OVS daemon. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c0e01eac |
|
18-May-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Avoid possible NULL pointer dereference In case we got an FDB notification for a port that doesn't exist we execute an FDB entry delete to prevent it from re-appearing the next time we poll for notifications. If the operation failed we would trigger a NULL pointer dereference as 'mlxsw_sp_port' is NULL. Fix it by reporting the error using the underlying bus device instead. Fixes: 12f1501e7511 ("mlxsw: spectrum: remove FDB entry in case we get unknown object notification") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b02eae9b |
|
16-May-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Move PVID code to appropriate place PVID is a port attribute and should therefore reside in the main driver file and not the switchdev specific one. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
7cbc4277 |
|
16-May-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Don't batch learning operations We no longer batch VLAN operations, so there's no need to set the learning state for a range of VLANs. Use a common function to set the learning state for a Port-VLAN, thereby making the code saner more receptive for upcoming changes. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
45bfe6b4 |
|
16-May-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Don't batch STP operations Simplify the code by using the common function that sets an STP state for a Port-VLAN and remove the existing one that tries to batch it for several VLANs. This will help us in a follow-up patchset to introduce a unified infrastructure for bridge ports, regardless if the bridge is VLAN-aware or not. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
fe9ccc78 |
|
16-May-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Don't batch VLAN operations switchdev's VLAN object has the ability to describe a range of VLAN IDs, but this is only used when VLAN operations are done using the SELF flag, which is something we would like to remove as it allows one to bypass the bridge driver. Do VLAN operations on a per-VLAN basis, thereby simplifying the code and preparing it for refactoring in a follow-up patchset. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d341e2ce |
|
16-May-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Remove redundant check Since commit 97c242902c20 ("switchdev: Execute bridge ndos only for bridge ports") switchdev code checks that port is bridged, so no need to perform the same check in the driver. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
5f6935c6 |
|
16-May-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum_switchdev: Reduce scope of bridge struct Some attributes in the global chip struct are only relevant for bridge operation, so encapsulate them in their own struct that isn't exposed to non-bridge code. This will also help us later, when we add more bridge-specific attributes. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
93cd0813 |
|
18-Apr-2017 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: spectrum: Teach mlxsw_sp_port_vlan_set to accept any vlan range So far, mlxsw_sp_port_vlan_set range is limited by MLXSW_REG_SPVM_REC_MAX_COUNT. In spectrum_switchdev code this is wrapped up by a helper function which actually does multiple calls to FW for bigger ranges. Move the code into mlxsw_sp_port_vlan_set and use it always. That allows caller not to care about the range. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
5ec2ee7d |
|
24-Mar-2017 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: Query maximum number of ports from firmware We currently hard code the maximum number of ports in the driver, but this may change in future devices, so query it from the firmware instead. Fallback to a maximum of 64 ports in case this number can't be queried. This should only happen in SwitchX-2 for which this number is correct. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
bf95233e |
|
17-Mar-2017 |
Arkadi Sharshevsky <arkadis@mellanox.com> |
mlxsw: spectrum: Cosmetic naming change Currently the struct representing router interface "mlxsw_sp_rif" is reffered as "r" in various places in the driver. Furthermore it contains a member which specify the index which is called "rif". This patch change "r" to "rif" and "rif" to "rif_index". Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
90e0f0c1 |
|
09-Feb-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum: Update mc_disabled flag by switchdev attr Add a function to update mc_disabled from switchdev attr SWITCHDEV_ATTR_ID_BRIDGE_MC_DISABLED Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Yotam Gigi <yotamg@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1e5d9432 |
|
09-Feb-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum: Extend port_orig_get for bridge devices The function mlxsw_sp_port_orig_get returns the vport from the physical port if needed, based on the original device. This patch addresses the case where the original device is a bridge. If it is vlan unaware bridge, it returns the matching vport. If it is vlan aware bridge, there is no matching vport, and it returns the original port. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Yotam Gigi <yotamg@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8ecd4591 |
|
09-Feb-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum: Add an option to flood mc by mc_router_port The decision whether to flood a multicast packet to a port dependent on three flags: mc_disabled, mc_router_port, mc_flood. If mc_disabled is on, the port will be flooded according to mc_flood, otherwise, according to mc_router_port. To accomplish that, add those flags into the mlxsw_sp_port struct and update the mc flood table accordingly. Update mc_router_port by switchdev attribute SWITCHDEV_ATTR_ID_PORT_MC_ROUTER_PORT. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Yotam Gigi <yotamg@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
71c365bd |
|
09-Feb-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum: Separate bc and mc floods Break the bm (broadcast-multicast) into two tables, one for broadcast (and link local multicast that behaves like bc) and one for unknown multicasts. Add a bool into mlxsw_sp_port named mc_flood that reflect the value this port should have in the mc flood table (currently, always 1); Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Yotam Gigi <yotamg@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
69be01f3 |
|
09-Feb-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum: Make port flood update more generic Currently, there is a per port flood update function only for the UC table. Make the function more generic by changing the table type to be an input. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Yotam Gigi <yotamg@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
eaa7df3c |
|
09-Feb-2017 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum: Break flood set func to be per table Currently, the flood set function can't operate on only one table, but sets both uc_flood and mb_flood together. This patch creates a function that sets the flood state per table. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Yotam Gigi <yotamg@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
46d0847c |
|
30-Oct-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Fix incorrect reuse of MID entries In the device, a MID entry represents a group of local ports, which can later be bound to a MDB entry. The lookup of an existing MID entry is currently done using the provided MC MAC address and VID, from the Linux bridge. However, this can result in an incorrect reuse of the same MID index in different VLAN-unaware bridges (same IP MC group and VID 0). Fix this by performing the lookup based on FID instead of VID, which is unique across different bridges. Fixes: 3a49b4fde2a1 ("mlxsw: Adding layer 2 multicast support") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Elad Raz <eladr@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c1a38311 |
|
21-Oct-2016 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: Convert resources into array Since the number of resources is going to get much bigger, ease up the addition by simly defining IDs. Convert the existing structure members to a set array, one for validity, one for values. Introduce a set of getters and setters for easy access. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b45f64d1 |
|
25-Sep-2016 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: spectrum_router: Use FIB notifications instead of switchdev calls Until now, in order to offload a FIB entry to HW we use switchdev op. However that has limits. Mainly in case we need to make the HW aware of all route prefixes configured in kernel. HW needs to know those in order to properly trap appropriate packets and pass the to kernel to do the forwarding. Abort mechanism is now handled within the mlxsw driver. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ce0bd2b0 |
|
20-Sep-2016 |
Nogah Frankel <nogahf@mellanox.com> |
mlxsw: spectrum: lag resources- use resources data instead of consts Use max lag and max ports in lag resources as the result of resource query instead of using const to save them. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
aad8b6ba |
|
01-Sep-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Use existing flood setup when adding VLANs When a VLAN is added on a bridge port we should use the existing unicast flood configuration of the port instead of assuming it's enabled. Fixes: 0293038e0c36 ("mlxsw: spectrum: Add support for flood control") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f1de7a28 |
|
01-Sep-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Don't take multiple references on a FID In commit 14d39461b3f4 ("mlxsw: spectrum: Use per-FID struct for the VLAN-aware bridge") I added a per-FID struct, which member ports can take a reference on upon VLAN membership configuration. However, sometimes only the VLAN flags (e.g. egress untagged) are toggled without changing the VLAN membership. In these cases we shouldn't take another reference on the FID. Fixes: 14d39461b3f4 ("mlxsw: spectrum: Use per-FID struct for the VLAN-aware bridge") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
81f77bc0 |
|
23-Aug-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Remove unnecessary check in FDB processing We now offload the learning configuration to the device and don't rely on the driver to decide whether to learn the FDB record, so remove the check. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
89b548f0 |
|
23-Aug-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Offload learning to the switch ASIC Up until now we simply stored the learning configuration of a bridge port in the driver and decided whether to learn a new FDB record based on this value. However, this is sub-optimal in cases where learning is disabled on the bridge port, as the device repeatedly generates learning notifications for the same record. Instead, offload the learning configuration to the device, thereby preventing it from generating notifications when learning is disabled. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
584d73df |
|
23-Aug-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Configure learning for VLAN-aware bridge port We are going to prevent the device from generating learning notifications for a port that was configured with learning disabled. Since learning configuration is done per {Port, VID} we need to apply the port's learning configuration for any VID that is added to the bridge port's VLAN filter list. When a VID is added to the VLAN filter list of a VLAN-aware bridge port, configure the {Port, VID} learning status according to the port's configuration. When the VID is removed, disable learning for the {Port, VID}. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
640be7b7 |
|
23-Aug-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Don't abort on first error when removing VLANs When removing VLANs from the VLAN-aware bridge we shouldn't abort on the first error, as we'll otherwise have resources that will never be freed. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f7a8f6ce |
|
23-Aug-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Make VLAN deletion function symmetric Commit 05978481e77e ("mlxsw: spectrum: Create PVID vPort before registering netdevice") removed __mlxsw_sp_port_vlans_del() from the init sequence of the driver, which forced it to be non-symmetric with regards to __mlxsw_sp_port_vlans_add(). Make both functions symmetric as the constraint no longer exists. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1803e0fb |
|
23-Aug-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Limit number of FDB records per learning session Up until now a learning session ended whenever the number of queried records was zero. This turned out to be problematic in situations where a large number of MACs (48K) had to be processed by the switch driver, as RTNL mutex is held during the learning session. Instead, limit the number of FDB records that can be processed in a session to 64. This means that every time the device is queried for learning notifications (currently, every 100ms), up to 64 records will be processed by the switch driver. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8168287b |
|
17-Aug-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Unmap 802.1Q FID before destroying it Before destroying the 802.1Q FID we should first remove the VID-to-FID mapping. This makes mlxsw_sp_fid_destroy() symmetric with regards to mlxsw_sp_fid_create(). Fixes: 14d39461b3f4 ("mlxsw: spectrum: Use per-FID struct for the VLAN-aware bridge") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
05978481 |
|
17-Aug-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Create PVID vPort before registering netdevice After registering a netdevice it's possible for user space applications to configure an IP address on it. From the driver's perspective, this means a router interface (RIF) should be created for the PVID vPort. Therefore, we must create the PVID vPort before registering the netdevice. Fixes: 99724c18fc66 ("mlxsw: spectrum: Introduce support for router interfaces") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
99f44bb3 |
|
04-Jul-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Enable L3 interfaces on top of bridge devices As with the previously introduced L3 interfaces, listen to 'inetaddr' notifications sent for bridges devices configured on top of the port netdevs and create / destroy router interfaces (RIFs) accordingly. This also includes VLAN devices configured on top of the VLAN-aware bridge. The RIFs will be destroyed either when the last IP address is removed or when the underlying FID is is destroyed. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
701b186e |
|
04-Jul-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Configure FIDs based on bridge events Before introducing support for L3 interfaces on top of the VLAN-aware bridge we need to add some missing infrastructure. Such an interface can either be the bridge device itself or a VLAN device on top of it. In the first case the router interface (RIF) is associated with FID 1, which is created whenever the first port netdev joins the bridge. We currently assume the default PVID is 1 and that it's already created, as it seems reasonable. This can be extended in the future. However, in the second case it's entirely possible we've yet to create a matching FID. This can happen if the VLAN device was configured before making any bridge port member in the VLAN. Prevent such ordering problems by using the VLAN device's CHANGEUPPER event to configure the FID. Make the VLAN device hold a reference to the FID and prevent it from being destroyed even if none of the port netdevs is using it. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
99724c18 |
|
04-Jul-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Introduce support for router interfaces Up until now we only supported bridged interfaces. Packets ingressing through the switch ports were either classified to FIDs (in the case of the VLAN-aware bridge) or vFIDs (in the case of VLAN-unaware bridges). The packets were then forwarded according to the FDB. Routing was done entirely in slowpath, by splitting the vFID range in two and using the lower 0.5K vFIDs as dummy bridges that simply flooded all incoming traffic to the CPU. Instead, allow packets to be routed in the device by creating router interfaces (RIFs) that will direct them to the router block. Specifically, the RIFs introduced here are Sub-port RIFs used for VLAN devices and port netdevs. Packets ingressing from the {Port / LAG ID, VID} with which the RIF was programmed with will be assigned to a special kind of FIDs called rFIDs and from there directed to the router. Create a RIF whenever the first IPv4 address was programmed on a VLAN / LAG / port netdev. Destroy it upon removal of the last IPv4 address. Receive these notifications by registering for the 'inetaddr' notification chain. A non-zero (10) priority is used for the notification block, so that RIFs will be created before routes are offloaded via FIB code. Note that another trigger for RIF destruction are CHANGEUPPER notifications causing the underlying FID's reference count to go down to zero. This can happen, for example, when a VLAN netdev with an IP address is put under bridge. While this configuration doesn't make sense it does cause the device and the kernel to get out of sync when the netdev is unbridged. We intend to address this in the future, hopefully in current cycle. Finally, Remove the lower 0.5K vFIDs, as they are deprecated by the RIFs, which will trap packets according to their DIP. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
6e095fd4 |
|
04-Jul-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Edit RIF properties based on netdev events We are just about to introduce router interfaces (RIFs), but before that we need to be able update the device with the correct RIF attributes whenever they change for the netdev the RIF is backing. Two such attributes are MTU and MAC. The MAC is used both to set the source MAC of packets egressing from the RIF and also to program an FDB rule that will direct packets to the router block. Use the existing netdevice notification block and respond to CHANGEADDR and CHANGEMTU accordingly. Store both attributes in the RIF struct in case we need to revert to old attributes following a failed update. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
61c503f9 |
|
04-Jul-2016 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: spectrum_router: Implement fib4 add/del switchdev obj ops Implement ipv4 FIB entries addition and removal. Initially, we support local and broadcast routes using "ip2me" trap action. Also, unicast routes without nexthop are supported using "local" action. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
32d863fb |
|
02-Jul-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Remove VLANs configuration via SELF flag When port isn't bridged it is still possible to invoke switchdev ops and configure the device's VLAN filters. However, this will require us to use different Router InterFaces (RIFs) for the same netdev, instead of one per-netdev as with any other configuration. Taking the above into account and the fact that this functionality is questionable with regards to the device's normal use-case, remove it and instead return an error. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
22305378 |
|
20-Jun-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Add debug prints For debug purposes, it's useful to know the order in which the driver responds to changes in the topology of its upper devices. Add debug prints to signal these events. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
fe3f6d14 |
|
20-Jun-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Refactor FDB flushing logic FDB entries are learned using {Port / LAG ID, FID} and therefore should be flushed whenever a port (vPort) leaves its FID (vFID). However, when the bridge port is a LAG device (or a VLAN device on top), then FDB flushing is conditional. Ports removed from such LAG configurations must not trigger flushing, as other ports might still be members in the LAG and therefore the bridge port is still active. The decision whether to flush or not was previously computed in the netdevice notification block, but in order to flush the entries when a port leaves its FID this decision should be computed there. Strip the notification block from this logic and instead move it to one FDB flushing function that is invoked from both the FID / vFID leave functions. When port isn't member in LAG, FDB flushing should always occur. Otherwise, it should occur only when the last port (vPort) member in the LAG leaves the FID (vFID). This will allow us - in the next patch - to simplify the cleanup code paths that are hit whenever the topology above the port netdevs changes. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
56918b6b |
|
20-Jun-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Don't count on FID being present Not all vPorts will have FIDs assigned to them, so make sure functions first test for FID presence. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
41b996cc |
|
20-Jun-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Add FID get / set functions As previously explained, not all vPorts will be assigned FIDs, so instead of returning the FID index of a vPort, return a pointer to its FID struct. This will allow us to know whether it's legal to access the vPort's FID parameters such as index and device. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
14d39461 |
|
20-Jun-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Use per-FID struct for the VLAN-aware bridge In a very similar way to the vFIDs, make the first 4K FIDs - used in the VLAN-aware bridge - use the new FID struct. Upon first use of the FID by any of the ports do the following: 1) Create the FID 2) Setup a matching flooding entry 3) Create a mapping for the FID Unlike vFIDs, upon creation of a FID we always create a global VID-to-FID mapping, so that ports without upper vPorts can use it instead of creating an explicit {Port, VID} to FID mapping. When a port leaves a FID the reverse is performed. Whenever the FID's reference count reaches zero the FID is deleted along with the global mapping. The per-FID struct will later allow us to configure L3 interfaces on top of the VLAN-aware bridge. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d0ec875a |
|
20-Jun-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Make vFID struct generic Up until now we had a dedicated struct only for vFIDs, but before introducing support for L3 interfaces we need to make it generic and use it for all three types of FIDs: 1) FIDs - 0..4K-1, used for the VLAN-aware bridge 2) vFIDs - 4K..15K-1, used for VLAN-unaware bridges 3) rFIDs - 15K..16K-1, used to direct traffic to / from the router in the device. Will be introduced later in the series. The three types of L3 interfaces - Router InterFaces, RIFs - that will be introduced correspond to the three types of FIDs and are configured using them. Therefore, we'll need to store the links between them as well as a reference count on the underlying FID, so that the corresponding RIF will be destroyed when it reaches zero. Note that the lower 0.5K vFIDs are currently used for for non-bridged netdevs, so that traffic could be flooded to the CPU port. However, when rFIDs will be introduced we'll no longer need these and they too will be used for VLAN-unaware bridges. Make the vFID struct generic by renaming it and some of its fields. FIDs will be converted to use it later in the series. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
e6060027 |
|
20-Jun-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Use FID instead of vFID to setup flooding Use a FID index instead of vFID and ease the transition towards a generic FID struct. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
47a0a9e6 |
|
20-Jun-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Remove redundant function argument In all call sites 'only_uc' is set to false, so strip it. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
28892865 |
|
06-May-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Add missing rollback in flood configuration When we fail to set the flooding configuration for the broadcast and unregistered multicast traffic, we should revert the flooding configuration of the unknown unicast traffic. Fixes: 0293038e0c36 ("mlxsw: spectrum: Add support for flood control") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
dd9bdb04 |
|
14-Apr-2016 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: core: Add mlxsw specific workqueue and use it for FDB notif. processing Follow-up patch is going to need to use delayed work as well and frequently. The FDB notification processing is already using that and also quite frequently. It makes sense to create separate workqueue just for mlxsw driver in this case and do not pollute system_wq. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
869f63a4 |
|
08-Mar-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Check requested ageing time is valid Commit c62987bbd8a1 ("bridge: push bridge setting ageing_time down to switchdev") added a check for minimum and maximum ageing time, but this breaks existing behaviour where one can set ageing time to 0 for a non-learning bridge. Push this check down to the driver and allow the check in the bridge layer to be removed. Currently ageing time 0 is refused by the driver, but we can later add support for this functionality. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
28a01d2d |
|
18-Feb-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Allow for PVID deletion When PVID is toggled off on a port member in a VLAN filtering bridge or the PVID VLAN is deleted, make the port drop untagged packets. Reverse the operation when PVID is toggled back on. Set the PVID back to the default (1), when leaving the bridge so that untagged traffic will be directed to the CPU. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4f2c6ae5 |
|
27-Jan-2016 |
Ido Schimmel <idosch@mellanox.com> |
switchdev: Require RTNL mutex to be held when sending FDB notifications When switchdev drivers process FDB notifications from the underlying device they resolve the netdev to which the entry points to and notify the bridge using the switchdev notifier. However, since the RTNL mutex is not held there is nothing preventing the netdev from disappearing in the middle, which will cause br_switchdev_event() to dereference a non-existing netdev. Make switchdev drivers hold the lock at the beginning of the notification processing session and release it once it ends, after notifying the bridge. Also, remove switchdev_mutex and fdb_lock, as they are no longer needed when RTNL mutex is held. Fixes: 03bf0c281234 ("switchdev: introduce switchdev notifier") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3f47f867 |
|
27-Jan-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Compare local ports instead of pointers When dumping the FDB we can't compare the actual pointers of the ports structs, as it's possible the struct represents a vPort instead of the underlying physical port. Solve this by comparing the local port number instead, as it's shared between the physical ports and all the vPorts on top of him. Fixes: 54a732018d8e ("mlxsw: spectrum: Adjust switchdev ops for VLAN devices") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
304f5158 |
|
27-Jan-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Dump LAG FDB records only once LAG FDB records can only point to LAG devices or VLAN devices configured on top of them. Therefore, when dumping the FDB we shouldn't associate these records with the underlying physical ports. Fixes: 8a1ab5d76639 ("mlxsw: spectrum: Implement FDB add/remove/dump for LAG") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
e43aca22 |
|
27-Jan-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Use correct netdev when notifying bridge LAG FDB entries pointing to VLAN devices should be reported to the bridge with the matching VLAN device and not the underlying LAG device. Fixes: aac78a440887 ("mlxsw: spectrum: Adjust FDB notifications for VLAN devices") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
004f85ea |
|
27-Jan-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Don't report VLAN for 802.1D FDB entries When dumping the hardware FDB we should report entries pointing to VLAN devices with VLAN 0, as packets coming into the bridge are untagged. Likewise, pass FDB_{ADD,DEL} notifications with VLAN 0 for these devices. Fixes: 54a732018d8e ("mlxsw: spectrum: Adjust switchdev ops for VLAN devices") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
45827d78 |
|
27-Jan-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Notify bridge's FDB only based on learning_sync When we disable learning on bridge port we should still update the software bridge's FDB when entry pointing to this bridge port is aged-out. We can otherwise have an inconsistency between software and hardware tables. Fixes: 8a1ab5d76639 ("mlxsw: spectrum: Implement FDB add/remove/dump for LAG") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
45491133 |
|
27-Jan-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Disable learning according to STP state When port is put into LISTENING state it shouldn't populate the FDB, so set the port's STP state in hardware to DISCARDING instead of LEARNING. It will therefore keep listening to BPDU packets, but discard other non-control packets and won't perform any learning. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9cb026eb |
|
27-Jan-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Don't forward packets when STP state is DISABLED When STP state is set to DISABLED the port is assumed to be inactive, but currently we forward packets ingressing through it. Instead, set the port's STP state in hardware to DISCARDING, which means it doesn't forward packets or perform any learning, but it does trap control packets. However, these packets will be dropped by bridge code, which results in the expected behavior. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4dc236c3 |
|
27-Jan-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Handle port leaving LAG while bridged It is possible for a user to remove a port from a LAG device, while the LAG device or VLAN devices on top of it are bridged. In these cases, bridge's teardown sequence is never issued, so we need to take care of it ourselves. When LAG's unlinking event is received by port netdev: 1) Traverse its vPorts list and make those member in a bridge leave it. They will be deleted later by LAG code. 2) Make the port netdev itself leave its bridge if member in one. Fixes: 0d65fc13042f ("mlxsw: spectrum: Implement LAG port join/leave") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
00ae40e7 |
|
13-Jan-2016 |
Dan Carpenter <dan.carpenter@oracle.com> |
mlxsw: fix SWITCHDEV_OBJ_ID_PORT_MDB There is a missing break statement so we always return -EOPNOTSUPP. Fixes: 3a49b4fde2a1 ('mlxsw: Adding layer 2 multicast support') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
366ce603 |
|
10-Jan-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Add FDB lock to prevent session interleaving Dumping the FDB (invoked with a process context) or handling FDB notifications (polled periodicly in delayed work) might each entail multiple EMAD transcations due to the number of entries. While we only allow one EMAD transaction at a time, there is nothing stopping the dump and notification processing sessions from interleaving. However, this is forbidden by the hardware, so we need to make sure only one of these sessions can run at a time. Solve this by adding a mutex ('fdb_lock'), as both kernel threads can sleep while waiting for the response EMAD. Fixes: 56ade8fe3f ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3a49b4fd |
|
10-Jan-2016 |
Elad Raz <eladr@mellanox.com> |
mlxsw: Adding layer 2 multicast support Add SWITCHDEV_OBJ_ID_PORT_MDB switchdev ops support. On first MDB insertion creates a new multicast group (MID) and add members port to the MID. Also add new MDB entry for the flooding-domain (fid-vid) and link the MDB entry to the newly constructed MC group. Signed-off-by: Elad Raz <eladr@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
e4b6f693 |
|
10-Jan-2016 |
Elad Raz <eladr@mellanox.com> |
mlxsw: Adding VID to FID translatation Adding a generic function that translate VID to FID. Signed-off-by: Elad Raz <eladr@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
12f1501e |
|
07-Jan-2016 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: spectrum: remove FDB entry in case we get unknown object notification It may happen that we get notification for FDB entry for object (port, lag, vport), which does not exist. Currently we ignore that, which only causes this being re-sent in next notification. The entry will never disappear. So get rid of it by simply removing it using SFD register. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
2fa9d45e |
|
07-Jan-2016 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: spectrum: pass local_port to mlxsw_sp_port_fdb_uc_op Do not pass struct mlxsw_sp_port to mlxsw_sp_port_fdb_uc_op and rather just pass local_port. This is needed in case this is called from SFN process function and mlxsw_sp_port is not existent for particular local_port. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
fc1273af |
|
06-Jan-2016 |
Elad Raz <eladr@mellanox.com> |
mlxsw: Remember untagged VLANs When a vlan is been configured, remeber the untagged mode of the vlan. When displaying the list of configured VLANs, show the untagged attribute. Signed-off-by: Elad Raz <eladr@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
26a4ea0f |
|
06-Jan-2016 |
Elad Raz <eladr@mellanox.com> |
mlxsw: Disable vlan_filtering for non .1D bridge When a port is bridged, the bridge must be vlan aware bridge (.1Q) or the bridging should be on top of VLAN interfaces (.1D bridge). Signed-off-by: Elad Raz <eladr@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
e4a13055 |
|
06-Jan-2016 |
Elad Raz <eladr@mellanox.com> |
mlxsw: Renaming local variable names for consistency Signed-off-by: Elad Raz <eladr@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
29edf44f |
|
06-Jan-2016 |
Elad Raz <eladr@mellanox.com> |
mlxsw: Fixing vlans init range Initialize VLANs 0..4095 (Remove init for VID 4096). Signed-off-by: Elad Raz <eladr@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
6c72a3d0 |
|
04-Jan-2016 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Change bridge port attributes only when bridged Bridge port attributes are offloaded to hardware when invoked with SELF flag set, but it really makes no sense to reflect them when port is not bridged. Allow a user to change these attribute only when port is bridged and initialize them correctly when joining or leaving a bridge. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
64771e31 |
|
15-Dec-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Enable FDB records for VLAN devices on top of LAG When adding or removing FDB records of VLAN devices on top of LAG we should set the lag_vid parameter to the VLAN ID of the VLAN device. It is reserved otherwise. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
afd7f979 |
|
15-Dec-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: reg: Add lag_vid field to SFD register Unicast LAG records in the Switch Filtering Database (SFD) register have a lag_vid field indicating the VLAN ID in case of vFIDs. This field is no longer reserved since we are going to add support for VLAN devices on top of LAG. Add the lag_vid field to be used by VLAN devies on top of LAG. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
26f0e7fb |
|
15-Dec-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Add support for VLAN devices bridging All the member VLAN devices in a bridge need to share the same vFID. To achieve that, expand the vFID struct to include the associated bridge device (or lack of) and allow one to lookup a vFID based on a bridge device. When joining a bridge, lookup the relevant vFID or create one if none exists. Next, make the VLAN device use the vFID. Leaving a bridge can either occur because a user removed the VLAN device from a bridge or because the VLAN device was deleted by the user. In the latter case the bridge's teardown sequence is invoked after the hardware vPort is already gone. Therefore, when unlinking the VLAN device from the real device, check if the associated vPort is bridged and act accordingly. The bridge's notification will be ignored in this case. Note that bridging a VLAN interface with an ordinary port netdev is currently not supported, but not forbidden. This will be addressed in a follow-up patchset. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
aac78a44 |
|
15-Dec-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Adjust FDB notifications for VLAN devices FDB notifications contain the FID and port (or LAG ID) on which the MAC was learned. In the case of the 802.1Q bridge one can easily derive the matching VID - as FID equals VID - and generate the appropriate notification for the software bridge. With VLAN devices this is no longer the case, as these are associated with a vFID. Solve that by converting the FID to a vFID and lookup the matching VLAN device. From that derive the VID and whether learning (and learning sync) should occur. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
54a73201 |
|
15-Dec-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Adjust switchdev ops for VLAN devices switchdev ops can now be called for VLAN devices and we need to be prepared for it. Until now they were only called for the port netdev. Use the newly propagated orig_dev passed as part of the switchdev attr/obj and determine whether the original device is a VLAN device. If so, act accordingly, otherwise continue as usual. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9de6a80e |
|
15-Dec-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Use FID instead of VID when accessing FDB In the Spectrum ASIC - unlike SwitchX-2 - FDB access is done by specifying FID as parameter and not VID. Change the relevant variables and parameters names to reflect that. Note that this was OK up until now, since FID was always equal to VID, but with the introduction of VLAN interfaces this is no longer the case. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
19ae6124 |
|
15-Dec-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Add another flood table for vFIDs We previously used only one flood table for packets classified to vFIDs. However, since we are going to add support for bridges between VLAN interfaces (mapped to vFIDs) we need to add one more flood table. That way we can separate the flooding domain of unknown unicast traffic from all the rest and support flood control (as we do with the 802.1Q bridge). Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c06a94ef |
|
15-Dec-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Use appropriate parameter name The __mlxsw_sp_port_flood_set function is now used to configure flooding for both FIDs and vFIDs, so change the parameter name to 'idx' instead of 'fid'. This is also consistent with hardware documentation. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
7f71eb46 |
|
15-Dec-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Split vFID range in two Up until now we used a 1:1 mapping - based on VID - to map a VLAN interface to a vFID. However, a different scheme is needed in order to support bridges between VLAN interfaces, as all the member interfaces - which can have different VIDs - need to share the same vFID. Solve that by splitting the vFID range in two: 1. Non-bridged VLAN interfaces 2. Bridged VLAN interfaces When a VLAN interface is created, assign it the next available vFID in the first range, unless one already exists for that VID or number of vFIDs in the range was exceeded. When interface is removed, free the vFID, unless other interfaces are mapped to it. To accomplish the above: 1. Store the VID to vFID mapping in a new struct (mlxsw_sp_vfid), which has a global context and holds a reference count. 2. Create a vPort (dummy in case of bridge SELF invocation) on top of of the physical port and hold a reference to the associated vFID. vfid vfid +-------------+ +-------------+ | vfid | | vfid | | vid +---> ... | vid | | nr_vports | | nr_vports | +------+------+ +------+------+ | +-----------------------+-------+ | | vport vport +-------------+ +-------------+ | ... | | ... | | *vfid +---> ... | *vfid +---> ... | ... | | ... | +------+------+ +------+------+ | | port port +-------------+ +-------------+ | ... | | ... | | vports_list | | vports_list | | ... | | ... | +-------------+ +-------------+ swXpY swXpZ Next patches in the series will add the missing infrastructure for the second range and transfer vPorts between the two ranges according to the received notifications. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8a1ab5d7 |
|
02-Dec-2015 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: spectrum: Implement FDB add/remove/dump for LAG Implement FDB offloading for lagged ports, including learning LAG FDB entries, adding/removing static FDB entries and dumping existing LAG FDB entries. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b07a966c |
|
18-Nov-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Add error paths to __mlxsw_sp_port_vlans_add The operation of adding VLANs on a port via switchdev ops can fail and we need to be prepared for it. If we do not rollback hardware operations following a failure, hardware and software will remain in an inconsistent state. Solve that by adding suitable error paths to __mlxsw_sp_port_vlans_add. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3b7ad5ec |
|
18-Nov-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Unify setting of HW VLAN filters When adding or deleting VLANs from a bridged port, HW VLAN filters must be set accordingly. Instead of having the same code in both add and delete functions, just wrap it in a function and call it with the appropriate parameters. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Elad Raz <eladr@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
06c071f6 |
|
18-Nov-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Use correct PVID value when removing VLANs When removing a range of VLANs in which PVID is a member we should use the correct PVID value instead of some VLAN in the range. Also, change two print statements to use 'dev' instead of 'mlxsw_sp_port->dev', as it's already used in other print statements in the function. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c7070fc4 |
|
28-Oct-2015 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: spectrum: Make mlxsw_sp_port_switchdev_ops static Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
135f9ece |
|
28-Oct-2015 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: spectrum: Fix ageing time value The value passed through switchdev attr set is not in jiffies, but in clock_t, so fix the convert. Reported-by: Sagi Rotem <sagir@mellanox.com> Fixes: 56ade8fe3f ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0293038e |
|
28-Oct-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Add support for flood control Add or remove a bridged port from the flooding domain of unknown unicast packets according to user configuration. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1b3433a9 |
|
28-Oct-2015 |
Ido Schimmel <idosch@mellanox.com> |
mlxsw: spectrum: Add support for VLAN ranges in flooding configuration When enabling a range of VLANs on a bridged port we can configure flooding for these VLANs by one register access instead of calling the same register for each VLAN. This is accomplished by using the 'range' field of the Switch Flooding Table Register (SFTR). Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
56ade8fe |
|
16-Oct-2015 |
Jiri Pirko <jiri@mellanox.com> |
mlxsw: spectrum: Add initial support for Spectrum ASIC Add support for new generation Mellanox Spectrum ASIC, 10/25/40/50 and 100Gb/s Ethernet Switch. The initial driver implements bridge forwarding offload including bridge internal VLAN support, FDB static entries, FDB learning and HW ageing including their setup. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Elad Raz <eladr@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|