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 2D7ABA32A4 for ; Fri, 25 Oct 2019 15:23:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E72641C1F4; Fri, 25 Oct 2019 15:23:34 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 19D431C124; Fri, 25 Oct 2019 15:23:33 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9166021C4E; Fri, 25 Oct 2019 09:23:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 25 Oct 2019 09:23:31 -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=mesmtp; bh=lIVXEQ/Nn5ctOaS4GRXZ7meUB7BNiwjgUi8ierV8UCI=; b=J9gkOd8bxjkZ 3wkVXhxPdEyxSo4cYGQkTPOXxwERV/P7pxyeC1rbuSi1SxQGz3wmjyFrx9tGFep8 yBhYpNQXyIoMJz//MuhruYHrdQSCGhkv641mku3u4W0p6WIEL2wznaE+EUr7TG6N 0iXUWIPNT7c/YId2j0ut09PBbg7BjDw= 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=lIVXEQ/Nn5ctOaS4GRXZ7meUB7BNiwjgUi8ierV8U CI=; b=yhrJKup9HzZX+lAd/Q5gJAMjlVcI1HPHgnAWO7WFARNq7GDzkvdXkO/t+ vFNAM8mbRN7eJVQuJaeHJ81rrra9iSiI/5xwAH5CNn3+QA527eNfaSrloQ/i4WZk zyt2Gck0B4nuRLFzQeygAP3vxwPN7Tj6S32lwm1I0KLrNmJIC1+Ni7qAYU/aaLdc 7Jb0Qs/u18aXU93I6EJgbDLkt69vLWD1zVsbz4+5XIyjq/nUOElV1QtpuUQMbe50 W71+OFYhmLCuvjjOCLFT1v2TP1hOQZdRpHB8CZdbdsZylq3QGLnzq9Lzid7zKtkj JXCB5WXbGTqsf/ZZXBFwB4jcrCKMw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrleefgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd 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 CC120D60063; Fri, 25 Oct 2019 09:23:29 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: John McNamara , Marko Kovacevic , dev@dpdk.org, stable@dpdk.org, Andrew Rybchenko , Adrien Mazarguil , Ajit Khaparde , Jerin Jacob Date: Fri, 25 Oct 2019 15:23:28 +0200 Message-ID: <2221169.ijzf7UYKas@xps> In-Reply-To: <20191025125118.47189-1-ferruh.yigit@intel.com> References: <20191025125118.47189-1-ferruh.yigit@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 1/2] doc: add PMD filtering features back 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" 25/10/2019 14:51, Ferruh Yigit: > Also filter definitions should be clarified more in the features > documentation so that all PMDs can easily figure out to announce or > not these filtering features, also users can understand better what to > expect from this feature. OK let's try to dig in some descriptions. [...] > +N-tuple filter > +-------------- > + > +Supports filtering on N-tuple values. What is n-tuple? 3-tuple is enough? > +Tunnel filter > +------------- > + > +Supports tunnel filtering. There are so many kinds of tunnels and filtering. What is minimum to declare such feature? Isn't it more relevant to list the supported tunnels? > +Flexible filter > +--------------- > + > +Supports a flexible (non-tuple or Ethertype) filter. This is meaningless and should be dropped for sure. > +* **[implements] eth_dev_ops**: ``filter_ctrl:RTE_ETH_FILTER_FLEXIBLE``. > +* **[related] API**: ``rte_eth_dev_filter_ctrl()``, ``rte_eth_dev_filter_supported()``. You are referring to the deprecated API here and in other places. > +Hash filter > +----------- > + > +Supports Hash filtering. Which hash? > +Flow director > +------------- > + > +Supports Flow Director style filtering to queues. I think it is an Intel wording. Could you describe it with networking words?