Thread (17 messages) flat view 17 messages, 5 authors, 2016-01-07

Re: [BUG] skb corruption and kernel panic at forwarding with fragmentation

From: Eric Dumazet <edumazet@google.com>
Date: 2016-01-07 19:47:10
Also in: lkml

On Thu, Jan 7, 2016 at 2:35 PM, Konstantin Khlebnikov [off-list ref] wrote:
On Thu, Jan 7, 2016 at 3:54 PM, Eric Dumazet [off-list ref] wrote:
 want to look at git history to find out why it is done this way.
quoted
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.
Then IP forwarding might be slower.

Look, each layer (TCP  , IP, ....) can organize its skb->cb[] as it wants.
Nobody tries to 'make universal room' for IPCB, since only IP layer wants it.

TCP could even find a way in the future to no longer hold a copy of
IPCB in the input skb,
if code is reorganized a bit.

Note that skbs for output path in TCP do not need IPCB at all.

Only when skb leaves TCP and enter IP, skb->cb[] content is scratched.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help