On Thu, Jan 7, 2016 at 3:54 PM, Eric Dumazet [off-list ref] wrote:
On Thu, Jan 7, 2016 at 7:04 AM, Konstantin Khlebnikov [off-list ref] wrote:
quoted
On Thu, Jan 7, 2016 at 2:59 PM, Eric Dumazet [off-list ref] wrote:
quoted
On Thu, Jan 7, 2016 at 6:38 AM, Konstantin Khlebnikov [off-list ref] wrote:
quoted
Also I've found strange thing: reason of expanding skb->cb from 40 to
48 bypes in 2006
3e3850e989c5d2eb1aab6f0fd9257759f0f4cbc6 was that struct inet6_skb_parm does
not fit. But it's is only 24 bytes. Does some arches add pad after
each _u16 field?
"struct inet6_skb_parm" is part of struct tcp_skb_cb
This is why Patrick had to increase skb->cb[]
Whoa. Funny. TCP moves that chunk back and forward instead of just
putting it at the first place in struct.
You probably want to look at git history to find out why it is done this way.
TCP performance is critical for some of us, and doing such trick avoid
one cache miss per skb in some critical list traversals.
Right. This way tcp stuff perfectly fits into leftovers of first cache line.
Then probably it's better to put ipv4/ipv6 cb into second line from
the beginning.