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.
--
MST
