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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 C5D97C43331 for ; Wed, 17 Mar 2021 00:46:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A347A64F94 for ; Wed, 17 Mar 2021 00:46:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229784AbhCQApr (ORCPT ); Tue, 16 Mar 2021 20:45:47 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:3365 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229699AbhCQApW (ORCPT ); Tue, 16 Mar 2021 20:45:22 -0400 Received: from DGGEMM404-HUB.china.huawei.com (unknown [172.30.72.53]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4F0WbL65njz5d03; Wed, 17 Mar 2021 08:42:54 +0800 (CST) Received: from dggpemm500005.china.huawei.com (7.185.36.74) by DGGEMM404-HUB.china.huawei.com (10.3.20.212) with Microsoft SMTP Server (TLS) id 14.3.498.0; Wed, 17 Mar 2021 08:45:17 +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.2106.2; Wed, 17 Mar 2021 08:45:17 +0800 Subject: Re: [PATCH net-next] net: sched: remove unnecessay lock protection for skb_bad_txq/gso_skb To: David Miller CC: , , , , , , References: <1615800610-34700-1-git-send-email-linyunsheng@huawei.com> <20210315.164151.1093629330365238718.davem@redhat.com> <1fea8225-69b0-5a73-0e9d-f5bfdecdc840@huawei.com> <20210316.144533.1015318495899101097.davem@davemloft.net> From: Yunsheng Lin Message-ID: <441a41d4-b547-6c30-f9a8-f76604293215@huawei.com> Date: Wed, 17 Mar 2021 08:45:17 +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: <20210316.144533.1015318495899101097.davem@davemloft.net> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.69.30.204] X-ClientProxiedBy: dggeme707-chm.china.huawei.com (10.1.199.103) 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/3/17 5:45, David Miller wrote: > From: Yunsheng Lin > Date: Tue, 16 Mar 2021 10:40:56 +0800 > >> On 2021/3/16 7:41, David Miller wrote: >>> From: Yunsheng Lin >> >> At least for the fast path, taking two locks for lockless qdisc hurts >> performance when handling requeued skb, especially if the lockless >> qdisc supports TCQ_F_CAN_BYPASS. > > The bad txq and gro skb cases are not "fast path", sorry You are right, it is more of exceptional data path, but it is still ok to clean that up without obvious risk, right? For I am going to replace qdisc->seqlock with qdisc_lock(q) for lockless qdisc too and remove qdisc->seqlock, which makes more sense. > > . >