|
From: | Vincenzo Maffione |
Subject: | Re: [Qemu-devel] [PATCH] net: QEMU_NET_PACKET_FLAG_MORE introduced |
Date: | Mon, 9 Dec 2013 14:25:46 +0100 |
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 ideaJust to check my understanding, we're talking about the following kind
> > (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.
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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |