From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 3F6D0559C for ; Thu, 1 Dec 2016 08:19:42 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id a197so289553267wmd.0 for ; Wed, 30 Nov 2016 23:19:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=XpF4zAmqgUJ6m5tYDqwcCVWcIggESEnn3syfzzmZOyE=; b=TXXw5/lQRHe+s8ndo4c9PqYPxM0YCJ9TWP6jN398iXzdQfRzl0ikFkTYVOwAwllPgm 9Kp1iMsFkcr0sEmSy+Ynsqvj5U0V5xiq+sQzll0gc6XgBL4AN3i4fJfD+xNVpBxJyQDn ZYSulHadxNwed0Mz0Ao2yzGbTkVripKfQIqD89WhKuAPfBBS3V7E9F6ss3xeSHx8o/Jz FbdvS+DVW+fqr3zjFpRgsETVgUNdL5MdxnS7pYoWQAkItwVwbuxv/OkBSLkAWlHhxFj3 LZD8VEjTgzgmYcV2tC9q+URfAMaqy168spULRjL8cLw48pVg9v03f6Y1uS61glN+oHRw +bvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=XpF4zAmqgUJ6m5tYDqwcCVWcIggESEnn3syfzzmZOyE=; b=YdSkMwuwLF1y4epHZ5dW68mZBsftuyBaeI4PZ5TygrdBLWyrlj5AeGbD07YPIZCieW G7BtaIGV388+fyXAyfdA9FnABgpcz/xm83tLiA9r+eszFFddxS08dnB8xd4ehzFzPIqF /N13jshJxpkcInrwVoN4DgsknV1aw1gQcNjbw3618XdGNhm0299tDMKCM4/Wc02rs29a sCI7jusBHrzi3OiZnx83VMm0a+j8o4QSlZRjLOYal1d1fuLfMf6zqxNqDal/KFodBXqp bExpr+eqxHNz78I2DUtQQhaU3qTaYvd8tyjbhVUuS1km1PmvNCqWP2I2DZiPd4aKDbem hRMg== X-Gm-Message-State: AKaTC01ZlFYKZCzTbcPeFjMs7MBGPdBE2dL3SBIG1PXQovGa3jl7eq/fGV79Fza91TTdmUma X-Received: by 10.28.6.203 with SMTP id 194mr30515181wmg.16.1480576782051; Wed, 30 Nov 2016 23:19:42 -0800 (PST) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id v2sm76754237wja.41.2016.11.30.23.19.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Nov 2016 23:19:41 -0800 (PST) Date: Thu, 1 Dec 2016 08:19:34 +0100 From: Adrien Mazarguil To: "Kulasek, TomaszX" Cc: Thomas Monjalon , "dev@dpdk.org" , "Ananyev, Konstantin" , "olivier.matz@6wind.com" Message-ID: <20161201071934.GH10340@6wind.com> References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <8317180.L80Qf11uiu@xps13> <20161130074003.GD10340@6wind.com> <2285429.Z7YL4y4ekv@xps13> <3042915272161B4EB253DA4D77EB373A14F57A50@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3042915272161B4EB253DA4D77EB373A14F57A50@IRSMSX102.ger.corp.intel.com> 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 07:19:42 -0000 Hi Tomasz, On Wed, Nov 30, 2016 at 10:30:54AM +0000, Kulasek, TomaszX wrote: [...] > > > In my opinion the second approach is both faster to applications and > > > more friendly from a usability perspective, am I missing something > > obvious? > > > > I think it was not clearly explained in this patchset, but this is my > > understanding: > > tx_prepare and tx_burst can be called at different stages of a pipeline, > > on different cores. > > Yes, this API is intended to be used optionaly, not only just before tx_burst. > > 1. Separating both stages: > a) We may have a control over burst (packet content, validation) when needed. > b) For invalid packets we may restore them or do some another task if needed (even on early stage of processing). > c) Tx burst keep as simple as it should be. > > 2. Joining the functionality of tx_prepare and tx_burst have some disadvantages: > a) When packet is invalid it cannot be restored by application should be dropped. > b) Tx burst needs to modify the content of the packet. > c) We have no way to eliminate overhead of preparation (tx_prepare) for the application where performance is a key. > > 3. Using tx callbacks > a) We still need to have different implementations for different devices. > b) The overhead in performance (comparing to the pair tx_prepare/tx_burst) will not be better while both ways uses very similar mechanism. > > In addition, tx_prepare mechanism can be turned off by compilation flag (as discussed with Jerin in http://dpdk.org/dev/patchwork/patch/15770/) to provide real NOOP functionality (e.g. for low-end CPUs, where even unnecessary memory dereference and check can have significant impact on performance). Thanks for the reminder, also I've missed v12 for some reason and still thought rte_phdr_cksum_fix() was some generic function that applications had to use directly regardless. Although I agree with your description, I still think there is an issue, please see my reply to Konstantin [1]. [1] http://dpdk.org/ml/archives/dev/2016-December/050970.html -- Adrien Mazarguil 6WIND