OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


> 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]