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 80B8E2B8C for ; Fri, 11 Nov 2016 15:16:13 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 16090282F005 for ; Fri, 11 Nov 2016 15:16:13 +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: <9754A038-DB66-417F-8958-2DDDE317E7A2@net.in.tum.de> Date: Fri, 11 Nov 2016 15:16:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F5A0391-F7F9-4B43-87A1-89A41458F695@net.in.tum.de> References: <750170fd-492a-588c-de6a-27c0547d1cbd@voipfuture.com> <9754A038-DB66-417F-8958-2DDDE317E7A2@net.in.tum.de> To: users X-Mailer: Apple Mail (2.3124) Subject: Re: [dpdk-users] Beginners question: rte_eth_tx_burst, rte_mbuf access synchronization 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: Fri, 11 Nov 2016 14:16:13 -0000 Hi, > Philipp Beyer : > But I might have found another idea: What about preparing all buffers = of a memory pool with the same payload? I should than get a pre-filled = buffer from rte_pktmbuf_alloc, right? Let's say, I initialize a buffer = for transmittion, the transmitting code free's this buffer, and I get = the same buffer back from rte_pktmbuf_alloc. What do I have to = re-initialize to have the same buffer again? Only the payload length? Is = this approach feasible, based on documented/specified behaviour? Yes, that's the easiest way to do it with DPDK's mbuf model. Your first approach would work well on frameworks that expose the ringbuffers directly in their API (e.g., netmap). I've implemented it like this in my packet generator MoonGen, you can read Section 4.2. of our paper at = https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/MoonGen_IMC= 2015.pdf for further details. Paul