From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Gregory Etelson <getelson@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Matan Azrad <matan@nvidia.com>, Ori Kam <orika@nvidia.com>,
Raslan Darawsheh <rasland@nvidia.com>,
"stable@dpdk.org" <stable@dpdk.org>,
Slava Ovsiienko <viacheslavo@nvidia.com>,
Shahaf Shuler <shahafs@nvidia.com>
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3] net/mlx5: fix tunnel offload private items location
Date: Wed, 5 May 2021 18:45:27 +0100 [thread overview]
Message-ID: <303e2815-ac2f-36df-1867-bf398be0306c@intel.com> (raw)
In-Reply-To: <BY5PR12MB48343E19B04DEA802069924EA55A9@BY5PR12MB4834.namprd12.prod.outlook.com>
On 5/4/2021 10:12 AM, Gregory Etelson wrote:
> Hello Ferruh,
>
> [:snip:]
>
>> Hi Gregory,
>>
>> The were some questions around testpmd part of this patch in previous
>> version, they are not answered and this version is dropping the testpmd
>> part.
>>
>
> The tunnel offload API allows application to place tunnel offload elements at any valid location in a flow rule.
How PMD should detect the tunnel offload elements?
And which API are we talking about, is there enough documentation in the API
about the location of the tunnel offload elements, or should we clarify it more?
> Current testpmd code places tunnel offload items
> at the beginning of pattern array and tunnel offload actions at the beginning of actions array.
Got it, so this patch is removing false expectation (about the location of the
tunnel offload elements in flow rule) in the PMD, right?
As far as I understand testpmd already satisfies this false expectation, so the
problem should not be visible with testpmd.
Was there a visible user impact, like any application failing because of this
false expectation, or is this theoretical fix to be correct with API contract?
btw, I can see 'MLX5_RTE_FLOW_ITEM_TYPE_TUNNEL' still checked if it in the first
location of the items (items[0].type), in 'flow_dv_validate()', 'mlx5_flow_dv.c'
https://git.dpdk.org/dpdk/tree/drivers/net/mlx5/mlx5_flow_dv.c?h=v21.05-rc1#n6298
Can you please confirm that this is expected?
> The testpmd patch in v1 & v2 changed location of tunnel offload elements in a flow rule.
>
>> Is it safe to remove the testpmd part? If so why was the changes for at first
>> place?
>>
>
> That patch was not a fix - it emphasized general usage of the tunnel offload API.
> Current testpmd code works fine.
>
>> And can you please reply to the questions on the testpmd patch for the
>> record?
>>
>
> I'll add my replies.
>
>> Thanks,
>> Ferruh
>
> Regards,
> Gregory
>
next prev parent reply other threads:[~2021-05-05 17:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-19 13:02 [dpdk-stable] [PATCH 1/2] " Gregory Etelson
2021-04-19 13:02 ` [dpdk-stable] [PATCH 2/2] app/testpmd: " Gregory Etelson
2021-04-23 8:50 ` Ferruh Yigit
2021-04-25 15:57 ` [dpdk-stable] [PATCH v2 1/2] net/mlx5: " Gregory Etelson
2021-04-25 15:57 ` [dpdk-stable] [PATCH v2 2/2] app/testpmd: " Gregory Etelson
2021-04-30 13:49 ` Ferruh Yigit
2021-04-25 16:28 ` [dpdk-stable] [dpdk-dev] [PATCH v2 1/2] net/mlx5: " Thomas Monjalon
2021-04-25 17:01 ` Gregory Etelson
2021-04-25 17:07 ` Thomas Monjalon
2021-04-26 7:54 ` Ferruh Yigit
2021-04-27 9:27 ` Gregory Etelson
2021-04-29 7:44 ` Gregory Etelson
2021-04-30 13:37 ` Ferruh Yigit
2021-05-04 9:20 ` Gregory Etelson
2021-05-02 8:08 ` [dpdk-stable] [PATCH v3] " Gregory Etelson
2021-05-04 8:10 ` Raslan Darawsheh
2021-05-04 8:20 ` Ferruh Yigit
2021-05-04 9:12 ` Gregory Etelson
2021-05-05 17:45 ` Ferruh Yigit [this message]
2021-05-06 6:08 ` [dpdk-stable] [dpdk-dev] " Gregory Etelson
2021-05-06 7:40 ` Gregory Etelson
2021-05-06 7:59 ` [dpdk-stable] [dpdk-dev] net/mlx5: mellanox cx5/cx6-dx increment "rx_phy_discard_packets" with DPDK rte_flow actions COUNT & DROP Arthas
2021-05-06 9:57 ` [dpdk-stable] [PATCH v4] net/mlx5: fix tunnel offload private items location Gregory Etelson
2021-05-11 22:16 ` Ferruh Yigit
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=303e2815-ac2f-36df-1867-bf398be0306c@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=getelson@nvidia.com \
--cc=matan@nvidia.com \
--cc=orika@nvidia.com \
--cc=rasland@nvidia.com \
--cc=shahafs@nvidia.com \
--cc=stable@dpdk.org \
--cc=viacheslavo@nvidia.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).