From: roopa <roopa@cumulusnetworks•com>
To: Thomas Graf <tgraf@suug•ch>
Cc: ebiederm@xmission•com, rshearma@brocade•com, netdev@vger•kernel.org
Subject: Re: [PATCH WIP RFC 0/3] mpls: support for ler
Date: Fri, 05 Jun 2015 07:16:08 -0700 [thread overview]
Message-ID: <5571AF28.8000009@cumulusnetworks.com> (raw)
In-Reply-To: <20150605091441.GA11896@pox.localdomain>
On 6/5/15, 2:14 AM, Thomas Graf wrote:
> On 06/03/15 at 07:21am, Roopa Prabhu wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks•com>
>>
>> This is still WIP and incomplete.
>> Posting it here because of the other discussions
>> happening around mpls ler in the context of Roberts
>> code and I happened to mention this implementation.
>>
>> This was in response to earlier email thread with Eric on
>> net-next of possibly using xfrm style stacked destination
>> approach.
>>
>> I introduce a new set of tunnel ops for light weight
>> tunnels (lwt), but this could be merged with the
>> other ip_tunnels code if possible.
>>
>> I had this code for 3.2 kernel initially, and
>> as I was pulling out code, I realize i had to separate
>> out some other mpls code that i have been working on
>> and quite likely this will not even compile. Sorry abt
>> that.
>>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks•com>
> Thanks for posting these patches Roopa!
>
> I see that some of the edges are still a bit rough. In particular
> the lack of sanity checking around type before indexing the array
> with it ;-)
Oh..., sorry you had to see that :)
(In my defense, ...i did successfully get some packets into the mpls
tunnel with this though! :) )
> No question that this would make a great optimization
> on top of existing IP tunnels though! I think this is where Eric
> was heading to and given this implementation, I'm perfectly fine
> with it as it does not *require* to precompute the headers for all
> encap types.
>
> This can be made compatible with the patches I have posted as well.
> A simple flag in what you call rtencap could indicate whether to
> perform the encap in the dst->output or merely attach the metadata
> and forward it to RTA_OIF for postponed encapsulation.
>
> That way, if desirable by the user, the net_device can be omitted
> which would suit Eric's architecture while we still also support
> the traditional net_device model which provides stats and a shared
> set of encapsulation parameters. It will also allow for bridges to
> perform the encapsulation decision if needed and we can still get
> rid of the OVS encapsulation special handling.
yeah, that's a great idea.
>
> As I mentioned to Robert, the new RTA_ENCAP should be a list of
> Netlink attributes from the beginning to make it extendible without
> ever breaking user ABI.
agreed.
>
> The most overlap seems to be with Robert's series. The direction
> seems to be very similar. How do you want to proceed? Work on a
> series together? I'm happy to rebase my series on top of both you
> and Robert's work and make use of a new generic per nexthop
> encapsulation API. Let me know how you guys want to proceed.
Robert, pls let me know if you have a preference on how you want to
proceed. One
option is for me to use your git tree as a way to get my patches in.
But, If we agree that we don't want to introduce a tunnel netdevice for
mpls yet (which is our vote as well),
then its probably better for me to rebase my changes on top of your
series and
re-submit (with proper attribution ofcourse).
(Happy to take erics feedback as well here).
Right now I am working on refining my patches and covering ipv6.
I would be happy to make RTA_ENCAP nested...unless you would prefer to
take that over.
I have also been trying to see If i can reuse any infra from the
existing ip_tunnel world.
Thanks for the feedback Thomas!.
next prev parent reply other threads:[~2015-06-05 14:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 14:21 [PATCH WIP RFC 0/3] mpls: support for ler Roopa Prabhu
2015-06-05 9:14 ` Thomas Graf
2015-06-05 14:16 ` roopa [this message]
2015-06-05 15:26 ` Robert Shearman
2015-06-06 2:54 ` roopa
2015-06-08 12:33 ` Thomas Graf
2015-06-08 15:17 ` roopa
2015-06-08 22:58 ` Thomas Graf
2015-06-10 7:13 ` roopa
2015-06-12 16:15 ` roopa
2015-06-05 14:31 ` Robert Shearman
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=5571AF28.8000009@cumulusnetworks.com \
--to=roopa@cumulusnetworks$(echo .)com \
--cc=ebiederm@xmission$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=rshearma@brocade$(echo .)com \
--cc=tgraf@suug$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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