On Thu, Aug 04, 2022 at 10:03:58AM -0700, Stanislav Fomichev wrote: > > I am planning to refactor the bpf_getsockopt also, > > so trying to avoid adding more dup code at this point > > while they can directly be read from sk through PTR_TO_BTF_ID. > > > > btw, since we are on bpf_getsockopt(), do you still see a usage on > > bpf_getsockopt() for those 'integer-value' optnames that can be > > easily read from the sk pointer ? > > Writing is still done via bpf_setsockopt, so having the same interface > to read the settings seems useful? Make sense. It probably will have less surprise to have a symmetrical optname expectation on set/getsockopt. It will be cheaper to add to bpf_getsockopt() anyway once it is cleaned up. Asking because I just don't have new use case (adding optnames) to bpf_getsockopt() after the bpf_skc_to_*() helpers were introduced. > > > > + case SO_MARK: > > > > + *optval = sk->sk_mark; > > > > + break; > > > > > > SO_MARK should be handled by bpf_getsockopt ? > > Good point, will remove SO_MARK case. > > > > Thanks for the review!
