On Wed, Sep 20, 2000 at 04:38:24AM +0200, Andi Kleen wrote:
> 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.
Agreed. I couldn't see how to "detect" the reordering in the receiver without
additional informations from the dev.c layer (I don't think it's possible to
detect it from the TCP layer without adding something like described by
Andi in the below section that looks not very nice because it would
hurt links with real packet loss).
> Or did I miss something ?
>
> The only way to do true reordering handling on the receiver I can think of
> would be to use something like the soft-timers to do very very fast delayed
> acks even for rcv_mss sized packets and hope that you collect packets from
> all CPUs in the delay, but overall it could still cost you a lot by
> disturbing the ACK clock
>
> [I talked a lot with Andrea about this during OLS, and we couldn't
> figure out a good way]
I couldn't figure out a good way to fix that internally to TCP, but I have a
quite simple solution at the dev.c layer (that would address also the problem
with the not smart protocols that needs to retransmit everything once an hole
in the sequence space is found).
The solution consists in a sequence number protected by the spinlock in the NIC
device driver (as DaveM suggested) and to increase this sequence number for
each packet received and to set the sequence number value of the moment in each
skb. Then we'd need a secondary (shared :( ) sequence numbers in the
net_rx_action layer that will tell us the sequence number of the last packet
that entered the higher level layer (IP in our case). With this per packet
sequence number information we'll know if we're generating reordering by
pushing the next packet in the softnet queue from net_rx_action to the IP
layer. In that case we should only set up a wake-up-me-later logic and giveup.
No idea how much this additional logic hurts. Certainly it could be enabled
per-device/per-protocol basis.
The other almost zero cost way to fix the reordering is of course to set the
irq affinity of each nic only to one CPU :)) (this applies to the less smart
protocol as well)
Andrea
-
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:23 EST