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 D813043A3A; Tue, 6 Feb 2024 23:39:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 638E8402E1; Tue, 6 Feb 2024 23:39:36 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 825FB402CE for ; Tue, 6 Feb 2024 23:39:35 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E563E5C0135; Tue, 6 Feb 2024 17:39:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 06 Feb 2024 17:39:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1707259172; x=1707345572; bh=HE3yOJetf/tg6mBXaaJKxB22p6uUBmBLQ93OKto29VE=; b= d6rTAuDC1mA0Y161Y4h6LDMCq+oDVOH42equaPNb8g1BCdmNYp5XJTfTTz2IQA/M idHASnmTFcEngUvOpnF0sn3dUB+ZBHD7d3zBRJ33qqM4V5fs0+YHujDZ/4+mzAiv l/pOye3S1yQkr+q1RZcB21O2mNQxVH64mxE4nNXlYMMhxCl2bqm6rW/I2Gj3tD1U yCEd1dThdVVMPKLSo+zwG8ADVLm5mv6NRi7xFimt1ZefY5qjpfaGARUxnEK+KKTa rklq0u8nM3+I7nP9Zuhv0w22kdVQyqh+BuOVWOoMWTgpoSGTDIAP7Yx0DGCgDKbZ iLcmjWurCo6UqZLDMuQpbQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1707259172; x= 1707345572; bh=HE3yOJetf/tg6mBXaaJKxB22p6uUBmBLQ93OKto29VE=; b=n l0uUiJTIMN/pS7ewvEuh+goIeBPQQ5UCJb/v+szmr26loNJ3J0bPZp4sJH8XmKFF GMCJShYIoh56CyNZHMI+BKwbtK1RlXJE0yzlOLs2Ig9ZzEaPC21Ot68OoKeW1CYz aVjMAE6fly+u4TMuF8fsF86JQ+YyH040Kkz0ieYXRTG6DoYU1Y3tbOdC88cOOmXL pOQMEU65mQFS043W9h0QeSAh1gSD9u4+p5urHdp4EWWhwaGnyJTbZJczLKsfUHZ9 UJSpkfece6sFyLC1yxm3cfaM1TTld8Sc7EVdYCbNp5b1bgfZ9rSs9fLy61L29Z8x r9iYemktsO3CQ8Yu9PDZA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrtddugddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Feb 2024 17:39:31 -0500 (EST) From: Thomas Monjalon To: Ori Kam Cc: dsosnowski@nvidia.com, ferruh.yigit@amd.com, cristian.dumitrescu@intel.com, andrew.rybchenko@oktetlabs.ru, stephen@networkplumber.org, dev@dpdk.org, rasland@nvidia.com Subject: Re: [PATCH 1/4] ethdev: introduce encap hash calculation Date: Tue, 06 Feb 2024 23:39:30 +0100 Message-ID: <3266952.oiGErgHkdL@thomas> In-Reply-To: <20240128093943.4461-2-orika@nvidia.com> References: <20240128093943.4461-1-orika@nvidia.com> <20240128093943.4461-2-orika@nvidia.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 28/01/2024 10:39, Ori Kam: > During the encapsulation of a packet, it is expected to calculate the > hash value which is based on the original packet (the outer values, > which will become the inner values). It is not clear what the hash is for. > The tunnel protocol defines which tunnel field should hold this hash, > but it doesn't define the hash calculation algorithm. If the hash is stored in the packet header, I expect it to be reproducible when being checked. How the algorithm may be undefined? > An application that uses flow offloads gets the first few packets > and then decides to offload the flow. As a result, there are two > different paths that a packet from a given flow may take. > SW for the first few packets or HW for the rest. > When the packet goes through the SW, the SW encapsulates the packet > and must use the same hash calculation as the HW will do for > the rest of the packets in this flow. > > This patch gives the SW a way to query the hash value > for a given packet as if the packet was passed through the HW. > > Signed-off-by: Ori Kam > --- > +Calculate encap hash > +~~~~~~~~~~~~~~~~~~~~ > + > +Calculating hash of a packet in SW as it would be calculated in HW for the encap action We should give the real full name of the flow action. > + > +When the HW execute an encapsulation action, it may calculate an hash value which is based > +on the original packet. This hash is stored depending on the encapsulation protocol, in one > +of the outer fields. Give an example of such encapsulation protocol? > +This function allows the application to calculate the hash for a given packet as if the > +encapsulation was done in HW. > + > +.. code-block:: c > + > + int > + rte_flow_calc_encap_hash(uint16_t port_id, > + const struct rte_flow_item pattern[], > + enum rte_flow_encap_hash_field dest_field, > + uint8_t hash_len, > + uint8_t *hash, > + struct rte_flow_error *error); I don't think we should add the complete prototype in this guide. [...] > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice. > + * > + * Simulates HW hash calculation that is done when encap action is being used. s/Simulates/Simulate/ > + * > + * @param[in] port_id > + * Port identifier of Ethernet device. > + * @param[in] pattern > + * The values to be used in the hash calculation. > + * @param[in] dest_field > + * Type of destination field for hash calculation. > + * @param[in] hash_len > + * The length of the hash pointer in bytes. Should be according to encap_hash_field. > + * @param[out] hash > + * Used to return the calculated hash. It will be written in network order, > + * so hash[0] is the MSB. > + * The number of bytes is based on the destination field type. > + * @param[out] error > + * Perform verbose error reporting if not NULL. > + * PMDs initialize this structure in case of error only. > + * > + * @return > + * - (0) if success. > + * - (-ENODEV) if *port_id* invalid. > + * - (-ENOTSUP) if underlying device does not support this functionality. > + * - (-EINVAL) if *pattern* doesn't hold enough information to calculate the hash > + * or the dest is not supported. > + */ > +__rte_experimental > +int > +rte_flow_calc_encap_hash(uint16_t port_id, const struct rte_flow_item pattern[], > + enum rte_flow_encap_hash_field dest_field, uint8_t hash_len, > + uint8_t *hash, struct rte_flow_error *error);