[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090225.140701.42567297.davem@davemloft.net>
Date: Wed, 25 Feb 2009 14:07:01 -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 09:18:41 -0500
> On Wed, Feb 25, 2009 at 04:01:30AM -0800, David Miller wrote:
> > From: Neil Horman <nhorman@...driver.com>
> > Date: Wed, 25 Feb 2009 06:54:19 -0500
> >
> > And you need the same thing to extract the same information
> > if you used tracepoints.
>
> Well, I think the above implementation can be done with or without
> tracepoints. The mechanism by which we get the drop information is
> orthogonal to what we do with it.
>
> Thanks for the feedback guys. I'll start modifying my kernel
> changes to reflect this striaght away. If you'd like to see
> something in the interim, let me know and I'll send you what I have.
> Currently I've got the user space delivery mechanism working as a
> Netlink protocol, and with your above suggestions, I expect to have
> the drop capture piece recode and working in the next few weeks.
Don't get me wrong.
If tracepoint annotations can be manageable (Herbert's concern), and
solve multiple useful problems in practice rather than just
theoretically (my concern), then that's what we should use for this
kind of stuff.
I just personally haven't been convinced of that yet.
--
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