From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pmatilai@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by dpdk.org (Postfix) with ESMTP id F37A1C5A0
 for <dev@dpdk.org>; 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 <e_zhumabekov@sts.kz>,
 "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
 "dev@dpdk.org" <dev@dpdk.org>
References: <5761235C.2090906@sts.kz>
 <3EB4FA525960D640B5BDFFD6A3D8912647A063F9@IRSMSX108.ger.corp.intel.com>
 <576137B6.2000103@sts.kz> <cf65c372-b2aa-8d44-98db-dcbf8a02ecb4@redhat.com>
 <576146AA.2030108@sts.kz>
From: Panu Matilainen <pmatilai@redhat.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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 -