From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7DC3EA057B; Mon, 30 Mar 2020 23:29:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 764881BFD9; Mon, 30 Mar 2020 23:29:46 +0200 (CEST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2080.outbound.protection.outlook.com [40.107.22.80]) by dpdk.org (Postfix) with ESMTP id 82B052BCE for ; Mon, 30 Mar 2020 23:29:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WfC4Gxl9kJ1a52U9cjSVGbOccmLfJ6BH5bDe5KfZov4=; b=Qh1ak7qyjehF5NLx8faWYCx/fCMtG2i8qWpY3ZbEG667kPPyo199Z+qh63K+s3OH57jAVjd2dEHR+0tJ0e3hBG99MOvzR6GSD6b3bdVL4QBfS6+6I5hs38jPj43H/p0YjcYH4lq8ldKO/i/g7DWDtd6B5LXOD4g6x2F+PcQ2TUQ= Received: from AM0PR05CA0059.eurprd05.prod.outlook.com (2603:10a6:208:be::36) by DB7PR08MB3690.eurprd08.prod.outlook.com (2603:10a6:10:77::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Mon, 30 Mar 2020 21:29:44 +0000 Received: from AM5EUR03FT048.eop-EUR03.prod.protection.outlook.com (2603:10a6:208:be:cafe::18) by AM0PR05CA0059.outlook.office365.com (2603:10a6:208:be::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20 via Frontend Transport; Mon, 30 Mar 2020 21:29:44 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dpdk.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dpdk.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT048.mail.protection.outlook.com (10.152.17.177) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Mon, 30 Mar 2020 21:29:44 +0000 Received: ("Tessian outbound 1425309d4c0b:v50"); Mon, 30 Mar 2020 21:29:43 +0000 X-CR-MTA-TID: 64aa7808 Received: from 785c2ca2eb0e.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 14809DEB-2466-42CA-BB7C-92AE0C348A5F.1; Mon, 30 Mar 2020 21:29:38 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 785c2ca2eb0e.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 30 Mar 2020 21:29:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eLIy9ODFkXNaNLdPOnSnNS7IYK5tNJ1Lt5N+7dacju/hGmjdGHR6YNUyq82xhk/IMSEnmU1hbJD9H+icSHcIkohlX84lHyrSknpNyLitJeaa0zo4cYwJckj1fyNnyRWKMQ0xag7AsMF9oZcGYA3VPn9NZhLO5qZlzxpd9Y4QqIulYJ2I+RXf/qNyZlcp2bi4gfai4GK3qz2xTxtgLi7Cv8O/HTrbDQ4HsLHSa+FDqH47UoQdLASbNEd+CvcuxZWxAk4VjDMfu8glsL1D24iYn4eay+s1fg4bP5txKAMbsnvt1lmmN8pn4xfKIPTEa4tz9LfCJjOZ3uaq3T9aAEdJ7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WfC4Gxl9kJ1a52U9cjSVGbOccmLfJ6BH5bDe5KfZov4=; b=exez/0hmvGPu6P0bJsyVM/RAsCs0WC5Ewa/CRn4UeoMcaJ6EUZ1/l1i3iiQvJ5pI0IiX24Q0gvYsaBV4iPVa9ZTPiXEgzMt9JVLWmnYiFjMW9ypW3Ta1oxzbepVlliCSCnb7Bq3V4FIULSSxRjSkdptEBfMcU45TQ3M76jV9ReSB9wuWtQcWuTxUtKFuR7epTRpVvz3WuDrmGEOjkDT6+tR1Q34y8Twz40OmKk53i75XB7p8UmrVfwzzUm52+rXGh2n7QQh5fpuPPMnLPEddY0MoKWdwOvA9lGVkWbS0MHnZQ5IU0UsXf+5Iy4SDysrx2FSrIcz3eEWZSPxZpSJGnw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WfC4Gxl9kJ1a52U9cjSVGbOccmLfJ6BH5bDe5KfZov4=; b=Qh1ak7qyjehF5NLx8faWYCx/fCMtG2i8qWpY3ZbEG667kPPyo199Z+qh63K+s3OH57jAVjd2dEHR+0tJ0e3hBG99MOvzR6GSD6b3bdVL4QBfS6+6I5hs38jPj43H/p0YjcYH4lq8ldKO/i/g7DWDtd6B5LXOD4g6x2F+PcQ2TUQ= Received: from DBBPR08MB4646.eurprd08.prod.outlook.com (10.255.79.144) by DBBPR08MB4791.eurprd08.prod.outlook.com (20.179.45.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.18; Mon, 30 Mar 2020 21:29:36 +0000 Received: from DBBPR08MB4646.eurprd08.prod.outlook.com ([fe80::1870:afc4:b90f:609d]) by DBBPR08MB4646.eurprd08.prod.outlook.com ([fe80::1870:afc4:b90f:609d%5]) with mapi id 15.20.2856.019; Mon, 30 Mar 2020 21:29:36 +0000 From: Honnappa Nagarahalli To: "Ananyev, Konstantin" , "dev@dpdk.org" CC: "olivier.matz@6wind.com" , nd , Honnappa Nagarahalli , nd Thread-Topic: [dpdk-dev] [RFC 0/6] New sync modes for ring Thread-Index: AQHWAuYLqB38ezBiB0izOzOcli/52ahW+IgQgANTMICAB1gSoA== Date: Mon, 30 Mar 2020 21:29:36 +0000 Message-ID: References: <20200224113515.1744-1-konstantin.ananyev@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 0b0974b8-416a-407a-b63a-a28d853df187.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Honnappa.Nagarahalli@arm.com; x-originating-ip: [70.113.25.165] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b6733772-7930-4c78-1361-08d7d4f176c6 x-ms-traffictypediagnostic: DBBPR08MB4791:|DBBPR08MB4791:|DB7PR08MB3690: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0358535363 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB4646.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(396003)(376002)(346002)(86362001)(186003)(966005)(76116006)(52536014)(66946007)(26005)(5660300002)(66476007)(64756008)(478600001)(71200400001)(8936002)(8676002)(81156014)(66446008)(81166006)(66556008)(2906002)(55016002)(6506007)(4326008)(7696005)(316002)(30864003)(54906003)(9686003)(33656002)(110136005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: C27CPc9yyPu3XxG4gsjc/bSX8CqbESZJxALp3XF8JLq5IKh7f2tsmH2/1YNqlaRwYoSWcq4A6tsEidEQORbQO/aSbGoJvnC8VMD/jrKnzVwswCtLh6u9Ic2ciL9XUkRK5f83llg9KUNMYy6moY3tQtzdv+FQD3wWTv0psqySOgP5rhoc628Ysw0FGyN7wE1aIH6EIhlpJmjCH7laqUB7rCv4y7PNPsUSm47G2+hkTBlYpHLTC3tCHE68tp/ZXKf/03BrZzlvChQvWf8v2lvrwT1Zg4cG2cmMeijEQbk83O3zhCKtnuJ/fQCOkFkie2bdAHK/m18jWVjTohpaq7qFAKw2A1YToD4+sMur4gdKVKzTrH2W12+f43HNhsgAiqlZriIoU9kTgHonpH662yvZGuHQMbd9Gi9rWsTzgX1FYThMAsuD4IQMbtnge1gLkMmA+ZpJLfAvAMGlfWcMBJlfvHnSMela+VCmhgXH8PGDF7JHhfKg9uedqgxXuGa23NNeh5INlCaYEmlEcQV/X3ZDAA== x-ms-exchange-antispam-messagedata: 2ibAIgqpRYSKlJszLXs6GVlKH2r8dfT1APOeCqZLhghBIKstHCA+bxwGzHfdmDcYy/5mPGl4fhOC4VIGM5+9TDTMaZ5c7+2rd3/EZbBURcSscrpt3XsMqwittRBCjzvsLTb8Y6Aw9L4rQoMeyb8iPA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4791 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Honnappa.Nagarahalli@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT048.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(376002)(346002)(46966005)(36906005)(30864003)(316002)(70586007)(54906003)(110136005)(70206006)(9686003)(55016002)(2906002)(81156014)(7696005)(47076004)(33656002)(186003)(81166006)(52536014)(356004)(336012)(6506007)(966005)(478600001)(5660300002)(8936002)(26826003)(26005)(4326008)(82740400003)(8676002)(86362001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 6e22e05c-eb4a-4565-d35a-08d7d4f1721e X-Forefront-PRVS: 0358535363 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /yZYSfdXExtmipPQ0TcxMOWophJcC4JcYHJw1bTQsz+DKVKSTqj0Ysd6BZVewz27E5Kh5pcy1AS7TJxTLScEHOujcp/HEmKEg57DoZlWSAZhARKt65u8ur9nxLT0EpVNy9NJpG+PCycNp1jsKuLtC2HHe8kKfx+BkbJ+TBtW/bumSsQ8Fw/5wh2Q3JkQuLIuSA2ZXyfglfPsZMO6Y0fxf7VS9EDaTCW9QZVbMBHqnMtOoneqjgjRuO+pgAJqwnsrgHV1fbBTXExBd6BFbImaOsK8A6fU0YOS1TsJoJ7JOC46KJ2subCvMKjc+7n8Y07dR+nlJnXrTGhRmRpW2cApoFMPDRQVVae0cKLAjlhtCXrESSH/mdvZZjDav35fskJbXfvDz9WCwk6nb+wuUoFOJosMQvHH/Y1eEzsFpBL6OxZ4Dy4Kzjt5dEp0/TzpTgJF1BGM06cIyIq6+OfoxOJZ/OvfqeoyBYwU67k8k1XclGa0WbcuZpyOQ1NkZdVco4IxKo8cYqJejeBuBFdG4L6RiMTKB+fSv/jo1/X/qpAuXc31oVoZj2bpcPDPtwgNQR/N2NMH7MifI37qyF579zkBlw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2020 21:29:44.0313 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b6733772-7930-4c78-1361-08d7d4f176c6 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3690 Subject: Re: [dpdk-dev] [RFC 0/6] New sync modes for ring 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > > > > > Subject: [dpdk-dev] [RFC 0/6] New sync modes for ring > > > > > > Upfront note - that RFC is not a complete patch. > > > It introduces an ABI breakage, plus it doesn't update ring_elem code > > > properly, > > As per the current rules, these changes (in the current form) will be > > accepted only for 20.11 release. How do we address this for immediate > requirements like RCU defer APIs? >=20 > I think I found a way to introduce these new modes without API/ABI breaka= ge. > Working on v1 right now. Plan to submit it by end of that week/start of n= ext > one. ok >=20 > > I suggest that we move forward with my RFC (taking into consideration y= our > feedback) to make progress on RCU APIs. > > > > > etc. > > > I plan to deal with all these things in later versions. > > > Right now I seek an initial feedback about proposed ideas. > > > Would also ask people to repeat performance tests (see below) on > > > their platforms to confirm the impact. > > > > > > More and more customers use(/try to use) DPDK based apps within > > > overcommitted systems (multiple acttive threads over same pysical cor= es): > > > VM, container deployments, etc. > > > One quite common problem they hit: Lock-Holder-Preemption with > rte_ring. > > > LHP is quite a common problem for spin-based sync primitives > > > (spin-locks, etc.) on overcommitted systems. > > > The situation gets much worse when some sort of fair-locking > > > technique is used (ticket-lock, etc.). > > > As now not only lock-owner but also lock-waiters scheduling order > > > matters a lot. > > > This is a well-known problem for kernel within VMs: > > > http://www-archive.xenproject.org/files/xensummitboston08/LHP.pdf > > > https://www.cs.hs-rm.de/~kaiser/events/wamos2017/Slides/selcuk.pdf > > > The problem with rte_ring is that while head accusion is sort of > > > un-fair locking, waiting on tail is very similar to ticket lock > > > schema - tail has to be updated in particular order. > > > That makes current rte_ring implementation to perform really pure on > > > some overcommited scenarios. > > > While it is probably not possible to completely resolve this problem > > > in userspace only (without some kernel communication/intervention), > > > removing fairness in tail update can mitigate it significantly. > > > So this RFC proposes two new optional ring synchronization modes: > > > 1) Head/Tail Sync (HTS) mode > > > In that mode enqueue/dequeue operation is fully serialized: > > > only one thread at a time is allowed to perform given op. > > > As another enhancement provide ability to split enqueue/dequeue > > > operation into two phases: > > > - enqueue/dequeue start > > > - enqueue/dequeue finish > > > That allows user to inspect objects in the ring without removing > > > them from it (aka MT safe peek). > > IMO, this will not address the problem described above. >=20 > It does, please see the results produced by ring_stress_*autotest below. > Let say for test-case: 8thread@2core(--lcores=3D'6,(10-13)@7,(20-23)@8' i= t Had not looked at these tests. Please see the numbers below. > shows: > avg number of cycles per object for enqueue /dequeue: > MP/MC: 280314.32 > HTS: 294.72 > RTS: 318.79 >=20 > Customer who tried it reported similar level of improvement. Is this tested with the VM/Container setup described in the slides you refe= rred to? > Actually if you have time - would be very interesting to see what numbers= will > be on ARM boxes. > To reproduce, just: > $cat ring_tests_u4 > ring_stress_autotest > ring_stress_hts_autotest > ring_stress_rts_autotest >=20 > /app/test/dpdk-test --lcores=3D'6,(10-13)@7,(20-23)@8' -n 4 < ring_tests= _u4 > 2>&1 | tee res1 >=20 > Then look at the ' AGGREGATE' stats. > Right now it is a bit too verbose, so probably the easiest thing to extra= ct same > numbers quickly: > grep 'cycles/obj' res1 | grep 'cycles/obj' | cat -n | awk '{if ($(1)%9= =3D=3D0) print > $(NF);}' > 280314.32 > 1057833.55 > 294.72 > 480.10 > 318.79 > 461.52 >=20 > First 2 numbers will be for MP/MC, next 2 for HTS, last 2 for RTS. 12305.05 12027.09 3.59 7.37 4.41 7.98 >=20 > > For ex: when a producer updates the head and gets scheduled out, other > > producers have to spin. >=20 > Sure, as I wrote in original cover letter: > " While it is probably not possible to completely resolve this problem in > userspace only (without some kernel communication/intervention), removing > fairness in tail update can mitigate it significantly." > Results from the ring_stress_*_autotest confirm that. >=20 > > The problem is probably worse as with non-HTS case moving of the head > > and copying of the ring elements can happen in parallel between the > producers (similarly for consumers). >=20 > Yes as we serialize the ring, we remove possibility of simultaneous copy. > That's why for 'normal' cases (one thread per core) original MP/MC is usu= ally > faster. > Though on overcommitted scenarios current MP/MC performance degrades > dramatically. > The main problem with current MP/MC implementation is in that tail update > have to be done in strict order (sort of fair locking scheme). > Which means that we have much-much worse LHP manifestation, then when > we use unfair schemes. > With serialized ring (HTS) we remove that ordering completely (same idea = as > switch from fair to unfair locking for PV spin-locks). >=20 > > IMO, HTS should not be a configurable flag. >=20 > Why? >=20 > > In RCU requirement, a MP enqueue and HTS dequeue are required. >=20 > This is supported, user can specify different modes for consumer and > producer: > (0 | RING_F_MC_HTS_DEQ). > Then it is up to the user either to call generic > rte_ring_enqueue/rte_ring_dequeue, > or specify mode manually by function name: > rte_ring_mp_enqueue_bulk/ rte_ring_hts_dequeue_bulk. Ok, that should be good. >=20 > > > > > 2) Relaxed Tail Sync (RTS) > > > The main difference from original MP/MC algorithm is that tail value > > > is increased not by every thread that finished enqueue/dequeue, but > > > only by the last one. > > > That allows threads to avoid spinning on ring tail value, leaving > > > actual tail value change to the last thread in the update queue. > > This can be a configurable flag on the ring. > > I am not sure how this solves the problem you have stated above > > completely. Updating the count from all intermediate threads is still > > required to update the value of the head. But yes, it reduces the sever= ity of > the problem by not enforcing the order in which the tail is updated. >=20 > As I said above, main source of slowdown here - that we have to update t= ail in > particular order. > So the main objective (same as for HTS) is to remove that ordering. >=20 > > I also think it introduces the problem on the other side of the ring > > because the tail is not updated soon enough (the other side has to wait > longer for the elements to become available). >=20 > Yes, producer/consumer starvation. > That's why we need max allowed Head-Tail-Distance (htd_max) - to limit ho= w > far head can go away from tail. >=20 > > It also introduces another configuration parameter (HTD_MAX_DEF) which > > they have to deal with. >=20 > If user doesn't provide any value, it will be set by default to ring.capa= city / 8. > From my measurements works quite well. > Though there possibility for the user to set another value, if needed. >=20 > > Users have to still implement the current hypervisor related solutions. >=20 > Didn't get what you trying to say with that phrase. The references you provided talked about resolving LHP by doing co-scheduli= ng of vCPUs (which I think could be applied to DPDK applications). I am say= ing that we still need such mechanisms along with these solutions. >=20 > > IMO, we should run the benchmark for this on an over committed setup to > understand the benefits. >=20 > That's why I created ring_stress_*autotest test-cases and collected numbe= rs > provided below. > I suppose they clearly show the problem on overcommitted scenarios, and > how RTS/HTS improve that situation. > Would appreciate if you repeat these tests on your machines. >=20 > > > > > > > > Test results on IA (see below) show significant improvements for > > > average enqueue/dequeue op times on overcommitted systems. > > > For 'classic' DPDK deployments (one thread per core) original MP/MC > > > algorithm still shows best numbers, though for 64-bit target RTS > > > numbers are not that far away. > > > Numbers were produced by ring_stress_*autotest (first patch in these > series). > > > > > > X86_64 @ Intel(R) Xeon(R) Platinum 8160 CPU @ 2.10GHz > > > DEQ+ENQ average cycles/obj > > > > > > MP/MC HTS RT= S > > > 1thread@1core(--lcores=3D6-7) 8.00 8.15 = 8.99 > > > 2thread@2core(--lcores=3D6-8) 19.14 19.61 = 20.35 > > > 4thread@4core(--lcores=3D6-10) 29.43 29.79 = 31.82 > > > 8thread@8core(--lcores=3D6-14) 110.59 192.81 = 119.50 > > > 16thread@16core(--lcores=3D6-22) 461.03 813.12 = 495.59 > > > 32thread/@32core(--lcores=3D'6-22,55-70') 982.90 1972.38 = 1160.51 > > > > > > 2thread@1core(--lcores=3D'6,(10-11)@7' 20140.50 23.58 = 25.14 > > > 4thread@2core(--lcores=3D'6,(10-11)@7,(20-21)@8' 153680.60 76.88 > 80.05 > > > 8thread@2core(--lcores=3D'6,(10-13)@7,(20-23)@8' 280314.32 294.72 > > > 318.79 16thread@2core(--lcores=3D'6,(10-17)@7,(20-27)@8' 643176.59 > > > 1144.02 > > > 1175.14 32thread@2core(--lcores=3D'6,(10-25)@7,(30-45)@8' 4264238.80 > > > 4627.48 4892.68 > > > > > > 8thread@2core(--lcores=3D'6,(10-17)@(7,8))' 321085.98 298.59 = 307.47 > > > 16thread@4core(--lcores=3D'6,(20-35)@(7-10))' 1900705.61 575.35 > 678.29 > > > 32thread@4core(--lcores=3D'6,(20-51)@(7-10))' 5510445.85 2164.36 > 2714.12 > > > > > > i686 @ Intel(R) Xeon(R) Platinum 8160 CPU @ 2.10GHz > > > DEQ+ENQ average cycles/obj > > > > > > MP/MC HTS RT= S > > > 1thread@1core(--lcores=3D6-7) 7.85 12.13 = 11.31 > > > 2thread@2core(--lcores=3D6-8) 17.89 24.52 = 21.86 > > > 8thread@8core(--lcores=3D6-14) 32.58 354.20 = 54.58 > > > 32thread/@32core(--lcores=3D'6-22,55-70') 813.77 6072.41 = 2169.91 > > > > > > 2thread@1core(--lcores=3D'6,(10-11)@7' 16095.00 36.06 = 34.74 > > > 8thread@2core(--lcores=3D'6,(10-13)@7,(20-23)@8' 1140354.54 346.61 > > > 361.57 16thread@2core(--lcores=3D'6,(10-17)@7,(20-27)@8' 1920417.86 > > > 1314.90 > > > 1416.65 > > > > > > 8thread@2core(--lcores=3D'6,(10-17)@(7,8))' 594358.61 332.70 = 357.74 > > > 32thread@4core(--lcores=3D'6,(20-51)@(7-10))' 5319896.86 2836.44 > 3028.87 > > > > > > Konstantin Ananyev (6): > > > test/ring: add contention stress test > > > ring: rework ring layout to allow new sync schemes > > > ring: introduce RTS ring mode > > > test/ring: add contention stress test for RTS ring > > > ring: introduce HTS ring mode > > > test/ring: add contention stress test for HTS ring > > > > > > app/test/Makefile | 3 + > > > app/test/meson.build | 3 + > > > app/test/test_pdump.c | 6 +- > > > app/test/test_ring_hts_stress.c | 28 ++ > > > app/test/test_ring_rts_stress.c | 28 ++ > > > app/test/test_ring_stress.c | 27 ++ > > > app/test/test_ring_stress.h | 477 +++++++++++++++++++ > > > lib/librte_pdump/rte_pdump.c | 2 +- > > > lib/librte_port/rte_port_ring.c | 12 +- > > > lib/librte_ring/Makefile | 4 +- > > > lib/librte_ring/meson.build | 4 +- > > > lib/librte_ring/rte_ring.c | 84 +++- > > > lib/librte_ring/rte_ring.h | 619 +++++++++++++++++++++++= -- > > > lib/librte_ring/rte_ring_elem.h | 8 +- > > > lib/librte_ring/rte_ring_hts_generic.h | 228 +++++++++ > > > lib/librte_ring/rte_ring_rts_generic.h | 240 ++++++++++ > > > 16 files changed, 1721 insertions(+), 52 deletions(-) create mode > > > 100644 app/test/test_ring_hts_stress.c create mode 100644 > > > app/test/test_ring_rts_stress.c create mode 100644 > > > app/test/test_ring_stress.c create mode 100644 > > > app/test/test_ring_stress.h create mode 100644 > > > lib/librte_ring/rte_ring_hts_generic.h > > > create mode 100644 lib/librte_ring/rte_ring_rts_generic.h > > > > > > -- > > > 2.17.1