From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id CCEE3DE0 for ; Wed, 16 Jan 2019 08:13:43 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id DE115100063; Wed, 16 Jan 2019 07:13:41 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 16 Jan 2019 07:13:35 +0000 To: Gage Eads , CC: , , References: <20190110205538.24435-1-gage.eads@intel.com> <20190115223232.31866-1-gage.eads@intel.com> <20190115223232.31866-3-gage.eads@intel.com> From: Andrew Rybchenko Message-ID: <12e1a42b-5973-748f-e6d0-32a453e7b744@solarflare.com> Date: Wed, 16 Jan 2019 10:13:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190115223232.31866-3-gage.eads@intel.com> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24366.000 X-TM-AS-Result: No-18.863700-8.000000-10 X-TMASE-MatchedRID: 0dFPYP4mu5T1Dewoh2WPYya1MaKuob8PBhfhOps3jaiqvcIF1TcLYDQb Y5MLDM8IdJ4l5Xe9dZhiOZRSJchaM+BJ9i6r4a9iLcLAlVGnzPrhv67FD+sD1iBQRBOQhaJikac r55+1Ub82A7xaOTin1KXd2CBmuu6VaACC67qZQKqLCjWjYfPAkKI0K26z6c86X5ol8zUEkXzAkt gDJtZ0AqyKKZjhY8NqsVOVA7u2n7Bbbwmb1mOey8gVr6nylDnuQKuv8uQBDjp04ux8AIlq4eIlP 3UX1pnJhVmF9kz2wxI7b3Js3F6vVA+9QmShUWvCyEj3mRPHpV727Syjew41+AeLCIX046iBSrJT O1VGhMF2+AZuxakJy89fuxSQqqSyyA1ihY42R28vj6wHfIGxyQhRCJFb9cus5x99q4kVOUh5RA2 9TjvO6H4MKWqwjUmzierhrTyYFA/fX2sZfyOJoZ4CIKY/Hg3AtOt1ofVlaoLUHQeTVDUrItRnEQ CUU+jzTpw8o8ZOgpkvI5Glm73FNjZBZ7gcVG/mlq07DXltfR4isd2ZCBVmn1Mylwc/RtjyZo2hJ wR1RzTOZep74YSiYbBtOmDlFZX+FNQUJ0xmGqI= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--18.863700-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24366.000 X-MDID: 1547622823-FyTUGAuN7K1t Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2 2/2] mempool/nb_stack: add non-blocking stack mempool X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 07:13:44 -0000 On 1/16/19 1:32 AM, Gage Eads wrote: > This commit adds support for non-blocking (linked list based) stack mempool > handler. The stack uses a 128-bit compare-and-swap instruction, and thus is > limited to x86_64. The 128-bit CAS atomically updates the stack top pointer > and a modification counter, which protects against the ABA problem. > > In mempool_perf_autotest the lock-based stack outperforms the non-blocking > handler*, however: > - For applications with preemptible pthreads, a lock-based stack's > worst-case performance (i.e. one thread being preempted while > holding the spinlock) is much worse than the non-blocking stack's. > - Using per-thread mempool caches will largely mitigate the performance > difference. > > *Test setup: x86_64 build with default config, dual-socket Xeon E5-2699 v4, > running on isolcpus cores with a tickless scheduler. The lock-based stack's > rate_persec was 1x-3.5x the non-blocking stack's. > > Signed-off-by: Gage Eads > --- Few minor nits below. Other than that Acked-by: Andrew Rybchenko Don't forget about release notes when 19.05 release cycle starts. [snip] > diff --git a/drivers/mempool/meson.build b/drivers/mempool/meson.build > index 4527d9806..01ee30fee 100644 > --- a/drivers/mempool/meson.build > +++ b/drivers/mempool/meson.build > @@ -2,6 +2,11 @@ > # Copyright(c) 2017 Intel Corporation > > drivers = ['bucket', 'dpaa', 'dpaa2', 'octeontx', 'ring', 'stack'] > + > +if dpdk_conf.has('RTE_ARCH_X86_64') > + drivers += 'nb_stack' > +endif > + I think it would be better to concentrate the logic inside nb_stack/meson.build. There is a 'build' variable which may be set to false disable the build. You can find an example in drivers/net/sfc/meson.build. [snip] > +static __rte_always_inline void > +nb_lifo_push(struct nb_lifo *lifo, > + struct nb_lifo_elem *first, > + struct nb_lifo_elem *last, > + unsigned int num) > +{ > + while (1) { > + struct nb_lifo_head old_head, new_head; > + > + old_head = lifo->head; > + > + /* Swing the top pointer to the first element in the list and > + * make the last element point to the old top. > + */ > + new_head.top = first; > + new_head.cnt = old_head.cnt + 1; > + > + last->next = old_head.top; > + > + if (rte_atomic128_cmpset((volatile uint64_t *) &lifo->head, Unnecessary space after type cast above. [snip] > + new_head.top = tmp; > + new_head.cnt = old_head.cnt + 1; > + > + if (rte_atomic128_cmpset((volatile uint64_t *) &lifo->head, Unnecessary space after type cast above. [snip]