Re: [PATCH RFC] rdma/ib: Add trace point macros to display human-readable values

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3049 bytes --]

On Wed, Nov 01, 2017 at 11:29:32AM -0400, Steven Rostedt wrote:
> On Wed, 1 Nov 2017 08:27:43 +0200
> Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 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-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> > > ---
> > >  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.

Thanks

>
> -- Steve
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]