DPDK patches and discussions
 help / color / mirror / Atom feed
From: Rasesh Mody <rasesh.mody@cavium.com>
To: dev@dpdk.org
Cc: Shahed Shaikh <shahed.shaikh@cavium.com>,
	ferruh.yigit@intel.com, Dept-EngDPDKDev@cavium.com
Subject: [dpdk-dev] [PATCH 08/17] net/qede/base: use trust mode for forced MAC limitations
Date: Sat,  8 Sep 2018 13:30:57 -0700	[thread overview]
Message-ID: <1536438666-22184-9-git-send-email-rasesh.mody@cavium.com> (raw)
In-Reply-To: <1536438666-22184-1-git-send-email-rasesh.mody@cavium.com>

From: Shahed Shaikh <shahed.shaikh@cavium.com>

When trust mode is set to ON, VF can change it's MAC address
inspite PF has set a forced MAC for that VF from HV.

Earlier similar functionality is provided by module parameter
"allow_vf_mac_change_mode" of qed.

This change makes few changes in behavior of VF shadow config -
 - Let driver track the VF mac in shadow config as long as trust
  mode is OFF.
 - Once trust mode is ON, we should not care about MACs in shadow
  config (because we never intend to fall back because of lack of restore
  implementation).
 - Delete existing shadow MAC (this helps when trust mode is turned OFF,
  and VF tries to add new MAC – it won’t fail that time since we have
  a clean slate).
 - Skip addition and deletion of MACs in shadow configs.

Signed-off-by: Shahed Shaikh <shahed.shaikh@cavium.com>
---
 drivers/net/qede/base/ecore_iov_api.h |    7 +++++++
 drivers/net/qede/base/ecore_sriov.c   |   36 ++++++++++++++++++++++++---------
 2 files changed, 34 insertions(+), 9 deletions(-)

diff --git a/drivers/net/qede/base/ecore_iov_api.h b/drivers/net/qede/base/ecore_iov_api.h
index 29001d7..d398478 100644
--- a/drivers/net/qede/base/ecore_iov_api.h
+++ b/drivers/net/qede/base/ecore_iov_api.h
@@ -84,6 +84,13 @@ struct ecore_public_vf_info {
 	 */
 	u8 forced_mac[ETH_ALEN];
 	u16 forced_vlan;
+
+	/* Trusted VFs can configure promiscuous mode and
+	 * set MAC address inspite PF has set forced MAC.
+	 * Also store shadow promisc configuration if needed.
+	 */
+	bool is_trusted_configured;
+	bool is_trusted_request;
 };
 
 struct ecore_iov_vf_init_params {
diff --git a/drivers/net/qede/base/ecore_sriov.c b/drivers/net/qede/base/ecore_sriov.c
index f7ebf7a..9e4a57b 100644
--- a/drivers/net/qede/base/ecore_sriov.c
+++ b/drivers/net/qede/base/ecore_sriov.c
@@ -1968,7 +1968,8 @@ static void ecore_iov_vf_mbx_acquire(struct ecore_hwfn       *p_hwfn,
 		return ECORE_INVAL;
 
 	if ((events & (1 << MAC_ADDR_FORCED)) ||
-	    p_hwfn->pf_params.eth_pf_params.allow_vf_mac_change) {
+	    p_hwfn->pf_params.eth_pf_params.allow_vf_mac_change ||
+	    p_vf->p_vf_info.is_trusted_configured) {
 		/* Since there's no way [currently] of removing the MAC,
 		 * we can always assume this means we need to force it.
 		 */
@@ -1989,7 +1990,8 @@ static void ecore_iov_vf_mbx_acquire(struct ecore_hwfn       *p_hwfn,
 			return rc;
 		}
 
-		if (p_hwfn->pf_params.eth_pf_params.allow_vf_mac_change)
+		if (p_hwfn->pf_params.eth_pf_params.allow_vf_mac_change ||
+		    p_vf->p_vf_info.is_trusted_configured)
 			p_vf->configured_features |=
 				1 << VFPF_BULLETIN_MAC_ADDR;
 		else
@@ -3351,6 +3353,15 @@ static void ecore_iov_vf_mbx_vport_update(struct ecore_hwfn *p_hwfn,
 	if (p_vf->bulletin.p_virt->valid_bitmap & (1 << MAC_ADDR_FORCED))
 		return ECORE_SUCCESS;
 
+	/* Since we don't have the implementation of the logic for removing
+	 * a forced MAC and restoring shadow MAC, let's not worry about
+	 * processing shadow copies of MAC as long as VF trust mode is ON,
+	 * to keep things simple.
+	 */
+	if (p_hwfn->pf_params.eth_pf_params.allow_vf_mac_change ||
+	    p_vf->p_vf_info.is_trusted_configured)
+		return ECORE_SUCCESS;
+
 	/* First remove entries and then add new ones */
 	if (p_params->opcode == ECORE_FILTER_REMOVE) {
 		for (i = 0; i < ECORE_ETH_VF_NUM_MAC_FILTERS; i++) {
@@ -4415,17 +4426,23 @@ void ecore_iov_bulletin_set_forced_mac(struct ecore_hwfn *p_hwfn,
 		return;
 	}
 
-	if (p_hwfn->pf_params.eth_pf_params.allow_vf_mac_change)
+	if (p_hwfn->pf_params.eth_pf_params.allow_vf_mac_change ||
+	    vf_info->p_vf_info.is_trusted_configured) {
 		feature = 1 << VFPF_BULLETIN_MAC_ADDR;
-	else
+		/* Trust mode will disable Forced MAC */
+		vf_info->bulletin.p_virt->valid_bitmap &=
+			~(1 << MAC_ADDR_FORCED);
+	} else {
 		feature = 1 << MAC_ADDR_FORCED;
+		/* Forced MAC will disable MAC_ADDR */
+		vf_info->bulletin.p_virt->valid_bitmap &=
+			~(1 << VFPF_BULLETIN_MAC_ADDR);
+	}
 
-	OSAL_MEMCPY(vf_info->bulletin.p_virt->mac, mac, ETH_ALEN);
+	OSAL_MEMCPY(vf_info->bulletin.p_virt->mac,
+		    mac, ETH_ALEN);
 
 	vf_info->bulletin.p_virt->valid_bitmap |= feature;
-	/* Forced MAC will disable MAC_ADDR */
-	vf_info->bulletin.p_virt->valid_bitmap &=
-	    ~(1 << VFPF_BULLETIN_MAC_ADDR);
 
 	ecore_iov_configure_vport_forced(p_hwfn, vf_info, feature);
 }
@@ -4460,7 +4477,8 @@ enum _ecore_status_t ecore_iov_bulletin_set_mac(struct ecore_hwfn *p_hwfn,
 
 	vf_info->bulletin.p_virt->valid_bitmap |= feature;
 
-	if (p_hwfn->pf_params.eth_pf_params.allow_vf_mac_change)
+	if (p_hwfn->pf_params.eth_pf_params.allow_vf_mac_change ||
+	    vf_info->p_vf_info.is_trusted_configured)
 		ecore_iov_configure_vport_forced(p_hwfn, vf_info, feature);
 
 	return ECORE_SUCCESS;
-- 
1.7.10.3

  parent reply	other threads:[~2018-09-08 20:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-08 20:30 [dpdk-dev] [PATCH 00/17] net/qede: add enhancements and fixes Rasesh Mody
2018-09-08 20:30 ` [dpdk-dev] [PATCH 01/17] net/qede/base: fix to handle stag update event Rasesh Mody
2018-09-08 20:30 ` [dpdk-dev] [PATCH 02/17] net/qede/base: add support for OneView APIs Rasesh Mody
2018-09-08 20:30 ` [dpdk-dev] [PATCH 03/17] net/qede/base: get pre-negotiated values for stag and bw Rasesh Mody
2018-09-08 20:30 ` [dpdk-dev] [PATCH 04/17] net/qede: fix to program HW regs with ether type Rasesh Mody
2018-09-08 20:30 ` [dpdk-dev] [PATCH 05/17] net/qede/base: limit number of non ethernet queues to 64 Rasesh Mody
2018-09-08 20:30 ` [dpdk-dev] [PATCH 06/17] net/qede/base: correct MCP error handler's log verbosity Rasesh Mody
2018-09-08 20:30 ` [dpdk-dev] [PATCH 07/17] net/qede/base: fix logic for sfp get/set Rasesh Mody
2018-09-08 20:30 ` Rasesh Mody [this message]
2018-09-08 20:30 ` [dpdk-dev] [PATCH 09/17] net/qede/base: use pointer for bytes len read Rasesh Mody
2018-09-08 20:30 ` [dpdk-dev] [PATCH 10/17] net/qede: reorganize filter code Rasesh Mody
2018-09-20 23:51   ` Ferruh Yigit
2018-09-08 20:31 ` [dpdk-dev] [PATCH 11/17] net/qede: fix flow director bug for IPv6 filter Rasesh Mody
2018-09-08 20:31 ` [dpdk-dev] [PATCH 12/17] net/qede: refactor fdir code into generic aRFS Rasesh Mody
2018-09-08 20:31 ` [dpdk-dev] [PATCH 13/17] net/qede: add support for generic flow API Rasesh Mody
2018-09-08 20:31 ` [dpdk-dev] [PATCH 14/17] net/qede: fix Rx buffer size calculation Rasesh Mody
2018-09-08 20:31 ` [dpdk-dev] [PATCH 15/17] net/qede: add support for Rx descriptor status Rasesh Mody
2018-09-08 20:31 ` [dpdk-dev] [PATCH 16/17] net/qede/base: fix MFW FLR flow bug Rasesh Mody
2018-09-08 20:31 ` [dpdk-dev] [PATCH 17/17] net/qede: add support for dev reset Rasesh Mody
2018-09-10  5:05 ` [dpdk-dev] [PATCH 00/17] net/qede: add enhancements and fixes David Marchand
2018-09-20 16:17 ` 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=1536438666-22184-9-git-send-email-rasesh.mody@cavium.com \
    --to=rasesh.mody@cavium.com \
    --cc=Dept-EngDPDKDev@cavium.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=shahed.shaikh@cavium.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).