Messages in this thread |  | | Date | Wed, 20 Sep 2000 15:29:39 +0200 | From | Andrea Arcangeli <> | Subject | Re: networking todo, was Re: Linux-2.4.0-test9-pre2 |
| |
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/
|  |