OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [virtio-comment] Re: [PATCH v18] virtio-net: support inner header hash


> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Wednesday, June 21, 2023 4:38 PM

> > > And the field is RO so no memory cost to exposing it in all VFs.
> > Two structures do not bring the asymmetry.
> > Accessing current and enabled fields via two different mechanism is bringing
> the asymmetry.
> 
> I guess it's a matter of taste, but it is clearly more consistent with other hash
> things, to which it's very similar.
>
This is consistent with new commands we define including notification coalescing whose GET is not coming config space.
 
> 
> Nah, config space is too convenient when we can live with its limitations. I don't
> thin kwe prefer not to keep growing it.
> For some things such as this one it's perfect.
>
Fields are different between different devices.

> For example, for migration driver might want to validate that two devices have
> same capability. doing it without dma is nicer.
> 
A migration driver for real world scenario, will almost have to use the dma for amount of data it needs to exchange.

> Another example, future admin transport will have ability to provision devices
> by supplying their config space.
> This will include this capability automatically, if instead we hide it in a command
> we need to do extra custom work.
> 
> > So we do not prefer to keep growing the config space anymore, hence
> > GET is the right approach to me.
> 
> Heh I know you hate config space. Let it go, stop wasting time arguing about the
> same thing on every turn and instead help define admin transport to solve it

This was discussed many times, a driver to have a direct (non-intercepted by owner device) channel to device.
If you mean this non-intercepted channel as admin transport, fine.
If you mean this is intercepted and it is going over admin cmd, then it is of no use for all future interfaces.

We discussed this in thread with you and Jason.
I provided concrete example with size and device provisioning math too and other example of multi-physical address VQ.
So transporting register by register over some admin transport is sub-optimal.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]