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: Mon, 08 Oct 2012 11:21:19 -0700 From: Rick Jones <rick.jones2@...com> To: Eric Dumazet <eric.dumazet@...il.com> CC: Herbert Xu <herbert@...dor.apana.org.au>, David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>, Jesse Gross <jesse@...ira.com> Subject: Re: [RFC] GRO scalability On 10/08/2012 10:55 AM, Eric Dumazet wrote: > On Mon, 2012-10-08 at 10:49 -0700, Rick Jones wrote: > >> So, with my term shuffle better defined, let's circle back to your >> proposal to try to GRO-service a very much larger group of flows, with a >> "flush queued packets older than N packets" heuristic as part of the >> latency minimization. If N were 2 there - half the number of flows, the >> "perfect" shuffle" doesn't get aggregated at all right? N would have to >> be 4 or the number of concurrent flows. What I'm trying to get at is >> just to how many concurrent flows you are trying to get GRO to scale, >> and whether at that level you have asymptotically approached having a >> hash/retained state that is, basically, a duplicate of what is happening >> in TCP. >> > > I didnt said "flush queued packets older than N packets" but instead > suggested to use a time limit, eventually a sysctl. Did I then mis-interpret: > 2) Use a LRU list to eventually be able to 'flush' too old packets, > even if the napi never completes. Each time we process a new packet, > being a GRO candidate or not, we increment a napi->sequence, and we > flush the oldest packet in gro_lru_list if its own sequence is too > old. in your initial RFC email? Because I took that as flushing a given packet if N packets have come through since that packet was queued to await coalescing. rick -- 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