From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v12 0/6] add Tx preparation Date: Thu, 01 Dec 2016 09:58:31 +0100 Message-ID: <4746171.WvdnAfCX13@xps13> References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <2601191342CEEE43887BDE71AB9772583F0E20C8@irsmsx105.ger.corp.intel.com> <20161201071518.GG10340@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: "Ananyev, Konstantin" , dev@dpdk.org, Rahul Lakkireddy , Stephen Hurd , Jan Medala , Jakub Palider , John Daley , Alejandro Lucero , Harish Patil , Rasesh Mody , Jerin Jacob , Yuanhan Liu , Yong Wang , "Kulasek, TomaszX" , olivier.matz@6wind.com To: Adrien Mazarguil Return-path: Received: from mail-wj0-f179.google.com (mail-wj0-f179.google.com [209.85.210.179]) by dpdk.org (Postfix) with ESMTP id 66F60379B for ; Thu, 1 Dec 2016 09:58:33 +0100 (CET) Received: by mail-wj0-f179.google.com with SMTP id mp19so198650425wjc.1 for ; Thu, 01 Dec 2016 00:58:33 -0800 (PST) In-Reply-To: <20161201071518.GG10340@6wind.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2016-12-01 08:15, Adrien Mazarguil: > I'm perhaps a bit pessimistic mind you, but I do not think tx_prepare() will > remain optional for long. Sure, PMDs that do not implement it do not care, > I'm focusing on applications, for which the performance impact of calling > tx_prepare() followed by tx_burst() is higher than a single tx_burst() > performing all the necessary preparation at once. I agree that tx_prepare() should become mandatory shortly. > [...] > > > Following the same logic, why can't such a thing be made part of the TX > > > burst function as well (through a direct call to rte_phdr_cksum_fix() > > > whenever necessary). From an application standpoint, what are the advantages > > > of having to: > > > > > > if (tx_prep()) // iterate and update mbufs as needed > > > tx_burst(); // iterate and send > > > > > > Compared to: > > > > > > tx_burst(); // iterate, update as needed and send > > > > I think that was discussed extensively quite a lot previously here: > > As Thomas already replied - main motivation is to allow user > > to execute them on different stages of packet TX pipeline, > > and probably on different cores. > > I think that provides better flexibility to the user to when/where > > do these preparations and hopefully would lead to better performance. > > And I agree, I think this use case is valid but does not warrant such a high > penalty when your application does not need that much flexibility. Simple > (yet conscious) applications need the highest performance. Complex ones as > you described already suffer quite a bit from IPCs and won't mind a couple > of extra CPU cycles right? > > Yes they will, therefore we need a method that satisfies both cases. > > As a possible solution, a special mbuf flag could be added to each mbuf > having gone through tx_prepare(). That way, tx_burst() could skip some > checks and things it would otherwise have done. I like this idea!