[PATCH] Receive multiple packets at a time

[Dave Taht]

On Wed, Dec 2, 2015 at 2:48 PM, Samuel Thibault
<samuel.thibault at ens-lyon.org> wrote:
> Dave Taht, on Wed 02 Dec 2015 14:41:35 +0100, wrote:
>> I guess my meta point is driven by my headaches. Getting per packet
>> processing to scale up past 100Mbit is hard without offloads even on
>> embedded hardware considered "high end".
>
> In my tests I was getting 800Mbps with common laptop Gb ethernet
> devices.

yep. what you are doing is a worthwhile improvement. But it isn't line
rate, even on a modern laptop...

I also try to get people measuring latency and bidirectional
throughput also - give the flent tool a shot- it has a great gui,
gives you all sorts of nice graphs and lets you create a variety of
useful workloads.

https://flent.org/

The best part for me is the ability to make a change in something, run
a test or string of tests, and plot the results in comparison with the
prior changes.

the rrul test is about the most common one used these days, although
things like tcp_upload_100 are good tests of small packets in one
direction or another.

example of rrul:

http://burntchrome.blogspot.se/2014/05/fixing-bufferbloat-on-comcasts-blast.html

Example of iterating over a set of changes to napi and BQL to get
better performance

http://snapon.cs.kau.se/~d/beagle_bql/beaglebonewithbql.png

*love flent*.

>
>> >> > At least for now we could commit the recvmmsg part?
>> >>
>> >> Not my call. It is a linux only thing, so far as I know.
>> >
>> > ATM yes.  I wouldn't be surprised that other OSes adopt it, though.
>>
>> Given how slow other OSes are evolving, I would not hold my breath,
>> and retain code paths that worked with them.
>
> Sure!
>
> Samuel