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

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

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.

-- 
MST