From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1C080A04AF; Wed, 19 Jan 2022 15:56:24 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 85EBB4115A; Wed, 19 Jan 2022 15:56:23 +0100 (CET) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by mails.dpdk.org (Postfix) with ESMTP id 64A0D41147 for ; Wed, 19 Jan 2022 15:56:22 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 0EA97320241F; Wed, 19 Jan 2022 09:56:20 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 19 Jan 2022 09:56:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= ZoqeAG/RRi8DnbrbxsxfiksXBSOgRsxiylrHzf4+Zxw=; b=LwdecJS2qjRQnT/a JSNXvLPQffQ/ZpG0sMiv4MJKSzJso3RsSk4l4fnbyFlnSZedyMWL07oIGtxohxej zi1b6mDA1vfL550YJzrXk19w9sV2KeBr2hdUEyKDOJyg2zgg1Zfj36CLZqrZOO/0 LNmLTOQnFAT5SDNYv1EBhAPpfjGJHKCLpZXyfox4+U22cP5fP1lEk+hmIDXokMSv kTDfQi9xvFMJbOyALCvHI8M+HytEKzRiYvlT70fuM9ruXgw43sQ1W2UGhSr0NMfw n0/CQ8SYoQKO/oCz9HugkAWPRWXsi/296u6kVEmdnbG51B9osOY7PNoZGpP3bMMM ruvGzg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ZoqeAG/RRi8DnbrbxsxfiksXBSOgRsxiylrHzf4+Z xw=; b=O2Ra/Uw1mj/JlVLzaySK/uqS1EtP7wc1k/inYNREZ19wLaFhJQS2LG1cK /8EuQJe773tuC6CpNhgafF1t7wYRk1vEnQqMdwCE8GgoQaUTL+xp3YS8ig7i/8dE 7ttrvm7ZIZdavF8FX7EMk5kOubGoffrMC2GROc9RGA2ubKRzDfqbdqeir9MOv+oX M12+n5R4TziKwGZ1YQlXYNTH4X00Pc3CJfOAw9uzUQwtKeytT0aGGQ0pq11hCGVv 0EJyRHjzXu2gptTcm2S5AQkHpB3nBfAdKaVpkstG8SnMuIzTjyV+g0jyJHqI+IxR gASbOHIFZ+wQgUEmL19rMdJ1ZTeig== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeigdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpefhjeelkefhheevheefuddvvdetgfehgeefhefgtdelheelgfejudeh vdfgjedvueenucffohhmrghinhepthifihhtthgvrhdrtghomhdpughpughkrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhm rghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 19 Jan 2022 09:56:19 -0500 (EST) From: Thomas Monjalon To: "Randles, Ronan" , "Van Haaren, Harry" Cc: dev@dpdk.org, Jerin Jacob , "dev@dpdk.org" , "Richardson, Bruce" Subject: Re: [PATCH 05/12] gen: add raw packet data API and tests Date: Wed, 19 Jan 2022 15:56:18 +0100 Message-ID: <5931992.YiXZdWvhHV@thomas> In-Reply-To: References: <20211214141242.3383831-1-ronan.randles@intel.com> <6332947.G0QQBjFxQf@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 20/12/2021 11:21, Van Haaren, Harry: > From: Thomas Monjalon > > 17/12/2021 12:40, Van Haaren, Harry: > > > I could ramble on a bit more, but mostly diminishing returns I think... > > > I'll just use this email as a reply to Thomas' tweet; > > > https://twitter.com/tmonjalo/status/1337313985662771201 > > > > My original question was to know available applications, > > not integrating such application in the DPDK repository. > > > > I may me miss something obvious, > > but I don't understand why trying to add a user app inside DPDK repo. > > There are likely a few points-of-view on this particular topic; and I'm glad > you mention it so we can discuss it clearly here. > > There are two main parts to this patchset, the first is a packet generation library, > with an easy to use string-based syntax. The *library* is designed to be extended in > future to a range of "useful stuff" to do while generating packets. The text syntax would be specific to this application and not usable somewhere else, so it doesn't make sense as a lib. > The packet generation > *application* should have minimal features, and focus on ease-of-use (as suggested below). It would be either a limited application, or an ever-growing application. If the latter, it should not be in the main DPDK repository in my opinion. By the way, I don't think it is the responsibility of DPDK to generate packets. I would prefer having an application using the already known scapy or a graphical interface like Ostinato. There are tons of approach to define packets to send (pCraft is another one). DPDK should only manage the Tx part, and optionally Rx of forwarded packets. > In order to test the DPDK code, we need a variety of unit tests, and a sample-application to show > users how to use the library (as well as docs etc). For me, the interesting part is that it is a small > step from a simple sample-app just for testing to a minimal tool for high-rate packet generation. > > I think many users of DPDK first install DPDK, then wish for a tool to generate high traffic rates > to test DPDK, and end up with a usability problem; DPDK does not include a usable packet generator. I don't see any usability problem in using an external well known tool. Learning a new tool provided by DPDK *is* a usabilty difficulty. > To highlight this point; our own DPDK Docs simply ignore the requirement of packet-generation to > actually have packets processed by skeleton: http://doc.dpdk.org/guides/sample_app_ug/skeleton.html > Our "quick start" on the website uses PCAP vdevs (avoiding the problem) https://core.dpdk.org/doc/quick-start/ > Even searching the entire docs for "generate packet" doesn't give any relevant/useful results: > http://doc.dpdk.org/guides/search.html?q=generate+packet&check_keywords=yes&area=default# > > Users could internet-search & find pktgen, moongen, trex, or similar tools. These tools are fantastic for experienced > developers such as devs on this mailing list - we should *NOT* replicate these complex tools in DPDK itself. However, > building any tool outside of DPDK repo requires more effort; another git-clone, another set of dependencies to install, > perhaps another build-system to get used to. Particularly for people starting out with DPDK (who are likely finding > it difficult to learn the various hugepage/PCI-binding etc), this is yet another problem to solve, or to give up. > > So my proposal is as follows; let us add a simple DPDK traffic generator to DPDK. We can define its scope > and its intended use, limiting the scope and capabilities. As before, I do NOT think it a good idea to build a > complex and feature-rich packet generator. I do feel it useful to have an easy-to-use application in DPDK that > is particularly designed for generating specific packets, at specific line-rates, and reports mpps returned. > > Thoughts on adding an small scope-limited application to DPDK enabling ease-of-packet-generation for new users? So you want a simple packet generator for simple benchmarks? And for complex benchmarks, we use another tool?