From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id 951B04C95 for ; Wed, 14 Nov 2018 20:41:04 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 2F93B4000F for ; Wed, 14 Nov 2018 20:41:04 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 1A40540014; Wed, 14 Nov 2018 20:41:03 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.1 X-Spam-Score: -1.0 Received: from [192.168.1.59] (host-90-232-59-122.mobileonline.telia.com [90.232.59.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 829BF4000F; Wed, 14 Nov 2018 20:41:02 +0100 (CET) To: Venky Venkatesh , "dev@dpdk.org" References: <27A03E76-DED0-435F-B02F-24A7A7B1BCC9@contoso.com> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: <779258cb-490f-0111-94ce-bc87d1502ed0@lysator.liu.se> Date: Wed, 14 Nov 2018 20:41:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <27A03E76-DED0-435F-B02F-24A7A7B1BCC9@contoso.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dpdk-dev] Application used for DSW event_dev performance testing 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, 14 Nov 2018 19:41:04 -0000 On 2018-11-14 20:16, Venky Venkatesh wrote: > Hi, > > https://mails.dpdk.org/archives/dev/2018-September/111344.html mentions that there is a sample application where “worker cores can sustain 300-400 million event/s. With a pipeline > with 1000 clock cycles of work per stage, the average event device > overhead is somewhere 50-150 clock cycles/event”. Is this sample application code available? > It's proprietary code, although it's also been tested by some of our partners. The primary reason for it not being contributed to DPDK is because it's a fair amount of work to do so. I would refer to it as an eventdev pipeline simulator, rather than a sample app. > We have written a similar simple sample application where 1 core keeps enqueuing (as NEW/ATOMIC) and n-cores dequeue (and RELEASE) and do no other work. But we are not seeing anything close in terms of performance. Also we are seeing some counter intuitive behaviors such as a burst of 32 is worse than burst of 1. We surely have something wrong and would thus compare against a good application that you have written. Could you pls share it? > Is this enqueue or dequeue burst? How large is n? Is this explicit release? What do you set nb_events_limit to? Good DSW performance much depends on the average burst size on the event rings, which in turn is dependent on the number of in-flight events. On really high core-count systems you might also want to increase DSW_MAX_PORT_OPS_PER_BG_TASK, since it effectively puts a limit on the maximum number of events buffered on the output buffers. In the pipeline simulator all cores produce events initially, and then recycles events when the number of in-flight events reach a certain threshold (50% of nb_events_limit). A single lcore won't be able to fill the pipeline, if you have zero-work stages. Even though I can't send you the simulator code at this point, I'm happy to assist you in any DSW-related endeavors.