From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by dpdk.org (Postfix) with ESMTP id F210647CD for ; Tue, 15 Nov 2016 15:56:22 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 34BBD282F004; Tue, 15 Nov 2016 15:56:22 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Paul Emmerich In-Reply-To: <294AEAFC4B0A3E498038549EC65E9D1B018AB09F91@BELGSMBX01.EVS.TV> Date: Tue, 15 Nov 2016 15:56:21 +0100 Cc: "users@dpdk.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <294AEAFC4B0A3E498038549EC65E9D1B018AB09F91@BELGSMBX01.EVS.TV> To: "VERDOUX, Sylvain" X-Mailer: Apple Mail (2.3124) Subject: Re: [dpdk-users] Howto control sending IFG X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 14:56:23 -0000 Hi, > VERDOUX, Sylvain : > Using i40e pmd i'm currently trying to control precisely packets = emission rate. When dealing with an IFG (inter frame gap) of 1ms it = works fine, but dealing with IFG under 100us I'm seeing bursts on the = receiver. I was wondering if there was a better way to be close to the = wanted IFG instead of waiting and using rte_eth_tx_burst with 1 packet = at a time. I did not see anything relevant in mbuf structure, and I was = wondering if tx queue threshold could help, but I'm not sure to = understand well the impact of those thresholds. > Any advice is welcome :) precision of IFGs is a tough problem for software packet generators. You can get to about +/- 1 us for >=3D 99.9% of the packets with = carefully timed busy waits and RDTSC and avoiding doing anything else in = the tx thread. You can even get to +/- 0.2us for ~99% of the packets. One possible hack is to fill the gaps with invalid packets instead of = real gaps. This relies on your device under test detecting and dropping = these invalid packets early in hardware. Incorrect CRC checksums work well for = this (requires a patched driver). I've implemented both in my packet generator: = https://github.com/emmericp/MoonGen You can read more about in Section 7 and 8 of our paper: = https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/MoonGen_IMC= 2015.pdf (Hardware rate control described there does not work on i40e if = precision is required (it generates bursty traffic)). Paul=