| Message ID | 1506335021-32024-3-git-send-email-simon.horman@netronome.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | nfp: flower vxlan tunnel offload | expand |
On Mon, Sep 25, 2017 at 1:23 PM, Simon Horman <simon.horman@netronome.com> wrote: > From: John Hurley <john.hurley@netronome.com> > > Compile ovs-tc flower vxlan metadata match fields for offloading. Only anything in the npf kernel bits has direct relation to ovs? what? > +++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c > @@ -52,8 +52,25 @@ > BIT(FLOW_DISSECTOR_KEY_PORTS) | \ > BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS) | \ > BIT(FLOW_DISSECTOR_KEY_VLAN) | \ > + BIT(FLOW_DISSECTOR_KEY_ENC_KEYID) | \ > + BIT(FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) | \ > + BIT(FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS) | \ this series takes care of IPv6 tunnels too?
On Mon, Sep 25, 2017 at 7:35 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote: > On Mon, Sep 25, 2017 at 1:23 PM, Simon Horman > <simon.horman@netronome.com> wrote: >> From: John Hurley <john.hurley@netronome.com> >> >> Compile ovs-tc flower vxlan metadata match fields for offloading. Only > > anything in the npf kernel bits has direct relation to ovs? what? > Sorry, this is a typo and should refer to TC. >> +++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c >> @@ -52,8 +52,25 @@ >> BIT(FLOW_DISSECTOR_KEY_PORTS) | \ >> BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS) | \ >> BIT(FLOW_DISSECTOR_KEY_VLAN) | \ >> + BIT(FLOW_DISSECTOR_KEY_ENC_KEYID) | \ >> + BIT(FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) | \ >> + BIT(FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS) | \ > > this series takes care of IPv6 tunnels too? IPv6 is not included in this set. The reason the IPv6 bit is included here is to account for behavior we have noticed in TC flower. If, for example, I add a filter with the following match fields: 'protocol ip flower enc_src_ip 10.0.0.1 enc_dst_ip 10.0.0.2 enc_dst_port 4789 enc_key_id 123' The 'used_keys' value in the dissector marks both IPv4 and IPv6 encap addresses as 'used'. I am not sure if this is a bug in TC or that we are expected to check the enc_control fields to determine if IPv4 or v6 addresses are used. Including the IPv6 used_keys bit in our whitelist approach allows us to accept legitimate IPv4 tunnel rules in these situations. If it is found to be IPv6 when the rule is parsed, it will be rejected here.
On Tue, Sep 26, 2017 at 4:58 PM, John Hurley <john.hurley@netronome.com> wrote: > On Mon, Sep 25, 2017 at 7:35 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote: >> On Mon, Sep 25, 2017 at 1:23 PM, Simon Horman >> <simon.horman@netronome.com> wrote: >>> From: John Hurley <john.hurley@netronome.com> >>> >>> Compile ovs-tc flower vxlan metadata match fields for offloading. Only >> >> anything in the npf kernel bits has direct relation to ovs? what? >> > > Sorry, this is a typo and should refer to TC. > >>> +++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c >>> @@ -52,8 +52,25 @@ >>> BIT(FLOW_DISSECTOR_KEY_PORTS) | \ >>> BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS) | \ >>> BIT(FLOW_DISSECTOR_KEY_VLAN) | \ >>> + BIT(FLOW_DISSECTOR_KEY_ENC_KEYID) | \ >>> + BIT(FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) | \ >>> + BIT(FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS) | \ >> >> this series takes care of IPv6 tunnels too? > > IPv6 is not included in this set. > The reason the IPv6 bit is included here is to account for behavior we > have noticed in TC flower. > If, for example, I add a filter with the following match fields: > 'protocol ip flower enc_src_ip 10.0.0.1 enc_dst_ip 10.0.0.2 > enc_dst_port 4789 enc_key_id 123' > The 'used_keys' value in the dissector marks both IPv4 and IPv6 encap > addresses as 'used'. > I am not sure if this is a bug in TC or that we are expected to check > the enc_control fields to determine if IPv4 or v6 addresses are used. you should have your code to check enc_control->addr_type to be FLOW_DISSECTOR_KEY_IPV4_ADDRS or IPV6_ADDRS > Including the IPv6 used_keys bit in our whitelist approach allows us > to accept legitimate IPv4 tunnel rules in these situations. mmm can please take a look on fl_init_dissector() and tell me if you see why FLOW_DISSECTOR_KEY_IPV6_ADDRS is set for ipv4 tunnels, I am not sure. > If it is found to be IPv6 when the rule is parsed, it will be rejected here.
On Tue, Sep 26, 2017 at 3:12 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote: > On Tue, Sep 26, 2017 at 4:58 PM, John Hurley <john.hurley@netronome.com> wrote: >> On Mon, Sep 25, 2017 at 7:35 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote: >>> On Mon, Sep 25, 2017 at 1:23 PM, Simon Horman >>> <simon.horman@netronome.com> wrote: >>>> From: John Hurley <john.hurley@netronome.com> >>>> >>>> Compile ovs-tc flower vxlan metadata match fields for offloading. Only >>> >>> anything in the npf kernel bits has direct relation to ovs? what? >>> >> >> Sorry, this is a typo and should refer to TC. >> >>>> +++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c >>>> @@ -52,8 +52,25 @@ >>>> BIT(FLOW_DISSECTOR_KEY_PORTS) | \ >>>> BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS) | \ >>>> BIT(FLOW_DISSECTOR_KEY_VLAN) | \ >>>> + BIT(FLOW_DISSECTOR_KEY_ENC_KEYID) | \ >>>> + BIT(FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) | \ >>>> + BIT(FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS) | \ >>> >>> this series takes care of IPv6 tunnels too? >> >> IPv6 is not included in this set. >> The reason the IPv6 bit is included here is to account for behavior we >> have noticed in TC flower. >> If, for example, I add a filter with the following match fields: >> 'protocol ip flower enc_src_ip 10.0.0.1 enc_dst_ip 10.0.0.2 >> enc_dst_port 4789 enc_key_id 123' >> The 'used_keys' value in the dissector marks both IPv4 and IPv6 encap >> addresses as 'used'. >> I am not sure if this is a bug in TC or that we are expected to check >> the enc_control fields to determine if IPv4 or v6 addresses are used. > > you should have your code to check enc_control->addr_type to be > FLOW_DISSECTOR_KEY_IPV4_ADDRS or IPV6_ADDRS > > >> Including the IPv6 used_keys bit in our whitelist approach allows us >> to accept legitimate IPv4 tunnel rules in these situations. > > mmm can please take a look on fl_init_dissector() and tell me if you > see why FLOW_DISSECTOR_KEY_IPV6_ADDRS is set for ipv4 tunnels, > I am not sure. The fl_init_dissector uses the FL_KEY_SET_IF_MASKED macro to set an array of keys which are then translated to the used_keys values. The FL_KEY_SET_IF_MASKED takes a 'struct fl_flow_key' as input and checks if any mask bits are set in a particular field - if so it eventually marks it as used. In struct fl_flow_key, the encap ipv4 and ipv6 addresses are represented as a union of the 2. Therefore, if we have masked bits set for IPv4, they are also being set for the IPv6 field. > >> If it is found to be IPv6 when the rule is parsed, it will be rejected here.
On Tue, Sep 26, 2017 at 6:11 PM, John Hurley <john.hurley@netronome.com> wrote: > On Tue, Sep 26, 2017 at 3:12 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote: >> On Tue, Sep 26, 2017 at 4:58 PM, John Hurley <john.hurley@netronome.com> wrote: >>> On Mon, Sep 25, 2017 at 7:35 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote: >>>> On Mon, Sep 25, 2017 at 1:23 PM, Simon Horman >>>> <simon.horman@netronome.com> wrote: >>>>> From: John Hurley <john.hurley@netronome.com> >>>>> >>>>> Compile ovs-tc flower vxlan metadata match fields for offloading. Only >>>> >>>> anything in the npf kernel bits has direct relation to ovs? what? >>>> >>> >>> Sorry, this is a typo and should refer to TC. >>> >>>>> +++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c >>>>> @@ -52,8 +52,25 @@ >>>>> BIT(FLOW_DISSECTOR_KEY_PORTS) | \ >>>>> BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS) | \ >>>>> BIT(FLOW_DISSECTOR_KEY_VLAN) | \ >>>>> + BIT(FLOW_DISSECTOR_KEY_ENC_KEYID) | \ >>>>> + BIT(FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) | \ >>>>> + BIT(FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS) | \ >>>> >>>> this series takes care of IPv6 tunnels too? >>> >>> IPv6 is not included in this set. >>> The reason the IPv6 bit is included here is to account for behavior we >>> have noticed in TC flower. >>> If, for example, I add a filter with the following match fields: >>> 'protocol ip flower enc_src_ip 10.0.0.1 enc_dst_ip 10.0.0.2 >>> enc_dst_port 4789 enc_key_id 123' >>> The 'used_keys' value in the dissector marks both IPv4 and IPv6 encap >>> addresses as 'used'. >>> I am not sure if this is a bug in TC or that we are expected to check >>> the enc_control fields to determine if IPv4 or v6 addresses are used. >> >> you should have your code to check enc_control->addr_type to be >> FLOW_DISSECTOR_KEY_IPV4_ADDRS or IPV6_ADDRS >> >> >>> Including the IPv6 used_keys bit in our whitelist approach allows us >>> to accept legitimate IPv4 tunnel rules in these situations. >> >> mmm can please take a look on fl_init_dissector() and tell me if you >> see why FLOW_DISSECTOR_KEY_IPV6_ADDRS is set for ipv4 tunnels, >> I am not sure. > > > The fl_init_dissector uses the FL_KEY_SET_IF_MASKED macro to set an > array of keys which are then translated to the used_keys values. > The FL_KEY_SET_IF_MASKED takes a 'struct fl_flow_key' as input and > checks if any mask bits are set in a particular field - if so it > eventually marks it as used. > In struct fl_flow_key, the encap ipv4 and ipv6 addresses are > represented as a union of the 2. > Therefore, if we have masked bits set for IPv4, they are also being > set for the IPv6 field. I see, do you consider it a bug?
On Tue, Sep 26, 2017 at 4:33 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote: > On Tue, Sep 26, 2017 at 6:11 PM, John Hurley <john.hurley@netronome.com> wrote: >> On Tue, Sep 26, 2017 at 3:12 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote: >>> On Tue, Sep 26, 2017 at 4:58 PM, John Hurley <john.hurley@netronome.com> wrote: >>>> On Mon, Sep 25, 2017 at 7:35 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote: >>>>> On Mon, Sep 25, 2017 at 1:23 PM, Simon Horman >>>>> <simon.horman@netronome.com> wrote: >>>>>> From: John Hurley <john.hurley@netronome.com> >>>>>> >>>>>> Compile ovs-tc flower vxlan metadata match fields for offloading. Only >>>>> >>>>> anything in the npf kernel bits has direct relation to ovs? what? >>>>> >>>> >>>> Sorry, this is a typo and should refer to TC. >>>> >>>>>> +++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c >>>>>> @@ -52,8 +52,25 @@ >>>>>> BIT(FLOW_DISSECTOR_KEY_PORTS) | \ >>>>>> BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS) | \ >>>>>> BIT(FLOW_DISSECTOR_KEY_VLAN) | \ >>>>>> + BIT(FLOW_DISSECTOR_KEY_ENC_KEYID) | \ >>>>>> + BIT(FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) | \ >>>>>> + BIT(FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS) | \ >>>>> >>>>> this series takes care of IPv6 tunnels too? >>>> >>>> IPv6 is not included in this set. >>>> The reason the IPv6 bit is included here is to account for behavior we >>>> have noticed in TC flower. >>>> If, for example, I add a filter with the following match fields: >>>> 'protocol ip flower enc_src_ip 10.0.0.1 enc_dst_ip 10.0.0.2 >>>> enc_dst_port 4789 enc_key_id 123' >>>> The 'used_keys' value in the dissector marks both IPv4 and IPv6 encap >>>> addresses as 'used'. >>>> I am not sure if this is a bug in TC or that we are expected to check >>>> the enc_control fields to determine if IPv4 or v6 addresses are used. >>> >>> you should have your code to check enc_control->addr_type to be >>> FLOW_DISSECTOR_KEY_IPV4_ADDRS or IPV6_ADDRS >>> >>> >>>> Including the IPv6 used_keys bit in our whitelist approach allows us >>>> to accept legitimate IPv4 tunnel rules in these situations. >>> >>> mmm can please take a look on fl_init_dissector() and tell me if you >>> see why FLOW_DISSECTOR_KEY_IPV6_ADDRS is set for ipv4 tunnels, >>> I am not sure. >> >> >> The fl_init_dissector uses the FL_KEY_SET_IF_MASKED macro to set an >> array of keys which are then translated to the used_keys values. >> The FL_KEY_SET_IF_MASKED takes a 'struct fl_flow_key' as input and >> checks if any mask bits are set in a particular field - if so it >> eventually marks it as used. >> In struct fl_flow_key, the encap ipv4 and ipv6 addresses are >> represented as a union of the 2. >> Therefore, if we have masked bits set for IPv4, they are also being >> set for the IPv6 field. > > I see, do you consider it a bug? The code seems to insist that, if either IPv4 or IPv6 is in use then a control encap key is also used: if (FL_KEY_IS_MASKED(&mask->key, enc_ipv4) || FL_KEY_IS_MASKED(&mask->key, enc_ipv6)) FL_KEY_SET(keys, cnt, FLOW_DISSECTOR_KEY_ENC_CONTROL, enc_control); Therefore, I think it should be ok to use this to determine the IP type in use by the tunnel.
diff --git a/drivers/net/ethernet/netronome/nfp/flower/cmsg.h b/drivers/net/ethernet/netronome/nfp/flower/cmsg.h index 7a5ccf0cc7c2..af9165b3b652 100644 --- a/drivers/net/ethernet/netronome/nfp/flower/cmsg.h +++ b/drivers/net/ethernet/netronome/nfp/flower/cmsg.h @@ -83,6 +83,14 @@ #define NFP_FL_PUSH_VLAN_CFI BIT(12) #define NFP_FL_PUSH_VLAN_VID GENMASK(11, 0) +/* Tunnel ports */ +#define NFP_FL_PORT_TYPE_TUN 0x50000000 + +enum nfp_flower_tun_type { + NFP_FL_TUNNEL_NONE = 0, + NFP_FL_TUNNEL_VXLAN = 2, +}; + struct nfp_fl_output { __be16 a_op; __be16 flags; @@ -230,6 +238,36 @@ struct nfp_flower_ipv6 { struct in6_addr ipv6_dst; }; +/* Flow Frame VXLAN --> Tunnel details (4W/16B) + * ----------------------------------------------------------------- + * 3 2 1 + * 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | ipv4_addr_src | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | ipv4_addr_dst | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | tun_flags | tos | ttl | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | gpe_flags | Reserved | Next Protocol | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | VNI | Reserved | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + */ +struct nfp_flower_vxlan { + __be32 ip_src; + __be32 ip_dst; + __be16 tun_flags; + u8 tos; + u8 ttl; + u8 gpe_flags; + u8 reserved[2]; + u8 nxt_proto; + __be32 tun_id; +}; + +#define NFP_FL_TUN_VNI_OFFSET 8 + /* The base header for a control message packet. * Defines an 8-bit version, and an 8-bit type, padded * to a 32-bit word. Rest of the packet is type-specific. diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.h b/drivers/net/ethernet/netronome/nfp/flower/main.h index c20dd00a1cae..cd695eabce02 100644 --- a/drivers/net/ethernet/netronome/nfp/flower/main.h +++ b/drivers/net/ethernet/netronome/nfp/flower/main.h @@ -58,6 +58,8 @@ struct nfp_app; #define NFP_FL_MASK_REUSE_TIME_NS 40000 #define NFP_FL_MASK_ID_LOCATION 1 +#define NFP_FL_VXLAN_PORT 4789 + struct nfp_fl_mask_id { struct circ_buf mask_id_free_list; struct timespec64 *last_used; diff --git a/drivers/net/ethernet/netronome/nfp/flower/match.c b/drivers/net/ethernet/netronome/nfp/flower/match.c index d25b5038c3a2..1fd1bab0611f 100644 --- a/drivers/net/ethernet/netronome/nfp/flower/match.c +++ b/drivers/net/ethernet/netronome/nfp/flower/match.c @@ -77,14 +77,17 @@ nfp_flower_compile_meta(struct nfp_flower_meta_one *frame, u8 key_type) static int nfp_flower_compile_port(struct nfp_flower_in_port *frame, u32 cmsg_port, - bool mask_version) + bool mask_version, enum nfp_flower_tun_type tun_type) { if (mask_version) { frame->in_port = cpu_to_be32(~0); return 0; } - frame->in_port = cpu_to_be32(cmsg_port); + if (tun_type) + frame->in_port = cpu_to_be32(NFP_FL_PORT_TYPE_TUN | tun_type); + else + frame->in_port = cpu_to_be32(cmsg_port); return 0; } @@ -189,15 +192,53 @@ nfp_flower_compile_ipv6(struct nfp_flower_ipv6 *frame, } } +static void +nfp_flower_compile_vxlan(struct nfp_flower_vxlan *frame, + struct tc_cls_flower_offload *flow, + bool mask_version) +{ + struct fl_flow_key *target = mask_version ? flow->mask : flow->key; + struct flow_dissector_key_ipv4_addrs *vxlan_ips; + struct flow_dissector_key_keyid *vni; + + /* Wildcard TOS/TTL/GPE_FLAGS/NXT_PROTO for now. */ + memset(frame, 0, sizeof(struct nfp_flower_vxlan)); + + if (dissector_uses_key(flow->dissector, + FLOW_DISSECTOR_KEY_ENC_KEYID)) { + u32 temp_vni; + + vni = skb_flow_dissector_target(flow->dissector, + FLOW_DISSECTOR_KEY_ENC_KEYID, + target); + temp_vni = be32_to_cpu(vni->keyid) << NFP_FL_TUN_VNI_OFFSET; + frame->tun_id = cpu_to_be32(temp_vni); + } + + if (dissector_uses_key(flow->dissector, + FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS)) { + vxlan_ips = + skb_flow_dissector_target(flow->dissector, + FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS, + target); + frame->ip_src = vxlan_ips->src; + frame->ip_dst = vxlan_ips->dst; + } +} + int nfp_flower_compile_flow_match(struct tc_cls_flower_offload *flow, struct nfp_fl_key_ls *key_ls, struct net_device *netdev, struct nfp_fl_payload *nfp_flow) { + enum nfp_flower_tun_type tun_type = NFP_FL_TUNNEL_NONE; int err; u8 *ext; u8 *msk; + if (key_ls->key_layer & NFP_FLOWER_LAYER_VXLAN) + tun_type = NFP_FL_TUNNEL_VXLAN; + memset(nfp_flow->unmasked_data, 0, key_ls->key_size); memset(nfp_flow->mask_data, 0, key_ls->key_size); @@ -216,14 +257,14 @@ int nfp_flower_compile_flow_match(struct tc_cls_flower_offload *flow, /* Populate Exact Port data. */ err = nfp_flower_compile_port((struct nfp_flower_in_port *)ext, nfp_repr_get_port_id(netdev), - false); + false, tun_type); if (err) return err; /* Populate Mask Port Data. */ err = nfp_flower_compile_port((struct nfp_flower_in_port *)msk, nfp_repr_get_port_id(netdev), - true); + true, tun_type); if (err) return err; @@ -291,5 +332,16 @@ int nfp_flower_compile_flow_match(struct tc_cls_flower_offload *flow, msk += sizeof(struct nfp_flower_ipv6); } + if (key_ls->key_layer & NFP_FLOWER_LAYER_VXLAN) { + /* Populate Exact VXLAN Data. */ + nfp_flower_compile_vxlan((struct nfp_flower_vxlan *)ext, + flow, false); + /* Populate Mask VXLAN Data. */ + nfp_flower_compile_vxlan((struct nfp_flower_vxlan *)msk, + flow, true); + ext += sizeof(struct nfp_flower_vxlan); + msk += sizeof(struct nfp_flower_vxlan); + } + return 0; } diff --git a/drivers/net/ethernet/netronome/nfp/flower/offload.c b/drivers/net/ethernet/netronome/nfp/flower/offload.c index a18b4d2b1d3e..637372ba8f55 100644 --- a/drivers/net/ethernet/netronome/nfp/flower/offload.c +++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c @@ -52,8 +52,25 @@ BIT(FLOW_DISSECTOR_KEY_PORTS) | \ BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS) | \ BIT(FLOW_DISSECTOR_KEY_VLAN) | \ + BIT(FLOW_DISSECTOR_KEY_ENC_KEYID) | \ + BIT(FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) | \ + BIT(FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS) | \ + BIT(FLOW_DISSECTOR_KEY_ENC_CONTROL) | \ + BIT(FLOW_DISSECTOR_KEY_ENC_PORTS) | \ BIT(FLOW_DISSECTOR_KEY_IP)) +#define NFP_FLOWER_WHITELIST_TUN_DISSECTOR \ + (BIT(FLOW_DISSECTOR_KEY_ENC_CONTROL) | \ + BIT(FLOW_DISSECTOR_KEY_ENC_KEYID) | \ + BIT(FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) | \ + BIT(FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS) | \ + BIT(FLOW_DISSECTOR_KEY_ENC_PORTS)) + +#define NFP_FLOWER_WHITELIST_TUN_DISSECTOR_R \ + (BIT(FLOW_DISSECTOR_KEY_ENC_CONTROL) | \ + BIT(FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) | \ + BIT(FLOW_DISSECTOR_KEY_ENC_PORTS)) + static int nfp_flower_xmit_flow(struct net_device *netdev, struct nfp_fl_payload *nfp_flow, u8 mtype) @@ -125,15 +142,58 @@ nfp_flower_calculate_key_layers(struct nfp_fl_key_ls *ret_key_ls, if (flow->dissector->used_keys & ~NFP_FLOWER_WHITELIST_DISSECTOR) return -EOPNOTSUPP; + /* If any tun dissector is used then the required set must be used. */ + if (flow->dissector->used_keys & NFP_FLOWER_WHITELIST_TUN_DISSECTOR && + (flow->dissector->used_keys & NFP_FLOWER_WHITELIST_TUN_DISSECTOR_R) + != NFP_FLOWER_WHITELIST_TUN_DISSECTOR_R) + return -EOPNOTSUPP; + + key_layer_two = 0; + key_layer = NFP_FLOWER_LAYER_PORT | NFP_FLOWER_LAYER_MAC; + key_size = sizeof(struct nfp_flower_meta_one) + + sizeof(struct nfp_flower_in_port) + + sizeof(struct nfp_flower_mac_mpls); + if (dissector_uses_key(flow->dissector, FLOW_DISSECTOR_KEY_ENC_CONTROL)) { + struct flow_dissector_key_ipv4_addrs *mask_ipv4 = NULL; + struct flow_dissector_key_ports *mask_enc_ports = NULL; + struct flow_dissector_key_ports *enc_ports = NULL; struct flow_dissector_key_control *mask_enc_ctl = skb_flow_dissector_target(flow->dissector, FLOW_DISSECTOR_KEY_ENC_CONTROL, flow->mask); - /* We are expecting a tunnel. For now we ignore offloading. */ - if (mask_enc_ctl->addr_type) + struct flow_dissector_key_control *enc_ctl = + skb_flow_dissector_target(flow->dissector, + FLOW_DISSECTOR_KEY_ENC_CONTROL, + flow->key); + if (mask_enc_ctl->addr_type != 0xffff || + enc_ctl->addr_type != FLOW_DISSECTOR_KEY_IPV4_ADDRS) return -EOPNOTSUPP; + + /* These fields are already verified as used. */ + mask_ipv4 = + skb_flow_dissector_target(flow->dissector, + FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS, + flow->mask); + if (mask_ipv4->dst != cpu_to_be32(~0)) + return -EOPNOTSUPP; + + mask_enc_ports = + skb_flow_dissector_target(flow->dissector, + FLOW_DISSECTOR_KEY_ENC_PORTS, + flow->mask); + enc_ports = + skb_flow_dissector_target(flow->dissector, + FLOW_DISSECTOR_KEY_ENC_PORTS, + flow->key); + + if (mask_enc_ports->dst != cpu_to_be16(~0) || + enc_ports->dst != htons(NFP_FL_VXLAN_PORT)) + return -EOPNOTSUPP; + + key_layer |= NFP_FLOWER_LAYER_VXLAN; + key_size += sizeof(struct nfp_flower_vxlan); } if (dissector_uses_key(flow->dissector, FLOW_DISSECTOR_KEY_BASIC)) { @@ -151,12 +211,6 @@ nfp_flower_calculate_key_layers(struct nfp_fl_key_ls *ret_key_ls, FLOW_DISSECTOR_KEY_IP, flow->mask); - key_layer_two = 0; - key_layer = NFP_FLOWER_LAYER_PORT | NFP_FLOWER_LAYER_MAC; - key_size = sizeof(struct nfp_flower_meta_one) + - sizeof(struct nfp_flower_in_port) + - sizeof(struct nfp_flower_mac_mpls); - if (mask_basic && mask_basic->n_proto) { /* Ethernet type is present in the key. */ switch (key_basic->n_proto) {