[lkml]   [2000]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: networking todo, was Re: Linux-2.4.0-test9-pre2
On Wed, Sep 20, 2000 at 03:29:39PM +0200, Andrea Arcangeli wrote:
> 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).

Assuming you have outgoing traffic on the NIC as well it isn't that bad,
because there will be likely some queueing delay for the ACK in which
you could in theory still cancel it of you know better (it would hurt the
abstraction between device drivers and dev.c a lot though)

> 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.

That would just break the whole idea behind softnet. When you're juggling
the cache line for the sequence counter you could as well juggle the
cache line with a shared queue head, e.g. we would be at 2.2 level again.

> 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)

That's the real solution long term, right.

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:39    [W:0.410 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site