From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=jt0lkL15ESCdjnVVwNDQleoe+H7BChenJIDMlW2W/hg=; b=ZI+w1RB7wC8vWwP0RgKYYDgczx6YfEsjbu0fcYLDRRQ2uvBwUxpLbjgEG6/O/ZXDFv uZe36Y7YT4JEJmN7/qlfWzRBGwS81txiWIMKMKNFjsCre657MLW6dFtuYVgjtEhGjac3 O0ML6DUIX+SVo+faqZaBHvUoDvPmywNQJ2tAGPDAK/Lmi0DXx+jO2gGlThQlX0v9rsct 8Ut8AGT7lj9v/s2wIK5mZpTHuAEKiJZHAGzbsWXbqCTOZn+v6iIoumWw1QTOUQr98Kh0 IM3nFTmqatcGtnZQHSJ2quU5iXo8WfCg945zqOeXnmabkNizKfBypHczky/2Yd0mCfas ZzjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=jt0lkL15ESCdjnVVwNDQleoe+H7BChenJIDMlW2W/hg=; b=Sj4YSO+IfeCowdyFzSEqo7VHDFbtVoZuEOXnKYvxh+37qE5jidJxjJrQOZzcLn2LzX lTsRtVnz+6K6mP6XxAM7wAUNWP83NSU5rf7S7IK3RJMzU2sslnyfyXKA4Xsp5QG4ErlZ tNT0CIAqB2fRzkPzvHByyXGO4z1bzL6gLR9x7D3+vrdqkX1Sz5cdODmunJXU8WfTbRFu EEPNbw2xy6F97PGMIO8DnBBZuryKxlcKL9FGqboX/AtLTpd5gR70ngP7aCXxPhgIraE5 r2SHAZW5hE8TVn27S0WlA+VcT+e1wSzYjZl2YEXJuOlFy9u8f2afAt20m1dDfTZ5sSh6 6spw== X-Gm-Message-State: AKaTC033YN2T5VBUDdlyW3U1E5nFs6OrU16XdBIz4RDrY5kNJr3i2HQRrjPAnf9YOCNagztj X-Received: by 10.194.81.233 with SMTP id d9mr39031052wjy.118.1480582713134; Thu, 01 Dec 2016 00:58:33 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id w79sm12025614wmw.0.2016.12.01.00.58.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 00:58:32 -0800 (PST) From: Thomas Monjalon To: Adrien Mazarguil 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 Date: Thu, 01 Dec 2016 09:58:31 +0100 Message-ID: <4746171.WvdnAfCX13@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20161201071518.GG10340@6wind.com> 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-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v12 0/6] add Tx preparation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 08:58:33 -0000 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!