DPDK patches and discussions
 help / color / mirror / Atom feed
From: Qiming Chen <chenqiming_huawei@163.com>
To: dev@dpdk.org
Cc: beilei.xing@intel.com, Qiming Chen <chenqiming_huawei@163.com>
Subject: [dpdk-dev] [PATCH v3] net/i40e: solve vf vlan strip
Date: Thu, 26 Aug 2021 22:09:56 +0800	[thread overview]
Message-ID: <20210826140956.1291-1-chenqiming_huawei@163.com> (raw)
In-Reply-To: <20210826140158.1232-1-chenqiming_huawei@163.com>

Kernel PF+DPDK VF mode, after vf adds vlan, the test result shows that the
vlan received from vf has been stripped.

The patch solves the problem that the kernel i40e.ko driver strips the vlan
by default after vf adds vlan. Determine whether to strip vlan through
the DEV_RX_OFFLOAD_VLAN_STRIP mask bit in rxmode.offload.

Environmental information:
1) dpdk 19.11
2) Kernel PF i40e.ko: 2.7.12
3) Firmware: 6.01 0x800034a3 1.1747.0

I did not use testpmd to test vlan filter, but write Demo for testing
based on the following deployment:
1) x710 nic, use 2 PFs, each PF virtualizes 1 VF
2) 2 pf connected with fiber optic cable
3) 2 vf are hard to pass through to the VM
4) In vm, dpdk takes over the vf port,
5) One port is used as the sending port, and the other port is used as
the receiving port, e.g. xmit portid is 0, rx portid is 1

Use the default configuration for port 0 as the sender, and configure
port 1 as the receiving port as follows:
1) rte_eth_dev_set_vlan_offload(1, ETH_VLAN_FILTER_OFFLOAD)
2) rte_eth_dev_vlan_filter(1, 100, 1)

Do the following tests:
Demo constructs a message with vlan 100 to be sent from port 0, and found
that the vlan header of the message received from port 1 was stripped.

Signed-off-by: Qiming Chen <chenqiming_huawei@163.com>
---
v2:
  Re-test vlan filtering is no problem.
v3:
  Clear coding style quesion.
---
 drivers/net/i40e/i40e_ethdev_vf.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
index 12e69a3233..2a291365c4 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1900,11 +1900,15 @@ static int
 i40evf_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
 {
 	int ret;
+	struct rte_eth_conf *dev_conf = &dev->data->dev_conf;
 
-	if (on)
+	if (on) {
 		ret = i40evf_add_vlan(dev, vlan_id);
-	else
+		if ((dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_VLAN_STRIP) == 0)
+			i40evf_disable_vlan_strip(dev);
+	} else {
 		ret = i40evf_del_vlan(dev,vlan_id);
+	}
 
 	return ret;
 }
-- 
2.30.1.windows.1


  reply	other threads:[~2021-08-26 14:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-24  8:51 [dpdk-dev] [PATCH] net/i40e: solve the failure of vf vlan filtering Qiming Chen
2021-08-24  9:29 ` [dpdk-dev] [PATCH v2] " Qiming Chen
2021-08-25  7:13   ` Xing, Beilei
2021-08-26  9:40     ` Qiming Chen
2021-08-26 14:01   ` [dpdk-dev] [PATCH v3] net/i40e: solve vf vlan strip Qiming Chen
2021-08-26 14:09     ` Qiming Chen [this message]
2021-08-30  0:49       ` Zhang, Qi Z

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=20210826140956.1291-1-chenqiming_huawei@163.com \
    --to=chenqiming_huawei@163.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    /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).