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 84A07A00C4; Thu, 31 Oct 2019 15:49:51 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E6ECB1C29F; Thu, 31 Oct 2019 15:49:50 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id 391571C295 for ; Thu, 31 Oct 2019 15:49:49 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 190F76DF3; Thu, 31 Oct 2019 10:49:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 31 Oct 2019 10:49:47 -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=/v4cjoS6FOPDvLt+PePwLk0CsWtfSOp+KjdCOF6m3s4=; b=p/qj715lIcnG AJ9qG0ts6CABGqVPUVO8bA/922LOM32C8wsq6lrQHC7gYbyslspM7bbE+kFNFagJ YKSkBvDsHo21HZiwcs9ky3cDV38i0hQDApgoGIql06Vld+ver6A6zMiWlV/z/W55 PCHQH2RzNM1fAwrOU4V1TjfMBXyAfmM= 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=/v4cjoS6FOPDvLt+PePwLk0CsWtfSOp+KjdCOF6m3 s4=; b=s1NiWt+T/Tg1d7KfM6W5eb9ulIN1tdU9cJA7ZwPenmt1Xg0xie7NJdTFZ MwTBgAKxfNkVrxOOKRSqEAI3sUsF/r9r7HvdzfyENAsUFe5uLJtUMTODk5IyN2h+ iT4Xo7NyDFmflA/zIzjRkeZeJ2D79EfF5IN+irpXEblK2EI7EEdvnifAN76NmTK0 paOR1wC2f2ngLTAOvV7tKdKpOlEVMAtXmcvumSnlVfrAWnIsO5RMlfqQa3bQ/4Oq iKnpIHJF/N+hrlVP++YHRoGNqP5pWYgG9U04JPEWru5vQoW71qbJEhrPHoZRguKR mA1XfZgExp+/V20NnCkt1IccUJOoQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddthedgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpehinhgsohigrdguphgukhdpohigrdgtohhmpdegtdhsohhlrghrfhhlrghr vgdrtghomhdpohhuthhlohhokhdrtghomhenucfkphepjeejrddufeegrddvtdefrdduke egnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhn vghtnecuvehluhhsthgvrhfuihiivgeptd 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 3245680063; Thu, 31 Oct 2019 10:49:44 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko Cc: dev@dpdk.org, Ori Kam , "pbhagavatula@marvell.com" , "ferruh.yigit@intel.com" , "jerinj@marvell.com" , John McNamara , Marko Kovacevic , Adrien Mazarguil , david.marchand@redhat.com, ktraynor@redhat.com Date: Thu, 31 Oct 2019 15:49:43 +0100 Message-ID: <3078181.9TjvbByyqQ@xps> In-Reply-To: References: <20191025152142.12887-1-pbhagavatula@marvell.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add flow action type update as an offload 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" 31/10/2019 10:49, Andrew Rybchenko: > On 10/28/19 5:00 PM, Ori Kam wrote: > >> -----Original Message----- > > From: Andrew Rybchenko > >> On 10/28/19 1:50 PM, Ori Kam wrote: > >>> Hi Pavan, > >>> > >>> Sorry for jumping in late. > >>> > >>> I don't understand why we need this feature. If the user didn't set any flow > >> with MARK > >>> then the user doesn't need to check it. > >> There is pretty long discussion on the topic already, please, read [1]. > >> > >> [1] > >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Finbox.dpdk > >> .org%2Fdev%2F3251fc00-7598-1c4f-fc2a- > >> 380065f0a435%40solarflare.com%2F&data=02%7C01%7Corika%40mellan > >> ox.com%7Ce3f779d4b7c44b682d6508d75b9d8688%7Ca652971c7d2e4d9ba6a4 > >> d149256f461b%7C0%7C0%7C637078604439019114&sdata=sYooc%2FQ3C > >> kUZG3gRFPlZrm8xMfMB9gOWWex5YIkWhMc%3D&reserved=0 > >> > > Thanks for the link, it was an interesting reading. > > > >>> Also it breaks compatibility. > >> Yes, there is a deprecation notice for it. > >> > >>> If my understanding is correct the MARK field is going to be moved to > >> dynamic field, and this > >>> will be way to control the use of MARK. > >> Yes and I think the offload should used to request dynamic > >> field register. Similar to timestamp in dynamic mbuf examples. > >> Application requests Rx timestamp offload, PMD registers dynamic > >> filed. > >> > > In general it was decided that there will be no capability for rte_flow API, due to the fact that > > it is impossible to support all possible combinations. For example a PMD can allow mark on Rx > > while not supporting it on e-switch (transfer) or on Tx. > > The only way to validate it is validating a flow. If the flow is validated then the action is supported. > > This is the exact approach we are implementing with the Meta feature. > > So as I see it, the logic should be something like this: > > 1. run devconfigure. > > 2. allocate mempool > > 3. setup queues. > > 4. run rte_flow_validate with mark action. > > If flow validated register mark in mbuf else don't register. > > If the PMD needs some special setting for mark he can update the queue when he gets the flow to validate. > > At this stage the device is not started so any change is allowed. > > I understand why there is capability reporting in rte_flow API when > it is about rte_flow API itself. The problem appears when rte_flow > API starts to interact with other functionality. > Which pattern/actions should application try in order to decide > if MARK is supported or not. Why application should decide whether MARK is supported or not? In my understanding it can be enabled dynamically per flow. > The right answer is a pattern/action > which will be really used, but what to do if there are many > combinations or if these combinations are not know in advance. > Minimal? But I easily imagine cases when minimal is not supported, > but more complex real life patterns are supported. > > The main idea behind the offload is as much as you know in advance > as much you can optimize without overcomplicating drivers and HW. > > In the case of OVS, absence MARK offload would mean that OVS > should not even try to use partial offload even if it is enabled. > So, no efforts are required to try to convert flow into pattern and > validate the flow rule. That's an interesting feedback. I would like to understand why OVS cannot adapt its datapath on demand per port, per queue and per flow?