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 C60D643EE9; Tue, 23 Apr 2024 13:45:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7998740E54; Tue, 23 Apr 2024 13:45:10 +0200 (CEST) Received: from agw.arknetworks.am (agw.arknetworks.am [79.141.165.80]) by mails.dpdk.org (Postfix) with ESMTP id 83DE0402AB for ; Tue, 23 Apr 2024 13:45:09 +0200 (CEST) Received: from debian (unknown [78.109.68.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by agw.arknetworks.am (Postfix) with ESMTPSA id 24A8FE0BFF; Tue, 23 Apr 2024 15:45:02 +0400 (+04) DKIM-Filter: OpenDKIM Filter v2.11.0 agw.arknetworks.am 24A8FE0BFF DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arknetworks.am; s=default; t=1713872703; bh=e527ibyHHUlHH1qw35tVlFkSf5qWxGG7+7tXdIJHiR4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=53Sry0213NempQTVHo0pXesKqcyyyBqbvnVjCKmX6Vz9kQOunjiP+6dXY9+xIsrYw dcwE3N0R77dgwvr1XtT1R4EMa4m7DnUxOCo2ei8nEcoKT7/t1fn7forUuWO3jGeNNM ROFFuTBvzNMTQLc7nVSib9rd4p/AoRyUmppxXnjl4u2XddBGbNIKNgettLd5rj/gzX pyaUgTv/4ZrCaLdnVFFn1Z+czIhXuU+upKtXvJqY0xXtcB6o5UJenXc4YlwkAedRKH Au5RnLYC8/OG9qTZzAhhi3bJY2MWr4jfzMopgp20BVKlyRVRqISC6PFQlEWmVy/xzY v3A8A3AT2s2Qw== Date: Tue, 23 Apr 2024 15:44:25 +0400 (+04) From: Ivan Malov To: Jie Hai cc: Yuying Zhang , Aman Singh , Thomas Monjalon , "ferruh.yigit@amd.com >> Ferruh Yigit" , andrew.rybchenko@oktetlabs.ru, dekelp@nvidia.com, psatheesh@marvell.com, adrien.mazarguil@6wind.com, fengchengwen , Huisong Li , Dengdui Huang , "dev@dpdk.org" , Ori Kam Subject: Re: question about eth and vlan item in flow pattern In-Reply-To: <75671ef0-70b6-2611-6ab4-1876b2724103@huawei.com> Message-ID: References: <6db61bde-eb34-d7e5-cb46-c08a3268a2a4@huawei.com> <88394620-bf43-92af-840b-89f5e7c50a23@arknetworks.am> <75671ef0-70b6-2611-6ab4-1876b2724103@huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-1132098255-1713872675=:6899" 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1132098255-1713872675=:6899 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi, Please see below. On Tue, 23 Apr 2024, Jie Hai wrote: > Hi, Ivan Malov, > Sorry for the late reply. > On 2024/4/10 21:19, Ivan Malov wrote: >> Hi Jie, >> >> Consider the following examples: >> 1) flow create 0 ingress pattern eth / ipv4 proto is 17 / udp / end \ >>    actions queue index 1 / end >> 2) flow create 0 ingress pattern eth / ipv4 / udp / end \ >>    actions queue index 1 / end >> >> Generally speaking, these two rules might be equivalent, with "proto is 17" >> in >> the first one probably being redundant (the very presence of "udp" item >> might >> stand for the same match criterion -- the protocol ID being 17). > I can understand that. Very well. >> >> And I'd be tempted to treat the "has_vlan" case similarly. Consider: >> 3) flow create 0 ingress pattern eth has_vlan is 1 / vlan / end \ >>    actions queue index 1 / end >> 4) flow create 0 ingress pattern eth / vlan / end \ >>    actions queue index 1 / end >> >> (rule (3) is similar to "rule-0" from your example) >> >> Rules (3) and (4) seem equivalent to me -- the "has_vlan is 1" bit might be >> redundant in flow (3) -- the presence of item "vlan" sort of means the >> same. > >> Rule (3) and (4) should probably match both single-tagged and double-tagged >> packets because, in both cases, the pattern does not clarify which protocol >> follows the outermost VLAN tag. If one needs to exclude double-tag match, >> they should clarify the rule in one of the possible ways, in example: >> >> - pattern eth / vlan has_more_vlan is 0 / end >> - pattern eth / vlan tpid is 0x0800 / end >> - pattern eth / vlan / ipv4 / end >> >> (the "tpid" goes to the "hdr.eth_proto" of "struct rte_flow_item_vlan"). >> > As mentioned above, `has_vlan is 1` and `vlan` are the same, > which means `vlan` stands for any-tagged vlan, > Then, is the introduction of `has_vlan` and `has_more_vlan` unnecessary? It's not clear why you believe it's unnecessary. Some vendors support boolean match on "is outer VLAN present" and "is inner VLAN present" in addition to exact match on TPID/TCI. It may be convenient to expose these match criteria as sub-fields in ETH and VLAN items. This should allow for faster parsing as one can drop item VLAN from pattern in case there's no intention to match on TPID/TCI. > > There are drivers seeing `vlan` an one vlan layer and match 'eth/vlan/end' > with single-tagged packets, e.g.bnxt, hns3, etc. > I think this meaning makes it easier to distinguish the functions of the two. > > The `has_more_vlan is 1` is defined and used by some drivers, like mlx5. > While the `has_more_vlan is 0` is not defined. What do you mean by saying "not defined"? Not defined where? Having "has_more_vlan is 0" is perfectly legit, isn't it? > Here you give the meaning as `having no vlan after this vlan`. > Then, What should the follow rule mean? single-tagged or double tagged? > > - pattern eth / vlan tpid is 0x8100 has_more_vlan is 0 / end Item VLAN here is supposed to describe the header _immediately_ following the ETH one, isn't it? If so, the rule means single-tagged. Doesn't it? Thank you. > >> With regard to the question about VLAN ID match, "pattern eth / vlan vid is >> 10", >> as well as "pattern eth has_vlan is 1 / vlan vid is 10", should probably >> match >> only on the outermost tag ID, -- that is, not on the inner one and not on >> both. > I agree with it. >> That is because the "vid is 10" criterion relates to the specific header, >> as per the match item it sits in. If the user wants to match on the >> inner VLAN ID (say, 11), they should clarify specify it as follows: >> >> - pattern eth / vlan vid is 10 / vlan vid is 11 / end >> - pattern eth / vlan / vlan vid is 11 / end >> > >> Hopefully, the rest of DPDK vendor community can correct me in case I got >> that wrong. Should you have more questions, please feel free to ask such. >> >> Thank you. >> >> On Wed, 10 Apr 2024, Jie Hai wrote: >> >>> Hi, all, >>> >>> I have some questions about the sub-options for ``VLAN`` and ``ETH`` item. >>> >>> According to the documentation, ``has_vlan`` is sub-option of ``ETH`` >>> item and it means that the pattern contains at least one vlan. >>> The ``VLAN`` item is used to match tagged packets and have some >>> sub-options such as ``vid``, ``tci``, etc. >>> >>> If we combine them, what should the effect be? >>> For instance, >>> >>> rule-0: flow create 0 ingress pattern  eth  has_vlan is 1 / vlan  / end >>> actions queue index 2 / end >>> rule-1: flow create 0 ingress pattern  eth  has_vlan is 1 / vlan vid is 10 >>> / end actions queue index 2 / end >>> >>> For rule-0, should it match single-tagged packets only or multi-tagged >>> only or both? >>> That is to say, which one will take effect, `has_vlan is 1`  or `vlan` or >>> both? >>> >>> For rule-2, which packets should it match, with inner VLAN id 10, or outer >>> VLAN id 10, or both 10? >>> >>> The hns3 driver supports only the exact matching of VLAN numer. >>> And it is planned to adapt ``has_vlan`` and ``has_more_vlan`` to the >>> meaning of one VLAN for hns3 driver. Therefore, if the preceding >>> combinations are supported, we need to confirm the exact meanings. >>> >>> So, what are your views on the above question? >>> >>> >>> >>> >> . > --8323328-1132098255-1713872675=:6899--