On Mon, Mar 25, 2024 at 06:43:29PM -0700, Andrii Nakryiko wrote: SNIP > > I'll add bpf_modify_return_test_tp() to not touch all the tests using > > bpf_modify_return_test() and bpf_modify_return_test2(), if that's ok. > > Existing ones expect some memory pointer, dereference it, etc, it > > seems cleaner to have a dedicated tp-triggering one for this. > > > > > Exercise of test tracepoint can be there as well. > > > Asking bpf prog to call a kfunc to call a tracepoint > > > looks like extra hop. > > > Existing test_run facility should be able to accommodate. > > > > You mean if I add bpf_modify_return_test_tp() above, I should pass an > > argument of how many times that tracepoint should be triggered? Or you > > mean to use test_run's repeat argument to trigger "driver program" N > > times, and the driver program would just call > > bpf_modify_return_test_tp() once? If the latter, I'm not sure it's the > > same as calling the driver program once and doing a loop inside, as > > we'll measure more of calling driver program overhead (N times vs 1 > > time right now, per each N tp/fmod_ret calls). > > > > (But tbh, not having to use test_run's repeat functionality is a > > benefit, IMO, we can have more flexible counting/timing code and > > whatever else we might need, I'm not sure why using test_run's repeat > > is advantageous here) > > > > Not sure what you are trying to optimize for here, please clarify. > > > > So I currently have these changes. I moved tp into bpf_test_run.h > (didn't know we have that, this should eliminate the issue that Jiri > saw as well). Moved kfunc into net/bpf/test_run.c and renamed it to sorry I did not get to it yet.. will test the new version jirka
