Re: [virtio-dev] RE: [PATCH v5 0/7] Introduce device group and device management

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

On Sun, Jul 24, 2022 at 09:25:17PM +0000, Parav Pandit wrote:
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Sunday, July 24, 2022 5:10 PM
> > 
> > I snippet rest of mail - wasn't sure whether you were waiting for an answer.
> > 
> > On Wed, Jul 06, 2022 at 08:45:26PM +0000, Parav Pandit wrote:
> > > > Again I don't know what to do with this. I feel if it's put up for
> > > > vote in the current form it's likely to fail. I propose cutting out
> > > > as much as possible as a first step, so we can make progress.
> > > > Specifically the MSI-X commands are clearly PF specific so there's
> > > > no concern about VF memory use at all.  We can worry about other types
> > of command down the road when it becomes relevant.
> > >
> > > Since feature bits proposes are limited to PF, I agree that current short cut
> > is fine to place in 64-127 feature bits.
> > >
> > > When/if similar functionality is needed at scale for the VF or SIOV devices,
> > placing them in 64-127 bits area weight way less for sake of "people
> > familiarity to feature bits".
> > > Do you agree?
> > 
> > I think we can all agree that extensions for scalable IOV will need more work
> > if that is what you are saying.
> Yes.
> Even VFs to negotiate few tens of Kbytes seems waste of resources for one time read/write bits.

It has small a cost for sure, but it's negligeable compared to the
current cost of implementing the spec.

> So better to start using AQ for new functionalities.
> What is stopping us to adapt to this modern and optimized way?

The cost/benefit tradeoff. The benefit is a theorectical gain of a few
bits per VF. The cost is very real engineering time spent.

I can keep poking holes and finding underspecified behaviour in the
proposal. But I don't really see why would anyone spend the time
duplicating what virtio spec is already doing decently.

> Why cant we keep features bits limited to device startup negotiation scheme?

Well they are already used for much more. So sure, maybe work on
changing that, but IMO trying it all in a single huge project is just
not a great idea.

> Other unrelated bits are added in past to feature bits  But lets follow the good examples instead when the new choice is already proposed and defined.

So IMHO saving a few bits here and there when we are spending tens of
bytes on state makes no sense.

Something like transport over AQ (or the transport vq proposal) or some
other concerted effort to save per device memory would be needed for
SIOV, and maybe it's useful for SRIOV too.



-- 
MST