#
73f7ae1d |
| 06-Dec-2024 |
Gavin Hu <gahu@nvidia.com> |
net/mlx5: fix polling CQEs
In certain situations, the receive queue (rxq) fails to replenish its internal ring with memory buffers (mbufs) from the pool. This can happen when the pool has a limited
net/mlx5: fix polling CQEs
In certain situations, the receive queue (rxq) fails to replenish its internal ring with memory buffers (mbufs) from the pool. This can happen when the pool has a limited number of mbufs allocated, and the user application holds incoming packets for an extended period, resulting in a delayed release of mbufs. Consequently, the pool becomes depleted, preventing the rxq from replenishing from it.
There was a bug in the behavior of the vectorized rxq_cq_process_v routine, which handled completion queue entries (CQEs) in batches of four. This routine consistently accessed four mbufs from the internal queue ring, regardless of whether they had been replenished. As a result, it could access mbufs that no longer belonged to the poll mode driver (PMD).
The fix involves checking if there are four replenished mbufs available before allowing rxq_cq_process_v to handle the batch. Once replenishment succeeds during the polling process, the routine will resume its operation.
Fixes: 1ded26239aa0 ("net/mlx5: refactor vectorized Rx") Cc: stable@dpdk.org
Reported-by: Changqi Dingluo <dingluochangqi.ck@bytedance.com> Signed-off-by: Gavin Hu <gahu@nvidia.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
90ec9b0d |
| 01-Nov-2023 |
Alexander Kozyrev <akozyrev@nvidia.com> |
net/mlx5: replenish MPRQ buffers for miniCQEs
Keep unzipping if the next CQE is the miniCQE array in rxq_cq_decompress_v() routine only for non-MPRQ scenario, MPRQ requires buffer replenishment betw
net/mlx5: replenish MPRQ buffers for miniCQEs
Keep unzipping if the next CQE is the miniCQE array in rxq_cq_decompress_v() routine only for non-MPRQ scenario, MPRQ requires buffer replenishment between the miniCQEs.
Restore the check for the initial compressed CQE for SPRQ and check that the current CQE is not compressed before copying it as a possible title CQE.
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com> Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
show more ...
|
#
fc3e1798 |
| 28-Feb-2023 |
Alexander Kozyrev <akozyrev@nvidia.com> |
net/mlx5: support enhanced CQE zipping in vector Rx burst
Add Enhanced CQE compression support to vectorized Rx burst routines. Adopt the same algorithm as scalar Rx burst routines have today. 1. Re
net/mlx5: support enhanced CQE zipping in vector Rx burst
Add Enhanced CQE compression support to vectorized Rx burst routines. Adopt the same algorithm as scalar Rx burst routines have today. 1. Retrieve the validity_iteration_count from CQEs and use it to check if the CQE is ready to be processed instead of the owner_bit. 2. Do not invalidate reserved CQEs between miniCQE arrays. 3. Copy the title packet from the last processed uncompressed CQE since we will need it later to build packets from zipped CQEs. 4. Skip the regular CQE processing and go straight to the CQE unzip function in case the very first CQE is compressed to sace CPU time.
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
aa67ed30 |
| 27-Jan-2023 |
Alexander Kozyrev <akozyrev@nvidia.com> |
net/mlx5: ignore non-critical syndromes for Rx queue
For non-fatal syndromes like LOCAL_LENGTH_ERR, the Rx queue reset shouldn't be triggered. Rx queue could continue with the next packets without a
net/mlx5: ignore non-critical syndromes for Rx queue
For non-fatal syndromes like LOCAL_LENGTH_ERR, the Rx queue reset shouldn't be triggered. Rx queue could continue with the next packets without any recovery. Only three syndromes warrant Rx queue reset: LOCAL_QP_OP_ERR, LOCAL_PROT_ERR and WR_FLUSH_ERR. Do not initiate a Rx queue reset in any other cases. Skip all non-critical error CQEs and continue with packet processing.
Fixes: 88c0733535 ("net/mlx5: extend Rx completion with error handling") Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com> Acked-by: Matan Azrad <matan@nvidia.com>
show more ...
|
#
633684e0 |
| 27-Jan-2023 |
Alexander Kozyrev <akozyrev@nvidia.com> |
net/mlx5: fix error CQE dumping for vectorized Rx
There is a dump file with debug information created for an error CQE to help with troubleshooting later. It starts with the last CQE, which, presuma
net/mlx5: fix error CQE dumping for vectorized Rx
There is a dump file with debug information created for an error CQE to help with troubleshooting later. It starts with the last CQE, which, presumably is the error CQE. But this is only true for the scalar Rx burst routing since we handle CQEs there one by one and detect the error immediately. For vectorized Rx bursts, we may already move to another CQE when we detect the error since we handle CQEs in batches there. Go back to the error CQE in this case to dump proper CQE.
Fixes: 88c0733535 ("net/mlx5: extend Rx completion with error handling") Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com> Acked-by: Matan Azrad <matan@nvidia.com>
show more ...
|
#
0947ed38 |
| 23-Nov-2021 |
Michael Baum <michaelba@nvidia.com> |
net/mlx5: improve stride parameter names
In the striding RQ management there are two important parameters, the size of the single stride in bytes and the number of strides.
Both the data-path struc
net/mlx5: improve stride parameter names
In the striding RQ management there are two important parameters, the size of the single stride in bytes and the number of strides.
Both the data-path structure and config structure keep the log of the above parameters. However, in their names there is no mention that the value is a log which may be misleading as if the fields represent the values themselves.
This patch updates their names describing the values more accurately.
Fixes: ecb160456aed ("net/mlx5: add device parameter for MPRQ stride size") Cc: stable@dpdk.org
Signed-off-by: Michael Baum <michaelba@nvidia.com> Acked-by: Matan Azrad <matan@nvidia.com>
show more ...
|
#
5cf0707f |
| 04-Nov-2021 |
Xueming Li <xuemingl@nvidia.com> |
net/mlx5: remove Rx queue data list from device
Rx queue data list(priv->rxqs) can be replaced by Rx queue list(priv->rxq_privs), removes it and replaces with universal wrapper API.
Signed-off-by:
net/mlx5: remove Rx queue data list from device
Rx queue data list(priv->rxqs) can be replaced by Rx queue list(priv->rxq_privs), removes it and replaces with universal wrapper API.
Signed-off-by: Xueming Li <xuemingl@nvidia.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
5db77fef |
| 04-Nov-2021 |
Xueming Li <xuemingl@nvidia.com> |
net/mlx5: remove port info from shareable Rx queue
To prepare for shared Rx queue, removes port info from shareable Rx queue control.
Signed-off-by: Xueming Li <xuemingl@nvidia.com> Acked-by: Viach
net/mlx5: remove port info from shareable Rx queue
To prepare for shared Rx queue, removes port info from shareable Rx queue control.
Signed-off-by: Xueming Li <xuemingl@nvidia.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
828274b7 |
| 04-Aug-2021 |
Alexander Kozyrev <akozyrev@nvidia.com> |
net/mlx5: fix mbuf replenishment check for zipped CQE
A core dump is being generated with the following call stack: 0 _mm256_storeu_si256 (__A=..., __P=0x80) 1 rte_mov32 (src=0x2299c9140 "", dst=0x8
net/mlx5: fix mbuf replenishment check for zipped CQE
A core dump is being generated with the following call stack: 0 _mm256_storeu_si256 (__A=..., __P=0x80) 1 rte_mov32 (src=0x2299c9140 "", dst=0x80) 2 rte_memcpy_aligned (n=60, src=0x2299c9140, dst=0x80) 3 rte_memcpy (n=60, src=0x2299c9140, dst=0x80) 4 mprq_buf_to_pkt (strd_cnt=1, strd_idx=0, buf=0x2299c8a00, len=60, pkt=0x18345f0c0, rxq=0x18345ef40) 5 rxq_copy_mprq_mbuf_v (rxq=0x18345ef40, pkts=0x7f76e0ff6d18, pkts_n=5) 6 rxq_burst_mprq_v (rxq=0x18345ef40, pkts=0x7f76e0ff6d18, pkts_n=46, err=0x7f76e0ff6a28, no_cq=0x7f76e0ff6a27) 7 mlx5_rx_burst_mprq_vec (dpdk_rxq=0x18345ef40, pkts=0x7f76e0ff6a88, pkts_n=128) 8 rte_eth_rx_burst (nb_pkts=128, rx_pkts=0x7f76e0ff6a88, queue_id=<optimized out>, port_id=<optimized out>)
This crash is caused by an attempt to copy previously uncompressed CQEs into non-allocated mbufs. There is a check to make sure we only use allocated mbufs in the rxq_burst_mprq_v() function, but it is done only before the main processing loop. Leftovers of compressed CQEs session are handled before that loop and may lead to the mbufs overflow as seen.
Move the check for replenished mbufs up to protect uncompressed CQEs session leftovers from accessing non-allocated mbufs after the mlx5_rx_mprq_replenish_bulk_mbuf() function is invoked.
Bugzilla ID: 746 Fixes: 0f20acbf5eda ("net/mlx5: implement vectorized MPRQ burst") Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
acc87479 |
| 13-Jul-2021 |
Alexander Kozyrev <akozyrev@nvidia.com> |
net/mlx5: fix threshold for mbuf replenishment in MPRQ
The replenishment scheme for the vectorized MPRQ Rx burst aims to improve the cache locality by allocating new mbufs only when there are almost
net/mlx5: fix threshold for mbuf replenishment in MPRQ
The replenishment scheme for the vectorized MPRQ Rx burst aims to improve the cache locality by allocating new mbufs only when there are almost no mbufs left: one burst gap between allocated and consumed indexes.
This gap is not big enough to accommodate a corner case when we have a very aggressive CQE compression with multiple regular CQEs at the beginning and 64 zipped CQEs at the end.
Need to keep in mind this case and extend the replenishment threshold by MLX5_VPMD_RX_MAX_BURST (64) to avoid mbuf overflow.
Fixes: 5fc2e5c27d6 ("net/mlx5: fix mbuf overflow in vectorized MPRQ") Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
1db288f9 |
| 07-Jul-2021 |
Ruifeng Wang <ruifeng.wang@arm.com> |
net/mlx5: reduce unnecessary memory access in Rx
MR btree len is a constant during Rx replenish. Moved retrieve of the value out of loop to reduce data loads. Slight performance uplift was measured
net/mlx5: reduce unnecessary memory access in Rx
MR btree len is a constant during Rx replenish. Moved retrieve of the value out of loop to reduce data loads. Slight performance uplift was measured on both N1SDP and x86.
Suggested-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
151cbe3a |
| 12-Apr-2021 |
Michael Baum <michaelba@nvidia.com> |
net/mlx5: separate Rx function declarations to another file
The mlx5_rxtx.c file contains a lot of Tx burst functions, each of those is performance-optimized for the specific set of requested offloa
net/mlx5: separate Rx function declarations to another file
The mlx5_rxtx.c file contains a lot of Tx burst functions, each of those is performance-optimized for the specific set of requested offloads. These ones are generated on the basis of the template function and it takes significant time to compile, just due to a large number of giant functions generated in the same file and this compilation is not being done in parallel with using multithreading.
Therefore we can split the mlx5_rxtx.c file into several separate files to allow different functions to be compiled simultaneously. In this patch, we separate Rx function declarations to different header file in preparation for removing them from the source file and as an optional preparation step for further consolidation of Rx burst functions.
Signed-off-by: Michael Baum <michaelba@nvidia.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
5fc2e5c2 |
| 21-Nov-2020 |
Alexander Kozyrev <akozyrev@nvidia.com> |
net/mlx5: fix mbuf overflow in vectorized MPRQ
Changing the allocation scheme to improve mbufs locality caused mbufs overrun in some cases. Revert the previous replenish logic back. Calculate a numb
net/mlx5: fix mbuf overflow in vectorized MPRQ
Changing the allocation scheme to improve mbufs locality caused mbufs overrun in some cases. Revert the previous replenish logic back. Calculate a number of unused mbufs and replenish max this number of mbufs.
Mark the last 4 mbufs as fake mbufs to prevent overflowing into consumed mbufs in the future. Keep the consumed index and the produced index 4 mbufs apart for this purpose.
Replenish some mbufs only in case the consumed index is within the replenish threshold of the produced index in order to retain the cache locality for the vectorized MPRQ routine.
Fixes: 5c68764377 ("net/mlx5: improve vectorized MPRQ descriptors locality")
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
5c687643 |
| 08-Nov-2020 |
Alexander Kozyrev <akozyrev@nvidia.com> |
net/mlx5: improve vectorized MPRQ descriptors locality
There is a performance penalty for the replenish scheme used in vectorized Rx burst for both MPRQ and SPRQ. Mbuf elements are being filled at t
net/mlx5: improve vectorized MPRQ descriptors locality
There is a performance penalty for the replenish scheme used in vectorized Rx burst for both MPRQ and SPRQ. Mbuf elements are being filled at the end of the mbufs array and being replenished at the beginning. That leads to an increase in cache misses and the performance drop. The more Rx descriptors are used the worse the situation.
Change the allocation scheme for vectorized MPRQ Rx burst: allocate new mbufs only when consumed mbufs are almost depleted (always have one burst gap between allocated and consumed indices). Keeping a small number of mbufs allocated improves cache locality and improves performance a lot.
Unfortunately, this approach cannot be applied to SPRQ Rx burst routine. In MPRQ Rx burst we simply copy packets from external MPRQ buffers or attach these buffers to mbufs. In SPRQ Rx burst we allow the NIC to fill mbufs for us. Hence keeping a small number of allocated mbufs will limit NIC ability to fill as many buffers as possible. This fact offsets the advantage of better cache locality.
Fixes: 0f20acbf5eda ("net/mlx5: implement vectorized MPRQ burst")
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
0f20acbf |
| 21-Oct-2020 |
Alexander Kozyrev <akozyrev@nvidia.com> |
net/mlx5: implement vectorized MPRQ burst
MPRQ (Multi-Packet Rx Queue) processes one packet at a time using simple scalar instructions. MPRQ works by posting a single large buffer (consisted of mult
net/mlx5: implement vectorized MPRQ burst
MPRQ (Multi-Packet Rx Queue) processes one packet at a time using simple scalar instructions. MPRQ works by posting a single large buffer (consisted of multiple fixed-size strides) in order to receive multiple packets at once on this buffer. A Rx packet is then copied to a user-provided mbuf or PMD attaches the Rx packet to the mbuf by the pointer to an external buffer.
There is an opportunity to speed up the packet receiving by processing 4 packets simultaneously using SIMD (single instruction, multiple data) extensions. Allocate mbufs in batches for every MPRQ buffer and process the packets in groups of 4 until all the strides are exhausted. Then switch to another MPRQ buffer and repeat the process over again.
The vectorized MPRQ burst routine is engaged automatically in case the mprq_en=1 devarg is specified and the vectorization is not disabled explicitly by providing rx_vec_en=0 devarg. There is a limitation: LRO is not supported and scalar MPRQ is selected if it is on.
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
1ded2623 |
| 21-Oct-2020 |
Alexander Kozyrev <akozyrev@nvidia.com> |
net/mlx5: refactor vectorized Rx
Move the main processing cycle into a separate function: rxq_cq_process_v. Put the regular rxq_burst_v function to a non-arch specific file. Having all SIMD instruct
net/mlx5: refactor vectorized Rx
Move the main processing cycle into a separate function: rxq_cq_process_v. Put the regular rxq_burst_v function to a non-arch specific file. Having all SIMD instructions in a single reusable block is a first preparatory step to implement vectorized Rx burst for MPRQ feature.
Pass a pointer to the storage of mbufs directly to the rxq_copy_mbuf_v instead of calculating the pointer inside this function. This is needed for the future vectorized Rx routing which is going to pass a different pointer here.
Calculate the number of packets to replenish inside the mlx5_rx_replenish_bulk_mbuf. Containing this logic in one place allows us to do the same for MPRQ case.
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
2c5e0dd2 |
| 19-Oct-2020 |
Ciara Power <ciara.power@intel.com> |
net/mlx5: check max SIMD bitwidth
When choosing a vector path to take, an extra condition must be satisfied to ensure the max SIMD bitwidth allows for the CPU enabled path.
Signed-off-by: Ciara Pow
net/mlx5: check max SIMD bitwidth
When choosing a vector path to take, an extra condition must be satisfied to ensure the max SIMD bitwidth allows for the CPU enabled path.
Signed-off-by: Ciara Power <ciara.power@intel.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
show more ...
|
#
9d60f545 |
| 19-Jul-2020 |
Ophir Munk <ophirmu@mellanox.com> |
common/mlx5: remove inclusion of Verbs header files
Several source files include Verbs header files as in (1). These source files will not compile under non-Linux operating systems. This commit remo
common/mlx5: remove inclusion of Verbs header files
Several source files include Verbs header files as in (1). These source files will not compile under non-Linux operating systems. This commit removes this inclusion in two cases:
Case 1: There is no usage of ibv_* or mlx5dv_* symbols in the source file so the inclusion in (1) can be safely removed.
Case 2: Verbs symbols are used. Please note the inclusion in (1) already appears in file linux/mlx5_glue.h (which represents the interface to the rdma-core library). Therefore, replace (1) in the source file with (2). Under non-Linux operating systems - file mlx5_glue.h will not include (1).
(1) #include <infiniband/verbs.h> #include <infiniband/mlx5dv.h>
(2) #include <mlx5_glue.h>
Signed-off-by: Ophir Munk <ophirmu@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
show more ...
|
#
0f006468 |
| 24-Jun-2020 |
Michael Baum <michaelba@mellanox.com> |
net/mlx5: fix iterator type in Rx queue management
The mlx5_check_vec_rx_support function in the mlx5_rxtx_vec.c file passes the RX queues array in the loop. Similarly, the mlx5_mprq_enabled functio
net/mlx5: fix iterator type in Rx queue management
The mlx5_check_vec_rx_support function in the mlx5_rxtx_vec.c file passes the RX queues array in the loop. Similarly, the mlx5_mprq_enabled function in the mlx5_rxq.c file passes the RX queues array in the loop.
In both cases, the iterator of the loop is called i and the variable representing the array size is called rxqs_n. The i variable is of UINT16_T type while the rxqs_n variable is of unsigned int type. The size of the rxqs_n variable is much larger than the number of iterations allowed by the i type, theoretically there may be a situation where the value of the rxqs_n will be greater than can be represented by 16 bits and the loop will never end.
Change the type of i to UINT32_T.
Fixes: 7d6bf6b866b8 ("net/mlx5: add Multi-Packet Rx support") Fixes: 6cb559d67b83 ("net/mlx5: add vectorized Rx/Tx burst for x86") Cc: stable@dpdk.org
Signed-off-by: Michael Baum <michaelba@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
show more ...
|
#
c9cc554b |
| 02-Jun-2020 |
Alexander Kozyrev <akozyrev@mellanox.com> |
net/mlx5: fix vectorized Rx burst termination
Maximum burst size of Vectorized Rx burst routine is set to MLX5_VPMD_RX_MAX_BURST(64). This limits the performance of any application that would like t
net/mlx5: fix vectorized Rx burst termination
Maximum burst size of Vectorized Rx burst routine is set to MLX5_VPMD_RX_MAX_BURST(64). This limits the performance of any application that would like to gather more than 64 packets from the single Rx burst for batch processing (i.e. VPP).
The situation gets worse with a mix of zipped and unzipped CQEs. They are processed separately and the Rx burst function returns small number of packets every call.
Repeat the cycle of gathering packets from the vectorized Rx routine until a requested number of packets are collected or there are no more CQEs left to process.
Fixes: 6cb559d67b83 ("net/mlx5: add vectorized Rx/Tx burst for x86") Cc: stable@dpdk.org
Signed-off-by: Alexander Kozyrev <akozyrev@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
show more ...
|
#
ce6427dd |
| 09-Feb-2020 |
Thomas Monjalon <thomas@monjalon.net> |
replace cold attributes
The new macro __rte_cold, for compiler hinting, is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net> Reviewed-by: David Christ
replace cold attributes
The new macro __rte_cold, for compiler hinting, is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net> Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
show more ...
|
#
8e46d4e1 |
| 30-Jan-2020 |
Alexander Kozyrev <akozyrev@mellanox.com> |
common/mlx5: improve assert control
Use the MLX5_ASSERT macros instead of the standard assert clause. Depends on the RTE_LIBRTE_MLX5_DEBUG configuration option to define it. If RTE_LIBRTE_MLX5_DEBUG
common/mlx5: improve assert control
Use the MLX5_ASSERT macros instead of the standard assert clause. Depends on the RTE_LIBRTE_MLX5_DEBUG configuration option to define it. If RTE_LIBRTE_MLX5_DEBUG is enabled MLX5_ASSERT is equal to RTE_VERIFY to bypass the global CONFIG_RTE_ENABLE_ASSERT option. If RTE_LIBRTE_MLX5_DEBUG is disabled, the global CONFIG_RTE_ENABLE_ASSERT can still make this assert active by calling RTE_VERIFY inside RTE_ASSERT.
Signed-off-by: Alexander Kozyrev <akozyrev@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
show more ...
|
#
7b4f1e6b |
| 29-Jan-2020 |
Matan Azrad <matan@mellanox.com> |
common/mlx5: introduce common library
A new Mellanox vdpa PMD will be added to support vdpa operations by Mellanox adapters.
This vdpa PMD design includes mlx5_glue and mlx5_devx operations and lar
common/mlx5: introduce common library
A new Mellanox vdpa PMD will be added to support vdpa operations by Mellanox adapters.
This vdpa PMD design includes mlx5_glue and mlx5_devx operations and large parts of them are shared with the net/mlx5 PMD.
Create a new common library in drivers/common for mlx5 PMDs. Move mlx5_glue, mlx5_devx_cmds and their dependencies to the new mlx5 common library in drivers/common.
The files mlx5_devx_cmds.c, mlx5_devx_cmds.h, mlx5_glue.c, mlx5_glue.h and mlx5_prm.h are moved as is from drivers/net/mlx5 to drivers/common/mlx5.
Share the log mechanism macros. Separate also the log mechanism to allow different log level control to the common library.
Build files and version files are adjusted accordingly. Include lines are adjusted accordingly.
Signed-off-by: Matan Azrad <matan@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
show more ...
|
#
2e542da7 |
| 16-Aug-2019 |
David Christensen <drc@linux.vnet.ibm.com> |
net/mlx5: add Altivec Rx
Added mlx5_rxtx_vec_altivec.h which supports vectorized RX using Altivec vector code. Modified associated build files to use the new code.
Signed-off-by: David Christensen
net/mlx5: add Altivec Rx
Added mlx5_rxtx_vec_altivec.h which supports vectorized RX using Altivec vector code. Modified associated build files to use the new code.
Signed-off-by: David Christensen <drc@linux.vnet.ibm.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Tested-by: Raslan Darawsheh <rasland@mellanox.com>
show more ...
|
#
17ed314c |
| 29-Jul-2019 |
Matan Azrad <matan@mellanox.com> |
net/mlx5: allow LRO per Rx queue
Enabling LRO offload per queue makes sense because the user will probably want to allocate different mempool for LRO queues - the LRO mempool mbuf size may be bigger
net/mlx5: allow LRO per Rx queue
Enabling LRO offload per queue makes sense because the user will probably want to allocate different mempool for LRO queues - the LRO mempool mbuf size may be bigger than non LRO mempool.
Change the LRO offload to be per queue instead of per port.
If one of the queues is with LRO enabled, all the queues will be configured via DevX.
If RSS flows direct TCP packets to queues with different LRO enabling, these flows will not be offloaded with LRO.
Signed-off-by: Matan Azrad <matan@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
show more ...
|