RE: [PATCH v3 1/4] Add virtio Admin virtqueue

From: Parav Pandit <parav@nvidia.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Max Gurtovoy <mgurtovoy@nvidia.com>,
	"virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	Shahaf Shuler <shahafs@nvidia.com>, Oren Duer <oren@nvidia.com>,
	"stefanha@redhat.com" <stefanha@redhat.com>
Subject: RE: [PATCH v3 1/4] Add virtio Admin virtqueue
Date: Tue, 8 Feb 2022 07:04:12 +0000	[thread overview]
Message-ID: <PH0PR12MB548104AB80FA36544DB3D7D0DC2D9@PH0PR12MB5481.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20220208014039-mutt-send-email-mst@kernel.org>


> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Tuesday, February 8, 2022 12:13 PM

> On Tue, Feb 08, 2022 at 06:25:41AM +0000, Parav Pandit wrote:
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Monday, February 7, 2022 4:09 PM
> > >
> > > Next, trying to think about scalable iov extensions. So we will have
> > > groups of VFs and then SFs as the next level.
> > > How does one differentiate between the two?
> > > Maybe reserve a field for "destination type"?
> > >
> > We already discussed this in v2.
> > SF will have different identification than 16-bits. And no one knows what
> that would be.
> > We just cannot reserve some arbitrary bytes for unknown.
> > You suggested in v2 to reserve 4 bytes for sf_id, and I explained you that 4
> bytes may not be enough.
> >
> > Whether SFs are on top of VFs or SFs are on top of PFs or both is completely
> different spec.
> > Whether PF will manage SFs of the VFs or it will be done nested manner by
> VF etc is a completely different discussion than what is being proposed here.
> > Whether PF will manage the SF is yet another big question. We work with
> users and they dislike this.
> > To address it, some OS has a different management interface (not visible to
> PF) for SF life cycle even though SFs are anchored on a PF.
> >
> > So SF/iov extension discussion has long way to go for community to first
> understand the use cases before crafting some extension.
> >
> > So lets not complicate and mix things here for a blurry definition of scalable
> iov/sf extension.
> 
> Some reserved bytes won't hurt. 2 bytes for type gives us 64k types, sounds like
> that should be enough.
It doesn't stop there.
Mentioning some destination type, interrupt type, etc also requires reserving bytes for different device id type, interrupt type and more.
We past this stage long ago after discussing this in v1 at [1].
It is just better and cleaner to define a different structure to describe SF/iov and its configuration.

[1] https://markmail.org/search/?q=Add+virtio+Admin+Virtqueue+specification&q=list%3Aorg.oasis-open.lists.virtio-dev#query:Add%20virtio%20Admin%20Virtqueue%20specification%20list%3Aorg.oasis-open.lists.virtio-dev+page:2+mid:ncyxqhjlvusjfust+state:results