On Fri, Feb 22, 2013 at 10:32:46AM +1030, Rusty Russell wrote: > "Michael S. Tsirkin" <m...@redhat.com> writes: > > On Tue, Feb 19, 2013 at 06:26:26PM +1030, Rusty Russell wrote: > >> These are specialized versions of virtqueue_add_buf(), which cover > >> over 50% of cases and are far clearer. > >> > >> In particular, the scatterlists passed to these functions don't have > >> to be clean (ie. we ignore end markers). > >> > >> FIXME: I'm not sure about the unclean sglist bit. I had a more > >> ambitious one which conditionally ignored end markers in the iterator, > >> but it was ugly and I suspect this is just as fast. Maybe we should > >> just fix all the drivers? > >> > >> Signed-off-by: Rusty Russell <ru...@rustcorp.com.au> > > > > Looking at code, it seems that most users really have a single sg, in > > low memory. So how about simply passing void * instead of sg? Whoever > > has multiple sgs can use the rich interface. > > Good point, let's do that: > 1) Make virtqueue_add_outbuf()/inbuf() take a void * and len. > 2) Transfer users across to use that. > 3) Make everyone else use clean scatterlists with virtqueue_add_sgs[]. > 4) Remove virtqueue_add_bufs(). > > > Long term we might optimize this unrolling some loops, I think > > I saw this giving a small performance gain for -net. > > I *think* we could make virtqueue_add() an inline and implement an > virtqueue_add_outsg() wrapper and gcc will eliminate the loops for us. > But not sure it's worth the text bloat... > > Cheers, > Rusty.
inline is mostly useless nowdays... We can make it a static function and let gcc decide. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
