- 29 Sep, 2022 40 commits
-
-
Liu Shixin authored
Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code. No functional change. Signed-off-by:
Liu Shixin <liushixin2@huawei.com> Link: https://lore.kernel.org/r/20220927111925.2424100-1-liushixin2@huawei.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Shang XiaoJing authored
Use skb_put_data() instead of skb_put() and memcpy(), which is clear. Signed-off-by:
Shang XiaoJing <shangxiaojing@huawei.com> Link: https://lore.kernel.org/r/20220927024511.14665-1-shangxiaojing@huawei.comSigned-off-by:
-
Shang XiaoJing authored
Use skb_put_data() instead of skb_put() and memcpy(), which is clear. Signed-off-by:
-
Shang XiaoJing authored
Use skb_put_data() instead of skb_put() and memcpy(), which is shorter and clear. Drop the tmp variable that is not needed any more. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxJakub Kicinski authored
Saeed Mahameed says: ==================== mlx5-updates-2022-09-27 This is Part #1 of 4 parts series to align mlx5's implementation of XSK (AF_XDP) RX-Qs indexing and management with other vendors: Maxim Says: =========== xsk: Bug fixes for frame mapping on striding RQ Striding RQ relies on the driver mapping RX buffers into the NIC's virtual memory space. Currently, regadless of the XSK frame size, mlx5e maps them using MTT, and each mapping's length is PAGE_SIZE. As the result, the stride size used by striding RQ is also equal to PAGE_SIZE. This decision has the following issues: 1. In the XSK aligned mode with frame size smaller than PAGE_SIZE, it's suboptimal. Using 2K strides and 2K pages allows to post twice as fewer WQEs. 2. MTT is not suitable for unaligned frames, as it requires natural alignment theoretically, in practice at least 8-byte alignment. 3. Using mapping and stride bigger than the frame has risk of writing over the bounds of the XSK frame upon receiving packets bigger than MTU, which is possible in some specific configurations. This series addresses issues 1 and 2 and alleviates issue 3. Where possible, page and stride size will match the XSK frame size (firmware upgrade may be needed to have effect for 2K frames). Unaligned mode will use KSM instead of MTT, which allows to drop the partial workaround [1]. [1]: https://lore.kernel.org/netdev/YufYFQ6JN91lQbso@boxer/T/ ==================== Link: https://lore.kernel.org/r/20220927203611.244301-1-saeed@kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Maxim Mikityanskiy authored
Some of the parameters of striding RQ are compile-time constants, but they are going to become dynamically calculated at runtime in a following commit. This commit prepares the datapath to take cached runtime parameters, prefilled at queue creation. New fields added to struct mlx5e_rq fit into an existing 7-byte hole. Signed-off-by:
Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
-
Maxim Mikityanskiy authored
This commit moves the dma_info array to the end of struct mlx5e_mpw_info to make it a flexible array. It also removes the intermediate struct mlx5e_umr_dma_info, which used to contain only this array. The flexibility of dma_info will allow to choose its size dynamically in a following commit. Signed-off-by:
-
Maxim Mikityanskiy authored
Normally, the MTU change requires reopening the channels, but it can be skipped if the new MTU doesn't change any of the queue parameters and if MTU is not used in the data path. The shortcut is applicable to the non-linear mode of striding RQ, because the only thing affected by MTU is the queue length. As ethtool sets the queue length in packets, but striding RQ length is defined in strides or bytes, we estimate the RQ length to be at least as big as the requested number of MTU-sized packets, that's why it depends on MTU. Improve the shortcut by actually checking whether the RQ length stayed the same, instead of an intermediate step in the calculation. As MTU also affects the SHAMPO parameters, skip the shortcut if SHAMPO is in use. Signed-off-by:
-
Maxim Mikityanskiy authored
In a typical scenario, if an XSK socket is opened first, then an XDP program is attached, mlx5e_validate_xsk_param will be called twice: first on XSK bind, second on channel restart caused by enabling XDP. The validation includes a call to mlx5e_rx_is_linear_skb, which checks the presence of the XDP program. The above means that mlx5e_rx_is_linear_skb might return true the first time, but false the second time, as mlx5e_rx_get_linear_sz_skb's return value will increase, because of a different headroom used with XDP. As XSK RQs never exist without XDP, it would make sense to trick mlx5e_rx_get_linear_sz_skb into thinking XDP is enabled at the first check as well. This way, if MTU is too big, it would be detected on XSK bind, without giving false hope to the userspace application. However, it turns out that this check is too restrictive in the first place. SKBs created on XDP_PASS on XSK RQs don't have any headroom. That means that big MTUs filtered out on the first and the second checks might actually work. So, address this issue in the proper way, but taking into account the absence of the SKB headroom on XSK RQs, when calculating the buffer size. Signed-off-by:
-
Maxim Mikityanskiy authored
One of the checks in mlx5e_rx_is_linear_skb verifies that the RX buffer fits into the XSK frame size. Remove the duplicating check from mlx5e_validate_xsk_param. It allows to make mlx5e_rx_get_min_frag_sz static. Remove mlx5e_rx_is_xdp altogether, as its only usage is located in a branch where xsk == NULL. Signed-off-by:
-
Maxim Mikityanskiy authored
Linear RX buffers must be big enough to fit the MTU-sized packet along with the headroom. On the other hand, they must be small enough to fit into a page (or into an XSK frame). A straightforward way to check whether the linear mode is possible would be comparing the required buffer size to PAGE_SIZE or XSK frame size. Stride size in the linear mode is defined by the following constraints: 1. A stride is at least as big as the buffer size, and it's a power of two. 2. If non-XSK XDP is enabled, the stride size is PAGE_SIZE, because mlx5e requires each packet to be in its own page when XDP is in use. The previous constraint is automatically fulfilled, because buffer size can't be bigger than PAGE_SIZE. 3. XSK uses stride size equal to PAGE_SIZE, but the following commits will allow it to use roundup_pow_of_two(XSK frame size), by allowing the NIC's MMU to use page sizes not equal to the CPU page size. This commit puts the above requirements and constraints straight to the code in an attempt to simplify it and to prepare it for changes made in the next patches. For the reference, the old code uses an equivalent, but trickier calculation (high-level simplified pseudocode): if XDP or XSK: mlx5e_rx_get_linear_frag_sz := max(buffer size, PAGE_SIZE) else: mlx5e_rx_get_linear_frag_sz := buffer size mlx5e_rx_is_linear_skb := mlx5e_rx_get_linear_frag_sz <= PAGE_SIZE stride size := roundup_pow_of_two(mlx5e_rx_get_linear_frag_sz) The new code effectively removes mlx5e_rx_get_linear_frag_sz that used to return either buffer size or stride size, depending on the situation, making it hard to work with and to make changes: if XDP or XSK: mlx5e_rx_get_linear_stride_sz := PAGE_SIZE else mlx5e_rx_get_linear_stride_sz := roundup_pow_of_two(buffer size) mlx5e_rx_is_linear_skb := buffer size <= (PAGE_SIZE or XSK frame sz) stride size := mlx5e_rx_get_linear_stride_sz Signed-off-by: -
Maxim Mikityanskiy authored
Instead of WARNing in runtime when TLS offload WQEs posted to ICOSQ are over the hardware limit, check their size before enabling TLS RX offload, and block the offload if the condition fails. It also allows to drop a u16 field from struct mlx5e_icosq. Signed-off-by:
-
Maxim Mikityanskiy authored
TX MPWQE size is limited to the cacheline-aligned maximum. Use the same value for the stop room and the capability check. Signed-off-by:
-
Maxim Mikityanskiy authored
Fix a typo in the function name: mpqwe -> mpwqe (stands for multi-packet work queue element). Signed-off-by:
-
Maxim Mikityanskiy authored
mlx5e_alloc_xdpsq calculates sq->stop_room internally, but there is already a function for that: mlx5e_stop_room_for_max_wqe. This commit makes use of this function. Signed-off-by:
-
Maxim Mikityanskiy authored
To shorten and simplify code, let mlx5e_get_sw_max_sq_mpw_wqebbs accept mdev and derive max SQ WQEBBs from it. Also rename the function to a more generic name mlx5e_get_max_sq_aligned_wqebbs, because the following patches will use it in non-MPWQE contexts. Signed-off-by:
-
Maxim Mikityanskiy authored
Currently, the driver can silently fall back to legacy RQ after enabling XDP, even if striding RQ was active before. It happens when PAGE_SIZE is bigger than the maximum supported stride size. This commit changes this behavior to more straightforward: if an operation (enabling XDP) doesn't support the current parameters (striding RQ mode), it fails. Signed-off-by:
-
Maxim Mikityanskiy authored
mlx5e_verify_rx_mpwqe_strides is only used in en/params.c, so it can be made static and removed from en/params.h. Signed-off-by:
-
Maxim Mikityanskiy authored
No need to keep max_sq_wqebbs in mlx5e_txqsq and mlx5e_xdpsq, as it's only used when allocating the queues. Removing an extra field reduces the struct size. Signed-off-by:
-
Maxim Mikityanskiy authored
The return value of mlx5e_get_max_sq_wqebbs is clamped down to MLX5_SEND_WQE_MAX_WQEBBS = 16, which fits into u8. This commit changes the return type of this function to u8 for stricter type safety. Signed-off-by:
-
Maxim Mikityanskiy authored
Add the capability that will allow the driver to determine the minimal MTT page size to be able to map the smallest possible pages in XSK. The older firmwares that don't have this capability default to 12 (i.e. 4096-byte pages). Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linuxJakub Kicinski authored
Saeed Mahameed says: ==================== updates from mlx5-next 2022-09-24 Updates form mlx5-next including[1]: 1) HW definitions and support for NPPS clock settings. 2) various cleanups 3) Enable hash mode by default for all NICs 4) page tracker and advanced virtualization HW definitions for vfio [1] https://lore.kernel.org/netdev/20220907233636.388475-1-saeed@kernel.org/ * 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux: net/mlx5: Remove from FPGA IFC file not-needed definitions net/mlx5: Remove unused structs net/mlx5: Remove unused functions net/mlx5: detect and enable bypass port select flow table net/mlx5: Lag, enable hash mode by default for all NICs net/mlx5: Lag, set active ports if support bypass port select flow table RDMA/mlx5: Don't set tx affinity when lag is in hash mode net/mlx5: add IFC bits for bypassing port select flow table net/mlx5: Add support for NPPS with real time mode net/mlx5: Expose NPPS related registers net/mlx5: Query ADV_VIRTUALIZATION capabilities net/mlx5: Introduce ifc bits for page tracker RDMA/mlx5: Move function mlx5_core_query_ib_ppcnt() to mlx5_ib ==================== Link: https://lore.kernel.org/all/20220927201906.234015-1-saeed@kernel.org/Signed-off-by:
-
Sean Anderson authored
Just use kzalloc instead. Fixes: d6f1e89b ("sunhme: Return an ERR_PTR from quattro_pci_find") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Sean Anderson <seanga2@gmail.com> Link: https://lore.kernel.org/r/20220928004157.279731-1-seanga2@gmail.comSigned-off-by:
-
Shang XiaoJing authored
Use skb_put_data() instead of skb_put() and memcpy(), which is clear. Signed-off-by:
M Chetan Kumar <m.chetan.kumar@intel.com> Link: https://lore.kernel.org/r/20220927023254.30342-1-shangxiaojing@huawei.comSigned-off-by:
-
Jakub Kicinski authored
Vladimir Oltean says: ==================== Rework resource allocation in Felix DSA driver The Felix DSA driver controls NXP variations of Microchip switches. Colin Foster is trying to add support in this driver for "genuine" Microchip hardware, but some of the NXP-isms in this driver need to go away before that happens cleanly. https://patchwork.kernel.org/project/netdevbpf/cover/20220926002928.2744638-1-colin.foster@in-advantage.com/ The starting point was Colin's patch 08/14 "net: dsa: felix: update init_regmap to be string-based", and this continues to be the central theme here, but things are done differently. In short (full explanations are in patches), the goal is for MFD-based switches like Colin's SPI-controlled VSC7512 to be able to request a regmap that was created 100% externally (by drivers/mfd/ocelot-core.c) in a very simple way, that does not create dependencies on other modules. That is dev_get_regmap(), and as input it wants a string, for the resource name. So we rework the resource allocation in this driver to be based on string names provided by the specific instantiation (in Colin's case, ocelot_ext.c). Patch set was boot-tested on NXP LS1028A. ==================== Link: https://lore.kernel.org/r/20220927191521.1578084-1-vladimir.oltean@nxp.comSigned-off-by:
-
Vladimir Oltean authored
Existing felix DSA drivers (vsc9959, vsc9953) are all switches that were integrated in NXP SoCs, which makes them a bit unusual compared to the usual Microchip branded Ocelot switches. To be precise, looking at Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml, one can see 21 memory regions for the "switch" node, and these correspond to the "targets" of the switch IP, which are spread throughout the guts of that SoC's memory space. In NXP integrations, those targets still exist, but they were condensed within a single memory region, with no other peripheral in between them, so it made more sense for the driver to ioremap the entire memory space of the switch, and then find the targets within that memory space via some offsets hardcoded in the driver. The effect of this design decision is that now, the felix driver expects hardware instantiations to provide their own resource definitions, which is kind of odd when considering a typical device (those are retrieved from 'reg' properties in the device tree, using platform_get_resource() or similar). Allow other hardware instantiations that share the felix driver to not provide a hardcoded array of resources in the future. Instead, make the common denominator based on which regmaps are created be just the resource "names". Each instantiation comes with its own array of names that are mandatory for it, and with an optional array of resources. So we split the resources in 2 arrays, one is what's requested and the other is what's provided. There is one pool of provided resources, in felix->info->resources (of length felix->info->num_resources). There are 2 different ways of requesting a resource. One is by enum ocelot_target (this handles the global regmaps), and one is by int port (this handles the per-port ones). For the existing vsc9959 and vsc9953, it would be a bit stupid to request something that's not provided, given that the 2 arrays are both defined in the same place. The advantage is that we can now modify felix_request_regmap_by_name() to make felix->info->resources[] optional, and if absent, the implementation can call dev_get_regmap() and this is something that is compatible with MFD. Co-developed-by:
Colin Foster <colin.foster@in-advantage.com> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
Use less verbose resource definitions in vsc9959 and vsc9953. This also sets IORESOURCE_MEM in the constant array of resources, so we don't have to do this from felix_init_structs() - in fact, in the future, we may even support IORESOURCE_REG resources. Note that this macro takes start and length as argument, and we had start and end before. So transform end into length. While at it, sort the resources according to their offset. Signed-off-by:
-
Vladimir Oltean authored
It turns out that the idea of having a customizable implementation of a regmap creation from a resource is not exactly useful. The idea was for the new MFD-based VSC7512 driver to use something that creates a SPI regmap from a resource. But there are problems in actually getting those resources (it involves getting them from MFD). To avoid all that, we'll be getting resources by name, so this custom init_regmap() method won't be needed. Remove it. Signed-off-by:
-
Vladimir Oltean authored
This address is only relevant for the vsc9959, which is a PCIe device that holds its switch registers in a different PCIe BAR compared to the registers for the internal MDIO controller. Hide this aspect from the common felix driver and move the pci_resource_start() call to the only place that needs it, which is in vsc9959_mdio_bus_alloc(). Signed-off-by:
-
Vladimir Oltean authored
The imdio_res is used only by vsc9959, which references its own vsc9959_imdio_res through the common felix_info->imdio_res pointer. Since the common code doesn't care about this resource (and it can't be part of the common array of resources, either, because it belongs in a different PCI BAR), just reference it directly. Signed-off-by:
-
Jakub Kicinski authored
We tell driver developers to always pass NAPI_POLL_WEIGHT as the weight to netif_napi_add(). This may be confusing to newcomers, drop the weight argument, those who really need to tweak the weight can use netif_napi_add_weight(). Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for CAN Link: https://lore.kernel.org/r/20220927132753.750069-1-kuba@kernel.orgSigned-off-by:
-
Martin KaFai Lau authored
The v6_rcv_saddr and rcv_saddr are inside a union in the 'struct inet_bind2_bucket'. When searching a bucket by following the bhash2 hashtable chain, eg. inet_bind2_bucket_match, it is only using the sk->sk_family and there is no way to check if the inet_bind2_bucket has a v6 or v4 address in the union. This leads to an uninit-value KMSAN report in [0] and also potentially incorrect matches. This patch fixes it by adding a family member to the inet_bind2_bucket and then tests 'sk->sk_family != tb->family' before matching the sk's address to the tb's address. Cc: Joanne Koong <joannelkoong@gmail.com> Fixes: 28044fc1 ("net: Add a bhash2 table hashed by port and address") Signed-off-by:
Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by:
Eric Dumazet <edumazet@google.com> Tested-by:
Alexander Potapenko <glider@google.com> Link: https://lore.kernel.org/r/20220927002544.3381205-1-kafai@fb.comSigned-off-by:
-
Jakub Kicinski authored
Mat Martineau says: ==================== mptcp: MPTCP support for TCP_FASTOPEN_CONNECT RFC 8684 appendix B describes how to use TCP Fast Open with MPTCP. This series allows TFO use with MPTCP using the TCP_FASTOPEN_CONNECT socket option. The scope here is limited to the initiator of the connection - support for MSG_FASTOPEN and the listener side of the connection will be in a separate series. The preexisting TCP fastopen code does most of the work, so these changes mostly involve plumbing MPTCP through to those TCP functions. Patch 1 changes the MPTCP socket option code to pass the TCP_FASTOPEN_CONNECT option through to the initial unconnected subflow. Patch 2 exports the existing tcp_sendmsg_fastopen() function from tcp.c Patch 3 adds the call to tcp_sendmsg_fastopen() from the MPTCP send function. Patch 4 modifies mptcp_poll() to handle the deferred TFO connection. ==================== Link: https://lore.kernel.org/r/20220926232739.76317-1-mathew.j.martineau@linux.intel.comSigned-off-by:
-
Benjamin Hesmans authored
If fastopen is used, poll must allow a first write that will trigger the SYN+data Similar to what is done in tcp_poll(). Acked-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Benjamin Hesmans <benjamin.hesmans@tessares.net> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Dmytro Shytyi authored
When TCP_FASTOPEN_CONNECT has been set on the socket before a connect, the defer flag is set and must be handled when sendmsg is called. This is similar to what is done in tcp_sendmsg_locked(). Acked-by:
Dmytro Shytyi <dmytro@shytyi.net> Signed-off-by:
-
Benjamin Hesmans authored
It will be used to support TCP FastOpen with MPTCP in the following commit. Acked-by:
-
Benjamin Hesmans authored
Set the option for the first subflow only. For the other subflows TFO can't be used because a mapping would be needed to cover the data in the SYN. Acked-by:
-
Gustavo A. R. Silva authored
Zero-length arrays are deprecated and we are moving towards adopting C99 flexible-array members, instead. So, replace zero-length arrays declarations in anonymous union with the new DECLARE_FLEX_ARRAY() helper macro. This helper allows for flexible-array members in unions. Link: https://github.com/KSPP/linux/issues/193 Link: https://github.com/KSPP/linux/issues/225 Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.htmlSigned-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/YzIvfGXxfjdXmIS3@workSigned-off-by:
-
Jakub Kicinski authored
Pavel Begunkov says: ==================== shrink struct ubuf_info struct ubuf_info is large but not all fields are needed for all cases. We have limited space in io_uring for it and large ubuf_info prevents some struct embedding, even though we use only a subset of the fields. It's also not very clean trying to use this typeless extra space. Shrink struct ubuf_info to only necessary fields used in generic paths, namely ->callback, ->refcnt and ->flags, which take only 16 bytes. And make MSG_ZEROCOPY and some other users to embed it into a larger struct ubuf_info_msgzc mimicking the former ubuf_info. Note, xen/vhost may also have some cleaning on top by creating new structs containing ubuf_info but with proper types. ==================== Link: https://lore.kernel.org/r/cover.1663892211.git.asml.silence@gmail.comSigned-off-by:
-
Pavel Begunkov authored
We can benefit from a smaller struct ubuf_info, so leave only mandatory fields and let users to decide how they want to extend it. Convert MSG_ZEROCOPY to struct ubuf_info_msgzc and remove duplicated fields. This reduces the size from 48 bytes to just 16. Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Acked-by:
-
