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, 05 Jun 2015 19:54:24 -0700
From:	roopa <roopa@...ulusnetworks.com>
To:	Robert Shearman <rshearma@...cade.com>
CC:	Thomas Graf <tgraf@...g.ch>, ebiederm@...ssion.com,
	netdev@...r.kernel.org,
	Vivek Venkatraman <vivek@...ulusnetworks.com>
Subject: Re: [PATCH WIP RFC 0/3] mpls: support for ler

On 6/5/15, 8:26 AM, Robert Shearman wrote:
>
> It isn't clear to me what the strategy here is for dealing with tunnel 
> encaps that aren't bound to an interface.
>
> Thomas, I presume you would prefer not to force the user to keep track 
> of changes to the output interface and nexthop corresponding to the 
> destination of the outer IP header? And I presume that Eric is opposed 
> to the option of using a virtual interface here, i.e. falling back to 
> the approach I proposed?
>
> In which case, what will the nexthop output interface be set to? 
> Logically, it should have no interface. At the moment, the code 
> assumes that a nexthop will have a valid interface and I don't have a 
> feel for what the impact would be of changing that.

The nexthop interface is the final output interface. Any reason it 
should not be ?
>
> However, with that resolved I'd be happy to work on a series together. 
> The remaining issue is whether to optimise for small encap that reside 
> in the same memory block as the fib_info, which aren't refcounted but 
> instead are copied around, or larger encaps that reside in their own 
> memory block that are refcounted and only a pointer passed around.
I would prefer the latter (as shown in my incomplete patch) simply 
because it stays separate from fib_info and allows for extending it in 
the future.

> If the latter, then there really isn't much left in my patch series 
> that can be reused, other than references to the places in the code 
> that need to be changed to support multipath and to make fib_info 
> matching work correctly.

Thanks,
Roopa

--
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