On Tue, Feb 08, 2022 at 06:25:41AM +0000, Parav Pandit wrote: > > > From: Michael S. Tsirkin <m...@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 --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
