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 B1B7241CE4; Sun, 19 Feb 2023 23:18:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 62A0442D4E; Sun, 19 Feb 2023 23:18:16 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id ED43B40698 for ; Sun, 19 Feb 2023 23:18:14 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 873535C00AC; Sun, 19 Feb 2023 17:18:14 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sun, 19 Feb 2023 17:18:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1676845094; x= 1676931494; bh=kgCUvRhPNwr0YOOxGWOOHNmtk0LVPSVhlB7oyT2pA18=; b=T XXiSnsdPQ2fxXAZmkTq1XlOBaJVacqydxPTNI+d/UZaUgJQdOgBrwJ+46ktj1iXh mL8lBfg6lWG2vAVSbrQw+Ao9mVUd/GGtprWZLQ5MoxnIMTnI8gM7gXHWnzw0HEGf DnjO4QVASdQfosj1hwIdPFNdzr38FMNpSnaNhpId6ZEO3njvEMoLKwH90ybw202g DSdOgTlb6wMcPaHgSmLvJBAqbyElNmuYqYIp21FLzVFisFktEXZasCjU2cWSFx2q 2LUBp0UBgUfMf9eOtl+uwQCGahf1UOd2fkXqjvLthDJIcZGH7DXdOjN4IL4zB8mv 8orFhrXbH6RA7+SWOJk4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1676845094; x= 1676931494; bh=kgCUvRhPNwr0YOOxGWOOHNmtk0LVPSVhlB7oyT2pA18=; b=C Lbx1gpKKkRHHIm48hVXNRlvP8Ci7bAh37MsKz07n3a/8jDoMG3aFs6MLBfyOwrQY zAOmYn8EyET7a6rKMZBAYzby3iIjx9d4WWXKvan2+y+xoPwW9ZHPujBnaepVQMej PFKubprk7HSDhpT1NzjSKUWv7jQayo6hNERqWL8MkqK3ZJoU+3WuSMhDEg9XqgYm /jZ8p0gNhtXFuYeeNDCe5JsJbpPnBGkOqlstyHXDNbNRtpgzlJcZ5IOCHdnhdhaQ +X31ZVJqKmiLdsAaHhjEBFe6KTRqIY0OB9hm5KYqF2h4Y393abjVkgFni7E4kmm4 OoF3vCKoz6wlXWU+YUvpQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejfedgudeiudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 19 Feb 2023 17:18:13 -0500 (EST) From: Thomas Monjalon To: Cristian Dumitrescu Cc: dev@dpdk.org, Kamalakannan R Subject: Re: [PATCH] pipeline: support conversion between big and small fields Date: Sun, 19 Feb 2023 23:18:12 +0100 Message-ID: <4323689.MSiuQNM8U4@thomas> In-Reply-To: <20230210195110.683162-1-cristian.dumitrescu@intel.com> References: <20230210195110.683162-1-cristian.dumitrescu@intel.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 10/02/2023 20:51, Cristian Dumitrescu: > While the small fields (size <= 64 bits) can be in either network byte > order (header fields) or host byte order (meta-data fields), the big > fields (size > 64 bits) are always expected to be in network byte > order (big endian), both header and metadata fields. > > Previously, a big field could be involved in an assignment only when > both the destination and the source are big fields of exactly the same > size. This restriction is now relaxed significantly: in case a big > field is involved as either destination or source, the other field can > now be either a big field (of the same or different size) or a small > header field, so in either case both destination and source are in the > network byte order. > > Signed-off-by: Cristian Dumitrescu > Signed-off-by: Kamalakannan R Applied, thanks.