[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1328541859.2220.52.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date: Mon, 06 Feb 2012 16:24:19 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: "Frank Ch. Eigler" <fche@...hat.com>
Cc: Neil Horman <nhorman@...driver.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
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)
--
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