From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 8 Feb 2022 01:42:41 -0500 From: "Michael S. Tsirkin" Subject: Re: [PATCH v3 1/4] Add virtio Admin virtqueue Message-ID: <20220208014039-mutt-send-email-mst@kernel.org> References: <20220203075716.11684-1-mgurtovoy@nvidia.com> <20220203075716.11684-2-mgurtovoy@nvidia.com> <20220207052843-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline To: Parav Pandit Cc: Max Gurtovoy , "virtio-comment@lists.oasis-open.org" , "cohuck@redhat.com" , "virtio-dev@lists.oasis-open.org" , "jasowang@redhat.com" , Shahaf Shuler , Oren Duer , "stefanha@redhat.com" List-ID: On Tue, Feb 08, 2022 at 06:25:41AM +0000, Parav Pandit wrote: > > > From: Michael S. Tsirkin > > 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