On Thu, Oct 07, 2021 at 11:25:29PM +0200, Daniel Borkmann wrote: > I tend to agree with Toke here that this is not generic. What has been tried > to improve the verifier instead before submitting the series? It would be much > more preferable to improve the developer experience with regards to a generic > solution, so that other/similar problems can be tackled in one go as well such > as IP options, extension headers, etc. It would be nice to improve verifier to recognize it more smoothly. Would love to hear idea how to do it. When adding the tcp header options for bpf_sockops, a bpf_store_hdr_opt() is needed to ensure the header option is sane. When writing test to parse variable length header option, I also pulled in tricks (e.g. "#pragma unroll" is easier to get it work. Tried bounded loop but then hits max insns and then moved some cases into subprog...etc). Most (if not all) TCP headers has some options (e.g. tstamp), so it will be useful to have an easy way to search a particular option and bpf_load_hdr_opt() was also added to bpf_sockops. When bpf-tcp-hdr-opt was added, the initial use case was only useful in the TCP stack because it wants to change the behavior of a tcp_sock. When bpf allows to add tcp-hdr-opt easily at tcp stack, it opens up other use cases and one of them is to load-balance by the tcp-hdr-opt "server_id" in XDP [1]. The same user that writes the bpf_sockops prog to add/parse tcp-opt needs to do extra tricks to get this work in xdp prog. The user had repeated a similar try-and-error exercise (e.g. while the logical thinking is to somehow bounded by the max tcp header size but that does not work in unroll. With the current cases in the loop, 15 is the max magic number that works and hoping it will continue to work). [1]: https://linuxplumbersconf.org/event/11/contributions/950/
