Re: [RFC PATCH net-next 3/5] ixgbe: Add GET_RSS_KEY command to VF-PF channel commands set
From: Jeff Kirsher <hidden>
Date: 2014-12-30 19:23:32
On Tue, Dec 30, 2014 at 8:30 AM, Vlad Zolotarov [off-list ref] wrote:
quoted hunk ↗ jump to hunk
82599 VFs and PF share the same RSS Key. Therefore we will return the same RSS key for all VFs. Signed-off-by: Vlad Zolotarov <redacted> --- drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 2 ++ drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 25 +++++++++++++++++++++++++ 2 files changed, 27 insertions(+)diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h index c1123d9..52e775b 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h@@ -97,6 +97,8 @@ enum ixgbe_pfvf_api_rev { #define IXGBE_VF_GET_RETA_1 0x0b /* get RETA[12..23] */ #define IXGBE_VF_GET_RETA_2 0x0c /* get RETA[24..31] */ +#define IXGBE_VF_GET_RSS_KEY 0x0d /* get RSS key */ + /* GET_QUEUES return data indices within the mailbox */ #define IXGBE_VF_TX_QUEUES 1 /* number of Tx queues supported */ #define IXGBE_VF_RX_QUEUES 2 /* number of Rx queues supported */diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c index 84db1a5..fc8233e 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c@@ -970,6 +970,28 @@ static int ixgbe_get_vf_reta(struct ixgbe_adapter *adapter, return 0; } +static int ixgbe_get_vf_rss_key(struct ixgbe_adapter *adapter, + u32 *msgbuf, u32 vf) +{ + struct ixgbe_hw *hw = &adapter->hw; + int i; + u32 *rss_key = &msgbuf[1]; + + /* verify the PF is supporting the correct API */ + switch (adapter->vfinfo[vf].vf_api) { + case ixgbe_mbox_api_12: + break; + default: + return -EPERM; + }
Same as in patch 01 of the series, a switch statement is overkill for
a single case. It would be far simpler to just have
if (adapter->vfinfo[vf].vf_api != ixgbe_mbox_api_12)
return -EPERM;
Later on, if there are multiple API's or future API's that also
support this, then we could move to a case statement.