On Sat, Jun 27, 2020 at 10:17:26AM -0700, Eric Dumazet wrote: [ ... ] > It seems strange that we want to add code in TCP stack only to cover a > limited use case (kind 254 and 0xEB9F magic) > > For something like the work Petar Penkov did (to be able to generate > SYNCOOKIES from XDP), we do not go through tcp_parse_options() and BPF > program > would have to implement its own parsing (without having an SKB at > hand), probably calling a helper function, with no > TCP_SKB_CB(skb)->bpf_hdr_opt_off. > > This patch is hard coding a specific option and will prevent anyone > using private option(s) from using this infrastructure in the future, > yet paying the extra overhead. There is a discussion in patch 4 about not limiting this patch set to option kind 254. That will affect the usefulness of bpf_hdr_opt_off. > > TCP_SKB_CB(skb) is tight, I would prefer keeping the space in it for > standard TCP stack features. > > If an optional BPF program needs to re-parse the TCP options to find a > specific option, maybe the extra cost is noise (especially if this is > only for SYN & SYNACK packets) ? > > Thanks
