[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v3 1/4] Add virtio Admin virtqueue
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]