[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57166E17.6030002@solarflare.com>
Date: Tue, 19 Apr 2016 18:42:47 +0100
From: Edward Cree <ecree@...arflare.com>
To: Eric Dumazet <eric.dumazet@...il.com>
CC: <netdev@...r.kernel.org>, David Miller <davem@...emloft.net>,
"Jesper Dangaard Brouer" <brouer@...hat.com>,
<linux-net-drivers@...arflare.com>
Subject: Re: [RFC PATCH net-next 2/8] sfc: batch up RX delivery on EF10
On 19/04/16 18:20, Eric Dumazet wrote:
> It seems all the discussions about fast kernel networking these days is
> adding yet another queues, code duplication and complexity, batches, and
> add latencies, on top of a single NIC RX queue.
>
> Apparently the multiqueue nature of a NIC is obsolete and people want to
> process 10+Mpps on a single queue.
The real goal here is to speed up packet processing generally.
Doing everything on a single queue (and thus a single CPU) is just a
convenient way of measuring that, while making sure performance is limited
by the RX side rather than the TX not being able to generate enough packets
to keep us busy. Similarly, measuring single-byte UDP packet rate with one
CPU running flat-out is easier than measuring CPU usage while receiving
line-rate TCP in 1400-byte chunks.
> We could probably get ~100% improvement in UDP if we really cared, just
> by changing net/ipv[46]/udp.c, not changing other layers.
Well, I don't know how to achieve that, but it sounds like you do, so why
not go ahead and show us ;)
If you submitted a patch series to make UDP twice as fast, I think people
would "really care" about an improvement of that magnitude.
But RX batching should speed up all traffic, not just UDP. Or at least,
that's the theory.
-Ed
Powered by blists - more mailing lists