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: Thu, 26 Apr 2012 10:10:54 +0200 From: Eric Dumazet <eric.dumazet@...il.com> To: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi> Cc: David Miller <davem@...emloft.net>, rick.jones2@...com, Netdev <netdev@...r.kernel.org>, therbert@...gle.com, ncardwell@...gle.com, maze@...gle.com, Yuchung Cheng <ycheng@...gle.com> Subject: [RFC] allow skb->head to point/alias to first skb frag On Tue, 2012-04-24 at 10:56 +0200, Eric Dumazet wrote: > Really I have many doubts about GRO today. Particularly if a NIC driver provides linear skbs : Resulting gro skb is a list of skbs, no memory savings, and many cache line misses when copying to userland. Maybe we could have a new kind of skb head allocation/setup, pointing to a frag of 2048 bytes instead of a kmalloc() blob. Right now, a fragged skb used 3 blocks of memory : 1) struct sk_buff 2) a bloc of 512 or 1024 or 2048 bytes of memory (skb->head) 3) a frag of 2048 (or PAGE_SIZE/2 or PAGE_SIZE) While a linear skb has : 1) struct sk_buff 2) a bloc of 512 or 1024 or 2048 bytes of memory (skb->head) from kmalloc() Idea would have : 1) struct sk_buff 2) skb->head points to frag (aliasing, no memory allocation) 3) frag of 2048 (or PAGE_SIZE/2 or PAGE_SIZE) Or the reverse (no frag so that skb is considered as linea), but special code to 'allow' this skb head be considered as a frag when needed (splice() code, or GRO merge, or TCP coalescing) That would make GRO (and TCP coalescing) much more efficient, since the resulting aggregated skb would be : 1) struct sk_buff 2) skb->head points to 1st frag (aliasing, no memory allocation) 3) array of [1..16] frags -- 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