On Mon, Feb 04, 2019 at 01:36:28PM +0800, Stefan Hajnoczi wrote: > On Fri, Feb 01, 2019 at 09:43:02AM -0800, Rob Miller wrote: > > Agreed that this is needed. > > > > I would also like to suggest splitting the F_IN_ORDER into > > F_RX_IN_ORDER and F_TX_IN_ORDER to support hw LRO implementations, > > which can be more of a scatter/gather than tx. This would allow > > batchmode for tx at least in packed rings. > > > > Finally, i would suggest a means to specify a given rings ring mode > > and packed leans more towards TX, whilst split can be either really > > depending upon LRO, jumbo, rx buff size, ect.. just like F_IN_ORDER, > > we can have RX & TX, split out. > > Device types beside virtio-net might also want per-virtqueue F_IN_ORDER > and other features,
Do you know that they will? Now that we already have implementations, how about a prototype patch showing the performance gains? > so let's find a way to make it independent of > virtio-net concepts like rx/tx. Add another field along with VQ PA. It's not rocket science. > The per-virtqueue in-order flag could live in struct > pvirtq_event_suppress (VIRTIO 1.1 2.7.14 Event Suppression Structure > Format). That's for dynamic things though. > Or a new structure could be used for per-virtqueue configuration. Doing > this is a little tricky if you want to select split vs packed ring > layout on a per-virtqueue basis, since this structure is part of the > split/packed ring layout. It would probably be necessary to add vring > mode selection to the transport (PCI, MMIO, CCW) instead. > > Stefan Yes. -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
