From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0FA15A0543 for ; Wed, 12 Oct 2022 17:30:26 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E501D43027; Wed, 12 Oct 2022 17:30:25 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 1B9B642EF7; Wed, 12 Oct 2022 17:30:24 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A52943200971; Wed, 12 Oct 2022 11:30:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 12 Oct 2022 11:30:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1665588620; x= 1665675020; bh=44p9JaCzC9Ah5B1NEX6SWXxeJZs7FcCvrdWCO7uY4j0=; b=N BxTVwWsgEieeaSIGFxFtHEkfocXuiGBGdmAg0EZse/ZsGDH+a1014884m5VTQVU6 KbyiZxCf6Q3eoyUxUi40c7BueXZuOnoOL8mqvTAOh70W8YwFzf8OLPTcnzkTlKoT TRXOyHTogcODqceMHjB1Fgp0VffqM/4aj7OGQIOq3eewzneG16X7O+22bjFpDe5u Ac0VrKbDGVfiN6GIrks7kUFelOxOKlK5n+NYfoN9icWgp1gQYHHM5zfGjZxWqZu9 89Qzm4OP5LLO/ZS0bLiayW9xeeO7U6PfOqTYL7hVCfO93Bjq1QicyLPvJALITTyQ 6mJCJRMB+a+3fA58uBw/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1665588620; x= 1665675020; bh=44p9JaCzC9Ah5B1NEX6SWXxeJZs7FcCvrdWCO7uY4j0=; b=I untpFFIvpvxNAbhDrrqsaZ3FLVwNyMEttl32ejIIAvu5lxYdBcoq3c8yNzvwgj/E W0c/dj+DuEqXak6l6wvtLv8aE+6jQc5zTgkLubntPgNxYFDiWK7LNhc7ilpXzEpG b2rNHlFKawkTonroEP8WdpyXZFuRhXegGZtDG/W9WkGYRo0DmPkCftTEbGuQtVvQ Xh8AMD4U4iMoZUTcEoC98ilFLmgTFyhxhZSk7NVmjZ2sDzcj9EHYPlbCbxW62IHf 80X5NhumHwlESMLLkK4cBOlqyBmseysdlW6L+I/iK41bKIyTUbCD3pVXFBnpCaNk NgVRP7xl7DlCBKUtCn1Lw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeejkedgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeejjefffffgffekfefflefgkeelteejffelledugefhheelffet heevudffudfgvdenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 12 Oct 2022 11:30:16 -0400 (EDT) From: Thomas Monjalon To: Ilya Maximets Cc: dev@dpdk.org, stable@dpdk.org, Ajit Khaparde , Rahul Lakkireddy , Hemant Agrawal , Haiyue Wang , John Daley , Guoyang Zhou , "Min Hu (Connor)" , Beilei Xing , Jingjing Wu , Qi Zhang , Rosen Xu , Matan Azrad , Viacheslav Ovsiienko , Liron Himi , Jiawen Wu , Ori Kam , ferruh.yigit@amd.com, andrew.rybchenko@oktetlabs.ru, david.marchand@redhat.com, olivier.matz@6wind.com Subject: Re: [PATCH] doc: fix support table for ETH and VLAN flow items Date: Wed, 12 Oct 2022 17:30:14 +0200 Message-ID: <6479268.QJadu78ljV@thomas> In-Reply-To: <96eb4c24-5a2c-98f0-9f27-4445a7f2732e@ovn.org> References: <20220316120157.390311-1-i.maximets@ovn.org> <96eb4c24-5a2c-98f0-9f27-4445a7f2732e@ovn.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org 07/10/2022 13:55, Ilya Maximets: > On 10/7/22 13:50, Ilya Maximets wrote: > > On 9/12/22 12:09, Thomas Monjalon wrote: > >> 16/03/2022 13:01, Ilya Maximets: > >>> 'has_vlan' attribute is only supported by sfc, mlx5 and cnxk. > >>> Other drivers doesn't support it. Most of them (like i40e) just > >>> ignore it silently. Some drivers (like mlx4) never had a full > >>> support of the eth item even before introduction of 'has_vlan' > >>> (mlx4 allows to match on the destination MAC only). > >>> > >>> Same for the 'has_more_vlan' flag of the vlan item. > >>> > >>> Changing the support level to 'partial' for all such drivers. > >>> This doesn't solve the issue, but at least marks the problematic > >>> drivers. > >> > >> You changed "eth" and "vlan" from "Y" to "P". > >> The field "has_vlan" is part of "rte_flow_item_eth", > >> and "has_more_vlan" is part of "rte_flow_item_vlan", > >> so I agree we need to change both items to "partial support". > >> It looks to be a good change, just needs to more explicit, > >> adding this kind of explanation about the fields. > > > > I can add this to the commit message. Should I also add > > some note alongside the table in that documentation page? I'm afraid it can be long and complex to add notes in the page about what is missing to get complete support for each feature/PMD. I think you can just re-spin with a clear explanation in the commit, so PMD maintainers can refer to it. > >> We missed this patch in 22.07, let's have some progress quickly. > > > > It was a busy month + PTO, sorry I didn't get to that patch faster. No problem, we are still on time for 22.11. > >>> Some details are available in: > >>> https://bugs.dpdk.org/show_bug.cgi?id=958 > >> > >> About rte_flow_item_eth.{src,dst}, I don't find a deprecation notice > >> about it in the history of the file doc/guides/rel_notes/deprecation.rst > > > > It took some time to find the deprecation notice, but I did find it > > in the end. It's in the doc/guides/rel_notes/deprecation.rst, and > > it says: > > > > * ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``, > > should start with relevant protocol header. > > Some matching pattern structures implements this by duplicating protocol header > > fields in the struct. To clarify the intention and to be sure protocol header > > is intact, will replace those fields with relevant protocol header struct. > > In v21.02 both individual protocol header fields and the protocol header struct > > will be added as union, target is switch usage to the protocol header by time. > > In v21.11 LTS, protocol header fields will be cleaned and only protocol header > > struct will remain. You're right, this is the general notice for rte_flow_item_*. > >> This is what we have in the code: > >> union { > >> struct { > >> /* > >> * These fields are retained for compatibility. > >> * Please switch to the new header field below. > >> */ > >> struct rte_ether_addr dst; /**< Destination MAC. */ > >> struct rte_ether_addr src; /**< Source MAC. */ > >> rte_be16_t type; /**< EtherType or TPID. */ > >> }; > >> struct rte_ether_hdr hdr; > >> }; > >> > >> Do you think we should remove the old fields now? > > > > From the OVS perspective, we do not care much. OVS is still using > > old fields, but it's fairly simple change that we can do while moving > > to a new version of DPDK. > > > > From the perspective of the API clarity, it's probably better to clean > > up these structures. > > There seems to be some outstanding work still though: > https://patches.dpdk.org/project/dpdk/patch/20210312110745.31721-1-ivan.malov@oktetlabs.ru/#129161 I think nobody took care of it so far. I will send a patch to clean the easy ones, and I will follow up with Ori for a complete plan. Thanks