[<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
Powered by blists - more mailing lists