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
next prev 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).