netdev - Re: [PATCH WIP RFC 0/3] mpls: support for ler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Jun 2015 11:14:42 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	Roopa Prabhu <roopa@...ulusnetworks.com>
Cc:	ebiederm@...ssion.com, rshearma@...cade.com, netdev@...r.kernel.org
Subject: Re: [PATCH WIP RFC 0/3] mpls: support for ler

On 06/03/15 at 07:21am, Roopa Prabhu wrote:
> From: Roopa Prabhu <roopa@...ulusnetworks.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@...ulusnetworks.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 ;-) 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.

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.

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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html