From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Parav Pandit Subject: RE: [virtio-comment] RE: [PATCH v5 2/7] Introduce admin command set Date: Mon, 20 Jun 2022 23:54:38 +0000 Message-ID: References: <20220515111056-mutt-send-email-mst@kernel.org> <20220517074130-mutt-send-email-mst@kernel.org> <20220620055014-mutt-send-email-mst@kernel.org> <20220620123447-mutt-send-email-mst@kernel.org> <05e1c6be-9d80-1fcb-f09b-70f5b4d562e4@nvidia.com> <20220620125514-mutt-send-email-mst@kernel.org> <20220620163309-mutt-send-email-mst@kernel.org> In-Reply-To: <20220620163309-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To: "Michael S. Tsirkin" Cc: Max Gurtovoy , "jasowang@redhat.com" , "virtio-comment@lists.oasis-open.org" , "cohuck@redhat.com" , "virtio-dev@lists.oasis-open.org" , Oren Duer , Shahaf Shuler , "aadam@redhat.com" , "virtio@lists.oasis-open.org" List-ID: > From: Michael S. Tsirkin > Sent: Monday, June 20, 2022 4:54 PM >=20 > On Mon, Jun 20, 2022 at 05:19:26PM +0000, Parav Pandit wrote: > > > > > > > From: Michael S. Tsirkin > > > Sent: Monday, June 20, 2022 1:04 PM > > > > > > Max with transport I am not talking about admin queue specifically. > > > The point Parav made is that he wants to avoid using memory writable > > > registers for slow path configuration, as far as possible. > > Precisely, especially those one which doesn't have direct impact on the > device initialization sequence. > > > > Please see my previous response. >=20 > Right. However > 1. The cost is quite modest here. E.g. we have two feature selectors whic= h > just wastes bits. Today because of short proposal there are two bits. But I expect them to gr= ow. For example, a device capable of modifying feature bits, num_vqs will expos= e two more bits. For net specific device, one might want to configure mac, mtu of the device= . LM specific capabilities, write logging capable. List will have few more entries. > How bad would be to just use feature bits for now, and > later/separately add an interface that reduces amount of writeable mmi= o, > if deemed appropriate? If one can think of using AQ to implement vdpa over virtio device, and havi= ng AQ on each VF, each VF will now have to have rare entries as registers. I think we can do better. > 2. Driver features are writeable but device features are not - > so why not have device features in memory? >=20 If virtio spec builds the channel to write driver features, it is more logi= cal to use same channel to read too.