[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080807100910.GA12391@ff.dom.local>
Date: Thu, 7 Aug 2008 10:09:10 +0000
From: Jarek Poplawski <jarkao2@...il.com>
To: David Miller <davem@...emloft.net>
Cc: jussi.kivilinna@...et.fi, kaber@...sh.net, netdev@...r.kernel.org
Subject: Re: qdisc_enqueue, NET_XMIT_SUCCESS and kfree_skb
On Wed, Aug 06, 2008 at 10:09:11PM -0700, David Miller wrote:
> From: David Miller <davem@...emloft.net>
> Date: Wed, 06 Aug 2008 20:26:36 -0700 (PDT)
>
> >
> > I still haven't seen anyone suggest creating a __NET_XMIT_KFREE_SKB to
> > fix this most rediculious problem.
> >
> > I'm still waiting...
>
> Here is what it might look like. I haven't tried to boot this,
> but the only non-trivial case was SFQ's congestion drop code.
After some checking it looks mostly OK to me, but one thing: in
sch_gred gred_drop() calls qdisc_drop(), so now it needs kfree_skb().
BTW, maybe it would be nicer to add __qdisc_drop() for these new
things?
There is also some doubt about differences between ->enqueue() and
->requeue() wrt. kfree_skb() and returning codes: maybe it would be
better (for uniformity) to add similar changes to requeues (and
dev_requeue_skb()) as well?
I don't know if it's worth to mention, but now, if somebody really
uses this sch_blackhole under some upper qdiscs the stats will change.
Jarek P.
--
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