> > > > > > > > In addition I wrote a sample eBPF which shows how one can further > > > > filter at the tracepoints to distill the information being traced. > > > > > > I would like to hear definitive answer from RDMA maintainers - yes/no. > > > Will those tracepoints be declared as user space ABI? > > > > > > > To be clear I am not proposing any ABI here. And, I _think_, that is pretty > well documented in the eBPF tracepoint documentation. The patch I'm > submitting is a _sample_ of how one can (with a particular version of the > kernel) alter the data reported from, or change the logic around, the > tracepoints. > > Ira, > > I'm totally with you and would like to see more tracepoints used in our > subsystem, but latest shit storm related to changes hfi1 debugfs showed that > promises, documentation and agreement to change debugfs in any given > time are not worth a dime, once anyone from the crowd throws an "ABI" > word. + Denny I think this is a bit unfair. The HFI debugfs worked differently from the other devices and caused some confusion about what debugfs names would be presented and if there was a fundamental breakage of debugfs. That is hardly a "shit storm". I agree that having the name be consistent with names used elsewhere in the RDMA namespace (and/or some mapping to easily resolve the names) should be a goal going forward. Regardless, and more importantly, this is a totally different thing. eBPF sample _code_ is a long way from a tool which is dependent on this "ABI". Ira
