netdev
[Top] [All Lists]

Re: [PATCH, untested] Support for PPPOE on SMP

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: [PATCH, untested] Support for PPPOE on SMP
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Thu, 26 Jun 2003 13:57:09 +1000
Cc: paulus@xxxxxxxxx, netdev@xxxxxxxxxxx, fcusack@xxxxxxxxx, carlson@xxxxxxxxxxxxxxx
In-reply-to: Your message of "Wed, 25 Jun 2003 14:33:34 MST." <20030625.143334.85380461.davem@redhat.com>
Sender: netdev-bounce@xxxxxxxxxxx
In message <20030625.143334.85380461.davem@xxxxxxxxxx> you write:
> 
> Why don't you just queue the payload packets in a "resolution queue"
> until the socket is created?  Just make the resolution queue packets
> timeout using a value that will easily exceed any reasonable PPP
> negotiation time.

Sure, that works in this case, where you know when you get the packet
that it's out of order.  But I wanted to see how ugly it got to do it
generally: a protocol where you can't tell until later that things
were in the wrong order can't use this technique.  Paul tells me that
multilink PPP assumes this (moral: don't do multilink PPPoE).

Anyway, my patch is fundamentally flawed: you can't do
cpu_raise_softirq() on another CPU, it's racy (*bad* *bad* interface).

> All this ordered packet arrival shit is just beyond stupid.

I want to know how often this is happening (Michal?), because if
protocols need ordering and can't tell, it becomes effectively a
packet drop somewhere down in the protocol.  If it's 1 in a million,
OK.  If it's 1 in a thousand, that's bad.

Frankly, I'm amazed anyone sees reordering in real life...
Thanks,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

<Prev in Thread] Current Thread [Next in Thread>