On Fri, May 15, 2020 at 5:12 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > > > > libbpf supports kconfig values, so don't have to even probe for that, > > it will just appear as a constant global variable: > > > > extern unsigned long CONFIG_HZ __kconfig; > > > > But I assume you want this for iproute2 case, which doesn't support > > this, right? We really should try to make iproute2 just use libbpf as > > It's one but not the only reason. Our golang daemon picks up the json config > from `bpftool feature -j` and based on that we decide which features our BPF > datapath will have where the daemons needs to also adapt accordingly. So for > users running older kernels we need fallback behavior in our daemon, for > example, in case of missing LPM delete or get_next_key from syscall side the > LPM map management and/or program regeneration will differ in the agent. In > case of jiffies, it's also not as trivial from control plane side, e.g. > existing deployments cannot simply switch from ktime to jiffies during upgrade > while traffic is live in the datapath given this has upgrade and downgrade > implications on timeouts. However, we can switch to using it for new deployments > via helm. In that case, the agent today probes for availability, so it needs > to know i) whether the underlying kernel supports jiffies64 helper, ii) it needs > to know the kernel hz value in order to convert timeouts for our CT's GC. This > is done based on bpftool feature -j from the agent's probe manager. Next, we > also cannot assume general availability of an existing .config from distro side, > so in that case we run the probe to determine kernel hz and emit the CONFIG_HZ > define instead, and if all breaks down we fall back to using ktime in our data > path. From the macro side, the timeouts all resolve nicely during compilation > time since everything is passed as a constant here. We have a small helper for > bpf_jiffies_to_sec() and bpf_sec_to_jiffies() that resolves it whereas `extern > unsigned long CONFIG_HZ __kconfig` hapens at load time plus relies on the fact > that config must be available, although the latter could probably be fixed via > user-callback. fair enough. Applied to bpf-next. Thanks
