[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6D8AEC2@saturn3.aculab.com>
Date: Mon, 14 Nov 2011 16:21:27 -0000
From: "David Laight" <David.Laight@...LAB.COM>
To: "Eric Dumazet" <eric.dumazet@...il.com>,
"David Miller" <davem@...emloft.net>
Cc: <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
> 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?
David
--
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