[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpVGm_Mz-yYUhhvn+p8H7mXHWHAuBNfyNj-251eY3Vr9iA@mail.gmail.com>
Date: Wed, 4 Nov 2020 22:04:38 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Yunsheng Lin <linyunsheng@...wei.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,
John Fastabend <john.fastabend@...il.com>,
Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH v2 net] net: sch_generic: aviod concurrent reset and
enqueue op for lockless qdisc
On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin <linyunsheng@...wei.com> wrote:
> >> From my understanding, we can do anything about the old qdisc (including
> >> destorying the old qdisc) after some_qdisc_is_busy() return false.
> >
> > But the current code does the reset _before_ some_qdisc_is_busy(). ;)
>
> If lock is taken when doing reset, it does not matter if the reset is
> before some_qdisc_is_busy(), right?
Why not? How about the following scenario?
CPU0: CPU1:
dev_reset_queue()
net_tx_action()
-> sch_direct_xmit()
-> dev_requeue_skb()
some_qdisc_is_busy()
// waiting for TX action on CPU1
// now some packets are requeued
Powered by blists - more mailing lists