[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230802113755.4451c861@kernel.org>
Date: Wed, 2 Aug 2023 11:37:55 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Liang Chen <liangchen.linux@...il.com>
Cc: davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
ast@...nel.org, daniel@...earbox.net, john.fastabend@...il.com,
ilias.apalodimas@...aro.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] xdp: Fixing skb->pp_recycle flag in generic
XDP handling
On Wed, 2 Aug 2023 15:04:54 +0800 Liang Chen wrote:
> In the generic XDP processing flow, if an skb with a page pool page
> (skb->pp_recycle == 1) fails to meet XDP packet requirements, it will
> undergo head expansion and linearization of fragment data. As a result,
> skb->head points to a reallocated buffer without any fragments. At this
> point, the skb will not contain any page pool pages. However, the
> skb->pp_recycle flag is still set to 1, which is inconsistent with the
> actual situation. Although it doesn't seem to cause much real harm at the
> moment(a little nagetive impact on skb_try_coalesce), to avoid potential
> issues associated with using incorrect skb->pp_recycle information,
> setting skb->pp_recycle to 0 to reflect the pp state of the skb.
pp_recycle just means that the skb is "page pool aware", there's
absolutely no harm in having an skb with pp_recycle = 1 and no
page pool pages attached.
I vote not to apply this.
Powered by blists - more mailing lists