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 6A387A0548; Tue, 24 Aug 2021 18:20:27 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DD584406A3; Tue, 24 Aug 2021 18:20:26 +0200 (CEST) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by mails.dpdk.org (Postfix) with ESMTP id 8A21440687 for ; Tue, 24 Aug 2021 18:20:26 +0200 (CEST) Received: (Authenticated sender: i.maximets@ovn.org) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id DA0ABFF80E; Tue, 24 Aug 2021 16:20:23 +0000 (UTC) To: Eli Britstein , Ilya Maximets , "Finn, Emma" , "dev@openvswitch.org" Cc: "Stokes, Ian" , Sriharsha Basavapatna , Gaetan Rivet , Majd Dibbiny , Salem Sol , Andrew Rybchenko , Ori Kam , dev References: <20210816135433.1922261-1-elibr@nvidia.com> <221d1783-58c0-5cb4-eb0d-c6ff5648636f@nvidia.com> <7f98de95-144f-bddd-6747-da145fc1e6d9@ovn.org> <6eae08ab-dc19-7623-ba2c-e76f8c435659@nvidia.com> From: Ilya Maximets Message-ID: Date: Tue, 24 Aug 2021 18:20:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <6eae08ab-dc19-7623-ba2c-e76f8c435659@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH V3 1/2] netdev-offload-dpdk: Use has_vlan match attribute 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" On 8/24/21 6:04 PM, Eli Britstein wrote: > > On 8/24/2021 6:47 PM, Ilya Maximets wrote: >> External email: Use caution opening links or attachments >> >> >> On 8/24/21 5:25 PM, Eli Britstein wrote: >>> On 8/24/2021 6:08 PM, Finn, Emma wrote: >>>> External email: Use caution opening links or attachments >>>> >>>> >>>> -----Original Message----- >>>> From: Eli Britstein >>>> Sent: Monday 16 August 2021 14:55 >>>> To: dev@openvswitch.org; Ilya Maximets >>>> Cc: Finn, Emma ; Stokes, Ian ; Sriharsha Basavapatna ; Gaetan Rivet ; Majd Dibbiny ; Eli Britstein ; Salem Sol >>>> Subject: [PATCH V3 1/2] netdev-offload-dpdk: Use has_vlan match attribute >>>> >>>> DPDK 20.11 introduced an ability to specify existance/non-existance of VLAN tag by [1]. >>>> Use this attribute. >>>> >>>> [1]: 09315fc83861 ("ethdev: add VLAN attributes to ethernet and VLAN items") >>>> >>>> Signed-off-by: Eli Britstein >>>> Reviewed-by: Salem Sol >>>> >>>> Hi Eli, >>>> >>>> I tested this but currently we don't have support in the i40e pmd for the has_vlan match attribute and with these patches it is breaking offload for VLAN packets on Intel devices. >>> Hi Emma, >>> >>> Thanks for testing. >>> >>> Is adding such support in your plans? >>> >>> How do you suggest to proceed? It is needed in order to fix OVS bug. >>> >>> Thanks, >>> >>> Eli >> The "Table 1.2 rte_flow items availability in networking drivers" >> here: https://doc.dpdk.org/guides/nics/overview.html >> says that both ixgbe and i40e has a full support for 'vlan' and >> 'eth' items.  Is it a bug?  Should it be 'partial' instead? >> >> In general, this sounds like a big limitation of rte_flow API. >> I mean the fact that there is no way to get what is implemented by >> a particular driver and what is not implemented in runtime. >> Someone should, probably, work on adding this kind of API to DPDK. >> Otherwise, we will stuck with inability to use certain actions/matches >> unless all the drivers supports them (which is also hard to check >> taking documentation issues into account).  If I missed it and the >> API actually exists, we should definitely start using it. >> >> CC: dpdk-dev and rte_flow maintainers. >> >> Thoughts? > > There is such an API - rte_flow_validate(). > > However, in OVS, as each flow is independent and can have different matches and actions, we just call rte_flow_create(). The PMD (at least mlx5) first internally validates it (as if rte_flow_validate() is called), and bail out with a failure in case validate fails. > > Can you suggest an effective way to utilize it in OVS? This one is hard to use. And I guess, it's hard to determine what exactly is not supported as some things can be only supported in certain combinations or otherwise not supported in certain combinations. So, rte_flow_validate() doesn't seem to be suitable for checking particular features and alternating the flow construction based on that. If we had clear yes/no flags for all features that could be easily probed/verified or otherwise retrived from the driver, that would be better. But it seems to be a problem for current rte_flow implementations in actual drivers. > > In theory, if the API exists in rte_flow, OVS should not care if all PMDs support it or not. > > In practice, the "has_vlan" field was introduced only in 20.11, and apparently Intel has not adapted i40e PMD, so it breaks their offloads. I suspected this so I've added Emma and Ian to review it. > > I don't know i40e HW capabilities, but at least from PMD point of view, it can be silently ignored until a proper support is added. > >> >> Best regards, Ilya Maximets.