From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id C5742A00E6 for ; Tue, 11 Jun 2019 08:40:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4A3781C275; Tue, 11 Jun 2019 08:40:15 +0200 (CEST) Received: from smtp-out.abv.bg (smtp-out.abv.bg [194.153.145.99]) by dpdk.org (Postfix) with ESMTP id 339A71C274 for ; Tue, 11 Jun 2019 08:40:14 +0200 (CEST) Received: from nm23.ni.bg (nm23.ni.bg [192.168.151.172]) by smtp-out.abv.bg (Postfix) with ESMTP id A048D5DD8; Tue, 11 Jun 2019 09:40:13 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=abv.bg; s=smtp-out; t=1560235213; bh=92//MKOLaN57OqvhiFcnRXVNFv+v3DyONiH7mNpnCGk=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=YrXYDzW8RtoBe2MtZ82s4BKjiuwfTK+gHV6Gy5zhS1CDDdkRHjIvd6hlz+VwPsQKi /KCKExHh2dXowq2Bl9WyCbLv9VfJ2LyIMcs52g4quny2oFcVv0gOvwP8MR9n9JKPsT hG0CGg6ai0b3MKELm56e3tzXSEyEfj9q3bCOarWk= Received: from nm23.ni.bg (localhost [127.0.0.1]) by nm23.ni.bg (Postfix) with ESMTP id 848CD9D818; Tue, 11 Jun 2019 09:40:13 +0300 (EEST) Date: Tue, 11 Jun 2019 09:40:13 +0300 (EEST) From: George Yaneff To: harry.van.haaren@intel.com Cc: "users@dpdk.org" Message-ID: <1013242989.1664215.1560235213544@nm23.ni.bg> In-Reply-To: References: <1567292027.2330305.1560177614329@nm22.abv.bg> MIME-Version: 1.0 X-Mailer: AbvMail 3.0 X-Originating-IP: 78.83.11.106 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] DPDK Distributor app issues X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" Harry, thank you for the answer. I will look into this event dev lib, but I hoped my time with the distributor lib will not be wasted. Actually it pretty much fits into my use case. About the packet loss I suspect that they are always the first one or two packets, I'm still debugging and trying to figure out what really happens. About the delay - unfortunately the cycles in the worker are not the cause for them. When I comment these lines there is no effect on the delay. Also these is some buffering happening in the tx_core but the reason is not there also. I suspect some buffering happens internally in the distributor itself. I understand that the throughput is traded for bigger latency, but hoped there will be a way to tune this. Regards George >-------- Оригинално писмо -------- >От: "Van Haaren, Harry" harry.van.haaren@intel.com >Относно: RE: [dpdk-users] DPDK Distributor app issues >До: George Yaneff , "users@dpdk.org" >Изпратено на: 10.06.2019 19:13 > -----Original Message----- > From: users [mailto:users-bounces@dpdk.org] On Behalf Of George Yaneff > Sent: Monday, June 10, 2019 3:40 PM > To: users@dpdk.org > Subject: [dpdk-users] DPDK Distributor app issues > > I'm playing with the distributor example application from dpdk 19.05.0 Ah cool - Not sure what your goal is, but if you're looking for the more future-proof load-balancing / distribution APIs in DPDK the I recommend to look at the Eventdev library, as this has been added to DPDK for more "pipelined" applications and load-balancing within those pipeline stages. If you know your use case matches distributor library, and are aware of the existence of Eventdev libs, please ignore the above :) > I > have three machines connected sequentially with an UTP Ethernet cable. The > middle is Ubuntu 18.04.2 LTS with a eigth core Intel I7 processor and 24 > GB ram. The eth device used is Intel I350 with four ports. > > The strange behavior I'm observing is when I ping the second node from the > first node (traffic passing through the distributor) there are always one > or two packets lost. > When I use > l2fwd or > basicfwd applications there is no packet loss. Anyone knows if this is > normal or if it is not - what I'm doing wrong? This seems strange - although I'm not very familiar with Distributor sample app. Perhaps add some statistics counters around the "rte_pktmbuf_free()" calls in the sample app, to identify if the sample-app is dropping packets in SW, or if the root cause is really platform configuration? > Another thing I noticed is that the ping replies come to the first node > with around one second of delay. (1024ms on most packets) Again there is no > latency with the basicfwd (packets arriving in 0.101 ms there). Is there > any way to minimize this delay in distributor application also? The sample application adds artificial "work" per packet to simulate a real world distributing workload: http://git.dpdk.org/dpdk/tree/examples/distributor/main.c#n574 Per packet, 100 cycles of work is performed, so eg: (burst-size # of packets * 100 cycles) @ CPU freq + RX, TX and Distributor work will be the total delay along the wire. > George Hope that helps, -Harry