netdev - Re: Drops in qdisc on ifb interface

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: <5567382E.4010706@gmail.com>
Date:	Thu, 28 May 2015 08:45:50 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	"jsullivan@...nsourcedevel.com" <jsullivan@...nsourcedevel.com>
CC:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: Drops in qdisc on ifb interface

On 05/28/2015 08:30 AM, jsullivan@...nsourcedevel.com wrote:
>
>> On May 28, 2015 at 11:14 AM Eric Dumazet <eric.dumazet@...il.com> wrote:
>>
>>
>> On Thu, 2015-05-28 at 10:38 -0400, jsullivan@...nsourcedevel.com wrote:
>>
> <snip>
>> IFB has still a long way before being efficient.
>>
>> In the mean time, you could play with following patch, and
>> setup /sys/class/net/eth0/gro_timeout to 20000
>>
>> This way, the GRO aggregation will work even at 1Gbps, and your IFB will
>> get big GRO packets instead of single MSS segments.
>>
>> Both IFB but also IP/TCP stack will have less work to do,
>> and receiver will send fewer ACK packets as well.
>>
>> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
>> b/drivers/net/ethernet/intel/igb/igb_main.c
>> index
>> f287186192bb655ba2dc1a205fb251351d593e98..c37f6657c047d3eb9bd72b647572edd53b1881ac
>> 100644
>> --- a/drivers/net/ethernet/intel/igb/igb_main.c
>> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
>> @@ -151,7 +151,7 @@ static void igb_setup_dca(struct igb_adapter *);
>> #endif /* CONFIG_IGB_DCA */
> <snip>
>
> Interesting but this is destined to become a critical production system for a
> high profile, internationally recognized product so I am hesitant to patch.  I
> doubt I can convince my company to do it but is improving IFB the sort of
> development effort that could be sponsored and then executed in a moderately
> short period of time? Thanks - John
> --

If your experimenting one thing you could do is create many
ifb devices and load balance across them from tc. I'm not
sure if this would be practical in your setup or not but might
be worth trying.

One thing I've been debating adding is the ability to match
on current cpu_id in tc which would allow you to load balance by
cpu. I could send you a patch if you wanted to test it. I would
expect this to help somewhat with 'single queue' issue but sorry
haven't had time yet to test it out myself.

.John

-- 
John Fastabend         Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html