From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com [209.85.215.194]) by dpdk.org (Postfix) with ESMTP id 0BBB45F44 for ; Tue, 16 Oct 2018 15:15:38 +0200 (CEST) Received: by mail-pg1-f194.google.com with SMTP id 80-v6so10837579pgh.10 for ; Tue, 16 Oct 2018 06:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3wovuAqUVctvcnUFg0T+6ykqP2CBmBYzSRu7yvNr8pM=; b=RpiLpfRm22vJeFFn1X2zzIShS9r4Z5l9s5q1mep2DF3CkTZ/jp09fZeXvtPsgshIgL +mPKNdvi0eOvQEPisaP+88PoWuMAUVxwIXLK0TZWthrtf5Dda8y3mxNdFHwFdhwgBMv4 B7guHRbcrqlqTpAd105K53uxqC4oqXKlkiZzda1ohlw69vBSt5QFXKajiJfqgEW1hekI w88OpyvRj+ueyFFEFPpZf+Uh16d1HiigvS1oXBlZJj50Lu0Cg4Yr0m9irN9ybOiUSJBT pArOf7FDvHIYLkWnVbEJctpsyVzQocjV/60LvP8dLs5NqdIzsJc8n8x0wv8CWcbmEdMC xg2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3wovuAqUVctvcnUFg0T+6ykqP2CBmBYzSRu7yvNr8pM=; b=Ic5JRoWhvLleFTY1yx+MlQAYeJXntvj+49oJryOpszqfYmQMgdqiAW6imf7i2zOWLN tIm/0V++zZTTQm2402VqD6P23j5SOzwaYKGVOQTwxywj66eCI40pa0gnsldiln1nMyff 7D5ijZuPRn2GGbFLtbN9brtNehfojLyESGejtlG+KOF6gnbvks/nfLYaDZpgcL5g0eE/ Ogdx7MACHlUuyTRhfMCmz/go1b4BNbT4e9Z6OiedgnFTzdyvQpMwHt7sTc1Oi/BUlmFK qPtl0/jqV+NWW+pL5YarbS6BdJFfZbI9FWhXriJcrFcPcjDb4HlPU7XclQjcu0pjFOoJ 7S4g== X-Gm-Message-State: ABuFfoikcH3CR6NSi1lQsMVpWK9BjlRCVWg/67RAauYJ3v7qys0kLVC/ LQKplLlFHdkl1cFP292pLpa64Kx4H4vI67YKq/g= X-Google-Smtp-Source: ACcGV63WQH7oMBMh6tJC3sSBICcHPrivIc+0ekLSsOM8RXdA2lh1NL8R3+HMYs8KUZ93uMdoXJFvOIALC73RAbiJmzg= X-Received: by 2002:a63:f448:: with SMTP id p8-v6mr20082673pgk.124.1539695736913; Tue, 16 Oct 2018 06:15:36 -0700 (PDT) MIME-Version: 1.0 References: <24D5A228-47D5-4FEE-9DD4-A6CFBAFC3EB5@net.in.tum.de> In-Reply-To: <24D5A228-47D5-4FEE-9DD4-A6CFBAFC3EB5@net.in.tum.de> From: Philipp B Date: Tue, 16 Oct 2018 15:15:25 +0200 Message-ID: To: emmericp@net.in.tum.de Cc: Cliff Burdick , andbain@microsoft.com, users@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-users] rte_eth_tx_burst: Can I insert timing gaps X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 13:15:38 -0000 Thanks a lot guys. This was really helpful and comprehensive! Philipp Am Mo., 15. Okt. 2018 um 21:08 Uhr schrieb Paul Emmerich : > > > > Am 15.10.2018 um 16:29 schrieb Cliff Burdick : > > > > My best guess would be that you can send the filler > > packets to your own MAC address so that the switch will drop it. > > A variant of that (with broken CRC checksums; require patched drivers) > of that yielded the best results in our evaluation linked above. > > Our implementation for this is here: > https://github.com/emmericp/MoonGen/blob/master/src/crc-rate-limiter.c > > Implementation of a busy-wait based rate limiter that is often good enoug= h is here: > https://github.com/emmericp/MoonGen/blob/master/src/software-rate-limiter= .cpp#L48 > > It runs in a separate thread that is fed through an rte_ring, so there is= only one tight loop > on that core that sleeps and sends out packets. > > > Paul > > > > > > > > > On Mon, Oct 15, 2018, 04:21 Andrew Bainbridge w= rote: > > > >> Is the feature you are describing is called packet "pacing"? Here's a > >> Mellanox document describing it: > >> https://community.mellanox.com/docs/DOC-2551 > >> > >> I grep'ed the DPDK source for "rate_limit" and found > >> rte_eth_set_queue_rate_limit(). Is that the function you need? > >> > >> From my quick grep'ing, it looks to me like this feature isn't support= ed > >> on Mellanox drivers but is in the ixgbe driver. However, this is all g= uess > >> work. I'm not an expert. I'd like to know the real answer! > >> > >> - Andrew > >> > >> -----Original Message----- > >> From: users On Behalf Of Philipp B > >> Sent: 15 October 2018 11:45 > >> To: shaklee3@gmail.com > >> Cc: users@dpdk.org > >> Subject: Re: [dpdk-users] rte_eth_tx_burst: Can I insert timing gaps > >> > >> Maybe I should explain with some ASCII art. It's not about sleeping ju= st > >> the remaining period of 20ms. This is exactly what I am doing already,= and > >> this works fine. > >> > >> Think of 20ms intervals like this > >> > >> |XXXXXXXXXXXXXXXXXX_____|XXXXXXXXXXXXXXXXXX_____ > >> > >> Where '|' is the start of the 20ms interval, X is a packet, and _ is a= n > >> idle gap of one packet. (Let's just pretend there are 1000s of Xs per > >> interval). > >> > >> As I said, I let the CPU sleep upto the beginning of the interval ('|'= ). > >> This beginning of interval is the only moment where CPU timing control= s > >> adapter timing. Then I send out a few 1000 packets. In this phase, I h= ave a > >> few 100 packets buffered by DPDK, so it will not help to sleep on the = CPU. > >> > >> The pattern above is what I can easily produce just with an OS sleep, = a > >> single buffer pool and rte_eth_tx_burst. What I am looking for, is a w= ay to > >> e.g. remove every second packet from that pattern, while keeping the o= ther > >> packet's timings unchanged: > >> > >> |X_X_X_X_X_X_X_X_X______|X_X_X_X_X_X_X_X_X______ > >> > >> Basically, I do not need to transmit anything in the gaps. I just need= the > >> delay. However, as my timing of CPU isn't coupled tightly to the adapt= er, > >> sleeping on the cpu will not help. This is intended by > >> design: I want to blow out a massive number of packets with exact timi= ng > >> and virtually no CPU requirement. > >> > >> What I look for is a sleep instruction executed by the adapter, which = is > >> buffered in order with the packets issued by rte_eth_tx_burst. > >> (Plus some basic math rules how to convert packet sizes to durations, > >> based on line speeds). > >> > >> Am Sa., 13. Okt. 2018 um 23:05 Uhr schrieb Cliff Burdick < > >> shaklee3@gmail.com>: > >>> > >>> Maybe I'm misunderstanding the problem, but do you need to transmit > >> anything? Can you just use the rte_cycles functions to sleep for the > >> remaining period in 20ms? > >>> > >>> On Thu, Oct 11, 2018 at 2:04 AM Philipp B > >> wrote: > >>>> > >>>> Hi all! > >>>> > >>>> I am working on an RTP test traffic generator. The basic idea is > >>>> clock_nanosleep providing a 20ms clock cycle to start a (big) number > >>>> of rte_eth_tx_bursts, sending equally sized buffers. As long as the > >>>> timing within a 20ms cycle is dictated primarily by the line speed, = I > >>>> can be sure that not just the first buffer of each cycle has a perio= d > >>>> of 20ms, but also the n-th buffer. (I have sent n-1 buffers before > >>>> with the same size.) > >>>> > >>>> Basically, I see one 20ms interval as a series of time slots, each > >>>> capable to store an active RTP stream. My question now is, what to t= o > >>>> with inactive time slots? As long as all active streams are located > >>>> at consecutive time slots from the start of the 20ms interval, > >>>> everything is fine. But I cannot guarantee this. > >>>> > >>>> What I need is some kind of dummy buffer, which is not transmitted > >>>> but generates a tx timing gap as a buffer of X bytes would take to b= e > >>>> transferred. > >>>> > >>>> Is such a functionality provided? As a workaround, I already thought > >>>> about sending invalid packets (bad IP Header checksum?). However, > >>>> this won't be optimal when multiple lines are aggregated. > >>>> > >>>> Thanks! > >>>> Philipp Beyer > >> > > -- > Chair of Network Architectures and Services > Department of Informatics > Technical University of Munich > Boltzmannstr. 3 > 85748 Garching bei M=C3=BCnchen, Germany > > > >