From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-f51.google.com (mail-yw1-f51.google.com [209.85.161.51]) by dpdk.org (Postfix) with ESMTP id C027A201 for ; Mon, 15 Oct 2018 16:29:57 +0200 (CEST) Received: by mail-yw1-f51.google.com with SMTP id v198-v6so7572194ywg.12 for ; Mon, 15 Oct 2018 07:29:57 -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; bh=MeStR1FuR4HsCItD9fiTcC6APnaURy8Pow6tEAQakDI=; b=TjhfYHlREiUHiNJHgeRofRhhSCDV1JKO4AY6OWNGB72CyLQ6msauxykeZPsYsPhdt7 vfuG2V6cKIyyEBx3OLnWunB5nMQPLr6yGPn7Ek56Q77qh0g3vW2AgW9/Hp2xVtPfukYE 7/2ulPuWe6qFr61U7FHQTKH3QVWFWh0Nbs9vCHfc6eSqzulxW1NBC1sepjYRQ7UqbwqZ 8ZrEBP0YsD12Curfm10+FOJ9rEiiAH5FW5zgof5fWib1Lcg86HRZ20uhRLTmcAIi7JLL Ag/kxBibE3/NJX8r0BfXNAQFQ5K0CiXMYwrtZrHqA5ef0/a4gVjgGGeXBpysY1A+zoZm 9MkQ== 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; bh=MeStR1FuR4HsCItD9fiTcC6APnaURy8Pow6tEAQakDI=; b=NwjyjgTViet67g4/9UzZIlEfQU/knq458SDFwXRxBx5u37X6/0qwzWwAelFVgkfo72 RTg2rJHzlaGJRhPv16/MEfo5DMNpiTBG2xIcjugcOwVKbVkGR2BrEnx9t8/ZGQSuzsUp SHtr7V2vzt2tl43p682jJm5vzZtcWrIZ83kS7Ppypf0FcyqxD2xw59oc4C91QaB3U2az FHxFNYLJs+PHhC6y79y+QPiSJCnNymfs8TYxZZJxwb9hThtRfdFNfjShpCDTOteDdT3X czEjpraeG9GKnXQYWT/SSyEusx8WcEcSdz+5jEVEJTLeoWhj2/41E49iWvh4KeJ+Lk6L h6Yg== X-Gm-Message-State: ABuFfogx9XI0ZEdOpIVtAvEsyWh0lPh6TTmMJQhOUSawSRCirCkEbduY EsaZp26oDi5b3scisxx8eFTE2Rb0QDrVeAqVijo= X-Google-Smtp-Source: ACcGV62wB3t/Qog1r1MEMv7LEayNyIDRLoqQZBk5Tc+xSG7mrDmmZqevUMhWE0sdLZla1Zlmp4Ym7tksNboU9okokUc= X-Received: by 2002:a81:668b:: with SMTP id a133-v6mr9221310ywc.254.1539613796815; Mon, 15 Oct 2018 07:29:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Cliff Burdick Date: Mon, 15 Oct 2018 07:29:43 -0700 Message-ID: To: Andrew Bainbridge Cc: philippb.ontour@gmail.com, users Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Mon, 15 Oct 2018 14:29:58 -0000 I believe mellanox does support it, but it is only part of their other library (rivermax) and not their DPDK driver. However, I don't know if that means you would be able to do something similar to puncturing packets like you are trying to do. My best guess would be that you can send the filler packets to your own MAC address so that the switch will drop it. On Mon, Oct 15, 2018, 04:21 Andrew Bainbridge 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 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 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 < > 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 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 >