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 5A5F6A0547; Mon, 8 Feb 2021 09:07:48 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C50AA1606E4; Mon, 8 Feb 2021 09:07:47 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 510F81606E2 for ; Mon, 8 Feb 2021 09:07:46 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5DBCD5C014B; Mon, 8 Feb 2021 03:07:44 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 08 Feb 2021 03:07:44 -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= BSz2ko0GUmoD95UU4vV8/pn42P/kqiJERwMtzDCHqvM=; b=AxKlVbd3ZeSTJ6QX 4cTos1ebRx13Gg8MXS1kCBL3u2RC+ySv4wWOsauf/4GFW/CljqFv9g2PLmPboJce AE0pq99cHMWi1zeyRhArGeWvYUCPCDfLMzbJUXrHGCLbv5FGKB6PlGmIhyUPq/0M JqOyk7pG1Bz/KzG+6z2jhjeAt9YqLTpst0vbIcMJeXKJeBn3I7XFSU3+Xt612DeD r6bCabO+XpFRUv1n+uGzqQlO97+SR8tzhLRPRNob8HD9p3vqqfj7DMgSH5Q9xTc8 PqHGg432DjbyEAj4YpxTqi9aWJpQ52E4Yz98vZDX3+DMPDAk/zS5ATEgDCqcaH1w WjeHHQ== 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=fm2; bh=BSz2ko0GUmoD95UU4vV8/pn42P/kqiJERwMtzDCHq vM=; b=i5r9Ux+gLhSNBSebot421Dv+lGNO+UoKLcwkMuBklA8g+zi2qlkNe/hS4 JHOIKkp5e7ewx+8BixWseioAMK1LUba505TBEaHPru5d75R/SLSFivMXLY2earHE YUtXctaqcqy3osmwqPBMDJReTt0m3LtzaKfDuXBmrqfdwVs/rgj8alSOqEb6xkFo lWAOfrNE8a2K+H0oZPyhbNBs1Bag0L4fOZNNDGHN8AMIeojQUMedUzorabz8MvzN F6We//T77YCTvU7gZ5UsuazuxKa4LfcXJsHOqn+EI1jVsXNIF0mg/dV5Ic2YE9sb oV6irpE2OLMQTPoLBeMDwsRJoFPOQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrhedvgdduudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7D3151080064; Mon, 8 Feb 2021 03:07:42 -0500 (EST) From: Thomas Monjalon To: Chengchang Tang Cc: Ferruh Yigit , "dev@dpdk.org" , linuxarm@openeuler.org, olivier.matz@6wind.com, konstantin.ananyev@intel.com Date: Mon, 08 Feb 2021 09:07:39 +0100 Message-ID: <2589865.Xk4bFtH7LZ@thomas> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [Question about 'rte_eth_tx_prepare'] 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 Sender: "dev" 08/02/2021 07:29, Chengchang Tang: > Hi, Thomas Monjalon and Ferruh Yigit and others. > > I have some questions about 'rte_eth_tx_prepare'. > > When I use TSO offload in bond mode, the checksum error occurs. It is > because the bond PMD does not implement 'tx_prepare'. So, it will not > invoke the 'tx_prepare' of each PMDs to do prepare for the PMDs. I am > not sure whether to add the 'tx_preapre' implementation for the bond > PMD or put the process of pseudo header in the apps. > > And we are now designing the outer UDP cksum offload for HNS3 PMD. > I find that many PMDs process these pseudo headers in 'tx_prepare', but > does not process the pseudo header for outer UDP checksum offload. > Instead, it is processed in csum forward mode of testpmd. Does this mean > that the pseudo header should be completed by the apps and the apps does > not need to call 'tx_prepare' to avoid repeated processing? (it seems > not transplantable) If so, it seems that PMDs need to avoid doing this > in 'tx_prepare'. > > Here are two questions: > 1. What functions should be included in the 'tx_prepare' for PMDs? > 2. Whether an app must invoke 'rte_eth_tx_prepare' or under which > conditions an app must invoke the 'rte_eth_tx_prepare'? I would say by default the app should prepare the checksums, except if there is an explicit offload request (DEV_TX_OFFLOAD_*). I think the tx_prepare should only prepare the HW Tx offload if the offload is not entirely done in HW.