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 7AABDA0573; Thu, 5 Mar 2020 17:35:38 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0E3BC2BB8; Thu, 5 Mar 2020 17:35:37 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 5EEC13B5 for ; Thu, 5 Mar 2020 17:35:36 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A479821C1E; Thu, 5 Mar 2020 11:35:35 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 05 Mar 2020 11:35:35 -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=mesmtp; bh=c99rSFmqZk0JYkmIGiOdGyk+5B6ZHwn1Wuh2RtRygak=; b=DehTt+jcTs4V V1XqVDKfGN5RD+P829z5YY4LyIK//x91LtwJTJz9C5aU+9azqMr2i0fhzbHL6mI2 E8fE2cJsAatNCzkNwEg1nbUIGQhBKL4SKxaJkJ247lNqt5+YjpiisXjmw1lCwQGk ND0JCJAPnOoGyJkRq3ZfdDeakiOnXcQ= 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=fm2; bh=c99rSFmqZk0JYkmIGiOdGyk+5B6ZHwn1Wuh2RtRyg ak=; b=3qwIlyp9gLzpzFG7D5F21/ZFDOBGyw7H3RfV4B3QLYM28A5cRiY7D1BTV LMpeSV+bEMqWWVb5SdvqPTAbwhFmd/D9j1cb5l/lvXkcRsqe5IL1R9Fq17dSM8EV UPtbgoNDXFuZX/rBYCKcfq+x7tYFqyuwJYsHJYkM3mknYBk1YlBqeLAMaLcG1dF3 QbR1CTsdtO4pI11Xu8AJTZQFF2OFESiBAENm3R0ov+BwlIFSQ2OSErLR5LbrM86l /s6Cf6ze2lo3v94Mmz4ApuBxKNYdiV/0xR30fcGMy55JIf+RZiMAU9b+RBk8Q22M kADJQ8nQecjT13s0xD8DZM86P6Uig== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddutddgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpehinhhtvghlrdgtohhmnecukfhppeejjedrudefgedrvddtfedrudekgeen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomh grshesmhhonhhjrghlohhnrdhnvght 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 62F77328005A; Thu, 5 Mar 2020 11:35:34 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, David Marchand , Andrew Rybchenko , Xiaolong Ye , Qi Zhang Date: Thu, 05 Mar 2020 17:35:32 +0100 Message-ID: <1814489.fIoEIV5pvu@xps> In-Reply-To: References: <20200305145533.1363013-1-ferruh.yigit@intel.com> <2211186.yKrmzQ4Hd0@xps> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [PATCH] devtools: add more headline case rules 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" 05/03/2020 17:06, Ferruh Yigit: > On 3/5/2020 3:11 PM, Thomas Monjalon wrote: > > 05/03/2020 15:55, Ferruh Yigit: > >> FDIR -> Flow Director > >=20 > > In general I prefer avoiding FDIR for two reasons: > > 1/ this is an Intel-only acronym >=20 > Yes, it is "Intel Ethernet Flow Director" but still it is a valid abbrevi= ation > and we have it in our git logs. >=20 > > 2/ rte_flow API is superseding it >=20 > I think there is a confusion here, two things seems confused. >=20 > Flow director is a NIC feature for filtering different flows to different > queues. It is kind of advanced RSS [1]. >=20 > You can use rte_flow to program FDIR, which is what we are doing for a wh= ile. So > this is *not* something conflicts with rte_flow. >=20 > Also there is 'filter_ctrl' API (rte_eth_dev_filter_ctrl) which is deprec= ated, > and which can be used to control HW filtering, including FDIR. >=20 > So 'rte_flow' doesn't supersede 'FDIR', it supersede 'filter_ctrl' API, a= nd > 'FDIR' feature can be used with rte_flow. Yes I understand the difference between the vendor's naming of the feature = and the API. > [1] > https://software.intel.com/en-us/articles/setting-up-intel-ethernet-flow-= director > " > Intel=AE Ethernet Flow Director (Intel=AE Ethernet FD) directs Ethernet p= ackets to > the core where the packet consuming process, application, container, or > microservice is running. It is a step beyond receive side scaling (RSS) i= n which > packets are sent to different cores for interrupt processing, and then > subsequently forwarded to cores on which the consuming process is running. >=20 > Intel Ethernet FD supports advanced filters that direct received packets = to > different queues, and enables tight control on flow in the platform. It m= atches > flows and CPU cores where the processing application is running for flow > affinity, and supports multiple parameters for flexible flow classificati= on and > load balancing. When operating in Application Targeting Routing (ATR) mod= e, > Intel Ethernet FD is essentially the hardware offloaded version of Receiv= e Flow > Steering available on Linux* systems, and when running in this mode, Rece= ive > Packet Steering and Receive Flow Steering are disabled. > " As said above, "flow steering" is a well understood description of such a f= eature. I don't see the need for using "FDIR" instead of "flow steering". The other issue is that I see other vendors using this term which should be reserved to Intel. Adding FDIR to the dictionary may increase the confusion. At the end, it is OK to use vendor-specific acronyms, the most important to me was to explain things in this discussion :-) > >> OOB -> Out Of Bounds > >=20 > > I don't think it is a good idea to use this acronym. It is not a techno. > > I prefer out-of-bounds with all letters. >=20 > This is coming from the git history, it seems we have used it in past at = least > once. Do you prefer to drop it? I prefer to drop yes. It could also mean Out Of Band, so it is confusing.