From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id C23542BCD for ; Wed, 30 Nov 2016 09:50:04 +0100 (CET) Received: by mail-wm0-f51.google.com with SMTP id a197so261743079wmd.0 for ; Wed, 30 Nov 2016 00:50:04 -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=2Un0/g/BHBu40uP5FSIw6SHuwsqcPBLE5XvG8bV57aQ=; b=UOB4zdTCQ18nEjVLfALGgPmFXbaRx0uuwy/yX/ALGGhkMUZWxMV8wRLx39uapkJQLr PzmZloOtX5LTdGd8Fg7/eD9qsDLPPRfBe5K90eAnD7JA+3N/zpTk6BvQUgZEwaVBxwLk 78m0Olb3azHx7up9DH5DezUWQX5yrnT9DIvQBWA8DI52tCCinFf+Iqpu4F/q6+yxmwe9 FFJhVkd0U2XxB4xX4ZMzqRV2VjTGMI3GjuZ0AyEKyIgzc82oGGGGJ3z9hg13nXbb4niQ He652Dm/GTrV4LvJQWi6+cxrEFBTDuUqiEr/ZQXbnb0KqXNBSFGaXFxuTJVsBuJHTQ2/ 8fUg== 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=2Un0/g/BHBu40uP5FSIw6SHuwsqcPBLE5XvG8bV57aQ=; b=juwXgjPR0aG8t7et8I2VflkFJ5GyeIg2f3etw4E4m+EZy8ig9c/WqNdUR0/KB0Co8m QoxPUDbBxIqxTZ0qM3BEiEuAapkXklior9vmKu+UnV2ytleNYkJvcaH8ILOE8fvXmv7g 29yWFk/CmmmrThue6Aw6wA/Zyex8wvlE0tgE4D3j8NzG5RYUeSKl4GbCtjjk0eKbfqcR KbahwefFfKndPlTYzjzmdCzaWCap9tY+rVtdtPisAzuVMywW8CeCxX9/3IDSOINNVgg6 qsE/1FBFDHFcvlquAXUKOiIuZVs7mFf8MCwiixOO0WquferhcfFYnrMRWMKzfk1zj/ll lp0w== X-Gm-Message-State: AKaTC01CgstcNqc8IX2Cq+LzYHTizmK9COmuoRbxJSCgYHg8nCoEbi64IHqu2p7wBwHr0iu4 X-Received: by 10.28.140.136 with SMTP id o130mr28875789wmd.76.1480495804512; Wed, 30 Nov 2016 00:50:04 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id d65sm6814276wmh.11.2016.11.30.00.50.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Nov 2016 00:50:03 -0800 (PST) From: Thomas Monjalon To: Adrien Mazarguil , Tomasz Kulasek Cc: dev@dpdk.org, konstantin.ananyev@intel.com, olivier.matz@6wind.com Date: Wed, 30 Nov 2016 09:50:02 +0100 Message-ID: <2285429.Z7YL4y4ekv@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20161130074003.GD10340@6wind.com> References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <8317180.L80Qf11uiu@xps13> <20161130074003.GD10340@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: Wed, 30 Nov 2016 08:50:04 -0000 2016-11-30 08:40, Adrien Mazarguil: [...] > I understand tx_prep() automates this process, however I'm wondering why > isn't the TX burst function doing that itself. Using nb_mtu_seg_max as an > example, tx_prep() has an extra check in case of TSO that the TX burst > function does not perform. This ends up being much more expensive to > applications due to the additional loop doing redundant testing on each > mbuf. > > If, say as a performance improvement, we decided to leave the validation > part to the TX burst function; what remains in tx_prep() is basically heavy > "preparation" requiring mbuf changes (i.e. erasing checksums, for now). > > 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 > > Note that PMDs could still provide different TX callbacks depending on the > set of enabled offloads so performance is not unnecessarily impacted. > > 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.