On 10/31/16 6:37 PM, Thomas Graf wrote: > Register two new BPF prog types BPF_PROG_TYPE_LWT_IN and > BPF_PROG_TYPE_LWT_OUT which are invoked if a route contains a > LWT redirection of type LWTUNNEL_ENCAP_BPF. > > The separate program types are required because manipulation of > packet data is only allowed on the output and transmit path as > the subsequent dst_input() call path assumes an IP header > validated by ip_rcv(). The BPF programs will be handed an skb > with the L3 header attached and may return one of the following > return codes: > > BPF_OK - Continue routing as per nexthop > BPF_DROP - Drop skb and return EPERM > BPF_REDIRECT - Redirect skb to device as per redirect() helper. > (Only valid on lwtunnel_xmit() hook) > > The return codes are binary compatible with their TC_ACT_ > relatives to ease compatibility. > > A new helper bpf_skb_push() is added which allows to preprend an > L2 header in front of the skb, extend the existing L3 header, or > both. This allows to address a wide range of issues: > - Optimize L2 header construction when L2 information is always > static to avoid ARP/NDisc lookup. > - Extend IP header to add additional IP options. > - Perform simple encapsulation where offload is of no concern. > (The existing funtionality to attach a tunnel key to the skb > and redirect to a tunnel net_device to allow for offload > continues to work obviously).
have you tested the adding of headers with large packets hitting gso and fragmentation? Wondering if mtu is used properly when headers are added and the lwt->headroom is not accounted. See 14972cbd34ff668c390cbd2e6497323484c9e812
