patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Ilya Maximets <i.maximets@ovn.org>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: i.maximets@ovn.org, dev@dpdk.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>, Ori Kam <orika@nvidia.com>,
	stable@dpdk.org, andrew.rybchenko@oktetlabs.ru,
	ferruh.yigit@amd.com, bruce.richardson@intel.com,
	david.marchand@redhat.com
Subject: Re: [PATCH v2] doc: fix support table for ETH and VLAN flow items
Date: Wed, 2 Nov 2022 12:41:34 +0100	[thread overview]
Message-ID: <6618b308-842f-ca4d-3252-5496f0e6c571@ovn.org> (raw)
In-Reply-To: <3640720.MHq7AAxBmi@thomas>

On 10/26/22 17:34, Thomas Monjalon wrote:
> 13/10/2022 12:48, Ilya Maximets:
>> '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>
> 
> Applied, thanks.

Thanks!

> 
> How can we encourage fixing the problematic drivers?

That's a tough question and I don't have a good answer.

One thought that I have is to make all drivers report a mask for
each ITEM.  That mask should represent all the bits in the ITEM
theoretically supported by the driver.  If some driver doesn't
report a mask for an ITEM, it is treated as all-zero mask.

While installing the flow or on flow validation, the generic
layer will check the rte_flow against masks reported by the
driver.  If there are no extra bits in the flow, it is passed
to the driver for further validation and installation.
If there are extra bits, flow is rejected at the high level.

Further validation is still required because only the driver
is able to check dependencies between fields.

Once such a checking is merged, it will break offloading for all
the drivers.  Maintainers will need to create appropriate masks
to unblock offloading.  memset() on the whole ITEM or similar
operations must not be allowed for these masks in the driver code.
Thorough review of these patches is necessary.

This will not help with encouraging to implement the features
per se, but will force maintainers to re-check their drivers.
And should eliminate issues where certain fields are silently
ignored, because until the driver is updated with a new mask
generic validation will reject offloading of flows that contain
matches on new fields.

At least applications will not fear to use certain features
knowing that they will be correctly rejected on validation.

Best regards, Ilya Maximets.

      reply	other threads:[~2022-11-02 11:41 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
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 [this message]

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=6618b308-842f-ca4d-3252-5496f0e6c571@ovn.org \
    --to=i.maximets@ovn.org \
    --cc=Yuying.Zhang@intel.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=beilei.xing@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=cloud.wangxiaoyun@huawei.com \
    --cc=david.marchand@redhat.com \
    --cc=dekelp@nvidia.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.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).