On Thu, 8 Oct 2020 at 16:09, Jesper Dangaard Brouer <brouer@xxxxxxxxxx> 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 www.cloudflare.com
