From: Benjamin LaHaise <bcrl@kvack.org>
To: James Chapman <jchapman@katalix.com>
Cc: "David S. Miller" <davem@davemloft.net>,
netdev@oss.sgi.com, kleptog@svana.org,
mostrows@styx.uwaterloo.ca
Subject: Re: PPP-over-L2TP kernel support, new patch for review
Date: Tue, 21 Sep 2004 17:04:27 -0400 [thread overview]
Message-ID: <20040921210427.GB19575@kvack.org> (raw)
In-Reply-To: <1095760525.414ffa8d111a1@www.katalix.com>
On Tue, Sep 21, 2004 at 10:55:25AM +0100, James Chapman wrote:
> Unfortunately I haven't seen Ben's code yet either so I can't give a
> direct comparison. Ben? I did have a look at the Babylon stuff
> (1.6-pre3), although I've no idea how much of it Ben has
> changed. Here's a summary, fyi.
>
> Babylon:-
>
> - Architecture seems to be using char devices for communication with
> the kernel and all the PPP datapath is handled by custom virtual
> net_devices; the generic PPP kernel code isn't used as far as I can
> tell. Unfortunately it is very old (linux-2.0 era I think) but Ben
> has probably updated it.
I've updated it. The current build is at http://www.kvack.org/~bcrl/babylon/
and is 1.6-pre3-bcrl8. The L2TP support is approaching beta, with the only
real todo items being proper retransmit with congestion control, plus the
kernel side of multihop support, and some locking fixes for smp and preempt.
Plus the api needs to be made into something more paletable (it abuses
a mix of ioctl, bind & connect to create l2tp sessions). No flames please,
but patches that keep the scaling characteristics and make the interface
more paletable gladly accepted.
> - Some form of L2TP support is there but it is very basic. Userspace
> sends data through char devices (read()/write() which the kernel
> char driver converts to skbs and passes on. Nasty.
That old code was completely tossed.
> - PPP stack supports multiple PPP sessions in one daemon (unlike pppd).
>
> - Unlikely to integrate with the new native IPSEC stuff.
L2TP over IPSEC? Are you insane? You'd not be able to terminate more than
a couple of dozen connections over it. =-)
> I think for general Linux L2TP support, a socket architecture makes
> more sense. But maybe I'm biased... :)
The current babylon code is using sockets. The l2tp sockets passes all
packets for a given tunnel through a single file descriptor. This seems
like the best tradeoff for being able to scale to decent numbers of
sessions.
-ben
--
"Time is what keeps everything from happening all at once." -- John Wheeler
next prev parent reply other threads:[~2004-09-21 21:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-20 21:11 PPP-over-L2TP kernel support, new patch for review James Chapman
2004-09-20 21:17 ` David S. Miller
2004-09-21 9:55 ` James Chapman
2004-09-21 21:04 ` Benjamin LaHaise [this message]
2004-09-21 23:07 ` Herbert Xu
2004-09-22 0:00 ` Michael Richardson
2004-09-22 1:14 ` Benjamin LaHaise
2004-09-22 2:42 ` David S. Miller
2004-09-22 3:03 ` jamal
2004-09-22 9:58 ` James Chapman
2004-09-22 10:53 ` Herbert Xu
2004-09-22 21:28 ` James Chapman
2004-09-22 22:05 ` Herbert Xu
2004-09-23 18:34 ` Martijn van Oosterhout
2004-09-21 21:11 ` Benjamin LaHaise
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=20040921210427.GB19575@kvack.org \
--to=bcrl@kvack.org \
--cc=davem@davemloft.net \
--cc=jchapman@katalix.com \
--cc=kleptog@svana.org \
--cc=mostrows@styx.uwaterloo.ca \
--cc=netdev@oss.sgi.com \
/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).