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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
