Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1099358pxj; Sat, 15 May 2021 03:58:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzNz4wSQFaFsR+bWYvWXrkm2m1mA0TbFEPJmkrqvo5SAOWdd8YOCcVoFweWY7u9cNuQtT4i X-Received: by 2002:a92:b106:: with SMTP id t6mr45569676ilh.99.1621076317883; Sat, 15 May 2021 03:58:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621076317; cv=none; d=google.com; s=arc-20160816; b=A8DuAayzYoR5rozK4IyXfLTzjzHor/vPN/qDqTj6qih9CJ2eLmyZ0l7oSTpTe+Fala 0gvMeEWK1P7XlVrE6OQx9Td7DOQg7yiv8wM55xRxNeiQV5mmXJHfNkvHvI4jr2wpzZ4w AYdetyOUMHTW+5VG5eszYkG+Vnxxt/7fybqfFbi+f6ORHJ8Dce63X3T+Rlb2yLLFsJbW lJKeh+QLdHceFscS8K9jWVT9yahR+AlOYPXoN7+M+Z1cKRP0gTrFj19xHeT7Ua0Qxnsw cxubGv0uts5GOhjCDVHoBvQrfowHO4TrjAXLYxr5OdKhegReILJTYhZYM5NUXnmPInjE 8SVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=TtCksPVpzMJoTfX+nrL46b7oWOl0kpgD55AVLNQTumk=; b=P+vkNMFnxedonFwVDVYmJXEMqImnLERqch42N5XcA14QF+EQeFFAfkfhr6O50u7mG4 hBjphp+pwsSSXb02XpShYhsPmpEGiaJUsr0hEJPMZpPtxMi68o815L8rnkwwl+GYy7zc Nm7jTuhgUT3IHR/j/p8iMr8dttISbK/qbTIf392+OBkChA3YbPiPHkCPYo8ju17uRycz N+xcqxkG6cpzIAz3Dyz8H05cZKYCYVUHq01tYiYHc4pIcxtFQzcoAhuFO8gzj1TwehIH UgBsk382QHPHwnXLF6kK848S3A/pXZ/uUOtWiRNZoUaS1kgLM1+85zZDneKk+XlHlEUQ Pwzg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b24si10253427jar.82.2021.05.15.03.58.25; Sat, 15 May 2021 03:58:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235460AbhEOC0l (ORCPT + 99 others); Fri, 14 May 2021 22:26:41 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:2986 "EHLO szxga06-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232297AbhEOC0k (ORCPT ); Fri, 14 May 2021 22:26:40 -0400 Received: from dggems705-chm.china.huawei.com (unknown [172.30.72.58]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4Fhq1s0Z3Vzlbrx; Sat, 15 May 2021 10:23:13 +0800 (CST) Received: from dggpemm500005.china.huawei.com (7.185.36.74) by dggems705-chm.china.huawei.com (10.3.19.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Sat, 15 May 2021 10:25:26 +0800 Received: from [127.0.0.1] (10.69.30.204) by dggpemm500005.china.huawei.com (7.185.36.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Sat, 15 May 2021 10:25:25 +0800 Subject: Re: [PATCH net v8 1/3] net: sched: fix packet stuck problem for lockless qdisc To: Jakub Kicinski , Cong Wang CC: David Miller , Vladimir Oltean , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eric Dumazet , "Wei Wang" , "Cong Wang ." , Taehee Yoo , Linux Kernel Network Developers , LKML , , Marc Kleine-Budde , , Jamal Hadi Salim , Jiri Pirko , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , , bpf , Jonas Bonn , Paolo Abeni , Michael Zhivich , Josh Hunt , Jike Song , Kehuan Feng , Ahmad Fatoum , , Alexander Duyck , "Hillf Danton" , , , "Michal Kubecek" , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Alexander Lobakin References: <1620959218-17250-1-git-send-email-linyunsheng@huawei.com> <1620959218-17250-2-git-send-email-linyunsheng@huawei.com> <20210514163923.53f39888@kicinski-fedora-PC1C0HJN> <20210514171759.5572c8f0@kicinski-fedora-PC1C0HJN> From: Yunsheng Lin Message-ID: Date: Sat, 15 May 2021 10:25:25 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20210514171759.5572c8f0@kicinski-fedora-PC1C0HJN> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.69.30.204] X-ClientProxiedBy: dggeme718-chm.china.huawei.com (10.1.199.114) To dggpemm500005.china.huawei.com (7.185.36.74) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/5/15 8:17, Jakub Kicinski wrote: > On Fri, 14 May 2021 16:57:29 -0700 Cong Wang wrote: >> On Fri, May 14, 2021 at 4:39 PM Jakub Kicinski wrote: >>> >>> On Fri, 14 May 2021 16:36:16 -0700 Cong Wang wrote: >> [...] >>>> >>>> We have test_and_clear_bit() which is atomic, test_bit()+clear_bit() >>>> is not. >>> >>> It doesn't have to be atomic, right? I asked to split the test because >>> test_and_clear is a locked op on x86, test by itself is not. >> >> It depends on whether you expect the code under the true condition >> to run once or multiple times, something like: >> >> if (test_bit()) { >> clear_bit(); >> // this code may run multiple times >> } >> >> With the atomic test_and_clear_bit(), it only runs once: >> >> if (test_and_clear_bit()) { >> // this code runs once >> } I am not sure if the above really matter when the test and clear does not need to be atomic. In order for the above to happens, the MISSED has to set between test and clear, right? >> >> This is why __netif_schedule() uses test_and_set_bit() instead of >> test_bit()+set_bit(). I think test_and_set_bit() is needed in __netif_schedule() mainly because STATE_SCHED is also used to indicate if the qdisc is in sd->output_queue, so it has to be atomic. > > Thanks, makes sense, so hopefully the MISSED-was-set case is not common > and we can depend on __netif_schedule() to DTRT, avoiding the atomic op > in the common case. > > . >