[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1325853226.2999.19.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date: Fri, 06 Jan 2012 13:33:46 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Ian Campbell <Ian.Campbell@...rix.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH 2/6] net: pad skb data and shinfo as a whole rather than
individually
Le vendredi 06 janvier 2012 à 11:20 +0000, Ian Campbell a écrit :
> It doesn't fit in a single cache line today.
It really does, thanks to your (net: pack skb_shared_info more
efficiently) previous patch.
I dont understand your numbers, very hard to read.
Current net-next :
offsetof(struct skb_shared_info, nr_frags)=0x0
offsetof(struct skb_shared_info, frags[1])=0x40 (0x30 on 32bit arches)
So _all_ fields, including one frag, are included in a single cache line
on most machines (64-bytes cache line), IF struct skb_shared_info is
aligned.
Your patch obviously breaks this on 64bit arches, unless you make sure
sizeof(struct skb_shared_info) is a multiple of cache line.
[BTW, it is incidentaly the case after your 1/6 patch]
fields reordering is not going to change anything on this.
Or maybe I misread your patch ?
At least you claimed in Changelog :
<quote>
Reducing this overhead means that sometimes the tail end of
the data can end up in the same cache line as the beginning of the shinfo but
in many cases the allocation slop means that there is no overlap.
</quote>
--
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