netdev - Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e

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]

Date:	Thu, 24 May 2012 23:01:07 -0700
From:	Tom Herbert <therbert@...gle.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Denys Fedoryshchenko <denys@...p.net.lb>, netdev@...r.kernel.org
Subject: Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86)
 and e1000e

I think there is a potential problem in that netdev_tx_completed could
be called multiple times for the same interrupt, for example if napi
poll routine completes it's budget and is scheduled again and some new
packets are completed.  We're looking at a solution to this.

Denys, can you try to increase the netdev budget to see if that has an effect?

Thanks,
Tom

On Tue, May 22, 2012 at 10:24 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Tue, 2012-05-22 at 20:11 +0300, Denys Fedoryshchenko wrote:
>
>> By the way, if BQL limit is going lower than MTU, is it considered as a
>> bug?
>> If yes, i can try to upload 3.4 to some servers and add condition to
>> WARN_ON if limit < 1500.
>
> There is no problem with BQL limit going lower than the max packet size.
>
> (With TSO it can be 64K)
>
> Remember BQL allows one packet to be sent to device, regardless of its
> size.
>
> Next packet might be blocked/stay in Qdisc
>
> If your workload is mostly idle, but sending bursts of 3 packets, then
> only one is immediately sent.
>
> Next packets shall wait the TX completion of first packet.
>
>
>
--
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