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,URIBL_BLOCKED,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 3603BC433E0 for ; Mon, 22 Mar 2021 01:06:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 044DD61943 for ; Mon, 22 Mar 2021 01:06:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229920AbhCVBGE (ORCPT ); Sun, 21 Mar 2021 21:06:04 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:5100 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229771AbhCVBF2 (ORCPT ); Sun, 21 Mar 2021 21:05:28 -0400 Received: from DGGEML401-HUB.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4F3bpx2724zYMmV; Mon, 22 Mar 2021 09:03:37 +0800 (CST) Received: from dggpemm500005.china.huawei.com (7.185.36.74) by DGGEML401-HUB.china.huawei.com (10.3.17.32) with Microsoft SMTP Server (TLS) id 14.3.498.0; Mon, 22 Mar 2021 09:05:25 +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; Mon, 22 Mar 2021 09:05:25 +0800 Subject: Re: [Linuxarm] Re: [RFC v2] net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc To: "Jason A. Donenfeld" CC: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , Cong Wang , Jakub Kicinski , 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 , , Thomas Gschwantner References: <1615603667-22568-1-git-send-email-linyunsheng@huawei.com> <1615777818-13969-1-git-send-email-linyunsheng@huawei.com> <20210315115332.1647e92b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <87eegddhsj.fsf@toke.dk> <3bae7b26-9d7f-15b8-d466-ff5c26d08b35@huawei.com> From: Yunsheng Lin Message-ID: <50b730de-1546-144f-6cdf-3943de0a65ad@huawei.com> Date: Mon, 22 Mar 2021 09:05:24 +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: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.69.30.204] X-ClientProxiedBy: dggeme717-chm.china.huawei.com (10.1.199.113) To dggpemm500005.china.huawei.com (7.185.36.74) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2021/3/20 3:03, Jason A. Donenfeld wrote: > On Thu, Mar 18, 2021 at 1:33 AM Yunsheng Lin wrote: >>> That offer definitely still stands. Generalization sounds like a lot of fun. >>> >>> Keep in mind though that it's an eventually consistent queue, not an >>> immediately consistent one, so that might not match all use cases. It >>> works with wg because we always trigger the reader thread anew when it >>> finishes, but that doesn't apply to everyone's queueing setup. >> >> Thanks for mentioning this. >> >> "multi-producer, single-consumer" seems to match the lockless qdisc's >> paradigm too, for now concurrent enqueuing/dequeuing to the pfifo_fast's >> queues() is not allowed, it is protected by producer_lock or consumer_lock. > > The other thing is that if you've got memory for a ring buffer rather > than a list queue, we worked on an MPMC ring structure for WireGuard a > few years ago that we didn't wind up using in the end, but it lives > here: > https://git.zx2c4.com/wireguard-monolithic-historical/tree/src/mpmc_ptr_ring.h?h=tg/mpmc-benchmark Thanks for mentioning that, It seems that is exactly what the pfifo_fast qdisc need for locklees multi-producer, because it only need the memory to store the skb pointer. Does it have any limitation? More specifically, does it works with the process or softirq context, if not, how about context with rcu protection? > _______________________________________________ > Linuxarm mailing list -- linuxarm@openeuler.org > To unsubscribe send an email to linuxarm-leave@openeuler.org >