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 EA590A034C; Tue, 11 Jan 2022 17:45:57 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 79E2B42738; Tue, 11 Jan 2022 17:45:57 +0100 (CET) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by mails.dpdk.org (Postfix) with ESMTP id 87F53410F1 for ; Tue, 11 Jan 2022 17:45:56 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 2DF1232006F2; Tue, 11 Jan 2022 11:45:53 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 11 Jan 2022 11:45:53 -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= 5n1z22m0kMujB2vg99LiY5guX7Aenlp3Q6Qz9QJHzLQ=; b=L5hE07mpiJ7LYVQG mUsCV7YjSpbAgVhZl8RXSDNhAMCgHCY6iIJo8HeNePiUJNasZ171lhYpa+W1sOKp VD2sMi3EW1LMof6PQmHF4O/dWEK1fjUbS+XyK7q+iVga0hoZXHlPoQ6I2vHbXwnW vcrfbXclcMRhtrC6itElOe7xTIKeeWHVm0pRWQz1oGcvxIkP87eidwAJKLsAubUi armB6pQK/K2jNSkxEznRibIweu1tSnPwfUxrdNXZNkPIUouBll+tvBja4+mTetoD Echnc3LWqCm7C+Zvhw6hrpkdaQY8cPekgvR3vxtRKV5PkDPYz+h+vxo5GKQv/+LG d2ZsZw== 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=fm1; bh=5n1z22m0kMujB2vg99LiY5guX7Aenlp3Q6Qz9QJHz LQ=; b=DYkWcCD+o9ND00z+HQFu+Vkj/6sGXq+0jDos+ON6Lz7HYghLKaDEi5OPB h4CPQ8MgJlvcH6zx1HWtpRE+/dMYAk4UszQdQCKMjBmj57zCl6JsOO4JgW5BlpZf KoiiE9JqWnDiCl+s3wj/VS78ZQoIvWvoqHoKCIdK+sfmroJNyYtb28zuPr88ccb4 jzCFpWogiYbbWfflgDC8AVimiYb8OMl+nP1zQKYdxfXKWsqMqLQzlOKHBjhQHWFz UHQ0l4Gtw9sJugG6HJlfjX4kBjTYAB5L7gLNaLiIUbqiPFJUtwFT+A034VsN871/ QT/Q+hoCGCBzTiXRKcycvEZJ+QdjQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehfedgleefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 11 Jan 2022 11:45:50 -0500 (EST) From: Thomas Monjalon To: liugaoxiang@huawei.com Cc: dev@dpdk.org, Olivier Matz , Gaoxiang Liu Subject: Re: [PATCH] mbuf: delete dynamic fields copy in hdr copy Date: Tue, 11 Jan 2022 17:45:49 +0100 Message-ID: <1737658.3VsfAaAtOV@thomas> In-Reply-To: <20211214075606.979-1-gaoxiangliu0@163.com> References: <20211214075606.979-1-gaoxiangliu0@163.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 14/12/2021 08:56, Gaoxiang Liu: > Because dynamic fields are registered by the DPDK application, > so it is up to the application to decide whether to copy the value of > dynamic fields. > So delete dynamic fields copy in __rte_pktmbuf_copy_hdr. > It's more flexible for the DPDK application, > and is useful for improving performance. Yes, removing operations will improve the performance, but it looks wrong. This is copying all dynamic fields, not matter which one is registered. We cannot ask the application to manage dynamic fields copy, especially if the copy is done inside a library.