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 86F4643E36; Wed, 10 Apr 2024 15:19:55 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 737EF40689; Wed, 10 Apr 2024 15:19:55 +0200 (CEST) Received: from agw.arknetworks.am (agw.arknetworks.am [79.141.165.80]) by mails.dpdk.org (Postfix) with ESMTP id B563C402C7 for ; Wed, 10 Apr 2024 15:19:53 +0200 (CEST) Received: from debian (unknown [78.109.75.113]) (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 69872E0AE4; Wed, 10 Apr 2024 17:19:52 +0400 (+04) DKIM-Filter: OpenDKIM Filter v2.11.0 agw.arknetworks.am 69872E0AE4 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arknetworks.am; s=default; t=1712755193; bh=UkpaDzfpY33geqGzE5rVP89C0miaFXThoVJnIBL6hKE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=mwMTCI+dNeTVY6futoenOQrMQ9scaAkn5horlptMuXocYrXbSb5+wOyEsDkyCgu8l vKcSots/+Y5R381U6jzyNRo6IHpWkecCfv2ePxgmkVik6KrPDe321pIR4UUzxr89E1 WBzluZFWJoibUqcync08LCJsgn36YOcxqEYjvIIuRPHEgAPOa/EEhQViSWsbQFD12d FH4fGu0IJ4ykZwXLXAe1YCoc6WQSESl6y+DohaBzbOAVl0bFWTW8MaqrEVBGpkNnzZ Dzrp6FtMi3LlSyqsGHhi1On7EreW9dkDamz5Brw5234UOZJg9rMGs/FxbX28d7GxFp 5/Q9W4vfXsJbw== Date: Wed, 10 Apr 2024 17:19:17 +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" Subject: Re: question about eth and vlan item in flow pattern In-Reply-To: <6db61bde-eb34-d7e5-cb46-c08a3268a2a4@huawei.com> Message-ID: <88394620-bf43-92af-840b-89f5e7c50a23@arknetworks.am> References: <6db61bde-eb34-d7e5-cb46-c08a3268a2a4@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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 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). 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"). 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. 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? > > > >