All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: xavier.huwei@huawei.com
Cc: dev@dpdk.org, ferruh.yigit@intel.com, arybchenko@solarflare.com,
	tangchengchang@huawei.com, hyonkim@cisco.com,
	sachin.saxena@oss.nxp.com, cloud.wangxiaoyun@huawei.com,
	hkalra@marvell.com, viacheslavo@mellanox.com
Subject: Re: [dpdk-dev] [PATCH v6 2/2] ethdev: fix VLAN offloads set if no relative capabilities
Date: Tue, 07 Jul 2020 16:11:46 +0200	[thread overview]
Message-ID: <3633587.h79vMgjPB0@thomas> (raw)
In-Reply-To: <1594019191-54524-3-git-send-email-xavier.huwei@huawei.com>

06/07/2020 09:06, Wei Hu (Xavier):
> Currently, there is a potential problem that calling the API function
> rte_eth_dev_set_vlan_offload to start VLAN hardware offloads which the
> driver does not support. If the PMD driver does not support certain VLAN
> hardware offloads and does not check for it, the hardware setting will
> not change, but the VLAN offloads in dev->data->dev_conf.rxmode.offloads
> will be turned on.
> 
> It is supposed to check the hardware capabilities to decide whether the
> relative callback needs to be called just like the behavior in the API
> function named rte_eth_dev_configure. And it is also needed to cleanup
> duplicated checks which are done in some PMDs. Also, note that it is
> behaviour change for some PMDs which simply ignore (with error/warning log
> message) unsupported VLAN offloads, but now it will fail.
> 
> Fixes: a4996bd89c42 ("ethdev: new Rx/Tx offloads API")
> Fixes: 0ebce6129bc6 ("net/dpaa2: support new ethdev offload APIs")
> Fixes: f9416bbafd98 ("net/enic: remove VLAN filter handler")
> Fixes: 4f7d9e383e5c ("fm10k: update vlan offload features")
> Fixes: fdba3bf15c7b ("net/hinic: add VLAN filter and offload")
> Fixes: b96fb2f0d22b ("net/i40e: handle QinQ strip")
> Fixes: d4a27a3b092a ("nfp: add basic features")
> Fixes: 56139e85abec ("net/octeontx: support VLAN filter offload")
> Fixes: ba1b3b081edf ("net/octeontx2: support VLAN offloads")
> Fixes: d87246a43759 ("net/qede: enable and disable VLAN filtering")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
> Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> Acked-by: Hyong Youb Kim <hyonkim@cisco.com>
> Acked-by: Sachin Saxena <sachin.saxena@oss.nxp.com>
> Acked-by: Xiaoyun wang <cloud.wangxiaoyun@huawei.com>
> Acked-by: Harman Kalra <hkalra@marvell.com>

Looks like a lot of reviews were already done. I missed this patch.
Please could you make sure API maintainers are Cc'ed?
You can use --cc-cmd devtools/get-maintainer.sh

> @@ -3317,6 +3319,25 @@ rte_eth_dev_set_vlan_offload(uint16_t port_id, int offload_mask)
>  	if (mask == 0)
>  		return ret;
>  
> +	ret = rte_eth_dev_info_get(port_id, &dev_info);
> +	if (ret != 0)
> +		return ret;
> +
> +	/*
> +	 * New added Rx VLAN offloading which are not enabled in
> +	 * rte_eth_dev_configure() must be within its device capabilities
> +	 */

What means "New added Rx VLAN offloading"?

> +	if ((dev_offloads & dev_info.rx_offload_capa) != dev_offloads) {
> +		new_offloads = dev_offloads & ~orig_offloads;
> +		RTE_ETHDEV_LOG(ERR,
> +			"Ethdev port_id=%u requested new added VLAN offloads "
> +			"0x%" PRIx64 " must be within Rx offloads capabilities "
> +			"0x%" PRIx64 " in %s()\n",
> +			port_id, new_offloads, dev_info.rx_offload_capa,
> +			__func__);
> +		return -EINVAL;
> +	}




  parent reply	other threads:[~2020-07-07 14:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-06  7:06 [dpdk-dev] [PATCH v6 0/2] ethdev: minor bugfixes Wei Hu (Xavier)
2020-07-06  7:06 ` [dpdk-dev] [PATCH v6 1/2] ethdev: fix data room size verification in Rx queue setup Wei Hu (Xavier)
2020-07-07 13:37   ` Slava Ovsiienko
2020-07-06  7:06 ` [dpdk-dev] [PATCH v6 2/2] ethdev: fix VLAN offloads set if no relative capabilities Wei Hu (Xavier)
2020-07-07  7:35   ` Jeff Guo
2020-07-07 13:38     ` Slava Ovsiienko
2020-07-08  3:53       ` Wei Hu (Xavier)
2020-07-07 14:11   ` Thomas Monjalon [this message]
2020-07-08  3:37     ` Wei Hu (Xavier)
2020-07-08 10:14       ` Thomas Monjalon
2020-07-09  7:39         ` Wei Hu (Xavier)
2020-07-09  9:04           ` Thomas Monjalon

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=3633587.h79vMgjPB0@thomas \
    --to=thomas@monjalon.net \
    --cc=arybchenko@solarflare.com \
    --cc=cloud.wangxiaoyun@huawei.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=hkalra@marvell.com \
    --cc=hyonkim@cisco.com \
    --cc=sachin.saxena@oss.nxp.com \
    --cc=tangchengchang@huawei.com \
    --cc=viacheslavo@mellanox.com \
    --cc=xavier.huwei@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.