From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0A9D7A04E7; Mon, 2 Nov 2020 12:08:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1A6A1BE97; Mon, 2 Nov 2020 12:08:23 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 8CBA7BE89 for ; Mon, 2 Nov 2020 12:08:21 +0100 (CET) IronPort-SDR: Vo5OMcK8SslfzWppEH3s9pHuV4DyEgA3A4Q4Lr1e7hc+xn7VpKsAg4vsr0xXWieIbmg4NfEECz lhXP4B2Xgp7w== X-IronPort-AV: E=McAfee;i="6000,8403,9792"; a="165363830" X-IronPort-AV: E=Sophos;i="5.77,444,1596524400"; d="scan'208";a="165363830" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Nov 2020 03:08:19 -0800 IronPort-SDR: CiNOTxGdELPYPSH8/7PedvIsKko4HCeddPZkbC26Ww0REGJVOgZZaNdXHCKjh7hFOjVVU3LpkX GfWYfbdZ/iag== X-IronPort-AV: E=Sophos;i="5.77,444,1596524400"; d="scan'208";a="537977017" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.219.143]) ([10.213.219.143]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Nov 2020 03:08:17 -0800 To: Jiawen Wu , 'David Marchand' , 'Thomas Monjalon' Cc: 'Jian Wang' , 'dev' , 'Bruce Richardson' , 'Olivier Matz' , 'Andrew Rybchenko' , 'Akhil Goyal' , 'Jerin Jacob Kollanukkaran' References: <20201026052105.1561859-1-thomas@monjalon.net> <16204738.pLQXvH3U5b@thomas> <5960b0cf-eb7a-af00-ae6a-86ad5e5db6eb@intel.com> <2336246.PS5YtoHrA8@thomas> <002501d6b0f8$1f5d1420$5e173c60$@trustnetic.com> From: Ferruh Yigit Message-ID: <9b514cef-9998-f9c1-7ebc-f7a0df4bf43e@intel.com> Date: Mon, 2 Nov 2020 11:08:13 +0000 MIME-Version: 1.0 In-Reply-To: <002501d6b0f8$1f5d1420$5e173c60$@trustnetic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v6 00/15] remove mbuf userdata X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" On 11/2/2020 9:11 AM, Jiawen Wu wrote: > On Sunday, November 1, 2020 6:26 PM, David Marchand wrote: >> On Sun, Nov 1, 2020 at 10:15 AM Thomas Monjalon >> wrote: >>>> The new txgbe driver in the next-net is also using ‘udata64’, that >>>> also needs to be updated. cc'ed txgbe maintainer. >>> >>> That's a pity it did not take into account the deprecation notice. >>> What kind of hack is it used for? >>> Can it be simply removed to allow quick merging of the PMD? >> >> +1 for removing. >> >> It seems to be a provision for future features, as this field is simply passed to >> an internal function that does not use it. >> >> $ git grep -C 2 udata drivers/net/txgbe/ >> drivers/net/txgbe/txgbe_rxtx.c- >> drivers/net/txgbe/txgbe_rxtx.c- >> txgbe_set_xmit_ctx(txq, ctx_txd, tx_ol_req, >> drivers/net/txgbe/txgbe_rxtx.c: >> tx_offload, &tx_pkt->udata64); >> drivers/net/txgbe/txgbe_rxtx.c- >> drivers/net/txgbe/txgbe_rxtx.c- txe->last_id = >> tx_last; >> >> $ git grep -C 2 txgbe_set_xmit_ctx drivers/net/txgbe/ >> drivers/net/txgbe/txgbe_rxtx.c- >> drivers/net/txgbe/txgbe_rxtx.c-static inline void >> drivers/net/txgbe/txgbe_rxtx.c:txgbe_set_xmit_ctx(struct txgbe_tx_queue >> *txq, >> drivers/net/txgbe/txgbe_rxtx.c- volatile struct >> txgbe_tx_ctx_desc *ctx_txd, >> drivers/net/txgbe/txgbe_rxtx.c- uint64_t ol_flags, union >> txgbe_tx_offload tx_offload, >> -- >> drivers/net/txgbe/txgbe_rxtx.c- } >> drivers/net/txgbe/txgbe_rxtx.c- >> drivers/net/txgbe/txgbe_rxtx.c: >> txgbe_set_xmit_ctx(txq, ctx_txd, tx_ol_req, >> drivers/net/txgbe/txgbe_rxtx.c- >> tx_offload, &tx_pkt->udata64); >> drivers/net/txgbe/txgbe_rxtx.c- >> >> $ git grep -w mdata drivers/net/txgbe/ >> drivers/net/txgbe/txgbe_rxtx.c: __rte_unused uint64_t *mdata) >> >> >> -- >> David Marchand > > Thanks for review. > It can be just simply removed in txgbe driver. > OK, I will remove it in the next-net.