[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [EXT] Re: Regarding VIRTIO_F_IN_ORDER and VIRTIO_F_NOTIFICATION_DATA
From: |
Srujana Challa |
Subject: |
RE: [EXT] Re: Regarding VIRTIO_F_IN_ORDER and VIRTIO_F_NOTIFICATION_DATA feature bits |
Date: |
Thu, 14 Dec 2023 08:05:21 +0000 |
> > ----------------------------------------------------------------------
> > On Wed, Dec 13, 2023 at 04:27:40PM +0000, Srujana Challa wrote:
> > > Hi Michael,
> > >
> > > While verifying virtio frontend drivers of guest OS on qemu with
> > > vhost-vdpa backend, we came across feature bits VIRTIO_F_IN_ORDER
> > > and VIRTIO_F_NOTIFICATION_DATA, which are introduced in virtio 1.1
> > > spec, are not yet enabled in qemu. These feature flags are very much
> > > useful for achieving better virtio-net performance and most of the
> > > latest
> > hardware VDPA devices supports these feature flags as per of virtio spec.
> >
> > Could you share more about which device do you mean? Does Marvell ship
> > or intends to ship one?
> >
> We are planning to ship virtio compliant devices (Marvell CN103/106 DPUs).
>
> > > Could you let us know if there are any plans, to add support for
> > > these features in upcoming qemu releases.
> > > I guess there was some discussion on VIRTIO_F_IN_ORDER feature bit
> > > long ago,
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__patchew.org_QEMU_
> > > 1533833677-2D27512-2D1-2Dgit-2Dsend-2Demail-2Di.maximets-
> > 40samsung.com
> > >
> >
> _&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Fj4OoD5hcKFpANhTWdwQzj
> > T1Jpf7veC5
> > > 263T47JVpnc&m=f_dkNKw4UhQulkhjHzd-
> > 2YuAvT5n_l_7yuu2r6wSNY2cRHCHnkEM1w2m
> > >
> BEX6Y_yv&s=E3PwNom0AdGnh6dp0WsFPANXX5qH3gAcUYucDyZ6_7Q&e=
> > > Seems like that discussion has not reached any conclusion or further
> work.
> > >
> > > Thanks,
> > > Srujana.
> >
> > Yes that patch got comments and these were not addressed.
> > Feel free to address them so this can proceed.
> >
> We are planning to address the concerns discussed in that mail chain.
Can we make the "vhost-internal" backend with its own set of supported
features? In this case we'll be able to use "host_features" as a set of
features available for negotiation and every backend (including "internal" one)
will negotiate features that it supports, as asked in the above patch thread?
> > --
> > MST