From: Andrew Rybchenko <arybchenko@solarflare.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>, <viveksharma@marvell.com>,
<thomas@monjalon.net>
Cc: <dev@dpdk.org>, <intoviveksharma@gmail.com>,
<stephen@networkplumber.org>, <ramirose@gmail.com>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Subject: Re: [dpdk-dev] [PATCH v3] ethdev: support QinQ strip dynamic configuration
Date: Mon, 1 Jul 2019 13:07:05 +0300 [thread overview]
Message-ID: <6d469b41-7261-34d2-3c20-9aa32b0042ce@solarflare.com> (raw)
In-Reply-To: <cd3445a5-f9e6-6239-74ab-ec4122743baf@intel.com>
On 27.06.2019 14:08, Ferruh Yigit wrote:
> On 4/19/2019 6:59 AM, viveksharma@marvell.com wrote:
>> From: Vivek Sharma <viveksharma@marvell.com>
>>
>> Enable missing support for runtime configuration (setting/getting)
>> of QinQ strip rx offload for a given ethdev.
>>
>> Signed-off-by: Vivek Sharma <viveksharma@marvell.com>
> <...>
>
>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>> index 40a068f..c1792f4 100644
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> @@ -550,11 +550,13 @@ struct rte_eth_rss_conf {
>> #define ETH_VLAN_STRIP_OFFLOAD 0x0001 /**< VLAN Strip On/Off */
>> #define ETH_VLAN_FILTER_OFFLOAD 0x0002 /**< VLAN Filter On/Off */
>> #define ETH_VLAN_EXTEND_OFFLOAD 0x0004 /**< VLAN Extend On/Off */
>> +#define ETH_QINQ_STRIP_OFFLOAD 0x0008 /**< QINQ Strip On/Off */
>>
>> /* Definitions used for mask VLAN setting */
>> #define ETH_VLAN_STRIP_MASK 0x0001 /**< VLAN Strip setting mask */
>> #define ETH_VLAN_FILTER_MASK 0x0002 /**< VLAN Filter setting mask*/
>> #define ETH_VLAN_EXTEND_MASK 0x0004 /**< VLAN Extend setting mask*/
>> +#define ETH_QINQ_STRIP_MASK 0x0008 /**< QINQ Strip setting mask */
>> #define ETH_VLAN_ID_MAX 0x0FFF /**< VLAN ID is in lower 12 bits*/
> On its own patch looks ok but a few high level questions:
>
> 1- Why we need this interim defines, instead of using actual offload values?
> Although changing this will be API/ABI breakage.
>
> 2- Why we have specific function to set vlan offloads, for other offloads the
> way is stop device and reconfigure it with new offload flags.
>
> 3- If devices can change offload configuration dynamically, do we need a generic
> API to alter the offload configs? (similar to these vlan APIs but more generic)?
If dynamic switching of offloads is really required, I think it would be
good if it is unified. If so, we can deprecate
rte_eth_dev_{s,g}et_vlan_offload() and implement it using the new one
to remove the old one from driver interface at least.
It requires reporting of dynamically switchable offloads on device and
queue level. Or just dynamically switchable offloads in assumption that
if the offload is supported on queue level and dynamically switchable,
it is dynamically switchable on queue level.
> Related to the patch, what do you think about following options:
> a)
> - Get this patch
> - Send a deprecation notice for 1) in this release
> - Next release remove these flags, which will be practically reverse this patch
> and more
>
> b)
> - Send a deprecation notice for 1) in this release
> - Next release update the APIs and a smaller/different version of this patch
> will be required.
I'm OK with both options, but I think it would be fair to go (a) to avoid
postponing of the feature too long.
The patch itself should update rte_eth_dev_{s,g}et_vlan_offload()
descriptions which enumerate switchable offloads.
Andrew.
next prev parent reply other threads:[~2019-07-01 10:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-14 11:11 [dpdk-dev] [PATCH] ethdev: fix QinQ strip offload support viveksharma
2019-04-14 11:11 ` viveksharma
2019-04-15 15:54 ` Stephen Hemminger
2019-04-15 15:54 ` Stephen Hemminger
2019-04-15 21:33 ` Rami Rosen
2019-04-15 21:33 ` Rami Rosen
2019-04-17 7:40 ` [dpdk-dev] [PATCH v2] " viveksharma
2019-04-17 7:40 ` viveksharma
2019-04-17 8:34 ` Thomas Monjalon
2019-04-17 8:34 ` Thomas Monjalon
2019-04-18 7:38 ` [dpdk-dev] [EXT] " Vivek Kumar Sharma
2019-04-18 7:38 ` Vivek Kumar Sharma
2019-04-18 8:07 ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2019-04-18 8:07 ` Thomas Monjalon
2019-04-19 5:59 ` [dpdk-dev] [PATCH v3] ethdev: support QinQ strip dynamic configuration viveksharma
2019-04-19 5:59 ` viveksharma
2019-06-27 11:08 ` Ferruh Yigit
2019-07-01 10:07 ` Andrew Rybchenko [this message]
2019-07-01 13:05 ` Ferruh Yigit
2019-07-02 3:37 ` [dpdk-dev] [PATCH v4] " viveksharma
2019-07-03 17:48 ` Ferruh Yigit
2019-07-03 19:55 ` Andrew Rybchenko
2019-07-04 9:41 ` Ferruh Yigit
2019-07-04 10:05 ` 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=6d469b41-7261-34d2-3c20-9aa32b0042ce@solarflare.com \
--to=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=intoviveksharma@gmail.com \
--cc=jerinj@marvell.com \
--cc=ramirose@gmail.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
--cc=viveksharma@marvell.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).