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 <l...@intel.com>
> Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
> Signed-off-by: Jesper Dangaard Brouer <bro...@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;
