[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
On Thu, Jun 22, 2023 at 12:32:33PM +0000, Parav Pandit wrote: > > > > From: Michael S. Tsirkin <mst@redhat.com> > > Sent: Thursday, June 22, 2023 2:23 AM > > > > On Wed, Jun 21, 2023 at 08:52:04PM +0000, Parav Pandit wrote: > > > > > > > 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. > > > > But there GET just reports the current state. Not the read only capability. So > > there would be cost per VF to keep it in config space. > > This one is RO no cost per VF. Let's make it convenient? > > > And each VF can have different value hence requires per VF storage in the device. > > > > > > > > > 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. > > > > Not sure what's the implication? > Implication is device needs to store this in always available on-chip memory which is not good. Oh by devices you mean VFs. Now I get your motivation, at least. Thanks. > > > > > > 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. > > > > Not migration itself, provisioning. > > > Provisioning driver usually do not attach to the member device directly. > This requires device reset, followed by reaching _DRIVER stage, querying features etc and config area. > And unbinding it and second reset by member driver. Ugh. > Provisioning driver also needs to get the state or capabilities even when member driver is already attached. > So config space is not much a gain either. > Absolutely, that's why we have admin commands. I was hoping for an admin command that basically gets/sets RO fields of the config space. > > > > 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. > > > > we can do that, sure. > > > > > 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. > > > > > > > Not register by register, we can send all of config space as long as it's RO. This > > field is. > > > It is RO in context of one member device, but every VF can have different value. > The device will never know if one will use new cmdvq to access or some old driver will use without it. > And hence, it always needs to provision it on onchip memory for backward compatibility. > > Instead of decision point being RO vs RW, > any new fields via cmdvq and existing fields stays in cfg space, give predictable behavior to size the member devices in the system. > Once the cmdvq is available, we can get rid of GET command used in this version for new future features. > Till that arrives, GET command is the efficient way. I understand. I just don't much like these patchwork solutions though. And I don't like that we will pay by not having a single conherent way to provision and query capabilities through config space, instead just for this thing we will have a special thing. Why don't we focus on a work on a full solution? Just don't implement this thing in your devices meanwhile until we do. > > -- > > MST
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]