| Message ID | 160407665728.1525159.18300199766779492971.stgit@firesoul |
|---|---|
| State | Not Applicable |
| Delegated to: | BPF Maintainers |
| Headers | show |
| Series | Subj: bpf: New approach for BPF MTU handling | expand |
| Context | Check | Description |
|---|---|---|
| jkicinski/cover_letter | success | Link |
| jkicinski/fixes_present | success | Link |
| jkicinski/patch_count | success | Link |
| jkicinski/tree_selection | success | Clearly marked for bpf-next |
| jkicinski/subject_prefix | success | Link |
| jkicinski/source_inline | success | Was 0 now: 0 |
| jkicinski/verify_signedoff | success | Link |
| jkicinski/module_param | success | Was 0 now: 0 |
| jkicinski/build_32bit | fail | Errors and warnings before: 15999 this patch: 15999 |
| jkicinski/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| jkicinski/verify_fixes | success | Link |
| jkicinski/checkpatch | fail | Link |
| jkicinski/build_allmodconfig_warn | success | Errors and warnings before: 16031 this patch: 16031 |
| jkicinski/header_inline | success | Link |
| jkicinski/stable | success | Stable not CCed |
Jesper Dangaard Brouer wrote: > The BPF-helpers for FIB lookup (bpf_xdp_fib_lookup and bpf_skb_fib_lookup) > can perform MTU check and return BPF_FIB_LKUP_RET_FRAG_NEEDED. The BPF-prog > don't know the MTU value that caused this rejection. > > If the BPF-prog wants to implement PMTU (Path MTU Discovery) (rfc1191) it > need to know this MTU value for the ICMP packet. > > Patch change lookup and result struct bpf_fib_lookup, to contain this MTU > value as output via a union with 'tot_len' as this is the value used for > the MTU lookup. > > V5: > - Fixed uninit value spotted by Dan Carpenter. > - Name struct output member mtu_result > > Reported-by: kernel test robot <lkp@intel.com> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> > --- > include/uapi/linux/bpf.h | 11 +++++++++-- > net/core/filter.c | 22 +++++++++++++++------- > tools/include/uapi/linux/bpf.h | 11 +++++++++-- > 3 files changed, 33 insertions(+), 11 deletions(-) > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > index e6ceac3f7d62..01b2b17c645a 100644 > --- a/include/uapi/linux/bpf.h > +++ b/include/uapi/linux/bpf.h > @@ -2219,6 +2219,9 @@ union bpf_attr { > * * > 0 one of **BPF_FIB_LKUP_RET_** codes explaining why the > * packet is not forwarded or needs assist from full stack > * > + * If lookup fails with BPF_FIB_LKUP_RET_FRAG_NEEDED, then the MTU > + * was exceeded and result params->mtu contains the MTU. > + * Do we need to hide this behind a flag? It seems otherwise you might confuse users. I imagine on error we could reuse the params arg, but now we changed the tot_len value underneath them? > * long bpf_sock_hash_update(struct bpf_sock_ops *skops, struct bpf_map *map, void *key, u64 flags) > * Description > * Add an entry to, or update a sockhash *map* referencing sockets. > @@ -4872,9 +4875,13 @@ struct bpf_fib_lookup { > __be16 sport; > __be16 dport;
On 10/30/20 10:50 AM, Jesper Dangaard Brouer wrote: > The BPF-helpers for FIB lookup (bpf_xdp_fib_lookup and bpf_skb_fib_lookup) > can perform MTU check and return BPF_FIB_LKUP_RET_FRAG_NEEDED. The BPF-prog > don't know the MTU value that caused this rejection. > > If the BPF-prog wants to implement PMTU (Path MTU Discovery) (rfc1191) it > need to know this MTU value for the ICMP packet. > > Patch change lookup and result struct bpf_fib_lookup, to contain this MTU > value as output via a union with 'tot_len' as this is the value used for > the MTU lookup. > > V5: > - Fixed uninit value spotted by Dan Carpenter. > - Name struct output member mtu_result > > Reported-by: kernel test robot <lkp@intel.com> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> > --- > include/uapi/linux/bpf.h | 11 +++++++++-- > net/core/filter.c | 22 +++++++++++++++------- > tools/include/uapi/linux/bpf.h | 11 +++++++++-- > 3 files changed, 33 insertions(+), 11 deletions(-) > Reviewed-by: David Ahern <dsahern@kernel.org>
On Fri, 30 Oct 2020 12:40:21 -0700 John Fastabend <john.fastabend@gmail.com> wrote: > Jesper Dangaard Brouer wrote: > > The BPF-helpers for FIB lookup (bpf_xdp_fib_lookup and bpf_skb_fib_lookup) > > can perform MTU check and return BPF_FIB_LKUP_RET_FRAG_NEEDED. The BPF-prog > > don't know the MTU value that caused this rejection. > > > > If the BPF-prog wants to implement PMTU (Path MTU Discovery) (rfc1191) it > > need to know this MTU value for the ICMP packet. > > > > Patch change lookup and result struct bpf_fib_lookup, to contain this MTU > > value as output via a union with 'tot_len' as this is the value used for > > the MTU lookup. > > > > V5: > > - Fixed uninit value spotted by Dan Carpenter. > > - Name struct output member mtu_result > > > > Reported-by: kernel test robot <lkp@intel.com> > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com> > > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> > > --- > > include/uapi/linux/bpf.h | 11 +++++++++-- > > net/core/filter.c | 22 +++++++++++++++------- > > tools/include/uapi/linux/bpf.h | 11 +++++++++-- > > 3 files changed, 33 insertions(+), 11 deletions(-) > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > > index e6ceac3f7d62..01b2b17c645a 100644 > > --- a/include/uapi/linux/bpf.h > > +++ b/include/uapi/linux/bpf.h > > @@ -2219,6 +2219,9 @@ union bpf_attr { > > * * > 0 one of **BPF_FIB_LKUP_RET_** codes explaining why the > > * packet is not forwarded or needs assist from full stack > > * > > + * If lookup fails with BPF_FIB_LKUP_RET_FRAG_NEEDED, then the MTU > > + * was exceeded and result params->mtu contains the MTU. > > + * > > Do we need to hide this behind a flag? It seems otherwise you might confuse > users. I imagine on error we could reuse the params arg, but now we changed > the tot_len value underneath them? The principle behind this bpf_fib_lookup helper, is that params (struct bpf_fib_lookup) is used for both input and output (results). Almost every field is change after the lookup. (For performance reasons this is kept at 64 bytes (cache-line)) Thus, users of this helper already expect/knows the contents of params have changed.
On 11/2/20 2:28 AM, Jesper Dangaard Brouer wrote: >>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h >>> index e6ceac3f7d62..01b2b17c645a 100644 >>> --- a/include/uapi/linux/bpf.h >>> +++ b/include/uapi/linux/bpf.h >>> @@ -2219,6 +2219,9 @@ union bpf_attr { >>> * * > 0 one of **BPF_FIB_LKUP_RET_** codes explaining why the >>> * packet is not forwarded or needs assist from full stack >>> * >>> + * If lookup fails with BPF_FIB_LKUP_RET_FRAG_NEEDED, then the MTU >>> + * was exceeded and result params->mtu contains the MTU. >>> + * >> >> Do we need to hide this behind a flag? It seems otherwise you might confuse >> users. I imagine on error we could reuse the params arg, but now we changed >> the tot_len value underneath them? > > The principle behind this bpf_fib_lookup helper, is that params (struct > bpf_fib_lookup) is used for both input and output (results). Almost > every field is change after the lookup. (For performance reasons this > is kept at 64 bytes (cache-line)) Thus, users of this helper already > expect/knows the contents of params have changed. > yes, that was done on purpose. Jesper: you should remove the '(if requested check_mtu)' comment in the documentation. That is an internal flag only -- xdp is true, tc is false.
David Ahern wrote: > On 11/2/20 2:28 AM, Jesper Dangaard Brouer wrote: > >>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > >>> index e6ceac3f7d62..01b2b17c645a 100644 > >>> --- a/include/uapi/linux/bpf.h > >>> +++ b/include/uapi/linux/bpf.h > >>> @@ -2219,6 +2219,9 @@ union bpf_attr { > >>> * * > 0 one of **BPF_FIB_LKUP_RET_** codes explaining why the > >>> * packet is not forwarded or needs assist from full stack > >>> * > >>> + * If lookup fails with BPF_FIB_LKUP_RET_FRAG_NEEDED, then the MTU > >>> + * was exceeded and result params->mtu contains the MTU. > >>> + * > >> > >> Do we need to hide this behind a flag? It seems otherwise you might confuse > >> users. I imagine on error we could reuse the params arg, but now we changed > >> the tot_len value underneath them? > > > > The principle behind this bpf_fib_lookup helper, is that params (struct > > bpf_fib_lookup) is used for both input and output (results). Almost > > every field is change after the lookup. (For performance reasons this > > is kept at 64 bytes (cache-line)) Thus, users of this helper already > > expect/knows the contents of params have changed. > > > > yes, that was done on purpose. OK sounds good then. Thanks. > > Jesper: you should remove the '(if requested check_mtu)' comment in the > documentation. That is an internal flag only -- xdp is true, tc is false.
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index e6ceac3f7d62..01b2b17c645a 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -2219,6 +2219,9 @@ union bpf_attr { * * > 0 one of **BPF_FIB_LKUP_RET_** codes explaining why the * packet is not forwarded or needs assist from full stack * + * If lookup fails with BPF_FIB_LKUP_RET_FRAG_NEEDED, then the MTU + * was exceeded and result params->mtu contains the MTU. + * * long bpf_sock_hash_update(struct bpf_sock_ops *skops, struct bpf_map *map, void *key, u64 flags) * Description * Add an entry to, or update a sockhash *map* referencing sockets. @@ -4872,9 +4875,13 @@ struct bpf_fib_lookup { __be16 sport; __be16 dport; - /* total length of packet from network header - used for MTU check */ - __u16 tot_len; + union { /* used for MTU check */ + /* input to lookup */ + __u16 tot_len; /* total length of packet from network hdr */ + /* output: MTU value (if requested check_mtu) */ + __u16 mtu_result; + }; /* input: L3 device index for lookup * output: device index from FIB lookup */ diff --git a/net/core/filter.c b/net/core/filter.c index 1ee97fdeea64..edb543c477b6 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -5265,12 +5265,14 @@ static const struct bpf_func_proto bpf_skb_get_xfrm_state_proto = { #if IS_ENABLED(CONFIG_INET) || IS_ENABLED(CONFIG_IPV6) static int bpf_fib_set_fwd_params(struct bpf_fib_lookup *params, const struct neighbour *neigh, - const struct net_device *dev) + const struct net_device *dev, u32 mtu) { memcpy(params->dmac, neigh->ha, ETH_ALEN); memcpy(params->smac, dev->dev_addr, ETH_ALEN); params->h_vlan_TCI = 0; params->h_vlan_proto = 0; + if (mtu) + params->mtu_result = mtu; /* union with tot_len */ return 0; } @@ -5286,8 +5288,8 @@ static int bpf_ipv4_fib_lookup(struct net *net, struct bpf_fib_lookup *params, struct net_device *dev; struct fib_result res; struct flowi4 fl4; + u32 mtu = 0; int err; - u32 mtu; dev = dev_get_by_index_rcu(net, params->ifindex); if (unlikely(!dev)) @@ -5354,8 +5356,10 @@ static int bpf_ipv4_fib_lookup(struct net *net, struct bpf_fib_lookup *params, if (check_mtu) { mtu = ip_mtu_from_fib_result(&res, params->ipv4_dst); - if (params->tot_len > mtu) + if (params->tot_len > mtu) { + params->mtu_result = mtu; /* union with tot_len */ return BPF_FIB_LKUP_RET_FRAG_NEEDED; + } } nhc = res.nhc; @@ -5389,7 +5393,7 @@ static int bpf_ipv4_fib_lookup(struct net *net, struct bpf_fib_lookup *params, if (!neigh) return BPF_FIB_LKUP_RET_NO_NEIGH; - return bpf_fib_set_fwd_params(params, neigh, dev); + return bpf_fib_set_fwd_params(params, neigh, dev, mtu); } #endif @@ -5406,7 +5410,7 @@ static int bpf_ipv6_fib_lookup(struct net *net, struct bpf_fib_lookup *params, struct flowi6 fl6; int strict = 0; int oif, err; - u32 mtu; + u32 mtu = 0; /* link local addresses are never forwarded */ if (rt6_need_strict(dst) || rt6_need_strict(src)) @@ -5481,8 +5485,10 @@ static int bpf_ipv6_fib_lookup(struct net *net, struct bpf_fib_lookup *params, if (check_mtu) { mtu = ipv6_stub->ip6_mtu_from_fib6(&res, dst, src); - if (params->tot_len > mtu) + if (params->tot_len > mtu) { + params->mtu_result = mtu; /* union with tot_len */ return BPF_FIB_LKUP_RET_FRAG_NEEDED; + } } if (res.nh->fib_nh_lws) @@ -5502,7 +5508,7 @@ static int bpf_ipv6_fib_lookup(struct net *net, struct bpf_fib_lookup *params, if (!neigh) return BPF_FIB_LKUP_RET_NO_NEIGH; - return bpf_fib_set_fwd_params(params, neigh, dev); + return bpf_fib_set_fwd_params(params, neigh, dev, mtu); } #endif @@ -5571,6 +5577,8 @@ BPF_CALL_4(bpf_skb_fib_lookup, struct sk_buff *, skb, dev = dev_get_by_index_rcu(net, params->ifindex); if (!is_skb_forwardable(dev, skb)) rc = BPF_FIB_LKUP_RET_FRAG_NEEDED; + + params->mtu_result = dev->mtu; /* union with tot_len */ } return rc; diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index e6ceac3f7d62..01b2b17c645a 100644 --- a/tools/include/uapi/linux/bpf.h +++ b/tools/include/uapi/linux/bpf.h @@ -2219,6 +2219,9 @@ union bpf_attr { * * > 0 one of **BPF_FIB_LKUP_RET_** codes explaining why the * packet is not forwarded or needs assist from full stack * + * If lookup fails with BPF_FIB_LKUP_RET_FRAG_NEEDED, then the MTU + * was exceeded and result params->mtu contains the MTU. + * * long bpf_sock_hash_update(struct bpf_sock_ops *skops, struct bpf_map *map, void *key, u64 flags) * Description * Add an entry to, or update a sockhash *map* referencing sockets. @@ -4872,9 +4875,13 @@ struct bpf_fib_lookup { __be16 sport; __be16 dport; - /* total length of packet from network header - used for MTU check */ - __u16 tot_len; + union { /* used for MTU check */ + /* input to lookup */ + __u16 tot_len; /* total length of packet from network hdr */ + /* output: MTU value (if requested check_mtu) */ + __u16 mtu_result; + }; /* input: L3 device index for lookup * output: device index from FIB lookup */
The BPF-helpers for FIB lookup (bpf_xdp_fib_lookup and bpf_skb_fib_lookup) can perform MTU check and return BPF_FIB_LKUP_RET_FRAG_NEEDED. The BPF-prog don't know the MTU value that caused this rejection. If the BPF-prog wants to implement PMTU (Path MTU Discovery) (rfc1191) it need to know this MTU value for the ICMP packet. Patch change lookup and result struct bpf_fib_lookup, to contain this MTU value as output via a union with 'tot_len' as this is the value used for the MTU lookup. V5: - Fixed uninit value spotted by Dan Carpenter. - Name struct output member mtu_result Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> --- include/uapi/linux/bpf.h | 11 +++++++++-- net/core/filter.c | 22 +++++++++++++++------- tools/include/uapi/linux/bpf.h | 11 +++++++++-- 3 files changed, 33 insertions(+), 11 deletions(-)