| bba8281d | 08-Nov-2021 |
Raja Zidane <[email protected]> |
common/mlx5: fix queue size in DevX queue pair creation
The number of WQEBBs was provided to QP create, and QP size was calculated
by multiplying the number of WQEBBs by 64, which is the send WQE si
common/mlx5: fix queue size in DevX queue pair creation
The number of WQEBBs was provided to QP create, and QP size was calculated
by multiplying the number of WQEBBs by 64, which is the send WQE size.
When creating RQ in the QP (i.e., vdpa driver), the queue size was bigger
because the receive WQE size is 16.
Provide queue size to QP create instead of the number of WQEBBs.
Fixes: f9213ab12cf9 ("common/mlx5: share DevX queue pair operations")
Signed-off-by: Raja Zidane <[email protected]>
Acked-by: Matan Azrad <[email protected]>
show more ...
|
| 5dfa003d | 03-Nov-2021 |
Michael Baum <[email protected]> |
common/mlx5: fix post doorbell barrier
The rdma-core library can map doorbell register in two ways, depending
on the environment variable "MLX5_SHUT_UP_BF":
- as regular cached memory, the variab
common/mlx5: fix post doorbell barrier
The rdma-core library can map doorbell register in two ways, depending
on the environment variable "MLX5_SHUT_UP_BF":
- as regular cached memory, the variable is either missing or set to
zero. This type of mapping may cause the significant doorbell
register writing latency and requires an explicit memory write
barrier to mitigate this issue and prevent write combining.
- as non-cached memory, the variable is present and set to not "0"
value. This type of mapping may cause performance impact under
heavy loading conditions but the explicit write memory barrier is
not required and it may improve core performance.
The UAR creation function maps a doorbell in one of the above ways
according to the system. In run time, it always adds an explicit memory
barrier after writing to.
In cases where the doorbell was mapped as non-cached memory, the
explicit memory barrier is unnecessary and may impair performance.
The commit [1] solved this problem for a Tx queue. In run time, it
checks the mapping type and provides the memory barrier after writing to
a Tx doorbell register if it is needed. The mapping type is extracted
directly from the uar_mmap_offset field in the queue properties.
This patch shares this code between the drivers and extends the above
solution for each of them.
[1] commit 8409a28573d3
("net/mlx5: control transmit doorbell register mapping")
Fixes: f8c97babc9f4 ("compress/mlx5: add data-path functions")
Fixes: 8e196c08ab53 ("crypto/mlx5: support enqueue/dequeue operations")
Fixes: 4d4e245ad637 ("regex/mlx5: support enqueue")
Cc: [email protected]
Signed-off-by: Michael Baum <[email protected]>
Reviewed-by: Viacheslav Ovsiienko <[email protected]>
Acked-by: Matan Azrad <[email protected]>
show more ...
|
| b4371d3d | 03-Nov-2021 |
Michael Baum <[email protected]> |
common/mlx5: fix doorbell mapping configuration
UAR mapping type can be affected by the devarg tx_db_nc, which can cause
setting the environment variable MLX5_SHUT_UP_BF.
So, the MLX5_SHUT_UP_BF val
common/mlx5: fix doorbell mapping configuration
UAR mapping type can be affected by the devarg tx_db_nc, which can cause
setting the environment variable MLX5_SHUT_UP_BF.
So, the MLX5_SHUT_UP_BF value and the UAR mapping parameter affect the
UAR cache mode.
Wrongly, the devarg was considered for the MLX5_SHUT_UP_BF but not for
the UAR mapping parameter in all the drivers except the net.
Take the tx_db_nc devarg into account for all the drivers.
Fixes: ca1418ce3910 ("common/mlx5: share device context object")
Cc: [email protected]
Signed-off-by: Michael Baum <[email protected]>
Reviewed-by: Viacheslav Ovsiienko <[email protected]>
Acked-by: Matan Azrad <[email protected]>
show more ...
|
| 20489176 | 03-Nov-2021 |
Michael Baum <[email protected]> |
common/mlx5: make multi-process MR management port-agnostic
In the multi-process mechanism, there are things that the secondary
process does not perform itself but asks the primary process to perfor
common/mlx5: make multi-process MR management port-agnostic
In the multi-process mechanism, there are things that the secondary
process does not perform itself but asks the primary process to perform
for it.
There is a special API for communication between the processes that
receives parameters necessary for the specific action required as well
as a special structure called mp_id that contains the port number of the
processes through which the initial process finds the relevant ETH
device for the processes.
One of the operations performed through this mechanism is the creation
of a memory region, where the secondary process sends the virtual
address as a parameter and the mp_id structure with the port number
inside it.
However, once the memory area management is shared between the drivers
and either port number or ETH device is no longer relevant to them, it
seems unnecessary to continue communicating between the processes
through the mp_id variable.
In this patch we will remove the use of the above structure for all MR
management, and add to the specific parameter of operations a pointer to
the common device that contains everything needed to create/register MR.
Fixes: 9f1d636f3ef08 ("common/mlx5: share MR management")
Signed-off-by: Michael Baum <[email protected]>
Reviewed-by: Viacheslav Ovsiienko <[email protected]>
Reviewed-by: Dmitry Kozlyuk <[email protected]>
Acked-by: Matan Azrad <[email protected]>
show more ...
|
| 350e25fa | 26-Oct-2021 |
Raja Zidane <[email protected]> |
compress/mlx5: add block size option
Currently, the compression block size is 15 by default, which
is the maximum.
Add "log-block-size" devarg to select compression block size manually.
The value p
compress/mlx5: add block size option
Currently, the compression block size is 15 by default, which
is the maximum.
Add "log-block-size" devarg to select compression block size manually.
The value provided should be between 4 to 15.
Any out-of-range value will be defaulted to 15.
Signed-off-by: Raja Zidane <[email protected]>
Acked-by: Matan Azrad <[email protected]>
show more ...
|