[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]