OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] packed ring layout proposal


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]