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 [PATCH net-next v1] net: gro_cells: move backlog drop handling outside the local lock 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.