From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id F37A1C5A0 for ; Wed, 15 Jun 2016 14:24:18 +0200 (CEST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 64ABE345590; Wed, 15 Jun 2016 12:24:18 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-7-108.ams2.redhat.com [10.36.7.108]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5FCOHY6031753; Wed, 15 Jun 2016 08:24:17 -0400 To: Yerden Zhumabekov , "Dumitrescu, Cristian" , "dev@dpdk.org" References: <5761235C.2090906@sts.kz> <3EB4FA525960D640B5BDFFD6A3D8912647A063F9@IRSMSX108.ger.corp.intel.com> <576137B6.2000103@sts.kz> <576146AA.2030108@sts.kz> From: Panu Matilainen Message-ID: <9dee2a6e-7aae-fbfa-18ab-16fce71a3144@redhat.com> Date: Wed, 15 Jun 2016 15:24:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <576146AA.2030108@sts.kz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 15 Jun 2016 12:24:18 +0000 (UTC) Subject: Re: [dpdk-dev] random pkt generator PMD X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 12:24:19 -0000 On 06/15/2016 03:14 PM, Yerden Zhumabekov wrote: > > > On 15.06.2016 17:25, Panu Matilainen wrote: >> On 06/15/2016 02:10 PM, Yerden Zhumabekov wrote: >>> >>> >>> On 15.06.2016 16:43, Dumitrescu, Cristian wrote: >>>> >>>>> >>>>> Hello everybody, >>>>> >>>>> DPDK already got a number of PMDs for various eth devices, it even has >>>>> PMD emulations for backends such as pcap, sw rings etc. >>>>> >>>>> I've been thinking about the idea of having PMD which would generate >>>>> mbufs on the fly in some randomized fashion. This would serve goals >>>>> like, for example: >>>>> >>>>> 1) running tests for applications with network processing capabilities >>>>> without additional software packet generators; >>>>> 2) making performance measurements with no hw inteference; >>>>> 3) ability to run without root privileges, --no-pci, --no-huge, for CI >>>>> build, so on. >>>>> >>>>> Maybe there's no such need, and these goals may be achieved by other >>>>> means and this idea is flawed? Any thoughts? >>>> How about a Perl/Python script to generate a PCAP file with random >>>> packets and then feed the PCAP file to the PCAP PMD? >>>> >>>> Random can mean different requirements for different >>>> users/application, I think it is difficult to fit this under a simple >>>> generic API. Customizing the script for different requirements if a >>>> far better option in my opinion. >>> >>> AFAIK, the thing about pcap pmd is that one needs to rewind pcap file >>> once pcap pmd reaches its end. It requires additional (non-generic) >>> handling in app code. >> >> So add a loop-mode to pcap pmd? > > It would be nice to have an option like "...,rewind=1,...". As Cristian points out in http://dpdk.org/ml/archives/dev/2016-June/041589.html, the current pmd behavior of stopping is the odd man out in the pmd crowd. Rather than whether to rewind or not, I'd make the number of loops configurable, defaulting to forever and 1 being the equal to current behavior. - Panu -