Re: [PATCH v2 0/2] Tracepoint for tcp retransmission

["Frank Ch. Eigler" <fche@redhat.com>]

Hi, Neil -

On Sun, Feb 05, 2012 at 08:32:47PM -0500, Neil Horman wrote:

> [...]
> > Hey Neil, I though about this more deeply. In my first iteration I
> > had the same answer. But IMHO if you think about this more deeply,
> > I think this is not a scalable approach (implementing in userspace
> > as systemtap scripts compared to implement them in kernelspace
> > (tracepoints). Why? Because at a deep TCP level the API (and thus
> > the context) is not static and the meaning of return values (or
> > arguments) change over time. No matter _where_ it is implemented
> > or coded.

> Yes, this is why I'm suggesting alternatives to the tracepoint.

I believe Hagen's point was that alternatives to tracepoints would
have substantially the same difficulty.  At some point in the stack,
you have to standardize/abstract.  What you hook up *at that point* is
not too important: tracepoints, or function calls, or expanded perf
machinery all seem to have the same burden.


> [...] If something is needed in the short term for Satoru, I still
> think a privately maintained module that registers a netfilter hook
> to watch outgoing packets for retransmits offers a good solution.

Does this mean that this netfilter hook mechanism is sufficient to
adapt to the current/future diversity of behaviors?  Why not make
*that* into a tracepoint then, so perf/stap scripts could get at it in
userspace?


- FChE