Messages in this thread |  | | Date | Tue, 19 Sep 2000 20:56:57 -0700 | From | "David S. Miller" <> | Subject | Re: networking todo, was Re: Linux-2.4.0-test9-pre2 |
| |
Date: Wed, 20 Sep 2000 04:38:24 +0200 From: "Andi Kleen" <ak@suse.de>
We must be talking about different things. It of course detects it on ACK input, but only for data it did send itself. Every TCP detects reordering automatically on the input with the sequence number check, but all we still do is to send an ACK immediately and go into quickack mode.
Or did I miss something ?
...
[I talked a lot with Andrea about this during OLS, and we couldn't figure out a good way]
Nevermind, I've apparently got my directions reversed. :-) I'll think about this a bit.
Just use __cacheline_aligned instead, like I did with the ip_local_data in the patch you just rejected. There is still the problem that generic SMP x86 kernels use a 32byte cacheline. Not a problem currently because the only x86 SMP is pII/pIII which has 32byte, but with Williamette/Athlon SMP it'll be a problem because these have 64byte and 128byte cache lines. With __cacheline_aligned it'll be easy though to pick up such changes.
Ok, feel free to send me a patch which does only this. I may doctor it up a bit, be warned :-)
On the other hand, the inetpeer code is only really exercised on machines that talk to lots and lots of destinations (=real servers), and 2.4 testing on such machines still has to begin.
Given that 2.4 testing has not really begun yet I would guess that it is safer to remove it now @)
True, but the following is what I'm really thinking about. Suppose a few weeks from now Alexey greets both of our mailboxes with a fabulous solution to the tw recycle masqeurading problem, wouldn't it be quite a pain in the ass to put back in and retest all the inetpeer code?
Let's sit on this until Alexey gives a forecast about the possibilities of a solution in the near future ok?
Later, David S. Miller davem@redhat.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |