similar to: [RFC PATCH net 0/3] virtio-net: allow usage of small vrings

At the moment, if a network device uses vrings with less than MAX_SKB_FRAGS + 2 entries, the device won't be functional. The following condition vq->num_free >= 2 + MAX_SKB_FRAGS will always evaluate to false, leading to TX timeouts. This patch introduces a new variable, single_pkt_max_descs, that holds the max number of descriptors we may need to handle a single packet. This patch

On Sun, Apr 30, 2023 at 04:15:17PM +0300, Alvaro Karsz wrote: > At the moment, if a network device uses vrings with less than > MAX_SKB_FRAGS + 2 entries, the device won't be functional. > > The following condition vq->num_free >= 2 + MAX_SKB_FRAGS will always > evaluate to false, leading to TX timeouts. > > This patch introduces a new variable,

> > At the moment, if a network device uses vrings with less than > > MAX_SKB_FRAGS + 2 entries, the device won't be functional. > > > > The following condition vq->num_free >= 2 + MAX_SKB_FRAGS will always > > evaluate to false, leading to TX timeouts. > > > > This patch introduces a new variable, single_pkt_max_descs, that holds > > the

This patch exports a new virtio core function: virtio_block_feature. The function should be called during a virtio driver probe. If a virtio driver blocks features during probe and fails probe, virtio core will reset the device, try to re-negotiate the new features and probe again. Signed-off-by: Alvaro Karsz <alvaro.karsz at solid-run.com> --- drivers/virtio/virtio.c | 73

On Sun, Apr 30, 2023 at 04:15:16PM +0300, Alvaro Karsz wrote: > This patch exports a new virtio core function: virtio_block_feature. > The function should be called during a virtio driver probe. > > If a virtio driver blocks features during probe and fails probe, virtio > core will reset the device, try to re-negotiate the new features and > probe again. > >

On Sun, Apr 30, 2023 at 06:54:08PM +0000, Alvaro Karsz wrote: > > > At the moment, if a network device uses vrings with less than > > > MAX_SKB_FRAGS + 2 entries, the device won't be functional. > > > > > > The following condition vq->num_free >= 2 + MAX_SKB_FRAGS will always > > > evaluate to false, leading to TX timeouts. > > > >

Check vring size and fail probe if a transmit/receive vring size is smaller than MAX_SKB_FRAGS + 2. At the moment, any vring size is accepted. This is problematic because it may result in attempting to transmit a packet with more fragments than there are descriptors in the ring. Furthermore, it leads to an immediate bug: The condition: (sq->vq->num_free >= 2 + MAX_SKB_FRAGS) in

Add VIRTIO_F_NOTIFICATION_DATA support for vDPA transport. If this feature is negotiated, the driver passes extra data when kicking a virtqueue. A device that offers this feature needs to implement the kick_vq_with_data callback. kick_vq_with_data receives the vDPA device and data. data includes the vqn, next_off and next_wrap for packed virtqueues. This patch follows a patch [1] by Viktor

Add more vDPA callbacks. [s/g]et_vq_state is added in patch 1, including a new control mechanism to read data from the DPU. suspend is added in patch 2. Alvaro Karsz (2): vdpa/snet: support getting and setting VQ state vdpa/snet: support the suspend vDPA callback drivers/vdpa/solidrun/Makefile | 1 + drivers/vdpa/solidrun/snet_ctrl.c | 324 +++++++++++++++++++++++++++++

Add more vDPA callbacks. [s/g]et_vq_state is added in patch 1, including a new control mechanism to read data from the DPU. suspend is added in patch 2. Alvaro Karsz (2): vdpa/snet: support getting and setting VQ state vdpa/snet: support the suspend vDPA callback drivers/vdpa/solidrun/Makefile | 1 + drivers/vdpa/solidrun/snet_ctrl.c | 324 +++++++++++++++++++++++++++++

The callback sends a resume command to the DPU through the control mechanism. Signed-off-by: Alvaro Karsz <alvaro.karsz at solid-run.com> --- drivers/vdpa/solidrun/snet_ctrl.c | 6 ++++++ drivers/vdpa/solidrun/snet_main.c | 15 +++++++++++++++ drivers/vdpa/solidrun/snet_vdpa.h | 1 + 3 files changed, 22 insertions(+) diff --git a/drivers/vdpa/solidrun/snet_ctrl.c

> > This patchset follows a discussion in the mailing list [1]. > > > > This fixes only part of the bug, rings with less than 4 entries won't > > work. > > Why the difference? > Because the RING_SIZE < 4 case requires much more adjustments. * We may need to squeeze the virtio header into the headroom. * We may need to squeeze the GSO header into the

Unify virtio_net_ctrl_coal_tx and virtio_net_ctrl_coal_rx structs into a single struct, virtio_net_ctrl_coal, as they are identical. This patch follows the VirtIO spec patch: https://lists.oasis-open.org/archives/virtio-comment/202302/msg00431.html Signed-off-by: Alvaro Karsz <alvaro.karsz at solid-run.com> --- drivers/net/virtio_net.c | 15 +++++++--------

On Sun, Apr 30, 2023 at 04:15:15PM +0300, Alvaro Karsz wrote: > At the moment, if a virtio network device uses vrings with less than > MAX_SKB_FRAGS + 2 entries, the device won't be functional. > > The following condition vq->num_free >= 2 + MAX_SKB_FRAGS will always > evaluate to false, leading to TX timeouts. > > This patchset attempts this fix this bug, and to

Hi Viktor, > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > index 4c3bb0ddeb9b..f9c6604352b4 100644 > --- a/drivers/virtio/virtio_ring.c > +++ b/drivers/virtio/virtio_ring.c > @@ -2752,6 +2752,23 @@ void vring_del_virtqueue(struct virtqueue *_vq) > } > EXPORT_SYMBOL_GPL(vring_del_virtqueue); > > +u32 vring_notification_data(struct

> Is this too late to be changed? > > Thanks You're right. What do you suggest, dropping the patch or adding the unified struct without deleting the existing ones?

On Sun, Apr 02, 2023 at 08:17:49AM +0000, Alvaro Karsz wrote: > Hi Viktor, > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > index 4c3bb0ddeb9b..f9c6604352b4 100644 > > --- a/drivers/virtio/virtio_ring.c > > +++ b/drivers/virtio/virtio_ring.c > > @@ -2752,6 +2752,23 @@ void vring_del_virtqueue(struct virtqueue *_vq) > > }

From: Jiri Pirko <jiri at nvidia.com> Virtio spec introduced a feature VIRTIO_NET_F_GUEST_HDRLEN which when which when set implicates that device benefits from knowing the exact size of the header. For compatibility, to signal to the device that the header is reliable driver also needs to set this feature. Without this feature set by driver, device has to figure out the header size itself.

> tagged. in the future pls CC everyone on the cover letter too. Ok, thanks. I'm not getting responses, should I resend it?

> Hmm so I conclude that drivers without kick_vq_with_data > should not accept VIRTIO_F_NOTIFICATION_DATA then? Yes, vDPA drivers without kick_vq_with_data should not offer VIRTIO_F_NOTIFICATION_DATA in the first place. We can be more forgiving in such cases and clear the feature bit + print a warning. It may be easier to debug when creating a new vDPA driver.