Re: [Qemu-devel] [PATCH] net: QEMU_NET_PACKET_FLAG_MORE introduced

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Dec 09, 2013 at 01:42:30PM +0100, Stefan Hajnoczi wrote:
> On Mon, Dec 09, 2013 at 01:14:31PM +0200, Michael S. Tsirkin wrote:
> > On Mon, Dec 09, 2013 at 11:55:57AM +0100, Vincenzo Maffione wrote:
> > > If you don't think adding the new flag support for virtio-net is a good idea
> > > (though TAP performance is not affected in every case) we could also make it
> > > optional.
> > > 
> > > 
> > > Cheers
> > >   Vincenzo
> > > 
> > 
> > I think it's too early to say whether this patch is benefitial for
> > netmap, too.  It looks like something that trades off latency
> > for throughput, and this is a decision the endpoint (VM) should
> > make, not the network (host).
> > So you should measure with offloads on before you make conclusions about it.
> 
> Just to check my understanding, we're talking about the following kind
> of batching:
> 
>   int num_packets = peek_available_packets(device);
>   while (num_packets-- > 0) {
>       int flags = MORE;
>       if (num_packets == 0) {
>           flags = NONE;
>       }
>       qemu_net_send_packet(..., flags);
>   }
> 
> In other words, this only batches up a single burst of packets.  It
> doesn't introduce timers or blocking calls.

Yes.

> So the effect of batching should be relatively small on latency.  In
> fact, it's almost like sendmmsg(2)/recvmmsg(2) but using a
> one-packet-at-a-time interface.
> 
> Does this sound right?
> 
> Stefan

Why would it be small?  Consider a queue of 256 packets.
You are sending out a single short packet, followed
by a burst of 255 larger packets.
the single packet is not transmitted until qemu completes
processing 255 larger ones.

-- 
MST