- 10 Jul, 2020 26 commits
-
-
Vladyslav Tarasiuk authored
Prepare a common routine in devlink_health_reporter_create() for usage in similar functions for devlink port health reporters. Signed-off-by: Vladyslav Tarasiuk <vladyslavt@mellanox.com> Reviewed-by: Moshe Shemesh <moshe@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-updates-2020-07-09 This series provides updates to mlx5 CT (connection tracking) offloads For more information please see tag log below. Please pull and let me know if there is any problem. The following conflict is expected when net is merged into net-next: to resolve just use the hunks from net-next. <<<<<<< HEAD (net-next) mlx5_tc_ct_del_ft_entry(ct_priv, entry); kfree(entry); ======= (net) mlx5_tc_ct_entry_del_rules(ct_priv, entry); kfree(entry); >>>>>>> b1a7d5bdfe54c98eca46e2c997d4e3b1484a49af mlx5 connection tracking offloads updates: 1) Restore CT state from lookup in zone instead of tupleid On a miss, Use this zone + 5 tuple taken from the skb, to lookup the CT entry and restore it, instead of the driver allocated tuple id. This improves flow insertion rate by avoiding the allocation of a header rewrite context to maintain the tupleid. 2) Re-use modify header HW objects for identical modify actions. 3) Expand tunnel register mappings Reg_c1 is 32 bits wide. Before this patchset, 24 bit were allocated for the tuple_id, 6 bits for tunnel mapping and 2 bits for tunnel options mappings. Restoring the ct state from zone lookup instead of tuple id requires reg_c1 to store 8 bits mapping the ct zone, leaving 24 bits for tunnel mappings. Expand tunnel and tunnel options register mappings to 12 bit each. 4) Trivial cleanup and fixes. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jakub Kicinski says: ==================== udp_tunnel: add NIC RX port offload infrastructure Kernel has a facility to notify drivers about the UDP tunnel ports so that devices can recognize tunneled packets. This is important mostly for RX - devices which don't support CHECKSUM_COMPLETE can report checksums of inner packets, and compute RSS over inner headers. Some drivers also match the UDP tunnel ports also for TX, although doing so may lead to false positives and negatives. Unfortunately the user experience when trying to take adavantage of these facilities is suboptimal. First of all there is no way for users to check which ports are offloaded. Many drivers resort to printing messages to aid debugging, other use debugfs. Even worse the availability of the RX features (NETIF_F_RX_UDP_TUNNEL_PORT) is established purely on the basis of the driver having the ndos installed. For most drivers, however, the ability to perform offloads is contingent on device capabilities (driver support multiple device and firmware versions). Unless driver resorts to hackish clearing of features set incorrectly by the core - users are left guessing whether their device really supports UDP tunnel port offload or not. There is currently no way to indicate or configure whether RX features include just the checksum offload or checksum and using inner headers for RSS. Many drivers default to not using inner headers for RSS because most implementations populate the source port with entropy from the inner headers. This, however, is not always the case, for example certain switches are only able to use a fixed source port during encapsulation. We have also seen many driver authors get the intricacies of UDP tunnel port offloads wrong. Most commonly the drivers forget to perform reference counting, or take sleeping locks in the callbacks. This work tries to improve the situation by pulling the UDP tunnel port table maintenance out of the drivers. It turns out that almost all drivers maintain a fixed size table of ports (in most cases one per tunnel type), so we can take care of all the refcounting in the core, and let the driver specify if they need to sleep in the callbacks or not. The new common implementation will also support replacing ports - when a port is removed from a full table it will try to find a previously missing port to take its place. This patch only implements the core functionality along with a few drivers I was hoping to test manually [1] along with a test based on a netdevsim implementation. Following patches will convert all the drivers. Once that's complete we can remove the ndos, and rely directly on the new infrastrucutre. Then after RSS (RXFH) is converted to netlink we can add the ability to configure the use of inner RSS headers for UDP tunnels. [1] Unfortunately I wasn't able to, turns out 2 of the devices I had access to were older generation or had old FW, and they did not actually support UDP tunnel port notifications (see the second paragraph). The thrid device appears to program the UDP ports correctly but it generates bad UDP checksums with or without these patches. Long story short - I'd appreciate reviews and testing here.. v4: - better build fix (hopefully this one does it..) v3: - fix build issue; - improve bnxt changes. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Convert to new infra, make use of the ability to sleep in the callback. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Convert to new infra, taking advantage of sleeping in callbacks. v2: - use bp->*_fw_dst_port_id != INVALID_HW_RING_ID as indication that the offload is active. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Make use of new common udp_tunnel_nic infra. ixgbe supports IPv4 only, and only single VxLAN and Geneve ports (one each). v2: - split out the RXCSUM feature handling to separate change; - declare structs separately; - use ti.type instead of assuming table 0 is VxLAN; - move setting netdev->udp_tunnel_nic_info to its own switch. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
It appears the clearing of UDP tunnel ports when RXCSUM is disabled is unnecessary. Driver will not pay attention to checksum bits if RXCSUM is not set, so we can let the hardware parse the packets. Note that the UDP tunnel port NDO handlers don't pay attention to the state of RXCSUM, so the ports could had been re-programmed, anyway. This cleanup simplifies later conversion patch. v2: - break this out of the following patch. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Add validating the UDP tunnel infra works. $ ./udp_tunnel_nic.sh PASSED all 383 checks Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Add UDP tunnel port handlers to our fake driver so we can test the core infra. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Add an interface to report offloaded UDP ports via ethtool netlink. Now that core takes care of tracking which UDP tunnel ports the NICs are aware of we can quite easily export this information out to user space. The responsibility of writing the netlink dumps is split between ethtool code and udp_tunnel_nic.c - since udp_tunnel module may not always be loaded, yet we should always report the capabilities of the NIC. $ ethtool --show-tunnels eth0 Tunnel information for eth0: UDP port table 0: Size: 4 Types: vxlan No entries UDP port table 1: Size: 4 Types: geneve, vxlan-gpe Entries (1): port 1230, vxlan-gpe v4: - back to v2, build fix is now directly in udp_tunnel.h v3: - don't compile ETHTOOL_MSG_TUNNEL_INFO_GET in if CONFIG_INET not set. v2: - fix string set count, - reorder enums in the uAPI, - fix type of ETHTOOL_A_TUNNEL_UDP_TABLE_TYPES to bitset in docs and comments. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Cater to devices which: (a) may want to sleep in the callbacks; (b) only have IPv4 support; (c) need all the programming to happen while the netdev is up. Drivers attach UDP tunnel offload info struct to their netdevs, where they declare how many UDP ports of various tunnel types they support. Core takes care of tracking which ports to offload. Use a fixed-size array since this matches what almost all drivers do, and avoids a complexity and uncertainty around memory allocations in an atomic context. Make sure that tunnel drivers don't try to replay the ports when new NIC netdev is registered. Automatic replays would mess up reference counting, and will be removed completely once all drivers are converted. v4: - use a #define NULL to avoid build issues with CONFIG_INET=n. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Make it possible to use tunnel types as flags more easily. There doesn't appear to be any user using the type as an array index, so this should make no difference. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
debugfs_create_u32_array() allocates a small structure to wrap the data and size information about the array. If users ever try to remove the file this leads to a leak since nothing ever frees this wrapper. That said there are no upstream users of debugfs_create_u32_array() that'd remove a u32 array file (we only have one u32 array user in CMA), so there is no real bug here. Make callers pass a wrapper they allocated. This way the lifetime management of the wrapper is on the caller, and we can avoid the potential leak in debugfs. CC: Chucheng Luo <luochucheng@vivo.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Roi Dayan authored
Before this commit, on ft flush, ft entries were not removed from the ct_tuple hashtables. Fix it. Fixes: ac991b48 ("net/mlx5e: CT: Offload established flows") Signed-off-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Eli Britstein <elibr@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Saeed Mahameed authored
"flow" parameter is not used in __mlx5_tc_ct_flow_offload_clear(), remove it. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com>
-
Saeed Mahameed authored
Instead of having to deal with converting between int and ERR_PTR for return values in mlx5_tc_ct_flow_offload(), make the internal helper functions return a ptr to mlx5_flow_handle instead of passing it as output param, this will also avoid gcc confusion and false alarms, thus we remove the redundant ERR_PTR rule initialization. Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Suggested-by: Jason Gunthorpe <jgg@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com>
-
Paul Blakey authored
Reg_c1 is 32 bits wide. Originally, 24 bit were allocated for the tuple_id, 6 bits for tunnel mapping and 2 bits for tunnel options mappings. Restoring the ct state from zone lookup instead of tuple id requires reg_c1 to store 8 bits mapping the ct zone, leaving 24 bits for tunnel mappings. Expand tunnel and tunnel options register mappings to 12 bit each. Signed-off-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Paul Blakey authored
Use a single byte mapping for zone restore register (zone matching remains 16 bit). This makes room for using the freed 8 bits on register C1 for mapping more tunnels and tunnel options. Signed-off-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Paul Blakey authored
After removing the tupleid register which changed per tuple, tuple modify headers set the ct_state, zone, mark, and label registers. For non-natted tuples going through the same tc rules path, their values will be the same, and all their modify headers will be the same. Re-use tuple modify header when possible, by adding each new modify header to an hahstable, and looking up identical ones before creating a new one. Signed-off-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Paul Blakey authored
Refactor sharing of mod headers to new file and while there, remove spin lock and flows list, as this is only used for warn on. Use the generic API in the next patch to re-use tuple modify headers for identical modify actions, Signed-off-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Paul Blakey authored
Remove tupleid, and replace it with zone_restore, which is the zone an established tuple sets after match. On miss, Use this zone + tuple taken from the skb, to lookup the ct entry and restore it. This improves flow insertion rate by avoiding the allocation of a header rewrite context. Signed-off-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Paul Blakey authored
Next patches will remove the tupleid registers that is used to restore the ct state on miss, and instead use the tuple on the missed packet to lookup which state to restore. Disable tuple rewrites after connection tracking. For tuple rewrites, inject a ct_state=-trk match so it won't change the tuple for established flows (+trk) that passed connection tracking, and instead miss to software. Signed-off-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Oz Shlomo authored
The next patch will pass the mlx5e_priv struct to the modify_header_match_supported method. Use this opportunity to refactor the existing pr_info call to a netdev_info call. Signed-off-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Paul Blakey authored
With ct clear we don't jump to the ct tables, so header rewrite of 5-tuple can be done in place (and not moved to after the CT action). Check for ct clear action, and if so, allow 5-tuple header rewrite. Signed-off-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Paul Blakey authored
Save original tuple and natted tuple in two new hashtables. This is a pre-step for restoring ct state after hw miss by performing a 5-tuple lookup on the hash tables. Signed-off-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Parav Pandit authored
When eswitch is unsupported, currently -EPERM error code is returned instead of -EOPNOTSUPP. Due to this VF device's devlink virtual port is not enumerated because port_function_get() callback returned -EPERM instead of -EOPNOTSUPP. Hence, return the error code -EOPNOTSUPP when eswitch is unsupported. Fixes: bd939753 ("net/mlx5: E-switch, Introduce and use eswitch support check helper") Signed-off-by: Parav Pandit <parav@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
- 09 Jul, 2020 14 commits
-
-
David S. Miller authored
Ido Schimmel says: ==================== Expose port split attributes Danielle says: Currently, user space has no way of knowing if a port can be split and into how many ports. Among other things, this makes it impossible to write generic tests for port split functionality. Therefore, this set exposes two new devlink port attributes to user space: Number of lanes and whether the port can be split or not. Patch set overview: Patches #1-#4 cleanup 'struct devlink_port_attrs' and reduce the number of parameters passed between drivers and devlink via devlink_port_attrs_set() Patch #5 adds devlink port lanes attributes Patches #6-#7 add devlink port splittable attribute Patch #8 exploits the fact that devlink is now aware of port's number of lanes and whether the port can be split or not and moves some checks from drivers to devlink Patch #9 adds a port split test Changes since v2: * Remove some local variables from patch #3 * Reword function description in patch #5 * Fix a bug in patch #8 * Add a test for the splittable attribute in patch #9 Changes since v1: * Rename 'width' attribute to 'lanes' * Add 'splittable' attribute * Move checks from drivers to devlink ==================== Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Danielle Ratson authored
Test port split configuration using previously added number of port lanes attribute. Check that all the splittable ports are successfully split to their maximum number of lanes and below, and that those which are not splittable fail to be split. Test output example: TEST: swp4 is unsplittable [ OK ] TEST: split port swp53 into 4 [ OK ] TEST: Unsplit port pci/0000:03:00.0/25 [ OK ] TEST: split port swp53 into 2 [ OK ] TEST: Unsplit port pci/0000:03:00.0/25 [ OK ] Signed-off-by: Danielle Ratson <danieller@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Danielle Ratson authored
Currently, all the input checks are done in driver. After adding the split capability to devlink port, move the checks to devlink. Signed-off-by: Danielle Ratson <danieller@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Danielle Ratson authored
Add a new attribute that indicates the split ability of devlink port. Drivers are expected to set it via devlink_port_attrs_set(), before registering the port. Signed-off-by: Danielle Ratson <danieller@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Danielle Ratson authored
Currently, port attributes like flavour, port number and whether the port was split are set when initializing a port. Set the split ability of the port as well, based on port_mapping->width field and split attribute of devlink port in spectrum, so that it could be easily passed to devlink in the next patch. Signed-off-by: Danielle Ratson <danieller@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Danielle Ratson authored
Add a new devlink port attribute that indicates the port's number of lanes. Drivers are expected to set it via devlink_port_attrs_set(), before registering the port. The attribute is not passed to user space in case the number of lanes is invalid (0). Signed-off-by: Danielle Ratson <danieller@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Danielle Ratson authored
Currently, port attributes like flavour, port number and whether the port was split are set when initializing a port. Set the number of lanes of the port as well so that it could be easily passed to devlink in the next patch. Signed-off-by: Danielle Ratson <danieller@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Danielle Ratson authored
Currently, devlink_port_attrs_set accepts a long list of parameters, that most of them are devlink port's attributes. Use the devlink_port_attrs struct to replace the relevant parameters. Signed-off-by: Danielle Ratson <danieller@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Danielle Ratson authored
The struct devlink_port_attrs holds the attributes of devlink_port. Similarly to the previous patch, 'switch_port' attribute is another exception. Move 'switch_port' to be devlink_port's field. Signed-off-by: Danielle Ratson <danieller@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Danielle Ratson authored
The struct devlink_port_attrs holds the attributes of devlink_port. The 'set' field is not devlink_port's attribute as opposed to most of the others. Move 'set' to be devlink_port's field called 'attrs_set'. Signed-off-by: Danielle Ratson <danieller@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
kernel test robot authored
drivers/net/phy/mscc/mscc_ptp.c:1496:1-3: WARNING: PTR_ERR_OR_ZERO can be used Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Generated by: scripts/coccinelle/api/ptr_ret.cocci Fixes: 7d272e63 ("net: phy: mscc: timestamping and PHC support") CC: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: kernel test robot <lkp@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
Currently the u16 skb->vlan_tci is being right shifted twice by VLAN_PRIO_SHIFT, once in the macro skb_vlan_tag_get_pri and explicitly by VLAN_PRIO_SHIFT afterwards. The combined shift amount is larger than the u16 so the end result is always zero. Remove the second explicit shift as this is extraneous. Fixes: 6e9fdb60 ("net: systemport: Add support for VLAN transmit acceleration") Addresses-Coverity: ("Operands don't affect result") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Paolo Abeni says: ==================== mptcp: introduce msk diag interface This series implements the diag interface for the MPTCP sockets. Since the MPTCP protocol value can't be represented with the current diag uAPI, the first patch introduces an extended attribute allowing user-space to specify lager protocol values. The token APIs are then extended to allow traversing the whole token container. Patch 3 carries the actual diag interface implementation, and later patch bring-in some functional self-tests. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paolo Abeni authored
basic functional test, triggering the msk diag interface code. Require appropriate iproute2 support, skip elsewhere. Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-