- 17 Aug, 2021 25 commits
-
-
Justin Iurman authored
As previously discussed with David Ahern, here is a refactored and improved version of the IOAM self-test. It is now more complete and more robust. Now, all tests are divided into three categories: OUTPUT (evaluates the IOAM processing by the sender), INPUT (evaluates the IOAM processing by the receiver) and GLOBAL (evaluates wider use cases that do not fall into the other two categories). Both OUTPUT and INPUT tests only use a two-node topology (alpha and beta), while GLOBAL tests use the entire three-node topology (alpha, beta, gamma). Each test is documented inside its own handler in the (bash) script. Signed-off-by:
Justin Iurman <justin.iurman@uliege.be> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Nikolay Aleksandrov says: ==================== net: bridge: vlan: fixes for vlan mcast contexts These are four fixes for vlan multicast contexts. The first patch enables mcast ctx snooping when adding already existing master vlans to be consistent with the rest of the code. The second patch accounts for the mcast ctx router ports when allocating skb for notification. The third one fixes two suspicious rcu usages due to wrong vlan group helper, and the fourth updates host vlan mcast state along with port mcast state. ==================== Signed-off-by: -
Nikolay Aleksandrov authored
When changing vlan mcast state by br_multicast_toggle_vlan it iterates over all ports and enables/disables the port mcast ctx based on the new state, but I forgot to update the host vlan (bridge master vlan entry) with the new state so it will be left out. Also that function is not used outside of br_multicast.c, so make it static. Fixes: f4b7002a ("net: bridge: add vlan mcast snooping knob") Signed-off-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
Nikolay Aleksandrov authored
When dereferencing the port vlan group we should use the rcu helper instead of the one relying on rtnl. In br_multicast_pg_to_port_ctx the entry cannot disappear as we hold the multicast lock and rcu as explained in the comment above it. For the same reason we're ok in br_multicast_start_querier. ============================= WARNING: suspicious RCU usage 5.14.0-rc5+ #429 Tainted: G W ----------------------------- net/bridge/br_private.h:1478 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by swapper/2/0: #0: ffff88822be85eb0 ((&p->timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x2da #1: ffff88810b32f260 (&br->multicast_lock){+.-.}-{3:3}, at: br_multicast_port_group_expired+0x28/0x13d [bridge] #2: ffffffff824f6c80 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire.constprop.0+0x0/0x22 [bridge] stack backtrace: CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Tainted: G W 5.14.0-rc5+ #429 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x45/0x59 nbp_vlan_group+0x3e/0x44 [bridge] br_multicast_pg_to_port_ctx+0xd6/0x10d [bridge] br_multicast_star_g_handle_mode+0xa1/0x2ce [bridge] ? netlink_broadcast+0xf/0x11 ? nlmsg_notify+0x56/0x99 ? br_mdb_notify+0x224/0x2e9 [bridge] ? br_multicast_del_pg+0x1dc/0x26d [bridge] br_multicast_del_pg+0x1dc/0x26d [bridge] br_multicast_port_group_expired+0xaa/0x13d [bridge] ? __grp_src_delete_marked.isra.0+0x35/0x35 [bridge] ? __grp_src_delete_marked.isra.0+0x35/0x35 [bridge] call_timer_fn+0x134/0x2da __run_timers+0x169/0x193 run_timer_softirq+0x19/0x2d __do_softirq+0x1bc/0x42a __irq_exit_rcu+0x5c/0xb3 irq_exit_rcu+0xa/0x12 sysvec_apic_timer_interrupt+0x5e/0x75 </IRQ> asm_sysvec_apic_timer_interrupt+0x12/0x20 RIP: 0010:default_idle+0xc/0xd Code: e8 14 40 71 ff e8 10 b3 ff ff 4c 89 e2 48 89 ef 31 f6 5d 41 5c e9 a9 e8 c2 ff cc cc cc cc 0f 1f 44 00 00 e8 7f 55 65 ff fb f4 <c3> 0f 1f 44 00 00 55 65 48 8b 2c 25 40 6f 01 00 53 f0 80 4d 02 20 RSP: 0018:ffff88810033bf00 EFLAGS: 00000206 RAX: ffffffff819cf828 RBX: ffff888100328000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff819cfa2d RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: ffff8881008302c0 R11: 00000000000006db R12: 0000000000000000 R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000 ? __sched_text_end+0x4/0x4 ? default_idle_call+0x15/0x7b default_idle_call+0x4d/0x7b do_idle+0x124/0x2a2 cpu_startup_entry+0x1d/0x1f secondary_startup_64_no_verify+0xb0/0xbb Fixes: 74edfd48 ("net: bridge: multicast: add helper to get port mcast context from port group") Signed-off-by: -
Nikolay Aleksandrov authored
When sending a global vlan notification we should account for the number of router ports when allocating the skb, otherwise we might end up losing notifications. Fixes: dc002875 ("net: bridge: vlan: use br_rports_fill_info() to export mcast router ports") Signed-off-by:
-
Nikolay Aleksandrov authored
We always create a vlan with enabled mcast snooping, so when the user turns on per-vlan mcast contexts they'll get consistent behaviour with the current situation, but one place wasn't updated when a bridge/master vlan which already exists (created due to port vlans) is being added as real bridge vlan (BRIDGE_VLAN_INFO_BRENTRY). We need to enable mcast snooping for that vlan when that happens. Fixes: 7b54aaaf ("net: bridge: multicast: add vlan state initialization and control") Signed-off-by:
-
David S. Miller authored
Subbaraya Sundeep says: ==================== octeontx2: Rework MCAM flows management for VFs From Octeontx2 hardware point of view there is no difference between PFs and VFs. Hence with refactoring in driver the packet classification features or offloads can be supported by VFs also. This patchset unifies the mcam flows management so that VFs can also support ntuple filters. Since there are MCAM allocations by all PFs and VFs in the system it is required to have the ability to modify number of mcam rules count for a PF/VF in runtime. This is achieved by using devlink. Below is the summary of patches: Patch 1,2,3 are trivial patches which helps in debugging in case of errors by using custom error codes and displaying proper error messages. Patches 4,5 brings rx-all and ntuple support for CGX mapped VFs and LBK VFs. Patches 6,7,8 brings devlink support to PF netdev driver so that mcam entries count can be changed at runtime. To change mcam rule count at runtime where multiple rule allocations are done sorting is required. Also both ntuple and TC rules needs to be unified. Patch 9 is related to AF NPC where a PF allocated entries are allocated at bottom(low priority). On CN10K there is slight change in reading NPC counters which is handled by patch 10. Patch 11 is to allow packets from CPT for NPC parsing on CN10K. ==================== Signed-off-by: -
Vidya authored
On CN10K, the higher bits in the channel number represents the CPT channel number. Mask out these higher bits in the npc configuration to allow packets from cpt for parsing. Signed-off-by:
Vidya <vvelumuri@marvell.com> Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
-
Hariprasad Kelam authored
The way SW can identify the number NPC counters supported by silicon has changed for CN10K. This patch addresses this reading appropriate registers to find out number of counters available. Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Signed-off-by:
-
Subbaraya Sundeep authored
If the mcam entry allocation request is from PF and NOT a priority allocation request then allocate low priority entries so that PF entries always have lower priority than its VFs. This is required so that entries with (base) MCAM match criteria have lower priority compared to entries with (base + additional) match criteria. This patch considers only best case scenario where PF entries are allocated from low priority zone if low priority zone has free space. There are worst case scenarios like: 1. VFs allocating hundreds of MCAM entries leading to VFs using all mid priority zone and low priority zone entries hence no entries free from low priority zone for PF. 2. All the PFs and VFs in the system allocating and freeing entries causing fragmentation in MCAM space and all the entries requested by PF could not fit in low priority zone for allocation. This patch do not handle worst case scenarios. Signed-off-by:
-
Sunil Goutham authored
Added support for setting or modifying MCAM entry count at runtime via devlink params. commands: devlink dev param show pci/0002:02:00.0: name mcam_count type driver-specific values: cmode runtime value 16 devlink dev param set pci/0002:02:00.0 name mcam_count value 64 cmode runtime Signed-off-by: -
Sunil Goutham authored
Variables used for TC flow management like maximum number of flows, number of flows installed etc are a copy of ntuple flow management variables. Since both TC and NTUPLE are not supported at the same time, it's better to unify these with common variables. This patch addresses this unification and also does cleanup of other minor stuff wrt TC. Signed-off-by:
-
Sunil Goutham authored
Per single mailbox request a maximum of 256 MCAM entries can be allocated. If more than 256 are being allocated, then the mcam indices in the final list could get jumbled. Hence sort the indices. Signed-off-by:
-
Rakesh Babu authored
Add packet flow classification support for both LMAC mapped virtual functions and loopback VFs. This patch adds supports for ntuple offload feature. Signed-off-by:
Rakesh Babu <rsaladi2@marvell.com> Signed-off-by:
-
Sunil Goutham authored
Enabled NETIF_F_RXALL support for VF driver. Also removed MTU range comments which are no longer valid. Signed-off-by:
-
Sunil Goutham authored
Added debug messages for various failures during probe. This will help in quickly identifying the API where the failure is happening. Signed-off-by:
-
Naveen Mamindlapalli authored
Add appropriate error codes to be used when returning from AF mailbox handlers due to some error condition. Signed-off-by:
Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by:
-
Subbaraya Sundeep authored
When installing a flow using npc_install_flow mailbox there are number of reasons to reject the request like caller is not permitted, invalid channel specified in request, flow not supported in extraction profile and so on. Hence define new error codes for npc flows and use them instead of generic error codes. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-updates-2021-08-16 The following patchset provides two separate mlx5 updates 1) Ethtool RSS context and MQPRIO channel mode support: 1.1) enable mlx5e netdev driver to allow creating Transport Interface RX (TIRs) objects on the fly to be used for ethtool RSS contexts and TX MQPRIO channel mode 1.2) Introduce mlx5e_rss object to manage such TIRs. 1.3) Ethtool support for RSS context 1.4) Support MQPRIO channel mode 2) Bridge offloads Lag support: to allow adding bond net devices to mlx5 bridge 2.1) Address bridge port by (vport_num, esw_owner_vhca_id) pair since vport_num is only unique per eswitch and in lag mode we need to manage ports from both eswitches. 2.2) Allow connectivity between representors of different eswitch instances that are attached to same bridge 2.3) Bridge LAG, Require representors to be in shared FDB mode and introduce local and peer ports representors, match on paired eswitch metadata in peer FDB entries, And finally support addition/deletion and aging of peer flows. ==================== Signed-off-by: -
Luke Hsiao authored
Since the original TFO server code was implemented in commit 168a8f58 ("tcp: TCP Fast Open Server - main code path") the TFO server code has supported the sysctl bit flag TFO_SERVER_COOKIE_NOT_REQD. Currently, when the TFO_SERVER_ENABLE and TFO_SERVER_COOKIE_NOT_REQD sysctl bit flags are set, a server connection will accept a SYN with N bytes of data (N > 0) that has no TFO cookie, create a new fast open connection, process the incoming data in the SYN, and make the connection ready for accepting. After accepting, the connection is ready for read()/recvmsg() to read the N bytes of data in the SYN, ready for write()/sendmsg() calls and data transmissions to transmit data. This commit changes an edge case in this feature by changing this behavior to apply to (N >= 0) bytes of data in the SYN rather than only (N > 0) bytes of data in the SYN. Now, a server will accept a data-less SYN without a TFO cookie if TFO_SERVER_COOKIE_NOT_REQD is set. Caveat! While this enables a new kind of TFO (data-less empty-cookie SYN), some firewall rules setup may not work if they assume such packets are not legit TFOs and will filter them. Signed-off-by:
Luke Hsiao <lukehsiao@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Acked-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20210816205105.2533289-1-luke.w.hsiao@gmail.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Jonathan Lemon says: ==================== ptp: ocp: minor updates and fixes. Fix errors spotted by automated tools. Add myself to the MAINTAINERS for the ptp_ocp driver. ==================== Link: https://lore.kernel.org/r/20210816221337.390645-1-jonathan.lemon@gmail.comSigned-off-by:
-
Jonathan Lemon authored
Add maintainer info for the OpenCompute PTP driver. Signed-off-by:
Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by:
-
Jonathan Lemon authored
NET doesn't imply NET_DEVLINK. Select this separately, so that random config combinations don't complain. Reported-by:
kernel test robot <lkp@intel.com> Fixes: 773bda96 ("ptp: ocp: Expose various resources on the timecard.") Signed-off-by:
-
Jonathan Lemon authored
If ptp_ocp_device_init() fails, pci_disable_device() is skipped. Fix the error handling so this case is covered. Update ptp_ocp_remove() so the normal exit path is identical. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 773bda96 ("ptp: ocp: Expose various resources on the timecard.") Signed-off-by:
-
Jonathan Lemon authored
If attempting to flash the firmware with a blob of size 0, the entire write loop is skipped and the uninitialized err is returned. Fix by setting to 0 first. Fixes: 773bda96 ("ptp: ocp: Expose various resources on the timecard.") Signed-off-by:
-
- 16 Aug, 2021 15 commits
-
-
Vlad Buslov authored
Allow adding bond net devices to mlx5 bridge with following changes: - Modify bridge representor code to obtain uplink represetor that belongs to eswitch that is registered for notification. Require representor to be in shared FDB mode. If representor is the lag master, then consider its port as local, otherwise treat it as peer. - Use devcom to match on paired eswitch metadata in peer FDB entries. This is necessary for shared FDB LAG to function since packets are always received on active eswitch instance as opposed to parent eswitch of port. - Support for deleting peer flows when receiving SWITCHDEV_FDB_DEL_TO_BRIDGE notification was implemented in one of previous patches in series. Now also implement support for handling SWITCHDEV_FDB_ADD_TO_BRIDGE which can be generated on peer by bridge update workqueue task in LAG configuration. Refresh the flow 'lastuse' timestamp to current jiffies when receiving such notification on eswitch that manages the local FDB entry. This allows peer entries to prevent ageing of the FDB. Signed-off-by:
Vlad Buslov <vladbu@nvidia.com> Reviewed-by:
Roi Dayan <roid@nvidia.com> Reviewed-by:
Mark Bloch <mbloch@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Vlad Buslov authored
Allow connectivity between representors of different eswitch instances that are attached to same bridge when merged_eswitch capability is enabled. Add ports of peer eswitch to bridge instance and mark them with MLX5_ESW_BRIDGE_PORT_FLAG_PEER. Mark FDBs offloaded on peer ports with MLX5_ESW_BRIDGE_FLAG_PEER flag. Such FDBs can only be aged out on their local eswitch instance, which then sends SWITCHDEV_FDB_DEL_TO_BRIDGE event. Listen to the event on mlx5 bridge implementation and delete peer FDBs in event handler. Signed-off-by:
-
Vlad Buslov authored
SWITCHDEV_FDB_DEL_TO_BRIDGE notification is generated in multiple places in bridge code. Following patch in series changes the condition for the notification. Extract the notification into dedicated helper function mlx5_esw_bridge_fdb_del_notify() to only modify it in single place in the future changes. Signed-off-by:
-
Vlad Buslov authored
Following patches in series allow traffic between vports of different eswitch instances, which requires addressing bridge port by vport_num+esw_owner_vhca_id pair since vport_num is only unique per-eswitch. As a preparation, extend struct mlx5_esw_bridge_port with 'esw_owner_vhca_id' field and use it as part of key for mlx5_esw_bridge->vports xarray. With this change we can't rely on switchdev_handle_port_obj_add() helper to get mlx5 representor from stacked device because we need specifically representor from parent eswitch that registered the callback to obtain correct esw_owner_vhca_id. The helper doesn't allow passing additional parameters to predicate function and doesn't provide access to the notifier block to obtain eswitch through br_offloads. Implement custom helpers to obtain mlx5 representor and use them in mlx5_esw_bridge_port_obj_{add|del|attr_set}() implementations. Remove direct pointer to parent bridge from struct mlx5_vport as it is no longer needed. Signed-off-by: -
Vlad Buslov authored
Following patches in series will pass bond device to bridge, which means the code can't assume the device is mlx5 representor. Moreover, the core device can be easily obtained from eswitch instance, so there is no reason for more complex code that obtains struct mlx5_priv from net_device in order to use its mdev. Refactor the code to use esw->dev instead of priv->mdev. Signed-off-by:
-
Vlad Buslov authored
Refactor mlx5_esw_bridge_vport_link() to release the bridge instance if mlx5_esw_bridge_vport_init() returned an error instead of relying on it to release the bridge. This improves the design because object instance is taken and released in same layer and simplifies following patches that add more logic to mlx5_esw_bridge_vport_link(). Signed-off-by:
-
Tariq Toukan authored
Add support for MQPRIO channel mode, in which a partition to TCs is defined over the channels. We allow partitions with contiguous queue indices, with no holes within. We do not allow modification to the num of channels while this MQPRIO mode is active. Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by:
-
Tariq Toukan authored
Add handling for failures in netdev_set_num_tc(). Let mlx5e_netdev_set_tcs return an int. Signed-off-by:
-
Tariq Toukan authored
This is in preparation for supporting MQPRIO CHANNEL mode in downstream patch, in addition to DCB mode that's supported today. Signed-off-by:
-
Tariq Toukan authored
Abstract the MQPRIO params into a struct. Use a getter for DCB mode num_tcs. Signed-off-by:
-
Tariq Toukan authored
Extend the existing flow classification support, to steer flows not only directly to a receive ring, but also into the new RSS contexts. Create needed TIR objects on demand, and hold reference on the RSS context. Signed-off-by:
-
Tariq Toukan authored
Add support to multiple RSS contexts. Resources of the non-default RSS contexts are allocated and created on demand. Each RSS context can be controlled and configured separately, via the implemented ethtool ops. Here we limit the num of total contexts to 16. We do not enforce any kind of new limitation over the indirection table content. More specifically, two separate contexts can be configured to fully or partially point to the same set of receive rings. The default RSS context (index 0) is created with its full set of TIRs. All other contexts are created with an empty set, then TIRs are added upon first usage when steering rules are added. We use a reference counting mechanism to make sure an RSS context is not removed before the rules pointing to it. Block ethtool set_channels operations when multiple RSS contexts exist, as currently the kernel doesn't protect against inconsistent channels configs that break non-default RSS contexts. Signed-off-by:
-
Tariq Toukan authored
Move from static to dynamic memory allocations for TIR. This is in preparation to supporting on-demand TIR operations in downstream patches, where every RSS context will be init with an empty set of TIRs. Signed-off-by:
-
Tariq Toukan authored
Code related to RSS is now encapsulated into a dedicated object and put into new files en/rss.{c,h}. All usages are converted. Signed-off-by: -
Tariq Toukan authored
Bring all fields that define and maintain RSS behavior together into a new structure. Align all usages with this new structure. Keep it hidden within rx_res.c. This helps supporting multiple RSS contexts in downstream patch. Use dynamic allocations for the RSS context. Signed-off-by:
-
