- 28 Oct, 2021 12 commits
-
-
Jakub Kicinski authored
Mat Martineau says: ==================== mptcp: Rework fwd memory allocation and one cleanup These patches from the MPTCP tree rework forward memory allocation for MPTCP (with some supporting changes in the net core), and also clean up an unused function parameter. Patch 1 updates TCP code but does not change any behavior, and creates some macros for reclaim thresholds that will be reused in the MPTCP code. Patch 2 adds sk_forward_alloc_get() to the networking core to support MPTCP's forward allocation with the diag interface. Patch 3 reworks forward memory for MPTCP. Patch 4 removes an unused arg and has no functional changes. ==================== Link: https://lore.kernel.org/r/20211026232916.179450-1-mathew.j.martineau@linux.intel.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Geliang Tang authored
Since mptcp_set_timeout() had removed from mptcp_push_release() in commit 33d41c9c ("mptcp: more accurate timeout"), the argument sk in mptcp_push_release() became useless. Let's drop it. Fixes: 33d41c9c ("mptcp: more accurate timeout") Reviewed-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Geliang Tang <geliang.tang@suse.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Paolo Abeni authored
All the mptcp receive path is protected by the msk socket spinlock. As consequences, the tx path has to play a few tricks to allocate the forward memory without acquiring the spinlock multiple times, making the overall TX path quite complex. This patch tries to clean-up a bit the tx path, using completely separated fwd memory allocation, for the rx and the tx path. The forward memory allocated in the rx path is now accounted in msk->rmem_fwd_alloc and is (still) protected by the msk socket spinlock. To cope with the above we provide a few MPTCP-specific variants for the helpers to charge, uncharge, reclaim and free the forward memory in the receive path. msk->sk_forward_alloc now accounts only the forward memory for the tx path, we can use the plain core sock helper to manipulate it and drop quite a bit of complexity. On memory pressure, both rx and tx fwd memories are reclaimed. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Paolo Abeni authored
A later patch will change the MPTCP memory accounting schema in such a way that MPTCP sockets will encode the total amount of forward allocated memory in two separate fields (one for tx and one for rx). MPTCP sockets will use their own helper to provide the accurate amount of fwd allocated memory. To allow the above, this patch adds a new, optional, sk method to fetch the fwd memory, wrap the call in a new helper and use it where it is appropriate. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Paolo Abeni authored
A following patch is going to implement a similar reclaim schema for the MPTCP protocol, with different locking. Let's define a couple of macros for the used thresholds, so that the latter code will be more easily maintainable. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
syzbot reported data-races in inet_getname() multiple times, it is time we fix this instead of pretending applications should not trigger them. getsockname() and getpeername() are not really considered fast path. v2: added the missing BPF_CGROUP_RUN_SA_PROG() declaration needed when CONFIG_CGROUP_BPF=n, as reported by kernel test robot <lkp@intel.com> syzbot typical report: BUG: KCSAN: data-race in __inet_hash_connect / inet_getname write to 0xffff888136d66cf8 of 2 bytes by task 14374 on cpu 1: __inet_hash_connect+0x7ec/0x950 net/ipv4/inet_hashtables.c:831 inet_hash_connect+0x85/0x90 net/ipv4/inet_hashtables.c:853 tcp_v4_connect+0x782/0xbb0 net/ipv4/tcp_ipv4.c:275 __inet_stream_connect+0x156/0x6e0 net/ipv4/af_inet.c:664 inet_stream_connect+0x44/0x70 net/ipv4/af_inet.c:728 __sys_connect_file net/socket.c:1896 [inline] __sys_connect+0x254/0x290 net/socket.c:1913 __do_sys_connect net/socket.c:1923 [inline] __se_sys_connect net/socket.c:1920 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1920 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xa0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff888136d66cf8 of 2 bytes by task 14408 on cpu 0: inet_getname+0x11f/0x170 net/ipv4/af_inet.c:790 __sys_getsockname+0x11d/0x1b0 net/socket.c:1946 __do_sys_getsockname net/socket.c:1961 [inline] __se_sys_getsockname net/socket.c:1958 [inline] __x64_sys_getsockname+0x3e/0x50 net/socket.c:1958 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xa0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x0000 -> 0xdee0 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 14408 Comm: syz-executor.3 Not tainted 5.15.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Link: https://lore.kernel.org/r/20211026213014.3026708-1-eric.dumazet@gmail.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Yajun Deng authored
There is a warning in xdp_rxq_info_unreg_mem_model() when reg_state isn't equal to REG_STATE_REGISTERED, so the warning in xdp_rxq_info_unreg() is redundant. Signed-off-by:
Yajun Deng <yajun.deng@linux.dev> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Link: https://lore.kernel.org/r/20211027013856.1866-1-yajun.deng@linux.devSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Commit 406f42fa ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it go through appropriate helpers. Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20211026175547.3198242-1-kuba@kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Use the new of_get_ethdev_address() helper for the cases where dev->dev_addr is passed in directly as the destination. @@ expression dev, np; @@ - of_get_mac_address(np, dev->dev_addr) + of_get_ethdev_address(np, dev) Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20211026175038.3197397-1-kuba@kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Guenter Roeck authored
Commit 4d98bb0d ("net: macb: Use mdio child node for MDIO bus if it exists") added code to detect if a 'mdio' child node exists to the macb driver. Ths added code does, however, not actually check if the child node exists, but if the parent node exists. This results in errors such as macb 10090000.ethernet eth0: Could not attach PHY (-19) if there is no 'mdio' child node. Fix the code to actually check for the child node. Fixes: 4d98bb0d ("net: macb: Use mdio child node for MDIO bus if it exists") Cc: Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
Sean Anderson <sean.anderson@seco.com> Tested-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20211026173950.353636-1-linux@roeck-us.netSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Seth Forshee authored
The only valid values for a miniq pointer are NULL or a pointer to miniq1 or miniq2, so testing for miniq_old != &miniq1 is functionally equivalent to testing that it is NULL or equal to &miniq2. Suggested-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Seth Forshee <sforshee@digitalocean.com> Link: https://lore.kernel.org/r/20211026183721.137930-1-seth@forshee.meSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Seth Forshee authored
Currently rcu_barrier() is used to ensure that no readers of the inactive mini_Qdisc buffer remain before it is reused. This waits for any pending RCU callbacks to complete, when all that is actually required is to wait for one RCU grace period to elapse after the buffer was made inactive. This means that using rcu_barrier() may result in unnecessary waits. To improve this, store the current RCU state when a buffer is made inactive and use poll_state_synchronize_rcu() to check whether a full grace period has elapsed before reusing it. If a full grace period has not elapsed, wait for a grace period to elapse, and in the non-RT case use synchronize_rcu_expedited() to hasten it. Since this approach eliminates the RCU callback it is no longer necessary to synchronize_rcu() in the tp_head==NULL case. However, the RCU state should still be saved for the previously active buffer. Before this change I would typically see mini_qdisc_pair_swap() take tens of milliseconds to complete. After this change it typcially finishes in less than 1 ms, and often it takes just a few microseconds. Thanks to Paul for walking me through the options for improving this. Cc: "Paul E. McKenney" <paulmck@kernel.org> Signed-off-by:
Seth Forshee <sforshee@digitalocean.com> Link: https://lore.kernel.org/r/20211026130700.121189-1-seth@forshee.meSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- 27 Oct, 2021 28 commits
-
-
Arnd Bergmann authored
The tc_gred_qopt_offload structure has grown too big to be on the stack for 32-bit architectures after recent changes. net/sched/sch_gred.c:903:13: error: stack frame size (1180) exceeds limit (1024) in 'gred_destroy' [-Werror,-Wframe-larger-than] net/sched/sch_gred.c:310:13: error: stack frame size (1212) exceeds limit (1024) in 'gred_offload' [-Werror,-Wframe-larger-than] Use dynamic allocation per qdisc to avoid this. Fixes: 50dc9a85 ("net: sched: Merge Qdisc::bstats and Qdisc::cpu_bstats data types") Fixes: 67c9e627 ("net: sched: Protect Qdisc::bstats with u64_stats") Suggested-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20211026100711.nalhttf6mbe6sudx@linutronix.deSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Leon Romanovsky says: ==================== Two reverts to calm down devlink discussion Two reverts as was discussed in [1], fast, easy and wrong in long run solution to syzkaller bug [2]. [1] https://lore.kernel.org/all/20211026120234.3408fbcc@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com [2] https://lore.kernel.org/netdev/000000000000af277405cf0a7ef0@google.com/ ==================== Link: https://lore.kernel.org/r/cover.1635276828.git.leonro@nvidia.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Leon Romanovsky authored
This reverts commit 22849b5e as it revealed that mlxsw and netdevsim (copy/paste from mlxsw) reregisters devlink objects during another devlink user triggered command. Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Leon Romanovsky authored
This reverts commit 8bbeed48 as it revealed that mlxsw and netdevsim (copy/paste from mlxsw) reregisters devlink objects during another devlink user triggered command. Fixes: 22849b5e ("devlink: Remove not-executed trap policer notifications") Reported-by: syzbot+93d5accfaefceedf43c1@syzkaller.appspotmail.com Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
David S. Miller authored
Vladimir Oltean says: ==================== Bridge FDB refactoring This series refactors the br_fdb.c, br_switchdev.c and switchdev.c files to offer the same level of functionality with a bit less code, and to clarify the purpose of some functions. No functional change intended. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
To reduce code churn, the same patch makes multiple changes, since they all touch the same lines: 1. The implementations for these two are identical, just with different function pointers. Reduce duplications and name the function pointers "mod_cb" instead of "add_cb" and "del_cb". Pass the event as argument. 2. Drop the "const" attribute from "orig_dev". If the driver needs to check whether orig_dev belongs to itself and then call_switchdev_notifiers(orig_dev, SWITCHDEV_FDB_OFFLOADED), it can't, because call_switchdev_notifiers takes a non-const struct net_device *. 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>
-
Vladimir Oltean authored
There are two places where a switchdev FDB entry is constructed, one is br_switchdev_fdb_notify() and the other is br_fdb_replay(). One uses a struct initializer, and the other declares the structure as uninitialized and populates the elements one by one. One problem when introducing new members of struct switchdev_notifier_fdb_info is that there is a risk for one of these functions to run with an uninitialized value. So centralize the logic of populating such structure into a dedicated function. Being the primary location where these structures are created, using an uninitialized variable and populating the members one by one should be fine, since this one function is supposed to assign values to all its members. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
br_fdb_replay is only called from switchdev code paths, so it makes sense to be disabled if switchdev is not enabled in the first place. As opposed to br_mdb_replay and br_vlan_replay which might be turned off depending on bridge support for multicast and VLANs, FDB support is always on. So moving br_mdb_replay and br_vlan_replay inside br_switchdev.c would mean adding some #ifdef's in br_switchdev.c, so we keep those where they are. The reason for the movement is that in future changes there will be some code reuse between br_switchdev_fdb_notify and br_fdb_replay. 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>
-
Vladimir Oltean authored
We can express the same logic without an "if" condition as big as the function, just return early if the kmem_cache_alloc() call fails. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
br_fdb_insert() is a wrapper over fdb_insert() that also takes the bridge hash_lock. With fdb_insert() being renamed to fdb_add_local(), rename br_fdb_insert() to br_fdb_add_local(). Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
fdb_insert() is not a descriptive name for this function, and also easy to confuse with __br_fdb_add(), fdb_add_entry(), br_fdb_update(). Even more confusingly, it is not even related in any way with those functions, neither one calls the other. Since fdb_insert() basically deals with the creation of a BR_FDB_LOCAL entry and is called only from functions where that is the intention: - br_fdb_changeaddr - br_fdb_change_mac_address - br_fdb_insert then rename it to fdb_add_local(), because its removal counterpart is called fdb_delete_local(). Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
fdb_insert() has a forward declaration because its first caller, br_fdb_changeaddr(), is declared before fdb_create(), a function which fdb_insert() needs. This patch moves the 2 functions above br_fdb_changeaddr() and deletes the forward declaration for fdb_insert(). Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
fdb_notify() has a forward declaration because its first caller, fdb_delete(), is declared before 3 functions that fdb_notify() needs: fdb_to_nud(), fdb_fill_info() and fdb_nlmsg_size(). This patch moves the aforementioned 4 functions above fdb_delete() and deletes the forward declaration. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Russell King says: ==================== Convert mvneta to phylink supported_interfaces This patch series converts mvneta to use phylinks supported_interfaces bitmap to simplify the validate() implementation. The patches: 1) Add the supported interface modes the supported_interfaces bitmap. 2) Removes the checks for the interface type being supported from the validate callback 3) Removes the now unnecessary checks and call to phylink_helper_basex_speed() to support switching between 1000base-X and 2500base-X for SFPs (3) becomes possible because when asking the MAC for its complete support, we walk all supported interfaces which will include 1000base-X and 2500base-X only if the comphy is present. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Russell King (Oracle) authored
Now that we have a better method to select SFP interface modes, we no longer need to use phylink_helper_basex_speed() in a driver's validation function, and we can also get rid of our hack to indicate both 1000base-X and 2500base-X if the comphy is present to make that work. Remove this hack and use of phylink_helper_basex_speed(). Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Russell King (Oracle) authored
As phylink checks the interface mode against the supported_interfaces bitmap, we no longer need to validate the interface mode in the validation function. Remove this to simplify it. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Russell King authored
Populate the phy_interface_t bitmap for the Marvell mvneta driver with interfaces modes supported by the MAC. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> 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-2021-10-26 HW-GRO support in mlx5 Beside the HW GRO this series includes two trivial non-mlx5 patches: - net: Prevent HW-GRO and LRO features operate together - lib: bitmap: Introduce node-aware alloc API Khalid Manaa Says: ================== This series implements the HW-GRO offload using the HW feature SHAMPO. HW-GRO: Hardware offload for the Generic Receive Offload feature. SHAMPO: Split Headers And Merge Payload Offload. This feature performs headers data split for each received packed and merge the payloads of the packets of the same session. There are new HW components for this feature: The headers buffer: – cyclic buffer where the packets headers will be located Reservation buffer: – capability to divide RQ WQEs to reservations, a definite size in granularity of 4KB, the reservation is used to define the largest segment that we can create by packets stitching. Each reservation will have a session and the new received packet can be merged to the session, terminate it, or open a new one according to the match criteria. When a new packet is received the headers will be written to the headers buffer and the data will be written to the reservation, in case the packet matches the session the data will be written continuously otherwise it will be written after performing an alignment. SHAMPO RQ, WQ and CQE changes: ----------------------------- RQ (receive queue) new params: -shampo_no_match_alignment_granularity: the HW alignment granularity in case the received packet doesn't match the current session. -shampo_match_criteria_type: the type of match criteria. -reservation_timeout: the maximum time that the HW will hold the reservation. -Each RQ has SKB that represents the current opened flow. WQ (work queue) new params: -headers_mkey: mkey that represents the headers buffer, where the packets headers will be written by the HW. -shampo_enable: flag to verify if the WQ supports SHAMPO feature. -log_reservation_size: the log of the reservation size where the data of the packet will be written by the HW. -log_max_num_of_packets_per_reservation: log of the maximum number of packets that can be written to the same reservation. -log_headers_entry_size: log of the header entry size of the headers buffer. -log_headers_buffer_entry_num: log of the entries number of the headers buffer. CQEs (Completion queue entry) SHAMPO fields: -match: in case it is set, then the current packet matches the opened session. -flush: in case it is set, the opened session must be flushed. -header_size: the size of the packet’s headers. -header_entry_index: the entry index in the headers buffer of the received packet headers. -data_offset: the offset of the received packet data in the WQE. HW-GRO works as follow: ---------------------- The feature can be enabled on the interface using the ethtool command by setting on rx-gro-hw. When the feature is on the mlx5 driver will reopen the RQ to support the SHAMPO feature: Will allocate the headers buffer and fill the parameters regarding the reservation and the match criteria. Receive packet flow: each RQ will hold SKB that represents the current GRO opened session. The driver has a new CQE handler mlx5e_handle_rx_cqe_mpwrq_shampo which will use the CQE SHAMPO params to extract the location of the packet’s headers in the headers buffer and the location of the packets data in the RQ. Also, the CQE has two flags flush and match that indicate if the current packet matches the current session or not and if we need to close the session. In case there is an opened session, and we receive a matched packet then the handler will merge the packet's payload to the current SKB, in case we receive no match then the handler will flush the SKB and create a new one for the new packet. In case the flash flag is set then the driver will close the session, the SKB will be passed to the network stack. In case the driver merges packets in the SKB, before passing the SKB to the network stack the driver will update the checksum of the packet’s headers. SKB build: --------- The driver will build a new SKB in the following situations: in case there is no current opened session. In case the current packet doesn’t match the current session. In case there is no place to add the packets data to the SKB that represents the current session. Otherwise, the driver will add the packet’s data to the SKB. When the driver builds a new SKB, the linear area will contain only the packet headers and the data will be added to the SKB fragments. In case the entry size of the headers buffer is sufficient to build the SKB it will be used, otherwise the driver will allocate new memory to build the SKB. ================== ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Maor Dickman authored
Fix "no previous prototype" W=1 warnings when CONFIG_MLX5_CORE_EN is not set: drivers/net/ethernet/mellanox/mlx5/core/lag_mp.h:34:6: error: no previous prototype for ‘mlx5_lag_is_multipath’ [-Werror=missing-prototypes] 34 | bool mlx5_lag_is_multipath(struct mlx5_core_dev *dev) { return false; } | ^~~~~~~~~~~~~~~~~~~~~ Fixes: 14fe2471 ("net/mlx5: Lag, change multipath and bonding to be mutually exclusive") Signed-off-by:
Maor Dickman <maord@nvidia.com>
-
Khalid Manaa authored
HW-GRO and CQE-COMPRESS are mutually exclusive, this commit adds this restriction. Signed-off-by:
Khalid Manaa <khalidm@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Khalid Manaa authored
This commit introduces HW-GRO offload by using the SHAMPO feature - Add set feature handler for HW-GRO. Signed-off-by:
Ben Ben-Ishay <benishay@nvidia.com> Signed-off-by:
Khalid Manaa <khalidm@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Khalid Manaa authored
This patch adds HW_GRO counters to RX packets statistics: - gro_match_packets: counter of received packets with set match flag. - gro_packets: counter of received packets over the HW_GRO feature, this counter is increased by one for every received HW_GRO cqe. - gro_bytes: counter of received bytes over the HW_GRO feature, this counter is increased by the received bytes for every received HW_GRO cqe. - gro_skbs: counter of built HW_GRO skbs, increased by one when we flush HW_GRO skb (when we call a napi_gro_receive with hw_gro skb). - gro_large_hds: counter of received packets with large headers size, in case the packet needs new SKB, the driver will allocate new one and will not use the headers entry to build it. Signed-off-by:
Khalid Manaa <khalidm@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Khalid Manaa authored
this patch updates the SHAMPO CQE handler to support HW_GRO, changes in the SHAMPO CQE handler: - CQE match and flush fields are used to determine if to build new skb using the new received packet, or to add the received packet data to the existing RQ.hw_gro_skb, also this fields are used to determine when to flush the skb. - in the end of the function mlx5e_poll_rx_cq the RQ.hw_gro_skb is flushed. Signed-off-by:
Khalid Manaa <khalidm@nvidia.com> Signed-off-by:
Ben Ben-Ishay <benishay@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Ben Ben-Ishay authored
The header buffer is used to store the headers of the rx packets. The header buffer size deduced from WorkQueue size + restriction of max packets per WorkQueueElement. This commit adds the functionality for posting/updating memory for the header buffer during the posting/updating of WQEs. Signed-off-by:
Ben Ben-Ishay <benishay@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Khalid Manaa authored
This patch adds the new CQE SHAMPO fields: - flush: indicates that we must close the current session and pass the SKB to the network stack. - match: indicates that the current packet matches the oppened session, the packet will be merge into the current SKB. - header_size: the size of the packet headers that written into the headers buffer. - header_entry_index: the entry index in the headers buffer. - data_offset: packets data offset in the WQE. Also new cqe handler is added to handle SHAMPO packets: - The new handler uses CQE SHAMPO fields to build the SKB. CQE's Flush and match fields are not used in this patch, packets are not merged in this patch. Signed-off-by:
Khalid Manaa <khalidm@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Ben Ben-Ishay authored
This commit introduces the control path infrastructure for SHAMPO feature. SHAMPO feature enables packet stitching by splitting packets to header and payload, the header is placed on a dedicated buffer and the payload on the RX ring, this allows stitching the data part of a flow together continuously in the receive buffer. SHAMPO feature is implemented as linked list striding RQ feature. To support packets splitting and payload stitching: - Enlarge the ICOSQ and the correspond CQ to support the header buffer memory regions. - Add support to create linked list striding RQ with SHAMPO feature set in the open_rq function. - Add deallocation function and corresponded calls for SHAMPO header buffer. - Add mlx5e_create_umr_klm_mkey to support KLM mkey for the header buffer. - Rename mlx5e_create_umr_mkey to mlx5e_create_umr_mtt_mkey. Signed-off-by:
Ben Ben-Ishay <benishay@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Ben Ben-Ishay authored
This commit adds the needed definitions for using the klm_umr_wqe. UMR stands for user-mode memory registration, is a mechanism to alter address translation properties of MKEY by posting WorkQueueElement aka WQE on send queue. MKEY stands for memory key, MKEY are used to describe a region in memory that can be later used by HW. KLM stands for {Key, Length, MemVa}, KLM_MKEY is indirect MKEY that enables to map multiple memory spaces with different sizes in unified MKEY. klm_umr_wqe is a UMR that use to update a KLM_MKEY. SHAMPO feature uses KLM_MKEY for memory registration of his header buffer. Signed-off-by:
Ben Ben-Ishay <benishay@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Khalid Manaa authored
This series introduces new packet merge type, therefore rename lro functions to packet merge to support the new merge type: - Generalize + rename mlx5e_build_tir_ctx_lro to mlx5e_build_tir_ctx_packet_merge. - Rename mlx5e_modify_tirs_lro to mlx5e_modify_tirs_packet_merge. - Rename lro bit in mlx5_ifc_modify_tir_bitmask_bits to packet_merge. - Rename lro_en in mlx5e_params to packet_merge_type type and combine packet_merge params into one struct mlx5e_packet_merge_param. Signed-off-by:
Khalid Manaa <khalidm@nvidia.com> Signed-off-by:
Ben Ben-Ishay <benishay@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-