Thanks a lot guys. This was really helpful and comprehensive!
Philipp Am Mo., 15. Okt. 2018 um 21:08 Uhr schrieb Paul Emmerich <[email protected]>: > > > > Am 15.10.2018 um 16:29 schrieb Cliff Burdick <[email protected]>: > > > > 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 enough 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 <[email protected]> wrote: > > > >> 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 supported > >> on Mellanox drivers but is in the ixgbe driver. However, this is all guess > >> work. I'm not an expert. I'd like to know the real answer! > >> > >> - Andrew > >> > >> -----Original Message----- > >> From: users <[email protected]> On Behalf Of Philipp B > >> Sent: 15 October 2018 11:45 > >> To: [email protected] > >> Cc: [email protected] > >> 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 just > >> 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 an > >> 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 controls > >> adapter timing. Then I send out a few 1000 packets. In this phase, I have 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 way to > >> e.g. remove every second packet from that pattern, while keeping the other > >> 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 adapter, > >> sleeping on the cpu will not help. This is intended by > >> design: I want to blow out a massive number of packets with exact timing > >> 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 < > >> [email protected]>: > >>> > >>> 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 <[email protected]> > >> 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 period > >>>> 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 to > >>>> 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 be > >>>> 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ünchen, Germany > > > >
