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
| ||
|
Date: Tue, 09 Oct 2012 23:02:07 +0200 From: Eric Dumazet <eric.dumazet@...il.com> To: Jesse Brandeburg <jesse.brandeburg@...el.com> Cc: Frank Reppin <frank@...ermydesk.org>, netdev@...r.kernel.org, Jeff Kirsher <jeffrey.t.kirsher@...el.com>, e1000-devel@...ts.sourceforge.net Subject: Re: [PATCH net] e1000e: Change wthresh to 1 to avoid possible Tx stalls. On Tue, 2012-10-09 at 10:36 -0700, Jesse Brandeburg wrote: > > > > Jesse did not share any performance numbers with me, I am sure he can > > > > give some background tomorrow when he is back online. > > > > > > > > I am working on an alternative patch now and should have something to > > > > share tomorrow. > > > Please allow me to ask if there's any progess here? > > > > > > I've tried 3.5.4 a couple of days ago on a SuperMicro X8SIE-LN4 (82574L) > > > and could still observe severe latency (up to 3000ms) spikes. > > > > > > Applying Hiroakis suggested patch did fix this for me as well. > > > [please note as well that I didn't had this issue in any 3.4.x kernel > > > before - so +1 for fixing the regression] > > I'm not sure what went wrong internally here that this hasn't been > fixed, and I'm personally embarrassed. I am working on it until I have > a patch/solution. > > currently am trying to reproduce the issue, am in some weird how to > use BQL limbo, the lack of documentation on user usage of BQL is slowing > me down. > BQL is blocking qdisc from delivering additional packet to TX as long as previous packets were not completed. Not sure what you want to know about BQL. > Hints or clues (I'm trying to follow the repro steps mentioned in > some related threads) are appreciated. Problem is BQL depends on TX completion being done in a reasonable time. It seems e1000e can hold an skb in TX ring for up to 3000ms (not reasonable it seems) Aggregation / coalescing is fine, as long as we dont hold a packet too long, in case no other packet follows. -- 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
Powered by blists - more mailing lists