From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kaYuplMlpwpGZvAhkFjo9BOtf8w57G/t368JQw3nwtg=; b=RA7Somc4dJK5+8w04VEnxAoUZ4oLhy42vX6eDgUdRQqlNmuS4iYRpNpFohGOAmcqbS /ks7cWaLejOMViHxuL/xoge6V+RlfcG2+kGC4Id6t1ZIbDBJh1gquK4JEHlZPzSsI2td Uthok5HmwItGiInj2/0SvW48PlNt7m/6UohgrT0vOW6FcT4zTmyHPTl7MWgTTXwNoRUn 1mKE5i0myCQVuB8u6+t85NioZQLfxIkWR8cDWCtq/5QAC+NqrT2bC+ZMKzF86/IDqcia uJFkEKlpzmY97WaWNoPeITT0nBfAhdHkbQZqESkLG5CLCTa+Cp6+XR2MPadernH4g60p T86Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kaYuplMlpwpGZvAhkFjo9BOtf8w57G/t368JQw3nwtg=; b=HfdBQDvxxb6UnOXMxfmciPqVnCngXo6lz/MU9FXqZeORbeAqIdz2AHZwQg3gyXb3/Q u2TIKWM9SSxcAK0EnkeTmbsVvG33IFOEZRKHCNyQbwITnigUGqXSIyVKYz7JqL0T1Ntc IPI6XOAxGNFtAFHVxE/wqT4W2HkqOs/USQRmAOxmrI6TflfjvPIkTHrRiG6W0DVMRoMN agBAnrOnowV9l6UxVEutd/7gLTbH2MQBFFDjsf6eSEIE+MCjhrd6n+tAsWDOBOjHEJgD 8rCID8iUjc3C8BID8HqfRGlX+wj4qMIFWcrYa2oRPBLeXwIgL9SDlnebby43GuEx+0mK W5Qg== X-Gm-Message-State: ALyK8tKDJHdmBTMqtJvveD06GrPMAIuaXnuKCHhc0dXd01saBB9CX6lr7vOynmF4O0j/qG1Eo/X9h56GiNuXGQ== X-Received: by 10.202.80.85 with SMTP id e82mr11223530oib.47.1465997444376; Wed, 15 Jun 2016 06:30:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.11.66 with HTTP; Wed, 15 Jun 2016 06:30:43 -0700 (PDT) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912647A066BF@IRSMSX108.ger.corp.intel.com> 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> From: Arnon Warshavsky Date: Wed, 15 Jun 2016 16:30:43 +0300 Message-ID: To: "Dumitrescu, Cristian" Cc: Yerden Zhumabekov , Panu Matilainen , "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 13:30:45 -0000 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