[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120206162136.GJ27935@redhat.com>
Date: Mon, 6 Feb 2012 11:21:36 -0500
From: "Frank Ch. Eigler" <fche@...hat.com>
To: Neil Horman <nhorman@...driver.com>
Cc: Hagen Paul Pfeifer <hagen@...u.net>,
"Frank Ch. Eigler" <fche@...stic.org>,
Satoru Moriya <satoru.moriya@....com>,
David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"tgraf@...radead.org" <tgraf@...radead.org>,
"stephen.hemminger@...tta.com" <stephen.hemminger@...tta.com>,
"eric.dumazet@...il.com" <eric.dumazet@...il.com>,
Seiji Aguchi <seiji.aguchi@....com>, fche@...rceware.org,
mathieu.desnoyers@...ymtl.ca, rostedt@...dmis.org
Subject: Re: [PATCH v2 0/2] Tracepoint for tcp retransmission
Hi -
On Mon, Feb 06, 2012 at 10:53:05AM -0500, Neil Horman wrote:
> [...] If you're unfamiliar with them, netfilter hooks are those
> standard points in the network input/output/forwarding paths at
> which we can watch and maniupulate network traffic. [...]
Aha, nf_register_hook and friends. Thanks for the pointer.
> > 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?
> I suppose you could. [...] I'm suggesting a kernel module because
> then you wouldn't have the performance overhead of moving all those
> frames to user space.
(For what it's worth, if there were a tracepoint in the netfilter
hook machinery, stap would be able to process the packets likewise,
in-kernel, with no kernel debuginfo installed.)
- FChE
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists