- 17 Jul, 2024 14 commits
-
-
Jiri Pirko authored
Instead of passing separate names and callbacks arrays to virtio_find_vqs(), allocate one of virtual_queue_info structs and pass it to virtio_find_vqs_info(). Suggested-by:
Xuan Zhuo <xuanzhuo@linux.alibaba.com> Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Message-Id: <20240708074814.1739223-15-jiri@resnulli.us> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
Jiri Pirko authored
Instead of passing separate names and callbacks arrays to virtio_find_vqs_ctx(), allocate one of virtual_queue_info structs and pass it to virtio_find_vqs_info(). Suggested-by:
-
Jiri Pirko authored
Instead of passing separate names and callbacks arrays to virtio_find_vqs(), allocate one of virtual_queue_info structs and pass it to virtio_find_vqs_info(). Suggested-by:
-
Jiri Pirko authored
Instead of passing separate names and callbacks arrays to virtio_find_vqs(), allocate one of virtual_queue_info structs and pass it to virtio_find_vqs_info(). Suggested-by:
-
Jiri Pirko authored
Instead of passing separate names and callbacks arrays to virtio_find_vqs(), allocate one of virtual_queue_info structs and pass it to virtio_find_vqs_info(). Suggested-by:
-
Jiri Pirko authored
Since the original find_vqs() is no longer present, rename find_vqs_info() back to find_vqs(). Signed-off-by:
-
Jiri Pirko authored
As it is no longer used, remove it. Signed-off-by:
-
Jiri Pirko authored
Since there are no more implementations of find_vqs() op, call virtio_find_vqs_info() from virtio_find_single_vq() directly. Signed-off-by:
-
Jiri Pirko authored
Convert existing find_vqs() transport implementations to use find_vqs_info() config op. Signed-off-by:
-
Jiri Pirko authored
Convert existing vp_find_vqs() and vp_modern_find_vqs() implementations to find_vqs_info() config op. Signed-off-by:
-
Jiri Pirko authored
Introduce a structure virtio_queue_info to carry name, callback and ctx together. In order to allow config implementations to accept config op with array of virtio_queue_info structures, introduce a new find_vqs_info() op. Do the needed conversion in virtio_find_vqs_ctx(). Note that whole virtio_find_vqs_ctx() is going to be eventually removed at the and of this patchset. Suggested-by:
-
Jiri Pirko authored
In order to prepare for conversion of virtio_find_vqs*() arguments, make virtio_find_single_vq() to call virtio_find_vqs() instead of op directly. Signed-off-by:
-
Jiri Pirko authored
In order to prepare for conversion of virtio_find_vqs*() arguments, make virtio_find_vqs() to call virtio_find_vqs_ctx() instead of op directly. Signed-off-by:
-
Jiri Pirko authored
Since caif uses only one queue, convert to virtio_find_single_vq() helper which is made for this purpose. Signed-off-by:
-
- 09 Jul, 2024 26 commits
-
-
Dragos Tatulea authored
VQ indices in the range [cur_num_qps, max_vqs) represent queues that have not yet been activated. .set_vq_ready should not activate these VQs. Reviewed-by:
Cosmin Ratiu <cratiu@nvidia.com> Acked-by:
Eugenio Pérez <eperezma@redhat.com> Signed-off-by:
Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20240626-stage-vdpa-vq-precreate-v2-24-560c491078df@nvidia.com> Signed-off-by:
-
Dragos Tatulea authored
The vdpa device can be reset many times in sequence without any significant state changes in between. Previously this was not a problem: VQs were torn down only on first reset. But after VQ pre-creation was introduced, each reset will delete and re-create the hardware VQs and their associated resources. To solve this problem, avoid resetting hardware VQs if the VQs are still in a blank state. Reviewed-by:
-
Dragos Tatulea authored
There are a few conditions under which the hardware VQs need a full teardown and setup: - VQ size changed to something else than default value. Hardware VQ size modification is not supported. - User turns off certain device features: mergeable buffers, checksum virtio 1.0 compliance. In these cases, the TIR and RQT need to be re-created. Add a needs_teardown configuration variable and set it when detecting the above scenarios. On next DRIVER_OK, the resources will be torn down first. Reviewed-by:
-
Dragos Tatulea authored
Currently, hardware VQs are created right when the vdpa device gets into DRIVER_OK state. That is easier because most of the VQ state is known by then. This patch switches to creating all VQs and their associated resources at device creation time. The motivation is to reduce the vdpa device live migration downtime by moving the expensive operation of creating all the hardware VQs and their associated resources out of downtime on the destination VM. The VQs are now created in a blank state. The VQ configuration will happen later, on DRIVER_OK. Then the configuration will be applied when the VQs are moved to the Ready state. When .set_vq_ready() is called on a VQ before DRIVER_OK, special care is needed: now that the VQ is already created a resume_vq() will be triggered too early when no mr has been configured yet. Skip calling resume_vq() in this case, let it be handled during DRIVER_OK. For virtio-vdpa, the device configuration is done earlier during .vdpa_dev_add() by vdpa_register_device(). Avoid calling setup_vq_resources() a second time in that case. On a 64 CPU, 256 GB VM with 1 vDPA device of 16 VQps, the full VQ resource creation + resume time was ~370ms. Now it's down to 60 ms (only VQ config and resume). The measurements were done on a ConnectX6DX based vDPA device. Signed-off-by:
-
Dragos Tatulea authored
Resume a VQ if it is already created when the number of VQ pairs increases. This is done in preparation for VQ pre-creation which is coming in a later patch. It is necessary because calling setup_vq() on an already created VQ will return early and will not enable the queue. For symmetry, suspend a VQ instead of tearing it down when the number of VQ pairs decreases. But only if the resume operation is supported. Reviewed-by:
-
Dragos Tatulea authored
Start using the suspend/resume_vq() error return codes previously added. Reviewed-by:
Zhu Yanjun <yanjun.zhu@linux.dev> Signed-off-by:
-
Dragos Tatulea authored
There are a few more places modifying the VQ to Ready directly. Let's consolidate them into resume_vq(). The redundant warnings for resume_vq() errors can also be dropped. There is one special case that needs to be handled for virtio-vdpa: the initialized flag must be set to true earlier in setup_vq() so that resume_vq() doesn't return early. Reviewed-by:
-
Dragos Tatulea authored
Instead of blindly calling suspend/resume_vqs(), make then return error codes. To keep compatibility, keep suspending or resuming VQs on error and return the last error code. The assumption here is that the error code would be the same. Reviewed-by:
-
Dragos Tatulea authored
Until now resume_vq() was used only for the suspend/resume scenario. This change also allows calling resume_vq() to bring it from Init to Ready state (VQ initialization). Signed-off-by:
-
Dragos Tatulea authored
Based on the filled flag, create VQs that are filled or blank. Blank VQs will be filled in later through VQ modify. Downstream patches will make use of this to pre-create blank VQs at vdpa device creation. Signed-off-by:
-
Dragos Tatulea authored
Otherwise, when virtqueues are moved from INIT to READY the latest mkey will not be set appropriately. Reviewed-by:
-
Dragos Tatulea authored
Currently rqt_size is initialized during device flag configuration. That's because it is the earliest moment when device knows if MQ (multi queue) is on or off. Shift this configuration earlier to device creation time. This implies that non-MQ devices will have a larger RQT size. But the configuration will still be correct. This is done in preparation for the pre-creation of hardware virtqueues at device add time. When that change will be added, RQT will be created at device creation time so it needs to be initialized to its max size. Reviewed-by:
-
Dragos Tatulea authored
The virtqueue size is a pre-requisite for setting up any virtqueue resources. For the upcoming optimization of creating virtqueues at device add, the virtqueue size has to be configured. The queue size check in setup_vq() will always be false. So remove it. Signed-off-by:
-
Dragos Tatulea authored
This is done in preparation for the pre-creation of hardware virtqueues at device add time. Signed-off-by:
-
Dragos Tatulea authored
This is done in preparation for the pre-creation of hardware virtqueues at device add time. Signed-off-by:
-
Dragos Tatulea authored
Function is used to set default values, so name it accordingly. Signed-off-by:
-
Dragos Tatulea authored
The hardware VQ configuration is mirrored by data in struct mlx5_vdpa_virtqueue . Instead of clearing just a few fields at reset, fully clear the struct and initialize with the appropriate default values. As clear_vqs_ready() is used only during reset, get rid of it. Reviewed-by:
-
Dragos Tatulea authored
The virtio spec says that a vdpa device should start off with one queue pair. The driver is already compliant. This patch moves the initialization to device add and reset times. This is done in preparation for the pre-creation of hardware virtqueues at device add time. Signed-off-by:
-
Dragos Tatulea authored
Use the dedicated suspend_vqs() function instead. Reviewed-by:
-
Dragos Tatulea authored
No need to iterate over max number of VQs. Reviewed-by:
-
Dragos Tatulea authored
The check is done inside teardown_vq(). Reviewed-by:
-
Dragos Tatulea authored
Originally, the second loop initialized the CVQ. But (acde3929 ("vdpa/mlx5: Use consistent RQT size") initialized all the queues in the first loop, so the second iteration in init_mvqs() is never called because the first one will iterate up to max_vqs. Reviewed-by:
-
Dragos Tatulea authored
... by changing the setup_vq_resources() parameter type. Reviewed-by:
-
Dragos Tatulea authored
setup_driver()/teardown_driver() are a bit vague. These functions are used for virtqueue resources. Same for alloc_resources()/teardown_resources(): they represent fixed resources that are meant to exist during the device lifetime. Reviewed-by:
-
Peter-Jan Gootzen authored
Currently, when the Virtio queue is full, a work item is scheduled to execute in 1ms that retries adding the request to the queue. This is a large amount of time on the scale on which a virtio-fs device can operate. When using a DPU this is around 30-40us baseline without going to a remote server (4k, QD=1). This patch changes the retrying behavior to immediately filling the Virtio queue up again when a completion has been received. This reduces the 99.9th percentile latencies in our tests by 60x and slightly increases the overall throughput, when using a workload IO depth 2x the size of the Virtio queue and a DPU-powered virtio-fs device (NVIDIA BlueField DPU). Signed-off-by:
Peter-Jan Gootzen <pgootzen@nvidia.com> Reviewed-by:
Max Gurtovoy <mgurtovoy@nvidia.com> Reviewed-by:
Yoray Zack <yorayz@nvidia.com> Message-Id: <20240517190435.152096-3-pgootzen@nvidia.com> Signed-off-by:
Stefan Hajnoczi <stefanha@redhat.com>
-
Peter-Jan Gootzen authored
Currently, when the enqueueing of a request or forget operation fails with -ENOMEM, the enqueueing is retried after a timeout. This patch removes this behavior and treats -ENOMEM in these scenarios like any other error. By bubbling up the error to user space in the case of a request, and by dropping the operation in case of a forget. This behavior matches that of the FUSE layer above, and also simplifies the error handling. The latter will come in handy for upcoming patches that optimize the retrying of operations in case of -ENOSPC. Signed-off-by:
-
