- 20 Mar, 2020 24 commits
-
-
David S. Miller authored
Lorenzo Bianconi says: ==================== add more xdp stats to veth driver Align veth xdp stats accounting to mellanox, intel and marvell implementation. Introduce the following xdp counters: - rx_xdp_tx - rx_xdp_tx_errors - tx_xdp_xmit - tx_xdp_xmit_errors - rx_xdp_redirect ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Lorenzo Bianconi authored
Remove atomic64_add from veth_xdp_xmit hotpath and rely on xdp_xmit_err/xdp_tx_err counters Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
Lorenzo Bianconi authored
Introduce xdp_xmit counter in order to distinguish between XDP_TX and ndo_xdp_xmit stats. Introduce the following ethtool counters: - rx_xdp_tx - rx_xdp_tx_errors - tx_xdp_xmit - tx_xdp_xmit_errors - rx_xdp_redirect Signed-off-by:
-
Lorenzo Bianconi authored
Distinguish between rx_drops and xdp_drops since the latter is already reported in rx_packets. Report xdp_drops in ethtool statistics Signed-off-by:
-
Lorenzo Bianconi authored
Introduce xdp_tx, xdp_redirect and rx_drops counters in veth_stats data structure. Move stats accounting in veth_poll. Remove xdp_xmit variable in veth_xdp_rcv_one/veth_xdp_rcv_skb and rely on veth_stats counters. This is a preliminary patch to align veth xdp statistics to mlx, intel and marvell xdp implementation Signed-off-by:
-
Lorenzo Bianconi authored
Move xdp stats in veth_stats data structure. This is a preliminary patch to align xdp statistics to mlx5, ixgbe and mvneta drivers Signed-off-by:
-
Christian Brauner authored
The CONFIG_SYSFS declaration of sysfs_group_change_owner() is different from the !CONFIG_SYSFS version and thus causes build failurs when !CONFIG_SYSFS is set. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 303a4276 ("sysfs: add sysfs_group{s}_change_owner()") Signed-off-by:
Christian Brauner <christian.brauner@ubuntu.com> Reported-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by:
-
David S. Miller authored
Antoine Tenart says: ==================== net: phy: mscc: add support for RGMII MAC mode This series adds support for the RGMII MAC mode for the VSC8584 PHY family and for RGMII_ID modes (Tx and/or Rx). I decided to drop the custom delay for now. I made some tests and it seemed to be working quite well. If we find out we really need to lower the delay, which I doubt, I'll send support for it. Since v2: - Dropped support for custom dt bindings. - Add the 2ns delay based on the interface mode. ==================== Signed-off-by: -
Antoine Tenart authored
This patch adds support for configuring the RGMII skew delays in Rx and Tx. The Rx and Tx skews are set based on the interface mode. By default their configuration is set to the default value in hardware (0.2ns); this means the driver do not rely anymore on the bootloader configuration. Then based on the interface mode being used, a 2ns delay is added: - RGMII_ID adds it for both Rx and Tx. - RGMII_RXID adds it for Rx. - RGMII_TXID adds it for Tx. Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Antoine Tenart authored
This patch adds support for connecting VSC8584 PHYs to the MAC using RGMII. Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Offload TC action skbedit priority Petr says: The TC action "skbedit priority P" has the effect of assigning skbprio of P to SKBs that it's applied on. In HW datapath of a switch, the corresponding action is assignment of internal switch priority. Spectrum switches allow setting of packet priority based on an ACL action, which is good match for the skbedit priority gadget. This patchset therefore implements offloading of this action to the Spectrum ACL engine. After a bit of refactoring in patch #1, patch #2 extends the skbedit action to support offloading of "priority" subcommand. On mlxsw side, in patch #3, the QOS_ACTION flexible action is added, with fields necessary for priority adjustment. In patch #4, "skbedit priority" is connected to that action. Patch #5 implements a new forwarding selftest, suitable for both SW- and HW-datapath testing. ==================== Signed-off-by: -
Petr Machata authored
Add a test that runs traffic through a port such that skbedit priority action acts on it during forwarding. Test that at egress, it is classified correctly according to the new priority at a PRIO qdisc. Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Petr Machata authored
Offload action skbedit priority when keyed to a flower classifier. The skb->priority field in Linux is very generic, so only allow setting the bottom 8 priorities and bounce anything else. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Petr Machata authored
The QOS_ACTION is used for manipulating the QoS attributes of a packet. Add the corresponding defines and helpers, in particular for the switch_priority override. Signed-off-by:
-
Petr Machata authored
The skbedit action "priority" is used for adjusting SKB priority. Allow drivers to offload the action by introducing two new skbedit getters and a new flow action, and initializing appropriately in tc_setup_flow_action(). Signed-off-by:
-
Petr Machata authored
The two functions is_tcf_skbedit_mark() and is_tcf_skbedit_ptype() have a very similar structure. A follow-up patch will add one more such function. Instead of more cut'n'pasting, extract a helper function that checks whether a TC action is an skbedit with the required flag. Convert the two existing functions into thin wrappers around the helper. Signed-off-by:
-
Dejin Zheng authored
it will check the return value of dwmac_dma_reset() in the stmmac_init_dma_engine() function and report an error if the return value is not zero. so don't need check here. Signed-off-by:
Dejin Zheng <zhengdejin5@gmail.com> Signed-off-by:
-
Antoine Tenart authored
Commit a5afc167 ("net: phy: mscc: add support for VSC8584 PHY") introduced a call to 'phy_write' storing its return value to a variable called 'ret'. But 'ret' never was checked for a possible error being returned, and hence was not used at all. Fix this by checking the return value and exiting the function if an error was returned. As this does not fix a known bug, this commit is mostly cosmetic and not sent as a fix. Signed-off-by:
-
YueHaibing authored
Remove including <linux/version.h> that don't need it. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
YueHaibing authored
Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/cavium/liquidio/lio_main.c: In function 'octeon_chip_specific_setup': drivers/net/ethernet/cavium/liquidio/lio_main.c:1378:8: warning: variable 's' set but not used [-Wunused-but-set-variable] It's not used since commit b6334be6 ("net/liquidio: Delete driver version assignment") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
The cited commit removed RTNL from tc_setup_flow_action(), but the function calls two tunnel key action helpers that use rtnl_dereference() to fetch the action's parameters. This leads to "suspicious RCU usage" warnings [1][2]. Change the helpers to use rcu_dereference_protected() while requiring the action's lock to be held. This is safe because the two helpers are only called from tc_setup_flow_action() which acquires the lock. [1] [ 156.950855] ============================= [ 156.955463] WARNING: suspicious RCU usage [ 156.960085] 5.6.0-rc5-custom-47426-gdfe43878d573 #2409 Not tainted [ 156.967116] ----------------------------- [ 156.971728] include/net/tc_act/tc_tunnel_key.h:31 suspicious rcu_dereference_protected() usage! [ 156.981583] [ 156.981583] other info that might help us debug this: [ 156.981583] [ 156.990675] [ 156.990675] rcu_scheduler_active = 2, debug_locks = 1 [ 156.998205] 1 lock held by tc/877: [ 157.002187] #0: ffff8881cbf7bea0 (&(&p->tcfa_lock)->rlock){+...}, at: tc_setup_flow_action+0xbe/0x4f78 [ 157.012866] [ 157.012866] stack backtrace: [ 157.017886] CPU: 2 PID: 877 Comm: tc Not tainted 5.6.0-rc5-custom-47426-gdfe43878d573 #2409 [ 157.027253] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016 [ 157.037389] Call Trace: [ 157.040170] dump_stack+0xfd/0x178 [ 157.044034] lockdep_rcu_suspicious+0x14a/0x153 [ 157.049157] tc_setup_flow_action+0x89f/0x4f78 [ 157.054227] fl_hw_replace_filter+0x375/0x640 [ 157.064348] fl_change+0x28ec/0x4f6b [ 157.088843] tc_new_tfilter+0x15e2/0x2260 [ 157.176801] rtnetlink_rcv_msg+0x8d6/0xb60 [ 157.190915] netlink_rcv_skb+0x177/0x460 [ 157.208884] rtnetlink_rcv+0x21/0x30 [ 157.212925] netlink_unicast+0x5d0/0x7f0 [ 157.227728] netlink_sendmsg+0x981/0xe90 [ 157.245416] ____sys_sendmsg+0x76d/0x8f0 [ 157.255348] ___sys_sendmsg+0x10f/0x190 [ 157.320308] __sys_sendmsg+0x115/0x1f0 [ 157.342553] __x64_sys_sendmsg+0x7d/0xc0 [ 157.346987] do_syscall_64+0xc1/0x600 [ 157.351142] entry_SYSCALL_64_after_hwframe+0x49/0xbe [2] [ 157.432346] ============================= [ 157.436937] WARNING: suspicious RCU usage [ 157.441537] 5.6.0-rc5-custom-47426-gdfe43878d573 #2409 Not tainted [ 157.448559] ----------------------------- [ 157.453204] include/net/tc_act/tc_tunnel_key.h:43 suspicious rcu_dereference_protected() usage! [ 157.463042] [ 157.463042] other info that might help us debug this: [ 157.463042] [ 157.472112] [ 157.472112] rcu_scheduler_active = 2, debug_locks = 1 [ 157.479529] 1 lock held by tc/877: [ 157.483442] #0: ffff8881cbf7bea0 (&(&p->tcfa_lock)->rlock){+...}, at: tc_setup_flow_action+0xbe/0x4f78 [ 157.494119] [ 157.494119] stack backtrace: [ 157.499114] CPU: 2 PID: 877 Comm: tc Not tainted 5.6.0-rc5-custom-47426-gdfe43878d573 #2409 [ 157.508485] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016 [ 157.518628] Call Trace: [ 157.521416] dump_stack+0xfd/0x178 [ 157.525293] lockdep_rcu_suspicious+0x14a/0x153 [ 157.530425] tc_setup_flow_action+0x993/0x4f78 [ 157.535505] fl_hw_replace_filter+0x375/0x640 [ 157.545650] fl_change+0x28ec/0x4f6b [ 157.570204] tc_new_tfilter+0x15e2/0x2260 [ 157.658199] rtnetlink_rcv_msg+0x8d6/0xb60 [ 157.672315] netlink_rcv_skb+0x177/0x460 [ 157.690278] rtnetlink_rcv+0x21/0x30 [ 157.694320] netlink_unicast+0x5d0/0x7f0 [ 157.709129] netlink_sendmsg+0x981/0xe90 [ 157.726813] ____sys_sendmsg+0x76d/0x8f0 [ 157.736725] ___sys_sendmsg+0x10f/0x190 [ 157.801721] __sys_sendmsg+0x115/0x1f0 [ 157.823967] __x64_sys_sendmsg+0x7d/0xc0 [ 157.828403] do_syscall_64+0xc1/0x600 [ 157.832558] entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: b15e7a6e ("net: sched: don't take rtnl lock during flow_action setup") Signed-off-by:Vlad Buslov <vladbu@mellanox.com> Signed-off-by:
-
Nikolay Aleksandrov authored
This patch adds support for vlan stats to be included when dumping vlan information. We have to dump them only when explicitly requested (thus the flag below) because that disables the vlan range compression and will make the dump significantly larger. In order to request the stats to be included we add a new dump attribute called BRIDGE_VLANDB_DUMP_FLAGS which can affect dumps with the following first flag: - BRIDGE_VLANDB_DUMPF_STATS The stats are intentionally nested and put into separate attributes to make it easier for extending later since we plan to add per-vlan mcast stats, drop stats and possibly STP stats. This is the last missing piece from the new vlan API which makes the dumped vlan information complete. A dump request which should include stats looks like: [BRIDGE_VLANDB_DUMP_FLAGS] |= BRIDGE_VLANDB_DUMPF_STATS A vlandb entry attribute with stats looks like: [BRIDGE_VLANDB_ENTRY] = { [BRIDGE_VLANDB_ENTRY_STATS] = { [BRIDGE_VLANDB_STATS_RX_BYTES] [BRIDGE_VLANDB_STATS_RX_PACKETS] ... } } Signed-off-by:Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Paolo Abeni authored
The name is misleading, it actually tracks the 'fully established' status. Reviewed-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
- 19 Mar, 2020 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-updates-2020-03-17 1) Compiler warnings and cleanup for the connection tracking series 2) Bug fixes for the connection tracking series 3) Fix devlink port register sequence 4) Last five patches in the series, By Eli cohen Add the support for forwarding traffic between two eswitch uplink representors (Hairpin for eswitch), using mlx5 termination tables to change the direction of a packet in hw from RX to TX pipeline. ==================== Signed-off-by: -
Heiner Kallweit authored
At least some integrated PHY's in RTL8168/RTL8125 chip versions support downshift, and the actual link speed can be read from a vendor-specific register. Info about this register was provided by Realtek. More details about downshift configuration (e.g. number of attempts) aren't available, therefore the downshift tunable is not implemented. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
- 18 Mar, 2020 14 commits
-
-
Petr Machata authored
In the commit referenced below, hw_stats_type of an entry is set for every entry that corresponds to a pedit action. However, the assignment is only done after the entry pointer is bumped, and therefore could overwrite memory outside of the entries array. The reason for this positioning may have been that the current entry's hw_stats_type is already set above, before the action-type dispatch. However, if there are no more actions, the assignment is wrong. And if there are, the next round of the for_each_action loop will make the assignment before the action-type dispatch anyway. Therefore fix this issue by simply reordering the two lines. Fixes: 74522e7b ("net: sched: set the hw_stats_type in pedit loop") Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: spectrum_cnt: Expose counter resources Jiri says: Capacity and utilization of existing flow and RIF counters are currently unavailable to be seen by the user. Use the existing devlink resources API to expose the information: $ sudo devlink resource show pci/0000:00:10.0 -v pci/0000:00:10.0: name kvd resource_path /kvd size 524288 unit entry dpipe_tables none name span_agents resource_path /span_agents size 8 occ 0 unit entry dpipe_tables none name counters resource_path /counters size 79872 occ 44 unit entry dpipe_tables none resources: name flow resource_path /counters/flow size 61440 occ 4 unit entry dpipe_tables none name rif resource_path /counters/rif size 18432 occ 40 unit entry dpipe_tables none ==================== Signed-off-by: -
Jiri Pirko authored
Add tests for mlxsw hw_stats types. Signed-off-by:
-
Jiri Pirko authored
Implement occupancy counting for counters and expose over devlink resource API. Signed-off-by:
-
Jiri Pirko authored
Put all init operations related to subpools into mlxsw_sp_counter_sub_pools_init(). Signed-off-by:
-
Jiri Pirko authored
Move the validation of subpools configuration, to avoid possible over commitment to resource registration. Add WARN_ON to indicate bug in the code. Signed-off-by:
-
Jiri Pirko authored
Implement devlink resources support for counter pools. Move the subpool sizes calculations into the new resources register function. Signed-off-by:
-
Jiri Pirko authored
Add new field to subpool struct that would indicate which resource id should be used to query the entry size for the subpool from the device. Signed-off-by:
-
Jiri Pirko authored
Currently, the global static array of subpools is used. Make it per-instance as multiple instances of the mlxsw driver can have different values. Signed-off-by:
-
Jiri Pirko authored
With the change that made the code to query counter bank size from device instead of using hard-coded value, the number of available counters changed for Spectrum-2. Adjust the limit in the selftests. Signed-off-by:
-
Jiri Pirko authored
The bank size is different between Spectrum versions. Also it is a resource that can be queried. So instead of hard coding the value in code, query it from the firmware. Signed-off-by:
-
Rahul Lakkireddy authored
Chelsio NICs have 3 filter regions, in following order of priority: 1. High Priority (HPFILTER) region (Highest Priority). 2. HASH region. 3. Normal FILTER region (Lowest Priority). Currently, there's a 1-to-1 mapping between the prio value passed by TC and the filter region index. However, it's possible to have multiple TC rules with the same prio value. In this case, if a region is exhausted, no attempt is made to try inserting the rule in the next available region. So, rework and remove the 1-to-1 mapping. Instead, dynamically select the region to insert the filter rule, as long as the new rule's prio value doesn't conflict with existing rules across all the 3 regions. Signed-off-by:
Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by:
-
Daniel Borkmann authored
This reverts the following commits: 8537f786 ("netfilter: Introduce egress hook") 5418d388 ("netfilter: Generalize ingress hook") b030f194 ("netfilter: Rename ingress hook include file") >From the discussion in [0], the author's main motivation to add a hook in fast path is for an out of tree kernel module, which is a red flag to begin with. Other mentioned potential use cases like NAT{64,46} is on future extensions w/o concrete code in the tree yet. Revert as suggested [1] given the weak justification to add more hooks to critical fast-path. [0] https://lore.kernel.org/netdev/cover.1583927267.git.lukas@wunner.de/ [1] https://lore.kernel.org/netdev/20200318.011152.72770718915606186.davem@davemloft.net/Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Cc: David Miller <davem@davemloft.net> Cc: Pablo Neira Ayuso <pablo@netfilter.org> Cc: Alexei Starovoitov <ast@kernel.org> Nacked-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
David S. Miller authored
Julian Wiedmann says: ==================== s390/qeth: updates 2020-03-18 please apply the following patch series for qeth to netdev's net-next tree. This consists of three parts: 1) support for __GFP_MEMALLOC, 2) several ethtool enhancements (.set_channels, SW Timestamping), 3) the usual cleanups. ==================== Signed-off-by:
-
