From: Xuanqiang Luo <xuanqiang.luo@linux.dev>
To: Eric Dumazet <edumazet@google.com>
Cc: netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Dong Chenchen <dongchenchen2@huawei.com>,
David Ahern <dsahern@kernel.org>, Kees Cook <kees@kernel.org>,
linux-kernel@vger.kernel.org,
Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Subject: Re: [PATCH net-next v1] net: gro_cells: move backlog drop handling outside the local lock
Date: Tue, 15 Sep 2026 20:34:20 +0800 [thread overview]
Message-ID: <1ec16cd0-5fef-4068-9317-1ade03c0ded6@linux.dev> (raw)
In-Reply-To: <CANn89i+d4ny7K0QV-v+ZY6Kj735tPVrrzd0AzwRqe4vvu5r=aw@mail.gmail.com>
在 2026/9/15 20:26, Eric Dumazet 写道:
> On Tue, Sep 15, 2026 at 5:16 AM Xuanqiang Luo <xuanqiang.luo@linux.dev> wrote:
>>
>> From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
>>
>> When the GRO cell queue length exceeds max_backlog, gro_cells_receive()
>> holds bh_lock while updating the RX drop counter and freeing the rejected
>> skb. The skb has not been queued, and the counter is updated with
>> this_cpu_inc(), so neither operation requires the queue lock.
>>
>> Release bh_lock before accounting for and freeing the dropped skb to
>> shorten the critical section.
>
> local_lock_nested_bh() is only a real lock on PREEMPT_RT. On other
> kernels it is a lockdep assertion, so this patch generates the same
> code. And this is the backlog overflow path: by definition we are
> already dropping packets there. Shortening this "critical section"
> buys nothing measurable, and there is no benchmark in the changelog.
>
> Also, the result is harder to read than what it replaces: a label
> named "unlock" that actually drops the skb, falling through into
> "drop:", and a backward goto past the return. Three labels for a
> 20-line function.
>
> If you want to improve gro_cells_receive(), please add drop reasons
> instead: SKB_DROP_REASON_DEV_READY for the !IFF_UP case and
> SKB_DROP_REASON_CPU_BACKLOG for the overflow one. That actually helps
> people tracking down drops.
>
Thank you for the quick reply!
I see your point. I'll take another look.
Thanks,
Xuanqiang
>
>>
>> Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
>> ---
>> net/core/gro_cells.c | 24 ++++++++++++------------
>> 1 file changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/net/core/gro_cells.c b/net/core/gro_cells.c
>> index d8c0a28671201..f46cecd246aab 100644
>> --- a/net/core/gro_cells.c
>> +++ b/net/core/gro_cells.c
>> @@ -14,7 +14,6 @@ struct gro_cell {
>> int gro_cells_receive(struct gro_cells *gcells, struct sk_buff *skb)
>> {
>> struct net_device *dev = skb->dev;
>> - bool have_bh_lock = false;
>> struct gro_cell *cell;
>> int res;
>>
>> @@ -26,32 +25,33 @@ int gro_cells_receive(struct gro_cells *gcells, struct sk_buff *skb)
>>
>> if (!gcells->cells || skb_cloned(skb) || netif_elide_gro(dev)) {
>> res = netif_rx(skb);
>> - goto unlock;
>> + goto out_rcu;
>> }
>>
>> local_lock_nested_bh(&gcells->cells->bh_lock);
>> - have_bh_lock = true;
>> cell = this_cpu_ptr(gcells->cells);
>>
>> - if (skb_queue_len(&cell->napi_skbs) > READ_ONCE(net_hotdata.max_backlog)) {
>> -drop:
>> - dev_core_stats_rx_dropped_inc(dev);
>> - kfree_skb(skb);
>> - res = NET_RX_DROP;
>> + if (skb_queue_len(&cell->napi_skbs) > READ_ONCE(net_hotdata.max_backlog))
>> goto unlock;
>> - }
>>
>> __skb_queue_tail(&cell->napi_skbs, skb);
>> if (skb_queue_len(&cell->napi_skbs) == 1)
>> napi_schedule(&cell->napi);
>>
>> + local_unlock_nested_bh(&gcells->cells->bh_lock);
>> res = NET_RX_SUCCESS;
>>
>> -unlock:
>> - if (have_bh_lock)
>> - local_unlock_nested_bh(&gcells->cells->bh_lock);
>> +out_rcu:
>> rcu_read_unlock();
>> return res;
>> +
>> +unlock:
>> + local_unlock_nested_bh(&gcells->cells->bh_lock);
>> +drop:
>> + dev_core_stats_rx_dropped_inc(dev);
>> + kfree_skb(skb);
>> + res = NET_RX_DROP;
>> + goto out_rcu;
>> }
>> EXPORT_SYMBOL(gro_cells_receive);
>>
>>
>> base-commit: 1142eb185b05db61a78130890fc4ed268f4cb4e6
>> --
>> 2.43.0
>>
prev parent reply other threads:[~2026-09-15 12:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 12:14 Xuanqiang Luo
2026-09-15 12:26 ` Eric Dumazet
2026-09-15 12:34 ` Xuanqiang Luo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1ec16cd0-5fef-4068-9317-1ade03c0ded6@linux.dev \
--to=xuanqiang.luo@linux.dev \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=dongchenchen2@huawei.com \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luoxuanqiang@kylinos.cn \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®