DPDK patches and discussions
 help / color / mirror / Atom feed
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?
>>
>>
>>
>>
> .

  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).