On 12/3/18 5:00 PM, David Miller wrote: > From: Toke Høiland-Jørgensen <t...@toke.dk> > Date: Mon, 03 Dec 2018 22:00:32 +0200 > >> I wonder if it would be possible to support both the "give me user >> normal stats" case and the "let me do whatever I want" case by a >> combination of userspace tooling and maybe a helper or two? >> >> I.e., create a "do_stats()" helper (please pick a better name), which >> will either just increment the desired counters, or set a flag so the >> driver can do it at napi poll exit. With this, the userspace tooling >> could have a "--give-me-normal-stats" switch (or some other interface), >> which would inject a call instruction to that helper at the start of the >> program. >> >> This would enable the normal counters in a relatively painless way, >> while still letting people opt out if they don't want to pay the cost in >> terms of overhead. And having the userspace tooling inject the helper >> call helps support the case where the admin didn't write the XDP >> programs being loaded. >> >> Any reason why that wouldn't work? > > I think this is a good idea, or even an attribute tag that gets added > to the XDP program that controls stats handling. >
My argument is that the ebpf program writer should *not* get that choice; the admin of the box should. Program writers make mistakes. Box admins / customer support are the ones that have to deal with those mistakes. Program writers - especially for xdp - are going to be focused on benchmarks; admins are focused on the big picture and should be given the option of trading a small amount of performance for simpler management. So, instead of a program tag which the program writer controls, how about some config knob that an admin controls that says at attach time use standard stats?
