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, 16 Jun 2009 08:12:30 +0200 From: Eric Dumazet <eric.dumazet@...il.com> To: starlight@...nacle.cx CC: Eric Dumazet <eric.dumazet@...il.com>, linux-kernel@...r.kernel.org, Mel Gorman <mel@....ul.ie>, linux-mm@...ck.org, hugh.dickins@...cali.co.uk, Lee.Schermerhorn@...com, kosaki.motohiro@...fujitsu.com, ebmunson@...ibm.com, agl@...ibm.com, apw@...onical.com, wli@...ementarian.org, Linux Netdev List <netdev@...r.kernel.org> Subject: Re: QUESTION: can netdev_alloc_skb() errors be reduced by tuning? Please dont top post, we prefer other way around :) starlight@...nacle.cx a écrit : > Eric, > > Great thought--thank you. Running a similar server with > 82571/e1000e and it does not exhibit the problem. 'e1000e' has > default copybreak=256 while 'ixgbe' has no copybreak. Rational > given is > > http://osdir.com/ml/linux.drivers.e1000.devel/2008-01/msg00103.html > > But the comparion is a bit apples-and-oranges since the 'e1000e' > system is dual Opteron 2354 while the 'ixgbe' system is Xeon > E5430 (a painful choice thus far). Also 'e1000e' system passes > data via a PACKET socket while the 'ixgbe' system passes data > via UDP (a configurable option). > > I'm not fully up on how this all works: am I to understand that > the error could result from RX ring-queue buffers not freeing > quickly enough because they have a use-count held non-zero as > the packet travels the stack? Well, error is normal in stress situation, when no more kernel memory is available. cat /proc/net/udp can show you (in last column) sockets where packets where dropped by UDP stack if their receive queue was full. > > I've just doubled some SLAB tuneables that seem relevant, but > if the cause is the aforementioned, this won't help. Will > have the answer on the tweaks by the end of Tuesday. > > David copybreak in drivers themselves is nice because driver can recycle its rx skbs much faster, but that is suboptimal in forwarding (routers) workloads. Its also a lot of duplicated code in every driver. So we could do the skb trimming (ie : reallocating the data portion to exactly the size of packet) in core network stack, when we know packet must be handled by an application, and not dropped or forwarded by kernel. Because of slab rounding, this reallocation should be done only if resulting data portion is really smaller (50 %) than original skb. > > > > At 04:26 AM 6/16/2009 +0200, Eric Dumazet wrote: >> 152691992335/724246449 = 210 bytes per rx packet in average >> >> It could make sense to add copybreak feature in this driver to >> reduce memory needs, but that also would consume more cpu >> cycles, and slow down forwarding setups. >> >> Maybe this packet trimming could be done generically in UDP >> stack input path, before queueing packet into a receive queue, >> if amount of available memory is under a given threshold. > -- 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