[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090225.040130.169376412.davem@davemloft.net>
Date: Wed, 25 Feb 2009 04:01:30 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: nhorman@...driver.com
Cc: herbert@...dor.apana.org.au, shemminger@...tta.com,
netdev@...r.kernel.org, kuznet@....inr.ac.ru, pekkas@...core.fi,
jmorris@...ei.org, yoshfuji@...ux-ipv6.org
Subject: Re: [RFC] addition of a dropped packet notification service
From: Neil Horman <nhorman@...driver.com>
Date: Wed, 25 Feb 2009 06:54:19 -0500
> I had actually started down this road for awhile, and liked it for
> its low maintenence overhead (as you mentioned, less to annotate),
> but I balked at it after a bit, mostly for its increased ambiguity.
> By catching the drop where the packet is freed, we lose information
> about the exact point at which we decided to drop it. As such,
> users of said dumped table loose (or potentially lose) the ability
> to correlate the saved stack pointer with an exact point in the code
> where a corresponding statistic was incremented, as well as the
> correlation to a specific point in the code (they just get the
> calling function program counter rather than file, funciton and line
> number).
Userland tools can extract this information from a non-stripped
kernel image file, given just a kernel PC value.
And you need the same thing to extract the same information
if you used tracepoints.
--
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