From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 94F81A0524; Fri, 8 Jan 2021 15:55:33 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0C262141008; Fri, 8 Jan 2021 15:55:16 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id 72A11140FEC for ; Fri, 8 Jan 2021 15:55:13 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id E0C191A6F; Fri, 8 Jan 2021 09:55:11 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Fri, 08 Jan 2021 09:55:12 -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=fm3; bh= mgRmQpbejq9o8wkEHSoDqY7n7vDGB0+KZCHy2xa9imo=; b=lv7thk3q6wuxn1sV 6TukYqKAjck6qCV3i6/jyfyfxq4v/ZZShH5FcLXf1csdMy+c+B/eev4DYxP6BbSm AkE/u6+8GbTPlqJ6EQ50UODX8cKNCYZIwYqpyOdVixdh0eawW17CumB0GYSwG7RR 8DJCNneHljKsWBrjP+fL77agP1SFozrY4Hmz1DVtcfg1Zuas2NQy/8AZCaXAcGsT Pjckn+Wyf/UgtlpxJLA1DMTkaHKiJUsyzHxabfGDlDDcaPHejvkf4Bcf/9xUA8jC UxUN5nE4iDDIzc4WzSggwNh3Hum247wSVD4BXbHoD3cVDy1IayWniT9w7zVehTLv amN9Og== 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=mgRmQpbejq9o8wkEHSoDqY7n7vDGB0+KZCHy2xa9i mo=; b=UXr7MQQu6jzvMeSJZt6No4VoC0eU5t5oGtp3r1I50aQhBtPI0nhVQuhU8 /JVuiQOWNmTe6kDElJBuf4hvb43x5LntGPFrslcW8mWKFH6FjEO5SmoST/QbqTQX lhTPfZNmHlZw+UYOoobVlmLKN3L47Fq6E5luFx6RtJ/6AQEkxeClf5e5XAqiE9Nt G2PvCSt/pM+v44ilUUSnSejGN+0Hp6hwpvCGV2dQZH/LJTZwnHva585pznqAK/Hf 1/nCH//+RpNU7lW0fwTGmE/8840EPSdUnf9d66ce2txDx8NN73FMT4opoFpPBqc8 n+Ss5NKD4WEw4I4vOxC4KUVS+B50Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeghedgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 49DDC240062; Fri, 8 Jan 2021 09:55:10 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit Cc: Tal Shnaiderman , dev@dpdk.org, matan@nvidia.com, rasland@nvidia.com, ophirmu@nvidia.com, Dekel Peled Date: Fri, 08 Jan 2021 15:55:09 +0100 Message-ID: <2671191.3mBJzJ6San@thomas> In-Reply-To: References: <20201217173037.11396-2-talshn@nvidia.com> <20201228123302.3608-25-talshn@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 24/35] net/mlx5/windows: introduce flow support 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 Sender: "dev" 08/01/2021 15:38, Ferruh Yigit: > On 12/28/2020 12:32 PM, Tal Shnaiderman wrote: > > From: Ophir Munk > > > > This patch adds the initial flow framework under Windows OS. It supports > > a subset of filters (ETH, IPV4, UDP) and a QUEUE action. It is based on > > DevX mechanism to send commands to the NIC through the kernel. It does > > not support steering rules (i.e. writing directly to the NIC memory). > > The Windows framework uses the existing DV framework where file > > mlx5_flow_dv.c remains intact. > > > > Steps involved in flow creation: > > 1. Create a domain (RX, TX, FDB). Since domains are created by steering > > rules and not with DevX, Windows does not require a domain object (this > > means switch dev mode which requires an FDB domain is not supported). > > 2. Create a table object. Windows only supports table 0. The call to > > mlx5_flow_os_create_flow_tbl() silently returns successfully. > > 3. Create a matcher object. A matcher struct is created by calling > > mlx5_flow_os_create_flow_matcher(). The matcher validation and > > translation are part of the DV implementation. The matcher bits that > > were created by DV in standard PRM format are copied into the matcher > > struct. > > 4. Create an action object. The call to > > mlx5_flow_os_create_flow_action_dest_devx_tir() creates an action struct > > with the TIR type and id. This struct will be a parameter later in a > > call to flow creation. All other action calls (e.g. packet reformat, > > header modification, jump to flow table, etc) return with a non > > supported error. > > 5. Create the flow. The call to mlx5_flow_os_create_flow() receives the > > matcher struct, action struct, and copy them into Windows specific > > fs_rule struct, then it calls glue API devx_fs_rule_add(). > > > > Details on additional APIs: > > * mlx5_flow_os_get_type() is called during flow type selection. In > > Windows it constantly returns MLX5_FLOW_TYPE_DV. > > * mlx5_flow_os_item_supported() is called before starting DV items > > validation or translation. It filters out the OS non supported items in > > advance. > > * mlx5_flow_os_action_supported() is called before starting DV actions > > validation or translation. It filters out the OS non supported actions > > in advance. > > * mlx5_flow_adjust_priority() is an OS stub for flow priority > > adjustment. Windows only supports flow priority 0. > > * Alarm API: mlx5_os_alarm_cancel() and mlx5_os_alarm_set() are > > implemented in Windows to match their Linux counterpart, see [1]. > > Currently they return -ENOTSUP. > > > > [1] > > ("net/mlx5/linux: wrap rte alarm API with mlx5") > > Can you please provide commit hash for this commit, I can amend it later in the > next-net? It looks to be garbage. There is no alarm-related function in this patch. Please remove these lines from the message.