On Mon, Sep 19, 2016 at 09:59:50PM +0200, Paolo Bonzini wrote:
> On 19/09/2016 21:14, Michael S. Tsirkin wrote:
> > > But I prefer all these tricks to be hidden within the driver.  It seems
> > > a good idea in the beginning to rig the device to second-guess what a
> > > driver could do, but then it makes things awkward.  (This is also why
> > > I'd rather get rid of VRING_DESC_F_NEXT).
> > 
> > Right, I'll CC dpdk list on this proposal. As dpdk uses _NEXT almost
> > exclusively I'd like to make sure we are not messing things up.
> > 
> > Maybe the right thing to do is to disallow _NEXT if _INDIRECT is
> > negotiated. Each device can then decide whether it wants to
> > use _INDIRECT or _NEXT (or both). How's that?
> Still a bit of feature creep if we can avoid it, but at least it lets
> you write two fast loops to parse the descriptors.  So that's already a
> huge improvement.
> Negotiating _INDIRECT would still allow a single direct buffer.
> Just one thing: in the  _NEXT case, does the driver write only one
> available descriptor for the head (effectively ignoring desc.index on
> all descriptors but the first)?  Or does it have to write all the
> descriptors?

It would be cleaner to write them all out. But maybe it works without,
somehow. This will need some thought.

>  If the latter, _INDIRECT would almost surely end up faster.
> Paolo

It does add overhead for sure, but OTOH it makes reuse by driver simpler.
I'll look into testing this.


To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org

Reply via email to