[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZXIQ9FCfUV1Fvr_A@C02YVCJELVCG.dhcp.broadcom.net>
Date: Thu, 7 Dec 2023 13:37:40 -0500
From: Andy Gospodarek <andrew.gospodarek@...adcom.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Michael Chan <michael.chan@...adcom.com>, davem@...emloft.net,
netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com,
Sreekanth Reddy <sreekanth.reddy@...adcom.com>,
Somnath Kotur <somnath.kotur@...adcom.com>,
Andy Gospodarek <andrew.gospodarek@...adcom.com>,
Vikas Gupta <vikas.gupta@...adcom.com>
Subject: Re: [PATCH net v2 2/4] bnxt_en: Fix skb recycling logic in
bnxt_deliver_skb()
On Thu, Dec 07, 2023 at 10:21:44AM -0800, Jakub Kicinski wrote:
> On Wed, 6 Dec 2023 16:05:49 -0800 Michael Chan wrote:
> > Receive SKBs can go through the VF-rep path or the normal path.
> > skb_mark_for_recycle() is only called for the normal path. Fix it
> > to do it for both paths to fix possible stalled page pool shutdown
> > errors.
>
> This patch is probably fine, but since I'm complaining -
> IMHO it may be better to mark the skbs right after they
> are allocated. Catching all "exit points" seems very error
> prone...
That's a good suggestion. To take it a step further...what about a
third arg (bool) to build_skb that would automatically call
skb_mark_for_recycle if the new 3rd arg was true? I don't love the
extra arg, but that would avoid duplicating the need to call
skb_mark_for_recycle for all drivers that use the page pool for all
data.
Powered by blists - more mailing lists