From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 19 Jan 2022 10:38:22 -0500 From: "Michael S. Tsirkin" Subject: Re: [PATCH 1/5] Add virtio Admin Virtqueue specification Message-ID: <20220119102027-mutt-send-email-mst@kernel.org> References: <20220113124137-mutt-send-email-mst@kernel.org> <20220117165941-mutt-send-email-mst@kernel.org> <20220118015736-mutt-send-email-mst@kernel.org> <20220118021651-mutt-send-email-mst@kernel.org> <84a8a004-cc78-170d-9856-f0b5f8115a6f@nvidia.com> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline To: Max Gurtovoy Cc: Parav Pandit , "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 Wed, Jan 19, 2022 at 04:47:10PM +0200, Max Gurtovoy wrote: > I agree, I don't see why it's not possible to use a different command opcode > for vf interrupt configuration and sf interrupt configuration. > > We're not short in opcodes and it's very elegant and extendable IMO. > > I think the order should be: > > 1. add adminq to virtio spec with one simple example (say MSIX config for > VFs) > > 2. in parallel submission for admin commands: S-IOV support, num VQs config, > feature bits config and more... Up to you for sure but didn't you guys try this already? I think there are concerns such as how this will be extended to support subfunctions. I can't say what do you want to do about that in v2, ignoring them completely is probably not a good way to get more support in the TC. Just my two cents, hope this helps. -- MST