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, 14 Nov 2011 17:36:45 +0100 From: Eric Dumazet <eric.dumazet@...il.com> To: David Laight <David.Laight@...LAB.COM> Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org, Ben Hutchings <bhutchings@...arflare.com>, Tom Herbert <therbert@...gle.com>, Jamal Hadi Salim <hadi@...atatu.com>, Stephen Hemminger <shemminger@...tta.com>, Thomas Graf <tgraf@...radead.org>, Herbert Xu <herbert@...dor.apana.org.au>, Jeff Kirsher <jeffrey.t.kirsher@...el.com>, pstaszewski@...are.pl, eilong@...adcom.com Subject: RE: [PATCH net-next 2/2] bnx2x: uses build_skb() in receive path Le lundi 14 novembre 2011 à 16:21 +0000, David Laight a écrit : > > bnx2x uses following formula to compute its rx_buf_sz : > > > > dev->mtu + 2*L1_CACHE_BYTES + 14 + 8 + 8 + 2 > > > > Then core network adds NET_SKB_PAD and SKB_DATA_ALIGN(sizeof(struct > > skb_shared_info)) > > > > Final allocated size for skb head on x86_64 (L1_CACHE_BYTES = 64, > > MTU=1500) : 2112 bytes : SLUB/SLAB round this to 4096 bytes. > > > > Since skb truesize is then bigger than SK_MEM_QUANTUM, we have lot of > > false sharing because of mem_reclaim in UDP stack. > > > > One possible way to half truesize is to reduce the need by 64 bytes > > (2112 -> 2048 bytes) > > Would seem to be worth trying to reduce the size for systems > where the L1 caches lines are 128 bytes - I think that includes > some of the large ppc systems. > > If the alignment of the malloced memory can't be assumed/forced > maybe one of the sub-structures could be dynamically placed > before the data buffer? > What do you call sub-structure ? Assuming you speak of skb_shared_info, moving at the start wont change overall head size. large ppc systems have 64Kb pages and SK_MEM_QUANTUM=64Kb, so it's less a problem. One other way would be to have a shinfo->nr_max_frags field, to reduce max number of fragments, instead of assumin MAX_SKB_FRAGS, for 'legacy' drivers. -- 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