Re: [virtio-dev] RFC: Doorbell suppression, packed-ring mode and hardware offload

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Feb 19, 2019 at 02:21:01PM +0800, Jason Wang wrote:
> 
> On 2019/2/15 äå12:23, Michael S. Tsirkin wrote:
> > On Fri, Feb 15, 2019 at 11:59:55AM +0800, Jason Wang wrote:
> > > On 2019/2/14 äå11:41, Michael S. Tsirkin wrote:
> > > > > I think it's as simple as increase the avail idx by X? Since descriptor were
> > > > > used in order, device can just read the next X-1 descriptors in this case.
> > > > > 
> > > > > Thanks
> > > > Right so a spec change would be needed, it's not transparent to guest.
> > > 
> > > With the change, IN_ORDER + split_ring becomes something like submission
> > > queue (descriptor ring) + completion queue (used ring). And used ring access
> > > could be eliminated sometime, e.g for net for TX, we don't care about used
> > > len.
> > Oh yes but fundamentally this becomes very close to packed ring.
> 
> 
> Looks not, it's a two rings vs one ring.
> 
> 
> > So I'm
> > not sure yet another option is justified by a small gain in PPS,
> 
> 
> 10% is done with less than 10 lines of code, I suspect maybe dpdk can see
> more.
> 
> 
> > especially considering that it depends on in order and so doesn't
> > support zero copy.
> 
> 
> It looks to me in order is not the blocker, even if we allow out of order,
> we may still suffer from HOL.

HOL isn't an issue with e.g. a dedicated VF.


> 
> > 
> > > What's more interesting is, this avail idx optimization is not required for
> > > out of order completion which means it could be used for e.g block or SCSI
> > > device.
> > I don't get the last sentence. This only works for in order right?
> 
> 
> Yes, you are right.
> 
> Thanks.