netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@osdl.org>
To: Jamal Hadi <hadi@shell.cyberus.ca>
Cc: mostrows@watson.ibm.com, rusty@rustcorp.com.au, davem@redhat.com,
	paulus@samba.org, netdev@oss.sgi.com, fcusack@samba.org,
	dfs@roaringpenguin.com, carlson@workingcode.com
Subject: Re: [PATCH, untested] Support for PPPOE on SMP
Date: Wed, 25 Jun 2003 10:40:01 -0700	[thread overview]
Message-ID: <20030625104001.476ee314.shemminger@osdl.org> (raw)
In-Reply-To: <20030625125518.N84526@shell.cyberus.ca>

On Wed, 25 Jun 2003 13:07:46 -0400 (EDT)
Jamal Hadi <hadi@shell.cyberus.ca> wrote:

> 
> 
> On Wed, 25 Jun 2003, Stephen Hemminger wrote:
> 
> > On Wed, 25 Jun 2003 12:22:35 -0400 (EDT)
> > Jamal Hadi <hadi@shell.cyberus.ca> wrote:
> >
> > > Placing control protocols in the kernel is plain wrong.
> >
> > What about arp, TCP, IP, routing protocols.
> 
> ARP should really be ripped off the kernel. I mentioned to you once
> the same in regards to STP and iirc you agreed.
> I  wouldnt call TCP or IP control protocols.
> 
> >The problem is that state management needs to be done in one place.
> 
> a protocol or implementation which wishes to do state maintanance
> properly oughta be able to do the synchronization on its own.
> Separation between policy and mechanism has been the strength of unix.
> A clean separation between control and a data path is very important.
> Control protocols tend to be very rich environments which are
> constantly changing. Take STP, there are so many features that could be
> added to STP that are much harder to add because it is in the kernel.

Rather than take an architectural approach about what is right and wrong,
I take the practical point of view.  If the protocol is small, and the 
policy can be done in the kernel fine; if the implementation gets messy
and the right information is not there, then it belongs in user space.

For PPPoE, the session management needs to be in kernel space, with the policy
in user space.  What if the kernel, initialized the session when it saw
the discovery and notified the pppd,  session would not be established
until ppd accepted the connection.  This would be more like a socket
protocol without auto-accept like TCP. Any data for the session would
then stay queued until it was accepted or rejected.

Having special non-SMP receive logic is bogus; and probably won't work
anyway with preempt and other races.

There is already work in moving STP out of the kernel, but even that
has shown that the problem is how to have the proper management hooks
to do the job. That is why it hasn't been a simple slam dunk.

  reply	other threads:[~2003-06-25 17:40 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-25  7:24 [PATCH, untested] Support for PPPOE on SMP Rusty Russell
2003-06-25 11:19 ` Jamal Hadi
2003-06-25 13:21 ` Michal Ostrowski
2003-06-25 13:42   ` Michal Ostrowski
2003-06-25 15:45     ` Jamal Hadi
2003-06-25 17:27       ` Michal Ostrowski
2003-06-25 22:17         ` Paul Mackerras
2003-06-25 22:56           ` Michal Ostrowski
2003-06-25 16:15   ` Stephen Hemminger
2003-06-25 16:22     ` Jamal Hadi
2003-06-25 16:39       ` Stephen Hemminger
2003-06-25 17:07         ` Jamal Hadi
2003-06-25 17:40           ` Stephen Hemminger [this message]
2003-06-25 18:00             ` Michal Ostrowski
2003-06-25 22:22           ` Paul Mackerras
2003-06-25 22:53             ` Ben Greear
2003-06-25 21:33   ` David S. Miller
2003-06-25 22:06     ` Michal Ostrowski
2003-06-26  1:04       ` David S. Miller
2003-06-26  3:57     ` Rusty Russell
2003-06-26  3:59       ` David S. Miller
2003-06-26  8:17         ` Rusty Russell
2003-06-26  8:55           ` David S. Miller
2003-06-26 10:47             ` James Carlson
2003-06-26 10:51         ` James Carlson
2003-06-26 23:18           ` Jamal Hadi
2003-06-27 11:39             ` James Carlson
2003-06-27 12:12               ` Paul Mackerras
2003-06-27 13:19                 ` James Carlson
2003-06-27 14:59                 ` Stephen Hemminger
2003-06-27 15:27                   ` James Carlson
2003-06-28  2:21               ` Jamal Hadi
2003-06-28 22:51                 ` Frank Cusack
2003-06-26 11:37       ` Michal Ostrowski
2003-06-25 16:01 ` Jason Lunz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030625104001.476ee314.shemminger@osdl.org \
    --to=shemminger@osdl.org \
    --cc=carlson@workingcode.com \
    --cc=davem@redhat.com \
    --cc=dfs@roaringpenguin.com \
    --cc=fcusack@samba.org \
    --cc=hadi@shell.cyberus.ca \
    --cc=mostrows@watson.ibm.com \
    --cc=netdev@oss.sgi.com \
    --cc=paulus@samba.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).