From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sender-pp-092.zoho.com (sender-pp-092.zoho.com [135.84.80.237]) by dpdk.org (Postfix) with ESMTP id 4153737B7 for ; Tue, 28 Aug 2018 21:16:43 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; t=1535483800; cv=none; d=zoho.com; s=zohoarc; b=EaGGF2jq8qACJIY6Hz0UzbVoP93kimy+ilORmA9JwqNX3GjFsb3Iz65rjs7V3UA0QHuaYckB28s3w/8G5sBoMG2b89l4AqOb1rFPJyxzjHgCWTHLd7F60l4xO0nPoTfQc/DoxWykdHXfa1TxHwhfaZ90ICWlm/++rsb1OWCsA9w= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1535483800; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=bs8gHJoUshMamTpt9XWIRlxZQh7hUFm6JoCzw32xIMc=; b=UxhwcAwwgXSMj0meG1B1L9m1F+lNzERuxih8d2K0rfKEmQQLpd+Xrcu4D/0PEYS3XueK6e71sexdXQmu1STXpjBz3cxyZqraP2KzpN1Lq7WLWHgEce2eyC2W0zn+IF4mUh9AYjCx7J3hB1Q5ABS84aTSZyoFAbTyxUNfy29Zddk= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=zoho.com; spf=pass smtp.mailfrom=irsaber@zoho.com; dmarc=pass header.from= header.from= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:to:cc:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=OnK0QUUgYraMXaB8me/DJSzEttra2/bAq4nB3jBzk/WQzvvH6Nsg+vja9YJG+u+R5SOgxNDePV6u 93pLdK9eKlcnJV6EIpfsF6juaS4/rJimLvUseytcEuGot9JjgvRD Received: from [192.168.1.8] (188.210.190.126 [188.210.190.126]) by mx.zohomail.com with SMTPS id 1535483799100381.4956253339376; Tue, 28 Aug 2018 12:16:39 -0700 (PDT) To: "Wiles, Keith" Cc: Stephen Hemminger , "dev@dpdk.org" References: <74400e6a-91ba-3648-0980-47ceae1089a7@zoho.com> <20180828090142.1262c5ea@shemminger-XPS-13-9360> From: Saber Rezvani Message-ID: <9e7b00bb-285b-fe37-f298-6d20d47a77ec@zoho.com> Date: Tue, 28 Aug 2018 23:46:34 +0430 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-ZohoMailClient: External Subject: Re: [dpdk-dev] IXGBE throughput loss with 4+ cores 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: Tue, 28 Aug 2018 19:16:43 -0000 On 08/28/2018 11:39 PM, Wiles, Keith wrote: > Which version of Pktgen? I just pushed a patch in 3.5.3 to fix a perform= ance problem. I use Pktgen verion 3.0.0, indeed it is O.k as far as I=C2=A0 have one core= .=20 (10 Gb/s) but when I increase the number of core (one core per queue)=20 then I loose some performance (roughly 8.5 Gb/s for 8-core). In my=20 scenario Pktgen shows it is generating at line rate, but receiving 8.5 Gb/s= . Is it because of Pktgen??? > >> On Aug 28, 2018, at 12:05 PM, Saber Rezvani wrote: >> >> >> >> On 08/28/2018 08:31 PM, Stephen Hemminger wrote: >>> On Tue, 28 Aug 2018 17:34:27 +0430 >>> Saber Rezvani wrote: >>> >>>> Hi, >>>> >>>> >>>> I have run multi_process/symmetric_mp example in DPDK example director= y. >>>> For a one process its throughput is line rate but as I increase the >>>> number of cores I see decrease in throughput. For example, If the numb= er >>>> of queues set to 4 and each queue assigns to a single core, then the >>>> throughput will be something about 9.4. if 8 queues, then throughput >>>> will be 8.5. >>>> >>>> I have read the following, but it was not convincing. >>>> >>>> http://mails.dpdk.org/archives/dev/2015-October/024960.html >>>> >>>> >>>> I am eagerly looking forward to hearing from you, all. >>>> >>>> >>>> Best wishes, >>>> >>>> Saber >>>> >>>> >>> Not completely surprising. If you have more cores than packet line rate >>> then the number of packets returned for each call to rx_burst will be l= ess. >>> With large number of cores, most of the time will be spent doing reads = of >>> PCI registers for no packets! >> Indeed pktgen says it is generating traffic at line rate, but receiving = less than 10 Gb/s. So, it that case there should be something that causes t= he reduction in throughput :( >> >> > Regards, > Keith >