* [PATCH/RFC] openvswitch: loosen restriction of output of MPLS to tunnel vports @ 2016-02-12 19:25 Simon Horman 2016-02-16 22:53 ` Jesse Gross 0 siblings, 1 reply; 4+ messages in thread From: Simon Horman @ 2016-02-12 19:25 UTC (permalink / raw) To: netdev; +Cc: dev, Pravin Shelar, Simon Horman 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.horman@netronome.com> --- net/openvswitch/flow_netlink.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c index d1bd4a45ca2d..a574796f35d2 100644 --- a/net/openvswitch/flow_netlink.c +++ b/net/openvswitch/flow_netlink.c @@ -2038,7 +2038,13 @@ static int validate_set(const struct nlattr *a, break; case OVS_KEY_ATTR_TUNNEL: - if (eth_p_mpls(eth_type)) + /* 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. + */ + if (!eth_p_mpls(flow_key->eth.type) && eth_p_mpls(eth_type)) return -EINVAL; if (masked) -- 2.7.0.rc3.207.g0ac5344 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH/RFC] openvswitch: loosen restriction of output of MPLS to tunnel vports 2016-02-12 19:25 [PATCH/RFC] openvswitch: loosen restriction of output of MPLS to tunnel vports Simon Horman @ 2016-02-16 22:53 ` Jesse Gross [not found] ` <CAEh+42g5GXduCgr0WCyAKvSO6LeATFuZoWU2aR0sfNDbJqG=6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 4+ messages in thread From: Jesse Gross @ 2016-02-16 22:53 UTC (permalink / raw) To: Simon Horman; +Cc: Linux Kernel Network Developers, ovs dev, Pravin Shelar On Fri, Feb 12, 2016 at 11:25 AM, Simon Horman <simon.horman@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.horman@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.) ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <CAEh+42g5GXduCgr0WCyAKvSO6LeATFuZoWU2aR0sfNDbJqG=6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH/RFC] openvswitch: loosen restriction of output of MPLS to tunnel vports [not found] ` <CAEh+42g5GXduCgr0WCyAKvSO6LeATFuZoWU2aR0sfNDbJqG=6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-02-19 7:59 ` Simon Horman 2016-02-19 15:45 ` Jesse Gross 0 siblings, 1 reply; 4+ messages in thread From: Simon Horman @ 2016-02-19 7:59 UTC (permalink / raw) To: Jesse Gross; +Cc: ovs dev, Linux Kernel Network Developers 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.horman@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.horman@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH/RFC] openvswitch: loosen restriction of output of MPLS to tunnel vports 2016-02-19 7:59 ` Simon Horman @ 2016-02-19 15:45 ` Jesse Gross 0 siblings, 0 replies; 4+ messages in thread From: Jesse Gross @ 2016-02-19 15:45 UTC (permalink / raw) To: Simon Horman; +Cc: Linux Kernel Network Developers, ovs dev, Pravin Shelar On Thu, Feb 18, 2016 at 11:59 PM, Simon Horman <simon.horman@netronome.com> wrote: > 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.horman@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.horman@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. I actually don't think that any changes are really needed to make this work. All we should have to do is remove the checks similar to the one you are modifying here in flow_netlink.c and the the runtime one in actions.c. It's probably good to look through the overall code path to double check but as long as tunnel devices don't enable support for MPLS offloading by the time that encapsulation happens MPLS should really just look like any other packet received off the wire. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-02-19 15:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-12 19:25 [PATCH/RFC] openvswitch: loosen restriction of output of MPLS to tunnel vports Simon Horman
2016-02-16 22:53 ` Jesse Gross
[not found] ` <CAEh+42g5GXduCgr0WCyAKvSO6LeATFuZoWU2aR0sfNDbJqG=6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-19 7:59 ` Simon Horman
2016-02-19 15:45 ` Jesse Gross
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).