virtio — archive

[PATCH requirements 0/7] virtio net new features requirements

From: Parav Pandit <[email protected]>
To: [email protected]
Date: Wed, 07 Jun 2023 20:53:00 -0000

> From: Michael S. Tsirkin <[email protected]> > Sent: Wednesday, June 7, 2023 4:50 PM > > On Wed, Jun 07, 2023 at 08:39:11PM +0000, Parav Pandit wrote: > > > > > > > From: Michael S. Tsirkin <[email protected]> > > > Sent: Wednesday, June 7, 2023 4:36 PM > > > > > > On Tue, Jun 06, 2023 at 11:08:12PM +0000, Parav Pandit wrote: > > > > We can debate and change from cvq to new cfgvq as part of the journey. > > > > It is fine. > > > > > > Just to stress, cvq has a bunch of drawbacks. For example it is hard > > > to access from the hypervisor since it's DMA from VF. > > > This is why I think our direction should be to add a vq transport > > > that does all config accesses over admin commands. > > We debate this before, so will write is below. > > > Or maybe I'm wrong. > > > > > > > > But, let's distinguish between requirements, and between > > > requirements and design. Getting supported counters is a requirement. > > > Doing this over cvq is a design. Reducing MMIO registers is a requirement. > OK? > > > > Yes, I would write it as reducing MMIO and accessing it over vq of the own > device is a requirement. > > reducing mmio is a requirement (unrelated to counters btw, it's general). access > over vq is a design point I think. Didn't you ask to combine requirements and high-level design together in the first draft? What changed? Should we create a new queue, reuse cvq, generalize over cfg q, etc are detailed design discussions.