[virtio-dev] Re: [virtio-comment] RE: [PATCH v19] virtio-net: support inner header hash

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 28, 2023 at 04:23:09AM +0000, Parav Pandit wrote:
> 
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Tuesday, June 27, 2023 11:46 PM
> > 
> > Having it in the config space, then a type agnostic provisioning through config
> > space + feature bits just works fine.
> >
> Provisioning is far simpler thing to do in device specific way than asking device to store this value in onchip area which is rarely accessed.

I thought a lot about this over the weekend. I just do not see this
working out, sorry.  Two things is never easier than one. We already
need config space with provisioning.  In fact e.g. on Linux we want
drivers to keep doing virtio_cread() and all the DMA tricks should be
hidden behind the scenes. You don't like it that config space is
on-chip? Build an interface for it not to be on chip. There is simply
no downside to that.

I came back after a small break and I still see this discussion
that keeps playing out as a big distraction.
In particular where are you doing to store the things that are for DMA?
In system RAM? We don't *have* anywhere in system RAM to store this,
we will need an interface to allocate system RAM and pass it to device
for this idea to work. So in 1.3 where we won't have this, there is
much less of an excuse to use a vq.




> There are many fields of many features for 1.4 are discussed including this one. All of these capabilities just cannot be stored in config space.

config space is synchronous interface, vq is asynchronous.  Setup
is just too messy to do asynchronously. So yes, config space.


Please let people just focus on fixing config space instead of
temporary cvq hacks.

-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org