[Top] [All Lists]

Re: RFC: PPP over X

To: Mitchell Blank Jr <mitch@xxxxxxxxxx>
Subject: Re: RFC: PPP over X
From: jamal <hadi@xxxxxxxxxx>
Date: Sun, 6 Feb 2000 12:05:37 -0500 (EST)
Cc: netdev@xxxxxxxxxxx, axboe@xxxxxxx, Mark Spencer <markster@xxxxxxxxx>, Andi Kleen <ak@xxxxxxx>, Marc Boucher <marc@xxxxxxx>, paulus@xxxxxxxxxxxxx, Michal Ostrowski <mostrows@xxxxxxxxxxxxxxxxx>, Ben LaHaise <bcrl@xxxxxxxxxx>
In-reply-to: <>
Sender: owner-netdev@xxxxxxxxxxx

On Fri, 4 Feb 2000, Mitchell Blank Jr wrote:

> jamal wrote:
> Ok, it wasn't clear to me what was being proposed for 2.3.
> > Nobody is arguing about that. In 2.2 it is out of question. tty
> > is the only answer.
> Why?  Instead of going through the effort of individually converting
> all the PPPoX modules to use tty, why not just backport the
> channels stuff?  Or maybe implement the kernel-land channel API
> on top of ttys? (ick!)

Backporting sounds like a huge pain to me. And would this be a separate
patch or part of the kernel proper? 2.2 is considered to be a stable

> Maybe I'm not familiar with netfilter enough, but isn't it just
> a rules-based engine for matching packets?  So if I had, say, 500
> PPPoE sessions going we'd have a painful O(n) search through the
> rules list trying to match the right one.

I am not sure about the exact details of the implementation, but O(n)
or not -- this is another way it could be done. It is not very smart, but
it is an alternative; thats the point i was trying to make.
(BTW, I think this is the way the BSDs did it ;-> )

> > mitch >> We are all curently in violent agreement that discovery should be
> > mitch > in
> > mitch >> user space (includes Michal).
> > So why dont you move OSPF to the kernel? It has its own addressing,
> Does it?  If it does then I've _never_ seen multiple OSPF sessions
> coexisting on the same physical network (and I doubt that gated even
> would support such a thing).  OSPF is just a multicast IP protocol,
> so it makes sense to use generic IP sockets. 

TCP is another IP protocol; so is OSPF. And sure OSPF can have unicast
addressing -- Point to point circuits use unicast; look at the specs,
and maybe look again at gated.
Even if it was just multicast alone, you could create a sockaddr struct
and put OSPF in the kernel.
I think that signalling/discovery protocols tend to be very rich and
sometimes dynamically changing; they dont affect the fast path of the data
flow therefore they dont need to be in the kernel -- they'll bloat it for
no good reason. TCP is the most used protocol. When you have that many
people using the protocol, it is fair to move it down. Mass use however,
by itself is not a good reason either. Moving a protocol to kernel
sometimes could have its consequences (look at the khttp dicussions in l-k
archives). You have to weigh a lot of options before making such a choice.


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