Date: Wed, 20 Sep 2000 03:14:10 +0200
From: "Andi Kleen" <ak@suse.de>
The ipid handling is still fishy, it will break when you talk to
more destinations than the inetpeer cache can take (I fixed it in
my local tree with the appended patch)
I don't like this change, please work with Alexey on this one.
Do not assume we are removing the inetpeer cache also, see below.
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.
What is the problem? Are you referering to the LAPB/X25 stuff?
The TCP connect running out of ports problem is still there (I
fixed it locally, but the changes are probably far too extensive
for 2.4.x now)
I think people can change their ip_local_port_range and I really
consider this a non-issue, at least, it's not a 2.4.x show stopper.
The TCP ISN computation is not SMP safe.
"Big deal". So how much effort will you go to to get how much more
protection and how much of it do we really need? How less secure are
our TCP ISN's because of this? Not a show-stopper.
I think you're reading too much tcp-impl :-)
include/linux/snmp.h is probably still not properly aligned for all
cache line sizes.
Read, and reread what Alexey tries to tell you over and over about
this. It is not meant to be cache line aligned, it is meant to be a
power of two and nothing more.
Not a bug.
UDP recvmsg error handling for csum errors is bogus (fix pending)
Ok, send me a patch so I can see what the problem is.
I also would like to remove the inetpeer cache code before 2.4.0, now
that nobody managed to salvage tw recycling and ipid can do without it.
I would prefer not to, it seems to be too potentially destabilizing
for questionable and unknown gain (ie. we don't know if tw recycling
can be salvaged, so lets not take any changes).
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/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:22 EST