Re: [PATCH bpf-next V3 3/6] bpf: add BPF-helper for MTU checking

Lorenz Bauer
2020-10-12T15:55:04Z

On Thu, 8 Oct 2020 at 16:09, Jesper Dangaard Brouer <brouer@redhat.com> wrote:

...

> + * The *flags* argument can be a combination of one or more of the
> + * following values:
> + *
> + * **BPF_MTU_CHK_RELAX**
> + * This flag relax or increase the MTU with room for one
> + * VLAN header (4 bytes) and take into account net device
> + * hard_header_len. This relaxation is also used by the
> + * kernels own forwarding MTU checks.
> + *
> + * **BPF_MTU_CHK_GSO**
> + * This flag will only works for *ctx* **struct sk_buff**.
> + * If packet context contains extra packet segment buffers
> + * (often knows as frags), then those are also checked
> + * against the MTU size.

Maybe this is a documentation issue, but how / when am I expected to
use these flags? I'm really ignorant when it comes to GSO, but could
BPF_MTU_CHK_GSO be implied when the skb is using GSO?

> + *
> + * The *mtu_result* pointer contains the MTU value of the net
> + * device including the L2 header size (usually 14 bytes Ethernet
> + * header). The net device configured MTU is the L3 size, but as
> + * XDP and TX length operate at L2 this helper include L2 header
> + * size in reported MTU.

What does mtu_result represent in the GSO case? I can imagine there
being some funky interactions between skb->len and the return value,
depending on how this is defined.

> + *
> + * Return
> + * * 0 on success, and populate MTU value in *mtu_result* pointer.
> + *
> + * * < 0 if any input argument is invalid (*mtu_result* not updated)
> + *
> + * MTU violations return positive values, but also populate MTU
> + * value in *mtu_result* pointer, as this can be needed for
> + * implemeting PMTU handing:
> + *
> + * * **BPF_MTU_CHK_RET_FRAG_NEEDED**
> + * * **BPF_MTU_CHK_RET_GSO_TOOBIG**
> + *

--
Lorenz Bauer | Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK