[lkml]   [2000]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: networking todo, was Re: Linux-2.4.0-test9-pre2
   Date: Wed, 20 Sep 2000 03:51:37 +0200
From: "Andi Kleen" <>

> Receiver side SMP reordering is still there, but I'm not sure if it is
> fixable (but it'll surely hit people that cannot use Linux senders, I
> just see the reports)
> Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input
> rewrite was strictly about dealing with this. No SMP reordering
> should cause any bogus fast retransmits etc. for example.

You mean TCP output rewrite ? The fix was strictly sender side only
(I first thought one of the ack changes alexey did was an attempt at a
hackish receiver side solution, but he told me that was false)

> What is the problem? Are you referering to the LAPB/X25 stuff?

When you have a non linux 2.4 sender you lose.

Alexey's changes detect reordering on the input side, regardless of
whether it is speaking to a Linux senders or not, to avoid false

Please show me (and even more importantly Alexey) an example of where
receive reordering detection is dependant upon Linux TCP sender
behavior, his code it is as generic as I can imagine it to be. In
fact, his code got lots of the testing on a web server serving almost
exclusively clients running windows :-)

When I count correctly sizeof(udp_mib) is 16 bytes currently (lots of
false sharing on 32/64byte cacheline sized architectures) and linux_mib
is 288 bytes currently (does not make any sense at all)

Ok, linux_mib is obviously not exact but in that case I would argue
that the extra size needed (to get to the next a power of 2) would
outweight whatever instruction performance gain we'd get.

As for the udp etc. case, how do we pick a "number" to make these
arrays as you say they should be?

I would only make these changes for the snmp mibs which are "smaller"
than this "number" we pick, the larger ones won't see much false
sharing at all.

I think this is really a small and trite issue actually.

> UDP recvmsg error handling for csum errors is bogus (fix pending)
> Ok, send me a patch so I can see what the problem is.



The "unknown gain" is just removing a lot of complexity => speed
and less bugs.

Removing a lot of code also means undoing all the testing done so far
with that code present :-)))

The only advantage I know left is saving pmtus for a bit longer,
but I doubt it is worth the complexity.

Neither of us are experts in this area, Alexey is.

Do you have any specific plan for salvaging tw recycling ? Just
keeping such an intrusive piece of code for benchmarks around looks
wasteful to me.

Nope, but this also requires Alexey's input.

David S. Miller
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.265 / U:23.996 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site