[Top] [All Lists]

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

To: Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>
Subject: Re: [PATCH, untested] Support for PPPOE on SMP
From: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Wed, 25 Jun 2003 09:15:31 -0700
Cc: rusty@xxxxxxxxxxxxxxx, davem@xxxxxxxxxx, paulus@xxxxxxxxx, netdev@xxxxxxxxxxx, fcusack@xxxxxxxxx, dfs@xxxxxxxxxxxxxxxxxx, carlson@xxxxxxxxxxxxxxx
In-reply-to: <>
Organization: Open Source Development Lab
References: <> <>
Sender: netdev-bounce@xxxxxxxxxxx
On 25 Jun 2003 09:21:02 -0400
Michal Ostrowski <mostrows@xxxxxxxxxxxxxx> wrote:

> First some background for those new to this discussion (I was going post
> the original discussion that strted this to this list, but the summary
> here should get everyone up to speed).
> A user has observed a race condition where the last packet of PPPoE
> discovery arrives just before the first payload packet.  The discovery
> packet carries the session id and pppd needs to take this session id and
> create a PPPoE socket which will then pick up all packets matching the
> given session id.  The race is between the arrival of the first payload
> packet and  pppd's creation of the socket that is to receive PPPoE
> payload.  If the packet wins the race, the payload packet is lost.  This
> problem was noticed only because the ISP in this case configured their
> systems to use a longer, non-standard (but legal) retransmit timeout
> thus causing noticeable delays in PPP negotiation.

Also, you only need the ordering dependency till the session is setup, not
after it is established.  Imagine a large ISP with many PPPoE sessions; it
makes no sense to serialize traffic just for this session establishment case.

In the long run, the right answer probably is to push the session management
out of the daemon and into the kernel.  Today the PPPoE code in the kernel
is only half-brained, it needs pppd to survive.

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