From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 15002A0351; Wed, 22 Dec 2021 04:25:47 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 92AA840040; Wed, 22 Dec 2021 04:25:46 +0100 (CET) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by mails.dpdk.org (Postfix) with ESMTP id C21EA4003C for ; Wed, 22 Dec 2021 04:25:44 +0100 (CET) Received: from dggeme756-chm.china.huawei.com (unknown [172.30.72.57]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4JJdtK5Tn4z1DK26; Wed, 22 Dec 2021 11:22:33 +0800 (CST) Received: from [10.67.103.128] (10.67.103.128) by dggeme756-chm.china.huawei.com (10.3.19.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Wed, 22 Dec 2021 11:25:41 +0800 Subject: Re: [PATCH 3/7] net/bonding: change mbuf pool and ring allocation To: "Sanford, Robert" , Robert Sanford , "dev@dpdk.org" CC: "chas3@att.com" References: <1639592401-56845-1-git-send-email-rsanford@akamai.com> <1639592401-56845-4-git-send-email-rsanford@akamai.com> <3eb682a7-74db-5bc6-cbd0-7dbbc4177abd@huawei.com> <7CE0C72F-5CFD-4C75-8B03-5739A0339092@akamai.com> <8C168DC6-124B-42B4-A766-11A6FA898256@akamai.com> <6afa9788-b349-d2b9-c869-d258b4a6d46f@huawei.com> <0E88B690-87AD-44A6-BCFA-22F342911E03@akamai.com> From: "Min Hu (Connor)" Message-ID: Date: Wed, 22 Dec 2021 11:25:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <0E88B690-87AD-44A6-BCFA-22F342911E03@akamai.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.128] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggeme756-chm.china.huawei.com (10.3.19.102) X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 在 2021/12/21 23:31, Sanford, Robert 写道: > Hi Connor, > > On 12/20/21, 9:03 PM, "Min Hu (Connor)" wrote: > >> Hi, Sanford, > >>> There is *NO* benefit for the consumer thread (interrupt thread >>> executing tx_machine()) to have caches on per-slave LACPDU pools. >>> The interrupt thread is a control thread, i.e., a non-EAL thread. >>> Its lcore_id is LCORE_ID_ANY, so it has no "default cache" in any >>> mempool. >> Well, sorry, I forgot that interrupt thread is non-EAL thread. > > No problem. (I added a temporary rte_log statement in tx_machine > to make sure lcore_id == LCORE_ID_ANY.) > >>> There is little or no benefit for active data-plane threads to have >>> caches on per-slave LACPDU pools, because on each pool, the producer >>> thread puts back, at most, one mbuf per second. There is not much >>> contention with the consumer (interrupt thread). >>> >>> I contend that caches are not necessary for these private LACPDU >> I agree with you. > > Thanks. > >>> I believe there is a mistake in the ring comments (in 3 places). >>> It would be better if they replace "free" with "full": >>> "... to differentiate a *full* ring from an empty ring." >>> >> Well, I still can not understand it. I think the ring size is N, it >> should store N items, why "N - 1" items.? >> Hope for your description, thanks. > > Here is an excellent article that describes ring buffers, empty vs full, N-1, etc. > https://embedjournal.com/implementing-circular-buffer-embedded-c/#the-full-vs-empty-problem > Thanks Sanford, I see. It is characteristics of ring queues which is different with common queue, like buffers. > >>>> To fix the bug, how about just setting the flags "RING_F_EXACT_SZ" >>> >>> Yes, this is a good idea. I will look for examples or test code that >>> use this flag. >> Yes, if fixed, ILGM. > > I will use RING_F_EXACT_SZ flag in the next version of the patchset. I did not know about that flag. > rte_ring_create(... N_PKTS ... RING_F_EXACT_SZ) > ... is equivalent to, and looks cleaner than ... > rte_ring_create(... rte_align32pow2(N_PKTS + 1) ... 0) > > I plan to create a separate patchset to update the comments in rte_ring.h, > re RING_F_EXACT_SZ and "free" vs "full". > > -- > Regards, > Robert Sanford > >