| 0777921a | 24-Feb-2022 |
Michael Baum <[email protected]> |
common/mlx5: glue device and PD import
Add support for rdma-core API to import device.
The API gets ibv_context file descriptor and returns an ibv_context
pointer that is associated with the given f
common/mlx5: glue device and PD import
Add support for rdma-core API to import device.
The API gets ibv_context file descriptor and returns an ibv_context
pointer that is associated with the given file descriptor.
Add also support for rdma-core API to import PD.
The API gets ibv_context and PD handle and returns a protection domain
(PD) that is associated with the given handle in the given context.
Signed-off-by: Michael Baum <[email protected]>
Acked-by: Matan Azrad <[email protected]>
show more ...
|
| 76b5bdf8 | 09-Nov-2021 |
Matan Azrad <[email protected]> |
common/mlx5: create wrapped MR
The mlx5 PMD uses the kernel mlx5 driver to map physical memory to the
HW.
Using the Verbs API ibv_reg_mr, a mkey can be created for that.
In this case, the mkey is s
common/mlx5: create wrapped MR
The mlx5 PMD uses the kernel mlx5 driver to map physical memory to the
HW.
Using the Verbs API ibv_reg_mr, a mkey can be created for that.
In this case, the mkey is signed on the user ID of the kernel driver.
Using the DevX API, a mkey also can be created, but it should point an
umem object (represents the specific buffer mapping) created by the
kernel. In this case, the mkey is signed on the user ID of the process
DevX context.
In FW DevX control commands which get mkey as a parameter, there is
a security check on the user ID and Verbs mkeys are rejected.
Unfortunately, also when using DevX mkey, there is an error in the FW
command on umem validation because the umem is not designed to be used
for any mkey parameters.
As a workaround to the kernel driver/FW issue, it is needed to use a
wrapped MR, which is an indirect mkey(created by the DevX API) pointing to
direct mkey created by the kernel for any DevX command uses an MR.
Add an API to create and destroy this wrapped MR.
Fixes: 5382d28c2110 ("net/mlx5: accelerate DV flow counter transactions")
Fixes: 9d39e57f21ac ("vdpa/mlx5: support live migration")
Cc: [email protected]
Signed-off-by: Michael Baum <[email protected]>
Signed-off-by: Matan Azrad <[email protected]>
show more ...
|
| 4d567938 | 21-Jul-2021 |
Thomas Monjalon <[email protected]> |
common/mlx5: get PCI device address from any bus
A function is exported to allow retrieving the PCI address
of the parent PCI device of a Sub-Function in auxiliary bus sysfs.
The function mlx5_dev_t
common/mlx5: get PCI device address from any bus
A function is exported to allow retrieving the PCI address
of the parent PCI device of a Sub-Function in auxiliary bus sysfs.
The function mlx5_dev_to_pci_str() is accepting both PCI and auxiliary
devices. In case of a PCI device, it is simply using the device name.
The function mlx5_dev_to_pci_addr(), which is based on sysfs path
and do not use any device object, is renamed to mlx5_get_pci_addr()
for clarity purpose.
Signed-off-by: Thomas Monjalon <[email protected]>
Acked-by: Viacheslav Ovsiienko <[email protected]>
show more ...
|