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 475F2A055F for ; Mon, 17 Oct 2022 13:55:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 288374021D; Mon, 17 Oct 2022 13:55:03 +0200 (CEST) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by mails.dpdk.org (Postfix) with ESMTP id 73E0E40143; Mon, 17 Oct 2022 13:55:01 +0200 (CEST) Received: from dggpeml500024.china.huawei.com (unknown [172.30.72.56]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4Mrb0B0cH9z1P7RX; Mon, 17 Oct 2022 19:50:18 +0800 (CST) Received: from [10.67.100.224] (10.67.100.224) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 17 Oct 2022 19:54:34 +0800 Subject: Re: [PATCH v2] doc: fix support table for ETH and VLAN flow items To: Eli Britstein , Ilya Maximets , "dev@dpdk.org" , Ori Kam , "NBU-Contact-Thomas Monjalon (EXTERNAL)" CC: Ajit Khaparde , Somnath Kotur , Rahul Lakkireddy , Hemant Agrawal , Sachin Saxena , Simei Su , Wenjun Wu , John Daley , Hyong Youb Kim , Ziyang Xuan , Xiaoyun Wang , Guoyang Zhou , Dongdong Liu , Yisen Zhuang , Yuying Zhang , Beilei Xing , Jingjing Wu , Qiming Yang , Qi Zhang , Junfeng Guo , Rosen Xu , Matan Azrad , Slava Ovsiienko , Liron Himi , Jiawen Wu , Jian Wang , Dekel Peled , "stable@dpdk.org" References: <20221013104849.2677995-1-i.maximets@ovn.org> <69896d4d-ccdf-34c6-f14a-adbc99402054@ovn.org> From: fengchengwen Message-ID: Date: Mon, 17 Oct 2022 19:54:34 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.100.224] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected 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 Thanks Ilya and Eli On 2022/10/16 13:26, Eli Britstein wrote: > > >> -----Original Message----- >> From: Ilya Maximets >> Sent: Friday, October 14, 2022 3:37 PM >> To: fengchengwen ; dev@dpdk.org; Ori Kam >> ; NBU-Contact-Thomas Monjalon (EXTERNAL) >> ; Eli Britstein >> Cc: i.maximets@ovn.org; Ajit Khaparde ; >> Somnath Kotur ; Rahul Lakkireddy >> ; Hemant Agrawal >> ; Sachin Saxena ; >> Simei Su ; Wenjun Wu ; John >> Daley ; Hyong Youb Kim ; Ziyang >> Xuan ; Xiaoyun Wang >> ; Guoyang Zhou >> ; Dongdong Liu ; >> Yisen Zhuang ; Yuying Zhang >> ; Beilei Xing ; Jingjing Wu >> ; Qiming Yang ; Qi Zhang >> ; Junfeng Guo ; Rosen Xu >> ; Matan Azrad ; Slava Ovsiienko >> ; Liron Himi ; Jiawen Wu >> ; Jian Wang ; Dekel >> Peled ; stable@dpdk.org >> Subject: Re: [PATCH v2] doc: fix support table for ETH and VLAN flow items >> >> External email: Use caution opening links or attachments >> >> >> On 10/14/22 11:41, fengchengwen wrote: >>> Hi Ilya, >>> >>> I have some questions about has_vlan/has_more_vlan fields: >> >> I think, these questions are more for rte_flow maintainers, but I'll try answer. >> Maintainers can correct me if I'm wrong. >> >>> >>> a\ DPDK framework support cvlan-tag(0x8100) and svlan-tag(0x88A8), >>> and also deprecated qinq-tag(eg. 0x9100) >> >> Didn't check, but sounds about right. > It is not related to "DPDK framework". It is up to the HW to determine. >> >>> b\ If has_vlan is used, does it mean that all the VLAN >> tags(0x8100/88A8/9100) must be matched ? >>> I think this is different from using type, which can only match one of >> them. >> >> I think so. has_vlan = 1 means that packet has some vlan regardless of the >> actual type of the vlan header. > Again, it is up to the HW. >> >>> c\ And has_more_vlan has the same function as has_vlan ? >> >> Yes, from my understanding, 'has_more_vlan' is the same as 'has_vlan', but >> for the 'inner_type'. >> >>> d\ What the problems are solved by the new two fields? >> >> One of the problems we solved in OVS by using these fields is that we need a >> way to match on the fact that there is a vlan, but we do not care what this vlan >> tag is and at the same time we want to match on the inner type for such >> packets. >> >> Trying to workaround that situation will likely require breaking the 1:1 >> mapping between OVS flows and rte_flow rules, so it is not really possible. In >> the end, we had to use 'has_vlan' field to fix an incorrect packet matching in >> OVS. Alternative, I guess, would be to just not offload vlan flows, but doesn't >> make a lot of sense. >> >> Eli should know better what was the actual problem, I think. > OVS does not support offload of qinq, so "has_more_vlan" is still not in use. > For native (untagged) flows, there is a need to tell the HW "has_vlan is 0", otherwise the HW flow will hit both tagged/untagged traffic, which is wrong. > For tagged flows, OVS will always match on the VLAN properties, so "has_vlan is 1" can be deducted/implicit. > Before that field existed, it could be implicit to deduct "lack" of VLAN header (e.g. "eth / ipv4" for example) as "has_vlan is 0". However, other applications that would like both tagged/untagged traffic to hit needed to have 2 separated flows (with a probably slightly lower performance). Got it, Thanks. > Also, DPDK rte-flow is to have things explicit. >> >>> >>> >>> If the above understanding is correct, and the hardware support identify >> there TPID(cvlan-0x8100, svlan-0x88A8, dqing-0x9100) as VLAN, then: >>> Rule: eth has_vlan is 1 / vlan vid is 100 / ipv4 / end actions xxx >>> Result: all ipv4 packets with at least one VLAN(the TPID can be one of the >> above) and the vid is 100 can be matched. >>> >>> Rule: eth type is 0x8100 / vlan vid is 100 / ipv4 / end actions xxx >>> Result: all ipv4 packets with at lease one VLAN(which TPID must be >> 0x8100) and the vid is 100 can be matched. >>> >>> Rule: eth has_vlan is 1 / vlan vid is 100 has_more_vlan is 1 / vlan vid is 200 >> / ipv4 / end action xxx >>> Result: all ipv4 packets with at least two VLAN(the TPID can be one of the >> above) and outer vid is 100 and the next vid is 200 can be matched. >>> >>> Rule: eth type is 0x88A8 / vlan vid is 100 inner_type is 0x8100 / vlan vid is >> 200 / ipv4 / end action xxx >>> Result: all ipv4 packets with at least two VLAN(the first TPID is 0x88A8 and >> second TPID is 0x8100) and outer vid is 100 and the next vid is 200 can be >> matched. >>> Is the above result correct ? >> >> Seems correct, but I don't have much experience with rte_flow notations. >> >> Ori, could you comment on this? Assuming that A is the number of VLANs by flow creation, and B is the number of VLANs of real flow What I'm concerned about is: Whether the matching is successful only when A is equal to B? In addition, the maximum number of VLANs that can be parsed by hardware is limited, For example, if the hardware supports a maximum of two VLAN tags, a rule with the number of two VLAN tags is created for the RTE_Flow. However, the actual flow has more than two VLAN tags. Can this situation be matched? Hi Ori, Could you check on this? >> >> Best regards, Ilya Maximets. >> >>> >>> Thanks >>> >>> On 2022/10/13 18:48, Ilya Maximets wrote: >>>> '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. >>>> >>>> 'has_vlan' is part of 'rte_flow_item_eth', so changing 'eth' >>>> field to 'partial support' in documentation for all such drivers. >>>> 'has_more_vlan' is part of 'rte_flow_item_vlan', so changing 'vlan' >>>> to 'partial support' as well. >>>> >>>> This doesn't solve the issue, but at least marks the problematic >>>> drivers. >>>> >>>> Some details are available in: >>>> https://bugs.dpdk.org/show_bug.cgi?id=958 >>>> >>>> Fixes: 09315fc83861 ("ethdev: add VLAN attributes to ethernet and >>>> VLAN items") >>>> Cc: stable@dpdk.org >>>> >>>> Signed-off-by: Ilya Maximets >>>> --- >>>> >>>> Version 2: >>>> - Rebased on a current main branch. >>>> - Added more clarifications to the commit message. >>>> >>>> I added the stable in CC, but the patch should be extended while >>>> backporting. For 21.11 the cnxk driver should be also updated, for >>>> 20.11, sfc driver should also be included. >>>> >>>> doc/guides/nics/features/bnxt.ini | 4 ++-- >>>> doc/guides/nics/features/cxgbe.ini | 4 ++-- >>>> doc/guides/nics/features/dpaa2.ini | 4 ++-- >>>> doc/guides/nics/features/e1000.ini | 2 +- >>>> doc/guides/nics/features/enic.ini | 4 ++-- >>>> doc/guides/nics/features/hinic.ini | 2 +- >>>> doc/guides/nics/features/hns3.ini | 4 ++-- >>>> doc/guides/nics/features/i40e.ini | 4 ++-- >>>> doc/guides/nics/features/iavf.ini | 4 ++-- >>>> doc/guides/nics/features/ice.ini | 4 ++-- >>>> doc/guides/nics/features/igc.ini | 2 +- >>>> doc/guides/nics/features/ipn3ke.ini | 4 ++-- >>>> doc/guides/nics/features/ixgbe.ini | 4 ++-- >>>> doc/guides/nics/features/mlx4.ini | 4 ++-- >>>> doc/guides/nics/features/mvpp2.ini | 4 ++-- >>>> doc/guides/nics/features/tap.ini | 4 ++-- >>>> doc/guides/nics/features/txgbe.ini | 4 ++-- >>>> 17 files changed, 31 insertions(+), 31 deletions(-) >