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

[Michal Ostrowski <mostrows@watson.ibm.com>]

Paul:  you made an assertion to me in an eariler e-mail that you were
concerned about packet ordering for the sake of vj and compression. 
IIRC the PPPoE spec prohibits compression, probably for this very
reason. Is there any other reason we'd be worried about re-ordering in
the PPP data stream?

On Wed, 2003-06-25 at 11:45, Jamal Hadi wrote:
> 
> Have you tested the case where the ethernet card is tied to only
> CPU in SMP? That guarantees ordering.

Agreed, this does guarantee ordering.  But there are cases where I don't
have this guarantee and those are the issues Rusty's patch attempts to
solve.

> Ordering per protocol should really be that protocols problem to
> solve. If you cant solve it you have a bug.
> 

The session initiation race I described earlier is brought about
independently by several problems:

1.  PPPoE negotiation is done in user space and thus there is a window
    between completion of this negotiation and the creation of the PPPoE
    socket during which a payload packet may arrive and be dropped (SMP
    and UP).

2.  Re-ordering by softIRQ handling on SMP may cause same problem.

There's also the question as to whether or not there are other protocols
(perhaps not implemented in the kernel, but relying on AF_PACKET) may be
affected by this (#2).

We can fix #1 without any patches to core networking code.  If the SMP
softIRQ re-ordering issues is handled, then we may have some better
options for fixing #1.  But note that even if #1 is fixed and #2 isn't,
then we're not any better off. 

-- 
Michal Ostrowski <mostrows@watson.ibm.com>