netdev - Re: [PATCH] net: improve ipv4 performances

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFgPn1Dk+48J1CDNvzcG6jRx1ccWrecru=QJxvNr1qjoAU4MLg@mail.gmail.com>
Date:   Sun, 1 Apr 2018 20:51:52 -0400
From:   "Md. Islam" <mislam4@...t.edu>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     Anton Gary Ceph <agaceph@...il.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: improve ipv4 performances

Yes, I'm also seeing good performance improvement after adding
likely() and prefetch().

On Sun, Apr 1, 2018 at 2:50 PM, Stephen Hemminger
<stephen@...workplumber.org> wrote:
> On Sun,  1 Apr 2018 20:31:21 +0200
> Anton Gary Ceph <agaceph@...il.com> wrote:
>
>> As the Linux networking stack is growing, more and more protocols are
>> added, increasing the complexity of stack itself.
>> Modern processors, contrary to common belief, are very bad in branch
>> prediction, so it's our task to give hints to the compiler when possible.
>>
>> After a few profiling and analysis, turned out that the ethertype field
>> of the packets has the following distribution:
>>
>>     92.1% ETH_P_IP
>>      3.2% ETH_P_ARP
>>      2.7% ETH_P_8021Q
>>      1.4% ETH_P_PPP_SES
>>      0.6% don't know/no opinion
>>
>> From a projection on statistics collected by Google about IPv6 adoption[1],
>> IPv6 should peak at 25% usage at the beginning of 2030. Hence, we should
>> give proper hints to the compiler about the low IPv6 usage.
>>
>> Here is an iperf3 run before and after the patch:
>>
>> Before:
>> [ ID]  Interval           Transfer    Bandwidth       Retr
>> [  4]  0.00-100.00 sec    100 GBytes  8.60 Gbits/sec  0       sender
>> [  4]  0.00-100.00 sec    100 GBytes  8.60 Gbits/sec          receiver
>>
>> After
>> [ ID]  Interval           Transfer    Bandwidth       Retr
>> [  4]  0.00-100.00 sec    109 GBytes  9.35 Gbits/sec  0       sender
>> [  4]  0.00-100.00 sec    109 GBytes  9.35 Gbits/sec          receiver
>>
>> [1] https://www.google.com/intl/en/ipv6/statistics.html
>>
>> Signed-off-by: Anton Gary Ceph <agaceph@...il.com>
>
> I am surprised it makes that much of an impact.
>
> It would be easier to manage future bisection if the big patch
> was split into several pieces. Bridge,  bonding, netfilter, etc.
> There doesn't appear to be any direct cross dependencies.
>
>



-- 
Tamim
PhD Candidate,
Kent State University
http://web.cs.kent.edu/~mislam4/