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 3054AA04B7; Tue, 13 Oct 2020 14:42:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3DBEA1BDFD; Tue, 13 Oct 2020 14:42:00 +0200 (CEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by dpdk.org (Postfix) with ESMTP id 997621BD17 for ; Tue, 13 Oct 2020 14:41:57 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 1644EC0D; Tue, 13 Oct 2020 08:41:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 13 Oct 2020 08:41:54 -0400 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=fm2; bh= tZT4VOqYbYx6X8tRY6rizcZfIp5dMMQCm2Htd2BzLrk=; b=bBNkhnv4N47swYpS AsOYnHDbRwn/dYnstfqlmB+uEqA/e/IhI7S6vUqTxD8MP1LaHXg6i8UzVkgt5RxN 92gpjUs6RU5DM7DQ9nbYphzY0D/cQ/s4zswBwce0plB5xXPnbSOdzlX6zN1SVMW7 P7SuYQNLlALRg6gPmlYwaNwrcJSusoJiTDDEnZmoOPMD3dM8Tn8kWmUl6bAZFmwc eO1Mb4tYpDaoI6UY/rEjeMJ8K4Ptv/gQKNSCDfoOXri9FHBHTF4rdUFU0Lnxj+Qu kpa1hqdiaWyewmH3WWLbB8robsCIpVZDs6qOxZeg2bHKzsSS3WP6ZQGeC/er6PBx AAQOJw== 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=tZT4VOqYbYx6X8tRY6rizcZfIp5dMMQCm2Htd2BzL rk=; b=DOC2mGlt2SeukBoqRcksr+4IOeKSQRC1Ulijt/NNB8OhzrlJoi7y4/7jd bBpbYmPtH2DJ9xKRBTTX4xIXZMa7LprGhJT3ZO8LSnUofkpmC+02VD8EfKSHH0Di PrgAM570mC6gRvYEyygE5u/op8fQEclD2ji0C6MEWcNZqrAcaB8iTiEdEjDn4Gno ja8tBbUOSMUPfr4BvD2umVvgF38CgHwkiYigTeYRPEiwexyorLUEkpBdZp95bKme OcuEvmnIg/IvaGWwTYLpIfNV7Re4xODkaqfCBInKTjBo6O8yZbznCy8dFEERscCP EPpdRLyMN9GDpv0zORl4rNPeoXeng== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrheelgdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth 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 EB00F3064680; Tue, 13 Oct 2020 08:41:48 -0400 (EDT) From: Thomas Monjalon To: Bing Zhao Cc: Ori Kam , "ferruh.yigit@intel.com" , "arybchenko@solarflare.com" , "mdr@ashroe.eu" , "nhorman@tuxdriver.com" , "bernard.iremonger@intel.com" , "beilei.xing@intel.com" , "wenzhuo.lu@intel.com" , "dev@dpdk.org" Date: Tue, 13 Oct 2020 14:41:47 +0200 Message-ID: <1745030.Et98dJ8b6a@thomas> In-Reply-To: References: <1602147098-9768-1-git-send-email-bingz@nvidia.com> <2115353.iQtFZFVSCL@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 2/6] ethdev: add new attributes to hairpin config 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" 13/10/2020 14:29, Bing Zhao: > From: Thomas Monjalon > > 08/10/2020 14:05, Bing Zhao: > > > struct rte_eth_hairpin_conf { > > > - uint16_t peer_count; /**< The number of peers. */ > > > + uint32_t peer_count:16; /**< The number of peers. */ > > > > Why not keeping uint16_t? > > The inside structure has a multiple of 4B, and the peer_count now only takes about 2B. AFAIK, usually, the structure will have an aligned length/offset and there will be some padding between the 2B + (2B pad) + 4B * 32 or 2B + (2B +2B) * 32 + 2B, depending on the compiler. > I changed to bit fields of a u32 due to the two facts: > 1. Using the 2B and keep the whole structure aligned. No waste except the reserved bits. > 2. Only u32 with bit fields is standard. Oh I see, this is because u16 bit fields are not standard? > > > + uint32_t tx_explicit:1; /**< Explicit TX flow rule mode. */ > > > + uint32_t manual_bind:1; /**< Manually bind hairpin queues. > > */ > > > > Please describe more the expectations of these bits: > > What is changed at ethdev or PMD level? > > In ethdev level, there is almost no change. This attribute will be passed to PMD directly through the function pointer. > In PMD level, these bits should be checked and better to be saved. And the attribute fields should be checked for per queue pair and all the queues, and each queue pair should have the same attributes configured to make the behavior aligned. But it depends on the PMD itself to decide if all the queue pairs between a port pair should have the same attributes, or even all the queues from / to same port of all hairpin port pairs. > If manual_bind is not set, then the PMD will try to bind the queues and enable hairpin during device start stage and there is no need to call the bind / unbind API. > If tx_explicit is set, the application should insert the RX flow rules and TX flow rules seperataly and connect the RX/TX logic connection together. > > > What the application is supposed to do? > > The application should specify the new two attributes during the queue setup. And also, it could leave it unset (0 by default) to keep the behavior compatible with the previous release. > If manual_bind is set, then it is the application's responsibility to call the bind / unbind API to enable / disable the hairpin between specific ports. > If tx_explicit is set, as described above, the application should maintain the flows logic to make hairpin work as expected, e.g., they can choose metadata (not the only method), in the RX flow, the metadata is set and in the TX flow, it is used for matching. Then even if the headers are changed with NAT action or encap, the hairpin function could work as expected. > > > Why choosing one mode or the other? > > If the application wants to have the full control of hairpin flows, it could chose the explicit TX flow mode. > If two or more ports involved into the hairpin, it is suggested to use the manual bind. > Please note, the actual supported attributes denpend on the PMD and HW. The application impact must be described shortly in doxygen please.