netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Chapman <jchapman@katalix.com>
To: Patrick McHardy <kaber@trash.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>, netdev@vger.kernel.org
Subject: Re: [RFC PATCH 0/8] l2tp: introduce L2TPv3 support
Date: Tue, 24 Feb 2009 09:55:05 +0000	[thread overview]
Message-ID: <49A3C3F9.6020409@katalix.com> (raw)
In-Reply-To: <49A3BCCF.9040203@trash.net>

Patrick McHardy wrote:
> James Chapman wrote:
>> Herbert Xu wrote:
>>> James Chapman <jchapman@katalix.com> wrote:
>>>> This patch series implements L2TPv3. It replaces the existing pppol2tp
>>>> driver with a number of separate drivers, namely:-
>>>>
>>>> l2tp_core    - L2TP driver core. Always required.
>>>> l2tp_ppp     - L2TP PPP
>>>> l2tp_eth     - L2TPv3 ethernet pseudowire
>>>> l2tp_ip      - L2TPv3 IP encapsulation
>>>> l2tp_netlink - L2TPv3 netlink API
>>> Have you thought by using the rtnl_link_ops interface instead
>>> of your own netlink API?
>>
>> I did, yes. I decided against it only because I didn't want to cause
>> confusion with what I perhaps wrongly perceive as an API for managing
>> net devices. In the L2TPv3 case, there might not be a netdev directly
>> associated with a newlink API call, for example. I've no problem with
>> switching the code to use it if it is preferred.
> 
> From a quick look, it seems you're (also) managing sessions, for
> which rtnl_link might not be the best choice. Could you give a
> short overview of the operations you need to be able to perform?

Sure.

Userspace needs to create, delete, modify and query L2TP tunnel and
session contexts in the kernel. Tunnels are associated with a tunnel
socket (UDP or L2TPIP) and can carry multiple sessions. Session contexts
differ according to type; they are associated with a pppol2tp socket and
implicit ppp netdev in the case of PPP pseudowires, or an ethernet
netdev in the case of ethernet pseudowires. Other pseudowires may be
added in the future for ATM, Frame Relay etc.

In the existing L2TPv2 driver, only PPP is supported by L2TPv2 so the
management of session contexts is done through [gs]etsockopt and ioctl
on the pppol2tp socket. Since in L2TPv3, there might not be a socket for
a session (i.e. in the case of ethernet), we need a new API to manage
the tunnel and session contexts in the kernel.

The extra L2TPv3 configuration parameters of tunnels also required a
more extensive API for creating tunnel contexts. In L2TPv2, tunnel
contexts were automatically created when the first session on that
tunnel was created. In L2TPv3, this isn't possible because the tunnel
creation parameters aren't known by the session. Therefore, the API was
changed to require that userspace create an L2TPv3 tunnel context in the
kernel separately, before creating sessions on it.

Is that enough detail?

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development


  reply	other threads:[~2009-02-24  9:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-22 17:52 [RFC PATCH 0/8] l2tp: introduce L2TPv3 support James Chapman
2009-02-24  6:39 ` Herbert Xu
2009-02-24  9:17   ` James Chapman
2009-02-24  9:24     ` Patrick McHardy
2009-02-24  9:55       ` James Chapman [this message]
2009-02-24 10:00         ` Patrick McHardy
2009-02-24  9:45     ` Herbert Xu

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=49A3C3F9.6020409@katalix.com \
    --to=jchapman@katalix.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    /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).