From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0FC7C433B4 for ; Tue, 6 Apr 2021 07:31:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8999B613B7 for ; Tue, 6 Apr 2021 07:31:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244315AbhDFHbZ (ORCPT ); Tue, 6 Apr 2021 03:31:25 -0400 Received: from mx2.suse.de ([195.135.220.15]:43328 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233476AbhDFHbY (ORCPT ); Tue, 6 Apr 2021 03:31:24 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 584DAAE6D; Tue, 6 Apr 2021 07:31:16 +0000 (UTC) Received: by lion.mk-sys.cz (Postfix, from userid 1000) id AC7EE60441; Tue, 6 Apr 2021 09:31:15 +0200 (CEST) Date: Tue, 6 Apr 2021 09:31:15 +0200 From: Michal Kubecek To: Yunsheng Lin Cc: Cong Wang , Jiri Kosina , Hillf Danton , John Fastabend , Paolo Abeni , Kehuan Feng , Jike Song , Michael Zhivich , David Miller , LKML , Netdev , Josh Hunt , "Jason A. Donenfeld" , Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Subject: Re: Packet gets stuck in NOLOCK pfifo_fast qdisc Message-ID: <20210406073115.3h6zehyteagav3f7@lion.mk-sys.cz> References: <5f51cbad3cc2_3eceb208fc@john-XPS-13-9370.notmuch> <20210403003537.2032-1-hdanton@sina.com> <2b99fce1-c235-6083-bd39-cece1f4a0343@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2b99fce1-c235-6083-bd39-cece1f4a0343@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 06, 2021 at 10:46:29AM +0800, Yunsheng Lin wrote: > On 2021/4/6 9:49, Cong Wang wrote: > > On Sat, Apr 3, 2021 at 5:23 AM Jiri Kosina wrote: > >> > >> I am still planning to have Yunsheng Lin's (CCing) fix [1] tested in the > >> coming days. If it works, then we can consider proceeding with it, > >> otherwise I am all for reverting the whole NOLOCK stuff. > >> > >> [1] https://lore.kernel.org/linux-can/1616641991-14847-1-git-send-email-linyunsheng@huawei.com/T/#u > > > > I personally prefer to just revert that bit, as it brings more troubles > > than gains. Even with Yunsheng's patch, there are still some issues. > > Essentially, I think the core qdisc scheduling code is not ready for > > lockless, just look at those NOLOCK checks in sch_generic.c. :-/ > > I am also awared of the NOLOCK checks too:), and I am willing to > take care of it if that is possible. > > As the number of cores in a system is increasing, it is the trend > to become lockless, right? Even there is only one cpu involved, the > spinlock taking and releasing takes about 30ns on our arm64 system > when CONFIG_PREEMPT_VOLUNTARY is enable(ip forwarding testing). I agree with the benefits but currently the situation is that we have a race condition affecting the default qdisc which is being hit in production and can cause serious trouble which is made worse by commit 1f3279ae0c13 ("tcp: avoid retransmits of TCP packets hanging in host queues") preventing the retransmits of the stuck packet being sent. Perhaps rather than patching over current implementation which requires more and more complicated hacks to work around the fact that we cannot make the "queue is empty" check and leaving the critical section atomic, it would make sense to reimplement it in a way which would allow us making it atomic. Michal