From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [RFC PATCH 0/8] l2tp: introduce L2TPv3 support Date: Tue, 24 Feb 2009 11:00:56 +0100 Message-ID: <49A3C558.2060602@trash.net> References: <20090224063908.GA20652@gondor.apana.org.au> <49A3BB1E.8040005@katalix.com> <49A3BCCF.9040203@trash.net> <49A3C3F9.6020409@katalix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Herbert Xu , netdev@vger.kernel.org To: James Chapman Return-path: Received: from stinky.trash.net ([213.144.137.162]:59338 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752026AbZBXKA7 (ORCPT ); Tue, 24 Feb 2009 05:00:59 -0500 In-Reply-To: <49A3C3F9.6020409@katalix.com> Sender: netdev-owner@vger.kernel.org List-ID: James Chapman wrote: > Patrick McHardy wrote: >> James Chapman wrote: >>> Herbert Xu wrote: >>>> James Chapman 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. rtnl_link really doesn't seem to be the best fit for this. It *could* be used for PPP device management, but since a userspace daemon is required anyways, it wouldn't be much of a benefit. > 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? Yes, thanks a lot.