[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <34612839.hAkXUcbKUQ@wuerfel>
Date: Wed, 10 Dec 2014 17:36:46 +0100
From: Arnd Bergmann <arnd@...db.de>
To: linux-arm-kernel@...ts.infradead.org
Cc: David Miller <davem@...emloft.net>, mark.rutland@....com,
devicetree@...r.kernel.org, f.fainelli@...il.com,
linux@....linux.org.uk, eric.dumazet@...il.com,
sergei.shtylyov@...entembedded.com, netdev@...r.kernel.org,
agraf@...e.de, xuwei5@...ilicon.com, David.Laight@...lab.com,
dingtianhong@...wei.com, zhangfei.gao@...aro.org
Subject: Re: [PATCH v8 3/3] net: hisilicon: new hip04 ethernet driver
On Wednesday 10 December 2014 11:07:32 David Miller wrote:
> From: Arnd Bergmann <arnd@...db.de>
> Date: Wed, 10 Dec 2014 10:35:20 +0100
>
> > On Wednesday 10 December 2014 14:45:29 Ding Tianhong wrote:
> >>
> >> Miss this code, I think the best way is skb_orphan(skb), just like the cxgb3 drivers, some hardware
> >> didn't use the tx inq to free dmad Tx packages.
> >
> > The problem with skb_orphan is that you are telling the network stack that
> > the packet is now out of its reach and it will no longer be able to take
> > queued packets into account.
>
> skb_orphan() also does not release netfilter resources attached to the
> packet.
>
> Really, all drivers must free TX SKBs in a small, finite, amount of
> time after submission.
>
> There is no way around this.
I see. Do you see a problem with returning early from napi->poll()
without calling napi_complete() when the TX queue remains full at
the end of the poll function?
Or is there any better alternative for broken hardware that lacks
a TX-complete interrupt?
Arnd
--
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