From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by dpdk.org (Postfix) with ESMTP id 4C53F239 for ; Mon, 15 Oct 2018 12:45:12 +0200 (CEST) Received: by mail-pg1-f177.google.com with SMTP id g12-v6so8983219pgs.1 for ; Mon, 15 Oct 2018 03:45:12 -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=Zm+AQ7VKlFrSLbi1lVYr9HVFf8xXLVFosHCgLFCq1/k=; b=r5w+Udqag0Z6l3TGrQGd41qPOlpevTAVO0XntksfGIvnfgKwa7HBZdPuispdufk+49 jUxnLthkmOy0yyCvcxzB1VpqWuknKc2ttT98WSxe4j3yG5GOXsyxneU9sBJEQCzD6Bcr kc3NRJ38kl1pxLdO2j06gYsAav9qulpP/gcH1byYrYju3eVyJGMCRgDQ+rr8h1ed2jnM i2EtOZJq8yC37Voy15dRiML4EdXy1PRtBDhLyR3EPIS4Smp7l0EikkatXfakHhu1LVaW EjIKuugb5Ci5AYnAa20tRCsB/Ku/c0Op9FoiXA+9Zwg/LDEzfpFmEilA0CLIZpotp1Cx YtRA== 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=Zm+AQ7VKlFrSLbi1lVYr9HVFf8xXLVFosHCgLFCq1/k=; b=RVdegA4ssALcR2jzRymdVVeoZh6A6gBD+Ss7Y5WvmmRGISTDoCEkvAtCDr/5K1NJ8/ IW9HzD1k+cHj8l4yPFMLcVhLjNWxo7OkyaAnMT+6bQCekl8E0QDGTUmMz0HmcxZsLQSR kkzwzkCG+89KxKXu46dC8GryXyYjpi4gfkGd3RN4qveq3fbqxSVPi610GwyUgUeSEEuI WcV/9PFv4/Xg0dhSxKWi2RkXmcW/3zxl3yN752YPgGOpEKC1LiewYe5mQ1dpEZFouUbW waheEXiSxFqm+uzkaga+QYVkTTWChnNyW0Som1UnNvwQeA3UOn6wlXiCYZd4clkL6S6K m4DQ== X-Gm-Message-State: ABuFfohzYju9lKP/NyWw/m13YoDve0U8TofmI130T6S/x36vrnZo3o2O 5JYpyICqsf310hAAu2llWwDncHetfmiNYgK09z9BfAn5 X-Google-Smtp-Source: ACcGV61B8IFp7rzUXtZKPrNV+UMKzayzF6fiOdAFO3XM0gxZp+KdDdOwMZwEL6Pc1Bwa8Q1jTtcuezeq1lyxxRxxEW8= X-Received: by 2002:a63:5c1f:: with SMTP id q31-v6mr15677391pgb.452.1539600311292; Mon, 15 Oct 2018 03:45:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Philipp B Date: Mon, 15 Oct 2018 12:44:59 +0200 Message-ID: To: shaklee3@gmail.com Cc: users@dpdk.org Content-Type: text/plain; charset="UTF-8" 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 10:45:12 -0000 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 : > > 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