From: Jie Hai <haijie1@huawei.com>
To: Ivan Malov <ivan.malov@arknetworks.am>
Cc: Yuying Zhang <yuying.zhang@intel.com>,
Aman Singh <aman.deep.singh@intel.com>,
Thomas Monjalon <thomas@monjalon.net>,
"ferruh.yigit@amd.com >> Ferruh Yigit" <ferruh.yigit@amd.com>,
<andrew.rybchenko@oktetlabs.ru>, <dekelp@nvidia.com>,
<psatheesh@marvell.com>, <adrien.mazarguil@6wind.com>,
fengchengwen <fengchengwen@huawei.com>,
Huisong Li <lihuisong@huawei.com>,
Dengdui Huang <huangdengdui@huawei.com>,
"dev@dpdk.org" <dev@dpdk.org>, Ori Kam <orika@nvidia.com>
Subject: Re: question about eth and vlan item in flow pattern
Date: Tue, 23 Apr 2024 17:34:46 +0800 [thread overview]
Message-ID: <75671ef0-70b6-2611-6ab4-1876b2724103@huawei.com> (raw)
In-Reply-To: <88394620-bf43-92af-840b-89f5e7c50a23@arknetworks.am>
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.
>
> 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?
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.
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
> 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?
>>
>>
>>
>>
> .
next prev parent reply other threads:[~2024-04-23 9:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-10 11:37 Jie Hai
2024-04-10 12:33 ` Thomas Monjalon
2024-04-10 13:19 ` Ivan Malov
2024-04-23 9:34 ` Jie Hai [this message]
2024-04-23 11:44 ` Ivan Malov
2024-04-24 20:21 ` Dariusz Sosnowski
2024-04-24 21:46 ` Ivan Malov
2024-05-13 1:45 ` Jie Hai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=75671ef0-70b6-2611-6ab4-1876b2724103@huawei.com \
--to=haijie1@huawei.com \
--cc=adrien.mazarguil@6wind.com \
--cc=aman.deep.singh@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dekelp@nvidia.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=ferruh.yigit@amd.com \
--cc=huangdengdui@huawei.com \
--cc=ivan.malov@arknetworks.am \
--cc=lihuisong@huawei.com \
--cc=orika@nvidia.com \
--cc=psatheesh@marvell.com \
--cc=thomas@monjalon.net \
--cc=yuying.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).