[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [virtio-dev] Re: [virtio-comment] Re: [PATCH v18] virtio-net: support inner header hash
> From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> On > Behalf Of Michael S. Tsirkin > Sent: Thursday, June 22, 2023 1:38 PM > > On Thu, Jun 22, 2023 at 05:15:50PM +0000, Parav Pandit wrote: > > > > > > > From: Michael S. Tsirkin <mst@redhat.com> > > > Sent: Thursday, June 22, 2023 1:11 PM > > > > > > 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. > > > > > > Actually it's RO so you *can* read it without any issues: > > > > It is RO but not same across all devices. > > If you provision VFs differently. I got it. > > > > - block guest access to status > > > - check DRIVER. > > > If set: > > > - read features, config > > > If not set: > > > - read features, config > > > - reset > > > > > This is what I explained. > > It is more messy if you equate to GET command has mess. > > At least it works. > And new GET command also works when CVQ is trapped. And also works when AQ is querying capabilities of a member device using WIP cmd. > > > I am not saying it is elegant but then all of vdpa pile of hacks is not elegant. > > > > > I don't want to comment for vdpa. But it is not part of the spec... > > Neither is QEMU. It's one of spec implementations. Yes, we care about not > adding blockers for features that, superficially, might make sense for them. > > > > And I am all for building something better but we didn't build it yet. > > > > The proposal for 1.4 is literally very simple as below. > > 1. All existing fields of cfg space stays in cfg space 2. Any new > > capabilities to be queried, query using a vq (aq, cfgvq, whatevervq). > > 3. Optionally existing fields can be queries over vq of #2 Once this > > arrive, no need for new GET commands. > > Till that time, don't keep infinitely grow the cfg space. > > Any next addition to cfg space, should work on defining the cfgvq. > > Simple, but short sighted. I know you guys don't support your hardware for 10- > 20 years but for software people do. > And so "All existing fields of cfg space stays in cfg space" is a bad idea simply > because this does not allow removing things from config space not in 10 not in > 20 years not ever. > #1 is for backward compat for existing drivers. You missed about #3. Existing cfg space fields can be queries using the cfgvq too. > > Instead we need to allow two ways to access config space. Teach drivers about > both, actually mandate supporting both. And then devices will make their own > cost/benefit decision about which features they want to support in MMIO. If both method is mandated, I don't see benefit at all of two methods. VQ is generic part of the spec for slow and fast operation, so it is not at all a cost for config reading.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]