[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120206153807.GA3620@hmsreliant.think-freely.org>
Date: Mon, 6 Feb 2012 10:38:07 -0500
From: Neil Horman <nhorman@...driver.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: "Frank Ch. Eigler" <fche@...hat.com>,
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>,
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
On Mon, Feb 06, 2012 at 04:24:19PM +0100, Eric Dumazet wrote:
> Le lundi 06 février 2012 à 10:20 -0500, Frank Ch. Eigler a écrit :
>
> > > [...] 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?
>
> Anyway, this netfilter module wont catch the failed retransmits (because
> of memory allocation errors or other checks done in our stack)
>
But the existing kfree_skb tracepoint will. As will the TCPRETANSFAIL counter.
--
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