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 7B89DA055A; Thu, 27 Feb 2020 11:32:12 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1A96C2C4F; Thu, 27 Feb 2020 11:32:11 +0100 (CET) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by dpdk.org (Postfix) with ESMTP id 855BC1C01 for ; Thu, 27 Feb 2020 11:32:09 +0100 (CET) Received: by mail-io1-f49.google.com with SMTP id z16so2585825iod.11 for ; Thu, 27 Feb 2020 02:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gXntZmg3+G0v2nCotbg7SrpEz3YDGK2WdDaibM1W8LI=; b=UV8wDWBYYa6nowDI9QzO1FUoQT2zMO9oBJ4fvwy4rls94biy92FyD4HxsQgXBYMuVR lBDGKSyyFrihaHXv2CW4+aWOTGKuAgLLMORz2ZrTf7G8AEs0wZEAveW0c3PuB4CXL4dm wHKH2c6jgAnOydENH2+n9VY9npEAYfN5p1Nzd5Zi2uKkPK7uieADmYWDYUh4ZC117awt Rf+EXD5b9GJ+Vhf0SCcZD5Yo23sZTXKBHhMzhbG26+nCisJz8KaOhRCPaJ4gwdY18a4v 8rCYOnuspRJUF7pNnHydVl6YR1IQKBcmiymni8u8LQb6F5AQPL2X3bMTfm44TPpbjgj7 Yqnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gXntZmg3+G0v2nCotbg7SrpEz3YDGK2WdDaibM1W8LI=; b=eKnNFrpwZ6XmIIZnaKCccfv/Vq/HNtsUCaGDBpXepz5eI99jUZUxuNHMg8IzxloF6O bLmH1Sq6xCJalQI8TgCZJHlq5HLYDjdc6bSFvTghcGxC5p6Nq5ZoQCxv5xu206OEslbR hVn6TQmwuekzqXsHj6gDajxJ8yQDGjIe8zFAMTTH6HSQiiCp+wwpq8giv/x+X+y+Grks ZGJ2DBPPUtqekssEaAZTMmxyqce6V4qRvgebaTuhJVZ6yAhKRUYOpyoYOUHXIqpdNGTq Iyw6nNZDQe2lEQMleqX+kMXSsJqfYJqM6v/Nqbv6J/eOhxG86flb4axHZG0hkkzr+qAf 4QQQ== X-Gm-Message-State: APjAAAVERwRkB5F4tlLTsWW8GSNgOgmrOHjXLRcTrBXCDPKAblYbteic m3wmQCOHoDzi/uN7n216ZLC47ruz3ENtkcUgvz4= X-Google-Smtp-Source: APXvYqyEpG3c6HZ+rT7JGxdZBqcr1GpDTTTebNRLJibjTa0Zu6+D+QECJ8wge0w/l42AMDgMnOYcZkfcSPemQk2l/Uo= X-Received: by 2002:a05:6638:a2c:: with SMTP id 12mr5199687jao.60.1582799528650; Thu, 27 Feb 2020 02:32:08 -0800 (PST) MIME-Version: 1.0 References: <20200224113515.1744-1-konstantin.ananyev@intel.com> <20200224085919.3e73fda7@hermes.lan> <20200224113529.4c1c94ab@hermes.lan> In-Reply-To: From: Jerin Jacob Date: Thu, 27 Feb 2020 16:01:52 +0530 Message-ID: To: "Ananyev, Konstantin" Cc: Stephen Hemminger , dpdk-dev , Olivier Matz , "drc@linux.vnet.ibm.com" Content-Type: text/plain; charset="UTF-8" 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" On Tue, Feb 25, 2020 at 7:11 PM Ananyev, Konstantin wrote: > We do have a run-time check in our current enqueue()/dequeue implementation. > In fact we support both modes: we have generic rte_ring_enqueue(/dequeue)_bulk(/burst) > where sync behaviour is determined at runtime by value of prod(/cons).single. > Or user can call rte_ring_(mp/sp)_enqueue_* functions directly. > This RFC follows exactly the same paradigm: > rte_ring_enqueue(/dequeue)_bulk(/burst) kept generic and it's > behaviour is determined at runtime, by value of prod(/cons).sync_type. > Or user can call enqueue/dequeue with particular sync mode directly: > rte_ring_(mp/sp/rts/hts)_enqueue_(bulk/burst)*. > The only thing that changed: > Format of prod/cons now could differ depending on mode selected at _init_. > So you can't create a ring for let say SP mode and then in the middle of data-path > change your mind and start using MP_RTS mode. > For existing modes (SP/MP, SC/MC) format remains the same and user can still > use them interchangeably, though of course that is an error prone practice. Makes sense. > > > > But I agree with the problem statement that in the virtualization use > > > case, It may be possible to have N virtual cores runs on a physical > > > core. > > > > > > IMO, The best solution would be keeping the ring API same and have a > > > different flavor in "compile-time". Something like > > > liburcu did for accommodating different flavors. > > > > > > i.e urcu-qsbr.h and urcu-bp.h will identical definition of API. The > > > application can simply include ONE header file in a C file based on > > > the flavor. > > I don't think it is a flexible enough approach. > In one app user might need to have several rings with different sync modes. > Or even user might need a ring with different sync modes for enqueue/dequeue. Ack. > Yes, hiding rte_ring implementation inside .c would help a lot > in terms of ABI maintenance and would make our future life easier. > The question is what is the price for it in terms of performance, > and are we ready to pay it. Not to mention that it would cause > changes in many other libs/apps... > So I think it should be a subject for a separate discussion. > But, agree it would be good at least to measure the performance > impact of such change. > If I'll have some spare cycles, will give it a try. > Meanwhile, can I ask Jerin and other guys to repeat tests from this RFC > on their HW? Before continuing discussion would probably be good to know > does the suggested patch work as expected across different platforms. I tested on an arm64 HW. The former section is without the patch(20.02) and later one with this patch. I agree with Konstantin that getting more platform tests will be good early so that we can focus on the approach to avoid back and forth latter. RTE>>ring_perf_autotest // without path ### Testing single element enq/deq ### legacy APIs: SP/SC: single: 289.78 legacy APIs: MP/MC: single: 516.20 ### Testing burst enq/deq ### legacy APIs: SP/SC: burst (size: 8): 312.88 legacy APIs: SP/SC: burst (size: 32): 426.72 legacy APIs: MP/MC: burst (size: 8): 510.95 legacy APIs: MP/MC: burst (size: 32): 702.01 ### Testing bulk enq/deq ### legacy APIs: SP/SC: bulk (size: 8): 306.74 legacy APIs: SP/SC: bulk (size: 32): 411.56 legacy APIs: MP/MC: bulk (size: 8): 501.32 legacy APIs: MP/MC: bulk (size: 32): 693.07 ### Testing empty bulk deq ### legacy APIs: SP/SC: bulk (size: 8): 7.00 legacy APIs: MP/MC: bulk (size: 8): 7.00 ### Testing using two physical cores ### legacy APIs: SP/SC: bulk (size: 8): 74.36 legacy APIs: MP/MC: bulk (size: 8): 110.18 legacy APIs: SP/SC: bulk (size: 32): 23.04 legacy APIs: MP/MC: bulk (size: 32): 32.29 ### Testing using all slave nodes ## Bulk enq/dequeue count on size 8 Core [8] count = 293741 Core [9] count = 293741 Total count (size: 8): 587482 Bulk enq/dequeue count on size 32 Core [8] count = 244909 Core [9] count = 244909 Total count (size: 32): 1077300 ### Testing single element enq/deq ### elem APIs: element size 16B: SP/SC: single: 255.37 elem APIs: element size 16B: MP/MC: single: 456.68 ### Testing burst enq/deq ### elem APIs: element size 16B: SP/SC: burst (size: 8): 291.99 elem APIs: element size 16B: SP/SC: burst (size: 32): 456.25 elem APIs: element size 16B: MP/MC: burst (size: 8): 497.77 elem APIs: element size 16B: MP/MC: burst (size: 32): 680.87 ### Testing bulk enq/deq ### elem APIs: element size 16B: SP/SC: bulk (size: 8): 284.40 elem APIs: element size 16B: SP/SC: bulk (size: 32): 453.17 elem APIs: element size 16B: MP/MC: bulk (size: 8): 485.77 elem APIs: element size 16B: MP/MC: bulk (size: 32): 675.08 ### Testing empty bulk deq ### elem APIs: element size 16B: SP/SC: bulk (size: 8): 8.00 elem APIs: element size 16B: MP/MC: bulk (size: 8): 7.00 ### Testing using two physical cores ### elem APIs: element size 16B: SP/SC: bulk (size: 8): 74.45 elem APIs: element size 16B: MP/MC: bulk (size: 8): 105.91 elem APIs: element size 16B: SP/SC: bulk (size: 32): 22.92 elem APIs: element size 16B: MP/MC: bulk (size: 32): 31.55 ### Testing using all slave nodes ### Bulk enq/dequeue count on size 8 Core [8] count = 308724 Core [9] count = 308723 Total count (size: 8): 617447 Bulk enq/dequeue count on size 32 Core [8] count = 214269 Core [9] count = 214269 Total count (size: 32): 1045985 RTE>>ring_perf_autotest // with patch ### Testing single element enq/deq ### legacy APIs: SP/SC: single: 289.78 legacy APIs: MP/MC: single: 475.76 ### Testing burst enq/deq ### legacy APIs: SP/SC: burst (size: 8): 323.91 legacy APIs: SP/SC: burst (size: 32): 424.60 legacy APIs: MP/MC: burst (size: 8): 523.00 legacy APIs: MP/MC: burst (size: 32): 717.09 ### Testing bulk enq/deq ### legacy APIs: SP/SC: bulk (size: 8): 317.74 legacy APIs: SP/SC: bulk (size: 32): 413.57 legacy APIs: MP/MC: bulk (size: 8): 512.89 legacy APIs: MP/MC: bulk (size: 32): 712.45 ### Testing empty bulk deq ### legacy APIs: SP/SC: bulk (size: 8): 7.00 legacy APIs: MP/MC: bulk (size: 8): 7.00 ### Testing using two physical cores ### legacy APIs: SP/SC: bulk (size: 8): 74.82 legacy APIs: MP/MC: bulk (size: 8): 96.45 legacy APIs: SP/SC: bulk (size: 32): 22.97 legacy APIs: MP/MC: bulk (size: 32): 32.52 ### Testing using all slave nodes ### Bulk enq/dequeue count on size 8 Core [8] count = 283928 Core [9] count = 283927 Total count (size: 8): 567855 Bulk enq/dequeue count on size 32 Core [8] count = 223916 Core [9] count = 223915 Total count (size: 32): 1015686 ### Testing single element enq/deq ### elem APIs: element size 16B: SP/SC: single: 267.65 elem APIs: element size 16B: MP/MC: single: 439.06 ### Testing burst enq/deq ### elem APIs: element size 16B: SP/SC: burst (size: 8): 302.44 elem APIs: element size 16B: SP/SC: burst (size: 32): 466.31 elem APIs: element size 16B: MP/MC: burst (size: 8): 502.51 elem APIs: element size 16B: MP/MC: burst (size: 32): 695.81 ### Testing bulk enq/deq ### elem APIs: element size 16B: SP/SC: bulk (size: 8): 295.15 elem APIs: element size 16B: SP/SC: bulk (size: 32): 462.77 elem APIs: element size 16B: MP/MC: bulk (size: 8): 496.89 elem APIs: element size 16B: MP/MC: bulk (size: 32): 690.46 ### Testing empty bulk deq ### elem APIs: element size 16B: SP/SC: bulk (size: 8): 7.50 elem APIs: element size 16B: MP/MC: bulk (size: 8): 7.44 ### Testing using two physical cores ### elem APIs: element size 16B: SP/SC: bulk (size: 8): 65.85 elem APIs: element size 16B: MP/MC: bulk (size: 8): 103.80 elem APIs: element size 16B: SP/SC: bulk (size: 32): 23.27 elem APIs: element size 16B: MP/MC: bulk (size: 32): 31.17 ### Testing using all slave nodes ### Bulk enq/dequeue count on size 8 Core [8] count = 304223 Core [9] count = 304221 Total count (size: 8): 608444 Bulk enq/dequeue count on size 32 Core [8] count = 214856 Core [9] count = 214855 Total count (size: 32): 1038155 Test OK RTE>>quit > Thanks > Konstantin