On Tue, Mar 26, 2024 at 9:18 PM Eric Dumazet [off-list ref] wrote:

On Tue, Mar 26, 2024 at 11:44 AM Jason Xing [off-list ref] wrote:

quoted

Well, it's a pity that it seems that we are about to abandon this
method but it's not that friendly to the users who are unable to
deploy BPF...

It is a pity these tracepoint patches are consuming a lot of reviewer
time, just because
some people 'can not deploy BPF'

Sure, not everyone can do this easily. The phenomenon still exists and
we cannot ignore it. Do you remember that about a month ago someone
submitted one patch introducing a new tracepoint and then I replied
to/asked you if it's necessary that we replace most of the tracepoints
with BPF? Now I realise and accept the fact...

I'll keep reviewing such patches and hope it can give you maintainers
a break. I don't mind taking some time to do it, after all it's not a
bad thing to help some people.

Well, I came up with more ideas about how to improve the

quoted

trace function in recent days. The motivation of doing this is that I
encountered some issues which could be traced/diagnosed by using trace
effortlessly without writing some bpftrace codes again and again. The
status of trace seems not active but many people are still using it, I
believe.

'Writing bpftrace codes again and again' is not a good reason to add
maintenance costs
to linux networking stack.

I'm just saying :)