[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6984825d-1ef7-bf58-75fe-cee1bafe3c1a@huawei.com>
Date: Wed, 2 Sep 2020 16:14:48 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Eric Dumazet <eric.dumazet@...il.com>,
Cong Wang <xiyou.wangcong@...il.com>
CC: Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>,
"David Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
"Linux Kernel Network Developers" <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, <linuxarm@...wei.com>
Subject: Re: [PATCH net-next] net: sch_generic: aviod concurrent reset and
enqueue op for lockless qdisc
On 2020/9/2 15:32, Eric Dumazet wrote:
>
>
> On 9/1/20 11:34 PM, Yunsheng Lin wrote:
>
>>
>> I am not familiar with TCQ_F_CAN_BYPASS.
>> From my understanding, the problem is that there is no order between
>> qdisc enqueuing and qdisc reset.
>
> Thw qdisc_reset() should be done after rcu grace period, when there is guarantee no enqueue is in progress.
>
> qdisc_destroy() already has a qdisc_reset() call, I am not sure why qdisc_deactivate() is also calling qdisc_reset()
That is a good point.
Do we allow skb left in qdisc when the qdisc is deactivated state?
And qdisc_destroy() is not always called after qdisc_deactivate() is called.
If we allow skb left in qdisc when the qdisc is deactivated state, then it is
huge change of semantics for qdisc_deactivate(), and I am not sure how many
cases will affected by this change.
>
>
>
Powered by blists - more mailing lists