From: Shradha Shah <sshah@solarflare.com>
To: David Miller <davem@davemloft.net>
Cc: <netdev@vger.kernel.org>, <linux-net-drivers@solarflare.com>
Subject: [PATCH net-next 06/14] sfc: record the PF's vport ID in nic_data
Date: Wed, 6 May 2015 00:57:14 +0100 [thread overview]
Message-ID: <554958DA.7090502@solarflare.com> (raw)
In-Reply-To: <554957DF.2010307@solarflare.com>
From: Daniel Pieczko <dpieczko@solarflare.com>
The default port ID of EVB_PORT_ID_ASSIGNED is a "magic" number
for the MCFW to select the physical port of the PF. If other
vswitches and vports are created on top of the default firmware
configuration, the ID of the newly created vport is then required
when passed to MCDI commands. Currently, this doesn't happen so
the vport_id is never changed, but a subsequent patch will change
this behaviour so that other vswitches and vports are created.
The vport_id recorded in nic_data is only relevant for PFs.
VFs will have their vports created by their parent PF, and in
that case the parent PF will record the vport ID of each VF.
For a VF, nic_data->vport_id is expected to remain at the default
value.
Signed-off-by: Shradha Shah <sshah@solarflare.com>
---
drivers/net/ethernet/sfc/ef10.c | 13 +++++++++----
drivers/net/ethernet/sfc/nic.h | 2 ++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index 4f9775f..8db717e 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -217,6 +217,8 @@ static int efx_ef10_probe(struct efx_nic *efx)
nic_data->rx_rss_context = EFX_EF10_RSS_CONTEXT_INVALID;
+ nic_data->vport_id = EVB_PORT_ID_ASSIGNED;
+
/* In case we're recovering from a crash (kexec), we want to
* cancel any outstanding request by the previous user of this
* function. We send a special message using the least
@@ -1245,6 +1247,7 @@ static void efx_ef10_tx_init(struct efx_tx_queue *tx_queue)
size_t entries = tx_queue->txd.buf.len / EFX_BUF_SIZE;
struct efx_channel *channel = tx_queue->channel;
struct efx_nic *efx = tx_queue->efx;
+ struct efx_ef10_nic_data *nic_data = efx->nic_data;
size_t inlen, outlen;
dma_addr_t dma_addr;
efx_qword_t *txd;
@@ -1259,7 +1262,7 @@ static void efx_ef10_tx_init(struct efx_tx_queue *tx_queue)
INIT_TXQ_IN_FLAG_IP_CSUM_DIS, !csum_offload,
INIT_TXQ_IN_FLAG_TCP_CSUM_DIS, !csum_offload);
MCDI_SET_DWORD(inbuf, INIT_TXQ_IN_OWNER_ID, 0);
- MCDI_SET_DWORD(inbuf, INIT_TXQ_IN_PORT_ID, EVB_PORT_ID_ASSIGNED);
+ MCDI_SET_DWORD(inbuf, INIT_TXQ_IN_PORT_ID, nic_data->vport_id);
dma_addr = tx_queue->txd.buf.dma_addr;
@@ -1390,11 +1393,12 @@ static int efx_ef10_alloc_rss_context(struct efx_nic *efx, u32 *context)
{
MCDI_DECLARE_BUF(inbuf, MC_CMD_RSS_CONTEXT_ALLOC_IN_LEN);
MCDI_DECLARE_BUF(outbuf, MC_CMD_RSS_CONTEXT_ALLOC_OUT_LEN);
+ struct efx_ef10_nic_data *nic_data = efx->nic_data;
size_t outlen;
int rc;
MCDI_SET_DWORD(inbuf, RSS_CONTEXT_ALLOC_IN_UPSTREAM_PORT_ID,
- EVB_PORT_ID_ASSIGNED);
+ nic_data->vport_id);
MCDI_SET_DWORD(inbuf, RSS_CONTEXT_ALLOC_IN_TYPE,
MC_CMD_RSS_CONTEXT_ALLOC_IN_TYPE_EXCLUSIVE);
MCDI_SET_DWORD(inbuf, RSS_CONTEXT_ALLOC_IN_NUM_QUEUES,
@@ -1508,6 +1512,7 @@ static void efx_ef10_rx_init(struct efx_rx_queue *rx_queue)
struct efx_channel *channel = efx_rx_queue_channel(rx_queue);
size_t entries = rx_queue->rxd.buf.len / EFX_BUF_SIZE;
struct efx_nic *efx = rx_queue->efx;
+ struct efx_ef10_nic_data *nic_data = efx->nic_data;
size_t inlen, outlen;
dma_addr_t dma_addr;
int rc;
@@ -1525,7 +1530,7 @@ static void efx_ef10_rx_init(struct efx_rx_queue *rx_queue)
INIT_RXQ_IN_FLAG_PREFIX, 1,
INIT_RXQ_IN_FLAG_TIMESTAMP, 1);
MCDI_SET_DWORD(inbuf, INIT_RXQ_IN_OWNER_ID, 0);
- MCDI_SET_DWORD(inbuf, INIT_RXQ_IN_PORT_ID, EVB_PORT_ID_ASSIGNED);
+ MCDI_SET_DWORD(inbuf, INIT_RXQ_IN_PORT_ID, nic_data->vport_id);
dma_addr = rx_queue->rxd.buf.dma_addr;
@@ -2294,7 +2299,7 @@ static void efx_ef10_filter_push_prep(struct efx_nic *efx,
match_fields);
}
- MCDI_SET_DWORD(inbuf, FILTER_OP_IN_PORT_ID, EVB_PORT_ID_ASSIGNED);
+ MCDI_SET_DWORD(inbuf, FILTER_OP_IN_PORT_ID, nic_data->vport_id);
MCDI_SET_DWORD(inbuf, FILTER_OP_IN_RX_DEST,
spec->dmaq_id == EFX_FILTER_RX_DMAQ_ID_DROP ?
MC_CMD_FILTER_OP_IN_RX_DEST_DROP :
diff --git a/drivers/net/ethernet/sfc/nic.h b/drivers/net/ethernet/sfc/nic.h
index 17ee3ae..f29e4ec 100644
--- a/drivers/net/ethernet/sfc/nic.h
+++ b/drivers/net/ethernet/sfc/nic.h
@@ -493,6 +493,7 @@ enum {
* %MC_CMD_GET_CAPABILITIES response)
* @rx_dpcpu_fw_id: Firmware ID of the RxDPCPU
* @tx_dpcpu_fw_id: Firmware ID of the TxDPCPU
+ * @vport_id: The function's vport ID, only relevant for PFs
*/
struct efx_ef10_nic_data {
struct efx_buffer mcdi_buf;
@@ -513,6 +514,7 @@ struct efx_ef10_nic_data {
u32 datapath_caps;
unsigned int rx_dpcpu_fw_id;
unsigned int tx_dpcpu_fw_id;
+ unsigned int vport_id;
};
int efx_init_sriov(void);
next prev parent reply other threads:[~2015-05-05 23:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-05 23:53 [PATCH net-next 00/14] sfc: Enabling EF10 Vf's, set up vswitching and bind the SFC driver to the VF's Shradha Shah
2015-05-05 23:55 ` [PATCH net-next 01/14] sfc: Own header for nic-specific sriov functions, single instance of netdev_ops and sriov removed from Falcon code Shradha Shah
2015-05-05 23:55 ` [PATCH net-next 02/14] sfc: Move and rename efx_vf struct to siena_vf Shradha Shah
2015-05-05 23:55 ` [PATCH net-next 03/14] sfc: Enable VF's via a write to the sysfs file sriov_numvfs Shradha Shah
2015-05-05 23:56 ` [PATCH net-next 04/14] sfc: Use MCDI to set FILTER_OP_IN_TX_DOMAIN Shradha Shah
2015-05-05 23:56 ` [PATCH net-next 05/14] sfc: Record [rt]x_dpcpu_fw_id in EF10 nic_data Shradha Shah
2015-05-05 23:57 ` Shradha Shah [this message]
2015-05-05 23:57 ` [PATCH net-next 07/14] sfc: create VEB vswitch and vport above default firmware setup Shradha Shah
2015-05-05 23:57 ` [PATCH net-next 08/14] sfc: get the PF number and record in nic_data Shradha Shah
2015-05-05 23:58 ` [PATCH net-next 09/14] sfc: Prepare to bind the sfc driver to the VF Shradha Shah
2015-05-05 23:58 ` [PATCH net-next 10/14] sfc: create vports for VFs and assign random MAC addresses Shradha Shah
2015-05-05 23:58 ` [PATCH net-next 11/14] sfc: manually allocate and free vadaptors Shradha Shah
2015-05-05 23:59 ` [PATCH net-next 12/14] sfc: Cope with permissions enforcement added to firmware for SR-IOV Shradha Shah
2015-05-05 23:59 ` [PATCH net-next 13/14] sfc: Add use of shared RSS contexts Shradha Shah
2015-05-06 0:00 ` [PATCH net-next 14/14] sfc: Bind the sfc driver to any available VF's Shradha Shah
2015-05-09 20:18 ` [PATCH net-next 00/14] sfc: Enabling EF10 Vf's, set up vswitching and bind the SFC driver to the VF's David Miller
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=554958DA.7090502@solarflare.com \
--to=sshah@solarflare.com \
--cc=davem@davemloft.net \
--cc=linux-net-drivers@solarflare.com \
--cc=netdev@vger.kernel.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).