On Wed, 1 Nov 2017 08:27:43 +0200 Leon Romanovsky <leon@xxxxxxxxxx> wrote: > On Mon, Oct 30, 2017 at 06:01:23PM -0400, Chuck Lever wrote: > > These can be shared with all kernel ULPs, and more can easily be > > added as needed. > > > > Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> > > --- > > include/trace/events/rdma.h | 128 +++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 128 insertions(+) > > create mode 100644 include/trace/events/rdma.h > > > > Hi- > > > > I'm putting together a series of patches for v4.16 (or later) that > > add static ftrace trace points to the RPC-over-RDMA client imple- > > mentation. As part of that effort, I've constructed some trace point > > helpers that might be useful for other kernel ULPs. > > > > So far this patch adds just helpers that xprtrdma needs. It is not > > complete, but additional helpers can be introduced as they are > > needed. > > > > I'd like to hear comments about these, or please let me know if > > such helpers already exist and where xprtrdma can find them. > > Bart, Steve > > You attended the MS track, and for the rest of us, the quote below > sounds a little bit cryptic. Does the quote below mean that Chuck's > proposal is no-go? Actually, I wasn't invited to the Maintainer's Summit. Perhaps I should have been. > > From LWN.net "Another attempt to address the tracepoint ABI problem" [1] > > "The solution that was arrived at for now, as related by Torvalds, > is to hold off on adding explicit tracepoints to the kernel. Instead, > support will be added to make it easy for an application to attach a > BPF script to any function in the kernel, with access to that function's > arguments." > > [1] https://lwn.net/Articles/737530/ What I can tell you is what I talked to Linus about when I cornered him in the hallway. ;-) Basically, nothing has changed. If a maintainer is fine with trace events, then they can add new trace events. The issue is with the maintainers that don't want the possibility of having to maintain stale trace events because some tool depends on them and it becomes a burden in the future. This is mostly an issues with the scheduler and VFS. What Linus asked me to do is to build an infrastructure on top of ftrace, and make it easier to extract data from these "dynamic function trace events". I need to add easier use cases for eBPF because the usage of eBPF is still a large learning curve compared to the ease of accessing the current trace event infrastructure. I'll be working on this in the very near future, but I don't expect anything to be useful for within a year's time. Thus, continue doing what you have been doing, and hopefully in a year we will be able to extract more data from the kernel from anywhere a function is traced. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
