From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnon Warshavsky Subject: Re: random pkt generator PMD Date: Wed, 15 Jun 2016 16:30:43 +0300 Message-ID: References: <5761235C.2090906@sts.kz> <3EB4FA525960D640B5BDFFD6A3D8912647A063F9@IRSMSX108.ger.corp.intel.com> <576137B6.2000103@sts.kz> <576146AA.2030108@sts.kz> <9dee2a6e-7aae-fbfa-18ab-16fce71a3144@redhat.com> <3EB4FA525960D640B5BDFFD6A3D8912647A065C2@IRSMSX108.ger.corp.intel.com> <5761501D.9000202@sts.kz> <3EB4FA525960D640B5BDFFD6A3D8912647A066BF@IRSMSX108.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Yerden Zhumabekov , Panu Matilainen , "dev@dpdk.org" To: "Dumitrescu, Cristian" Return-path: Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by dpdk.org (Postfix) with ESMTP id F095EC448 for ; Wed, 15 Jun 2016 15:30:44 +0200 (CEST) Received: by mail-oi0-f51.google.com with SMTP id d132so33408209oig.1 for ; Wed, 15 Jun 2016 06:30:44 -0700 (PDT) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912647A066BF@IRSMSX108.ger.corp.intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Jun 15, 2016 at 4:03 PM, Dumitrescu, Cristian < cristian.dumitrescu@intel.com> wrote: > > > > -----Original Message----- > > From: Yerden Zhumabekov [mailto:e_zhumabekov@sts.kz] > > Sent: Wednesday, June 15, 2016 1:55 PM > > To: Dumitrescu, Cristian ; Panu > Matilainen > > ; dev@dpdk.org > > Subject: Re: [dpdk-dev] random pkt generator PMD > > > > > > > > On 15.06.2016 18:25, Dumitrescu, Cristian wrote: > > > > >>>> 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 - > > > +1 > > > > I'm afraid, all packets from pcap file would need to be preloaded to > > memory. Otherwise, each loop would infer pcap_open/pcap_close(), am I > > wrong? > > This exactly what the code in source port is doing. > > Basically, this is optimized for the case when number of packets in the > PCAP file is relatively small, so the PCAP memory footprint when loaded > into memory is small so it fits the L1/L2 cache. Provides traffic > generation capability when performance measurements are not key: testing, > code development on your laptop while on board of a plane, simulation > environments, etc. > > When the PCAP is large (e.g. capture of the traffic in your local cloud > for 2 mins), then PCAP memory gets swapped to disk and performance > obviously drops. Still better than opening PCAC for each packet. Useful for > e.g. IDS/IPS testing. > If you are after continuous traffic that varies all the time in high performance rather than loop the same pcap over and over again, check out the T-Rex traffic generator which is an open source and dpdk based. https://trex-tgn.cisco.com/ /Arnon