On Tue, Feb 16, 2016 at 02:53:39PM -0800, Jesse Gross wrote: > On Fri, Feb 12, 2016 at 11:25 AM, Simon Horman > <simon.hor...@netronome.com> wrote: > > If an skb was not MPLS initially then it may be GSO and in that case if it > > became MPLS then GSO can't be performed because both MPLS and tunnels make > > use of the inner_protocol field of struct skbuff in order to allow GSO to > > be performed in the inner packet. > > > > On the other hand if an skb was MPLS initially then it will not be GSO, > > as there is no support for GRO for MPLS. Thus in this case it is safe > > to allow output of MPLS on tunnel vports. > > > > Signed-off-by: Simon Horman <simon.hor...@netronome.com> > > I don't think that any tunnel implementations expose support for MPLS > offloads as part of their features. In that case, if we have an MPLS > GSO packet (regardless of how it came to be), I think it will be > broken apart in software before encapsulation. At that point, it > should be safe for the tunnel to overwrite any fields MPLS was > previously using for offloading. As a result, I believe we can allow > all combinations of MPLS with tunnels. (Note that historically this > wasn't true, the change is a result of lightweight tunnels.)
Hi Jesse, wow, that does sound very promising. I would certainly be in favour of allowing MPLS with tunnels. I am wondering if you could point me in the general direction of the changes you mention above.
