patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Ilya Maximets <i.maximets@ovn.org>
To: fengchengwen <fengchengwen@huawei.com>,
	dev@dpdk.org, Ori Kam <orika@nvidia.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	Eli Britstein <elibr@nvidia.com>
Cc: i.maximets@ovn.org, Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Somnath Kotur <somnath.kotur@broadcom.com>,
	Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	Sachin Saxena <sachin.saxena@oss.nxp.com>,
	Simei Su <simei.su@intel.com>, Wenjun Wu <wenjun1.wu@intel.com>,
	John Daley <johndale@cisco.com>,
	Hyong Youb Kim <hyonkim@cisco.com>,
	Ziyang Xuan <xuanziyang2@huawei.com>,
	Xiaoyun Wang <cloud.wangxiaoyun@huawei.com>,
	Guoyang Zhou <zhouguoyang@huawei.com>,
	Dongdong Liu <liudongdong3@huawei.com>,
	Yisen Zhuang <yisen.zhuang@huawei.com>,
	Yuying Zhang <Yuying.Zhang@intel.com>,
	Beilei Xing <beilei.xing@intel.com>,
	Jingjing Wu <jingjing.wu@intel.com>,
	Qiming Yang <qiming.yang@intel.com>,
	Qi Zhang <qi.z.zhang@intel.com>,
	Junfeng Guo <junfeng.guo@intel.com>,
	Rosen Xu <rosen.xu@intel.com>, Matan Azrad <matan@nvidia.com>,
	Viacheslav Ovsiienko <viacheslavo@nvidia.com>,
	Liron Himi <lironh@marvell.com>,
	Jiawen Wu <jiawenwu@trustnetic.com>,
	Jian Wang <jianwang@trustnetic.com>,
	Dekel Peled <dekelp@nvidia.com>,
	stable@dpdk.org
Subject: Re: [PATCH v2] doc: fix support table for ETH and VLAN flow items
Date: Fri, 14 Oct 2022 14:37:29 +0200	[thread overview]
Message-ID: <69896d4d-ccdf-34c6-f14a-adbc99402054@ovn.org> (raw)
In-Reply-To: <b7aeb1f4-be03-e526-7570-cd79e3ea12b0@huawei.com>

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.

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

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

> 
> 
>    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?

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 <i.maximets@ovn.org>
>> ---
>>
>> 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(-)


  reply	other threads:[~2022-10-14 12:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-13 10:48 Ilya Maximets
2022-10-14  9:41 ` fengchengwen
2022-10-14 12:37   ` Ilya Maximets [this message]
2022-10-16  5:26     ` Eli Britstein
2022-10-17 11:54       ` fengchengwen
2022-10-18  7:18         ` Ori Kam
2022-10-26 15:34 ` Thomas Monjalon
2022-11-02 11:41   ` Ilya Maximets

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=69896d4d-ccdf-34c6-f14a-adbc99402054@ovn.org \
    --to=i.maximets@ovn.org \
    --cc=Yuying.Zhang@intel.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=beilei.xing@intel.com \
    --cc=cloud.wangxiaoyun@huawei.com \
    --cc=dekelp@nvidia.com \
    --cc=dev@dpdk.org \
    --cc=elibr@nvidia.com \
    --cc=fengchengwen@huawei.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=hyonkim@cisco.com \
    --cc=jianwang@trustnetic.com \
    --cc=jiawenwu@trustnetic.com \
    --cc=jingjing.wu@intel.com \
    --cc=johndale@cisco.com \
    --cc=junfeng.guo@intel.com \
    --cc=lironh@marvell.com \
    --cc=liudongdong3@huawei.com \
    --cc=matan@nvidia.com \
    --cc=orika@nvidia.com \
    --cc=qi.z.zhang@intel.com \
    --cc=qiming.yang@intel.com \
    --cc=rahul.lakkireddy@chelsio.com \
    --cc=rosen.xu@intel.com \
    --cc=sachin.saxena@oss.nxp.com \
    --cc=simei.su@intel.com \
    --cc=somnath.kotur@broadcom.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@nvidia.com \
    --cc=wenjun1.wu@intel.com \
    --cc=xuanziyang2@huawei.com \
    --cc=yisen.zhuang@huawei.com \
    --cc=zhouguoyang@huawei.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).