* Re: [PATCH v8 18/25] app/testpmd: use VFD APIs on i40e
From: Ferruh Yigit @ 2017-01-10 11:29 UTC (permalink / raw)
To: Wenzhuo Lu, dev; +Cc: Chen Jing D(Mark), Bernard Iremonger
In-Reply-To: <1484032580-60134-19-git-send-email-wenzhuo.lu@intel.com>
On 1/10/2017 7:16 AM, Wenzhuo Lu wrote:
> The new VF Daemon (VFD) APIs is implemented on i40e. Change
> testpmd code to use them, including VF MAC anti-spoofing,
> VF VLAN anti-spoofing, TX loopback, VF VLAN strip, VF VLAN
> insert.
>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Signed-off-by: Chen Jing D(Mark) <jing.d.chen@intel.com>
> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> ---
<...>
> +#ifdef RTE_LIBRTE_IXGBE_PMD
Within this ifdef, there is following call:
ret = rte_pmd_ixgbe_set_all_queues_drop_en(res->port_id, is_on);
It is not safe to make that call directly, port should be verified first
if it is ixgbe port, as done in other functions.
> /* all queues drop enable configuration */
>
> /* Common result structure for all queues drop enable */
> @@ -11277,6 +11351,9 @@ struct cmd_all_queues_drop_en_result {
> case -ENODEV:
> printf("invalid port_id %d\n", res->port_id);
> break;
> + case -ENOTSUP:
> + printf("function not implemented\n");
> + break;
> default:
> printf("programming error: (%s)\n", strerror(-ret));
> }
> @@ -11381,6 +11458,7 @@ struct cmd_vf_split_drop_en_result {
> NULL,
> },
> };
> +#endif
>
<...>
> @@ -11619,20 +11711,20 @@ struct cmd_set_vf_mac_addr_result {
> (cmdline_parse_inst_t *)&cmd_config_e_tag_forwarding_en_dis,
> (cmdline_parse_inst_t *)&cmd_config_e_tag_filter_add,
> (cmdline_parse_inst_t *)&cmd_config_e_tag_filter_del,
> -#ifdef RTE_LIBRTE_IXGBE_PMD
> (cmdline_parse_inst_t *)&cmd_set_vf_vlan_anti_spoof,
> (cmdline_parse_inst_t *)&cmd_set_vf_mac_anti_spoof,
> (cmdline_parse_inst_t *)&cmd_set_vf_vlan_stripq,
> (cmdline_parse_inst_t *)&cmd_set_vf_vlan_insert,
> (cmdline_parse_inst_t *)&cmd_set_tx_loopback,
> +#ifdef RTE_LIBRTE_IXGBE_PMD
Overall, since port will be verified within the function, why not remove
this ifdef completely?
So all functions will be visible to everyone, but only the PMDs support
it will be called, others will return "not supported", as done in some
functions supports bot i40e and ixgbe pmd specific APIs.
> (cmdline_parse_inst_t *)&cmd_set_all_queues_drop_en,
> (cmdline_parse_inst_t *)&cmd_set_vf_split_drop_en,
> - (cmdline_parse_inst_t *)&cmd_set_vf_mac_addr,
> (cmdline_parse_inst_t *)&cmd_set_vf_rxmode,
> (cmdline_parse_inst_t *)&cmd_set_vf_traffic,
> (cmdline_parse_inst_t *)&cmd_vf_rxvlan_filter,
> (cmdline_parse_inst_t *)&cmd_vf_rate_limit,
> #endif
> + (cmdline_parse_inst_t *)&cmd_set_vf_mac_addr,
> NULL,
> };
>
>
^ permalink raw reply
* Re: [PATCH 2/8] i40e: don't refer to eth_dev->pci_dev
From: Jan Blunck @ 2017-01-10 12:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Stephen Hemminger
In-Reply-To: <20170107181756.1944-3-sthemmin@microsoft.com>
On Sat, Jan 7, 2017 at 7:17 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> Later patches remove pci_dev from the ethernet device structure.
> Fix the i40e code to just use it's own name when forming zone name.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> drivers/net/i40e/i40e_fdir.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c
> index 335bf15c..68a2523c 100644
> --- a/drivers/net/i40e/i40e_fdir.c
> +++ b/drivers/net/i40e/i40e_fdir.c
> @@ -250,8 +250,7 @@ i40e_fdir_setup(struct i40e_pf *pf)
> }
>
> /* reserve memory for the fdir programming packet */
> - snprintf(z_name, sizeof(z_name), "%s_%s_%d",
> - eth_dev->driver->pci_drv.driver.name,
> + snprintf(z_name, sizeof(z_name), "i40e_%s_%d",
The driver is called 'net_i40e'.
> I40E_FDIR_MZ_NAME,
> eth_dev->data->port_id);
> mz = i40e_memzone_reserve(z_name, I40E_FDIR_PKT_LEN, SOCKET_ID_ANY);
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH 3/8] vmxnet3: don't refer to eth_dev->pci_dev
From: Jan Blunck @ 2017-01-10 12:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Stephen Hemminger
In-Reply-To: <20170107181756.1944-4-sthemmin@microsoft.com>
On Sat, Jan 7, 2017 at 7:17 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> Fix the vmxnet3 code to just use it's own name when forming zone name.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> drivers/net/vmxnet3/vmxnet3_rxtx.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmxnet3_rxtx.c
> index 36513693..8df4c8ea 100644
> --- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
> +++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
> @@ -849,9 +849,8 @@ ring_dma_zone_reserve(struct rte_eth_dev *dev, const char *ring_name,
> char z_name[RTE_MEMZONE_NAMESIZE];
> const struct rte_memzone *mz;
>
> - snprintf(z_name, sizeof(z_name), "%s_%s_%d_%d",
> - dev->driver->pci_drv.driver.name, ring_name,
> - dev->data->port_id, queue_id);
> + snprintf(z_name, sizeof(z_name), "vmxnet3_%s_%d_%d",
> + ring_name, dev->data->port_id, queue_id);
The driver is called 'net_vmxnet3'.
>
> mz = rte_memzone_lookup(z_name);
> if (mz)
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH 4/8] cxgbe: don't refer to eth_dev->pci_dev
From: Jan Blunck @ 2017-01-10 12:12 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Stephen Hemminger
In-Reply-To: <20170107181756.1944-5-sthemmin@microsoft.com>
On Sat, Jan 7, 2017 at 7:17 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> Later patches remove pci_dev from the ethernet device structure.
> Fix the cxgbe code to just use it's own name when forming zone name.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> drivers/net/cxgbe/sge.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/cxgbe/sge.c b/drivers/net/cxgbe/sge.c
> index 736f08ce..e935dc42 100644
> --- a/drivers/net/cxgbe/sge.c
> +++ b/drivers/net/cxgbe/sge.c
> @@ -1644,8 +1644,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq,
> /* Size needs to be multiple of 16, including status entry. */
> iq->size = cxgbe_roundup(iq->size, 16);
>
> - snprintf(z_name, sizeof(z_name), "%s_%s_%d_%d",
> - eth_dev->driver->pci_drv.driver.name,
> + snprintf(z_name, sizeof(z_name), "cxgbe_%s_%d_%d",
The driver is called 'net_cxgbe'.
> fwevtq ? "fwq_ring" : "rx_ring",
> eth_dev->data->port_id, queue_id);
> snprintf(z_name_sw, sizeof(z_name_sw), "%s_sw_ring", z_name);
> @@ -1697,8 +1696,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq,
> fl->size = s->fl_starve_thres - 1 + 2 * 8;
> fl->size = cxgbe_roundup(fl->size, 8);
>
> - snprintf(z_name, sizeof(z_name), "%s_%s_%d_%d",
> - eth_dev->driver->pci_drv.driver.name,
> + snprintf(z_name, sizeof(z_name), "cxgbe_%s_%d_%d",
> fwevtq ? "fwq_ring" : "fl_ring",
> eth_dev->data->port_id, queue_id);
> snprintf(z_name_sw, sizeof(z_name_sw), "%s_sw_ring", z_name);
> @@ -1893,8 +1891,7 @@ int t4_sge_alloc_eth_txq(struct adapter *adap, struct sge_eth_txq *txq,
> /* Add status entries */
> nentries = txq->q.size + s->stat_len / sizeof(struct tx_desc);
>
> - snprintf(z_name, sizeof(z_name), "%s_%s_%d_%d",
> - eth_dev->driver->pci_drv.driver.name, "tx_ring",
> + snprintf(z_name, sizeof(z_name), "cxgbe_%d_%d",
> eth_dev->data->port_id, queue_id);
> snprintf(z_name_sw, sizeof(z_name_sw), "%s_sw_ring", z_name);
>
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH 5/8] nfp: don't refer to eth_dev->pci_dev
From: Jan Blunck @ 2017-01-10 12:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Stephen Hemminger
In-Reply-To: <20170107181756.1944-6-sthemmin@microsoft.com>
On Sat, Jan 7, 2017 at 7:17 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> Later patches remove pci_dev from the ethernet device structure.
> Fix the nfp code to just use it's own name when forming zone name.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> drivers/net/nfp/nfp_net.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
> index e85315f1..970b5c84 100644
> --- a/drivers/net/nfp/nfp_net.c
> +++ b/drivers/net/nfp/nfp_net.c
> @@ -213,8 +213,7 @@ ring_dma_zone_reserve(struct rte_eth_dev *dev, const char *ring_name,
> char z_name[RTE_MEMZONE_NAMESIZE];
> const struct rte_memzone *mz;
>
> - snprintf(z_name, sizeof(z_name), "%s_%s_%d_%d",
> - dev->driver->pci_drv.driver.name,
> + snprintf(z_name, sizeof(z_name), "nfp_%s_%u_%u",
> ring_name, dev->data->port_id, queue_id);
>
The driver is called 'net_nfp'.
> mz = rte_memzone_lookup(z_name);
> @@ -1009,7 +1008,6 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
> hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>
> dev_info->pci_dev = RTE_DEV_TO_PCI(dev->device);
> - dev_info->driver_name = dev->driver->pci_drv.driver.name;
> dev_info->max_rx_queues = (uint16_t)hw->max_rx_queues;
> dev_info->max_tx_queues = (uint16_t)hw->max_tx_queues;
> dev_info->min_rx_bufsize = ETHER_MIN_MTU;
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH 6/8] qat: don't refer to eth_dev->pci_dev
From: Jan Blunck @ 2017-01-10 12:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Stephen Hemminger
In-Reply-To: <20170107181756.1944-7-sthemmin@microsoft.com>
On Sat, Jan 7, 2017 at 7:17 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> Later patches remove pci_dev from the ethernet device structure.
> Fix the quick assist code to just use it's own name when forming zone name.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> drivers/crypto/qat/qat_qp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/qat/qat_qp.c b/drivers/crypto/qat/qat_qp.c
> index 2e7188bd..fe76e04a 100644
> --- a/drivers/crypto/qat/qat_qp.c
> +++ b/drivers/crypto/qat/qat_qp.c
> @@ -299,9 +299,9 @@ qat_queue_create(struct rte_cryptodev *dev, struct qat_queue *queue,
> /*
> * Allocate a memzone for the queue - create a unique name.
> */
> - snprintf(queue->memz_name, sizeof(queue->memz_name), "%s_%s_%d_%d_%d",
> - dev->driver->pci_drv.driver.name, "qp_mem", dev->data->dev_id,
> - queue->hw_bundle_number, queue->hw_queue_number);
> + snprintf(queue->memz_name, sizeof(queue->memz_name),
> + "qat_qp_mem_%d_%u_%u", dev->data->dev_id,
This driver is called 'crypto_qat'.
> + queue->hw_bundle_number, queue->hw_queue_number);
> qp_mz = queue_dma_zone_reserve(queue->memz_name, queue_size_bytes,
> socket_id);
> if (qp_mz == NULL) {
> --
> 2.11.0
>
^ permalink raw reply
* i40e_aq_get_phy_capabilities() fails when using SFP+ with no link
From: Christos Ricudis @ 2017-01-10 12:32 UTC (permalink / raw)
To: dev
Hello,
Using a X710 based 4-port 4x10Gbit NIC, I have came across the following issue on the i40e PMD:
When an optical SFP+ (Finisar FTLX8571D3BCL) is used with no active link partner on the other end of the link (or fiber completely disconnected from the SFP+), i40e_aq_get_phy_capabilities() (called by i40e_dev_sync_phy_type() on port initialization), fails with a 0x05 return value (EIO) on the AQ response structure. The struct i40e_aq_get_phy_abilities_resp buffer passed to the Get Phy Abilities command is unmodified upon return.
This prevents DPDK 16.11 from initializing the port, and ultimately fails with the following error:
PMD: eth_i40e_dev_init(): Failed to sync phy type: -95
The change introducing this issue was http://dpdk.org/ml/archives/dev/2016-September/047663.html
Reading the X710 datasheet, I notice that no specific mention is given on the meaning of EIO as a response to Get PHY Abilities command (opcode 0x0600), whereas in most other commands, an explicit mention of the meaning of the possible error status responses is given.
This behaviour is the same across the following NVM releases:
FW 4.33 API 1.2 NVM 04.04.02 eetrack 800018a6
FW 4.40 API 1.4 NVM 04.05.03 eetrack 80001cd8
FW 5.0 API 1.5 NVM 05.00.04 eetrack 800024da
I will try to get around the issue by falling back to PHY capabilities detection using the device ID in the case i40e_aq_get_phy_capabilities() fails, but conceptually the capabilities of the PHY should not be dependent on whether PHY detects an active link or not.
I’d be happy to do more testing on this issue per your recommendations.
Moreover, while trying to debug this issue, I managed to get both 3 NIC adapters on my test system on a state where the PHY has apparently died - no link indication at all on any ports. A reboot solved this, and I am now trying to replicate this behaviour under more controlled conditions.
Best regards,
Christos Ricudis.
^ permalink raw reply
* [PATCH 0/5] Assorted fixes for the flow API
From: Adrien Mazarguil @ 2017-01-10 13:08 UTC (permalink / raw)
To: dev
This series makes a few adjustments to the flow API (rte_flow) based on
issues encountered by preliminary PMD implementations and addresses bugs
reported by Coverity in the testpmd flow command.
Adrien Mazarguil (5):
app/testpmd: fix array bounds checks
ethdev: modify flow API's error setting function
ethdev: clarify MARK and FLAG actions in flow API
ethdev: clarify RSS action in flow API
ethdev: define default item masks in flow API
app/test-pmd/config.c | 8 +-
app/test-pmd/rxonly.c | 3 +-
doc/guides/prog_guide/rte_flow.rst | 57 +++++++------
lib/librte_ether/rte_flow.c | 24 +++---
lib/librte_ether/rte_flow.h | 137 +++++++++++++++++++++++++++-----
lib/librte_ether/rte_flow_driver.h | 6 +-
6 files changed, 170 insertions(+), 65 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 1/5] app/testpmd: fix array bounds checks
From: Adrien Mazarguil @ 2017-01-10 13:08 UTC (permalink / raw)
To: dev
In-Reply-To: <cover.1484046037.git.adrien.mazarguil@6wind.com>
This commit addresses several obvious issues reported by Coverity (139596,
139597, 139598 and 139599) with array bounds checks in functions related to
the flow API.
Fixes: 938a184a1870 ("app/testpmd: implement basic support for flow API")
Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
---
app/test-pmd/config.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 9716ce7..e1af064 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -884,7 +884,7 @@ port_flow_new(const struct rte_flow_attr *attr,
do {
struct rte_flow_item *dst = NULL;
- if ((unsigned int)item->type > RTE_DIM(flow_item) ||
+ if ((unsigned int)item->type >= RTE_DIM(flow_item) ||
!flow_item[item->type].name)
goto notsup;
if (pf)
@@ -918,7 +918,7 @@ port_flow_new(const struct rte_flow_attr *attr,
do {
struct rte_flow_action *dst = NULL;
- if ((unsigned int)action->type > RTE_DIM(flow_action) ||
+ if ((unsigned int)action->type >= RTE_DIM(flow_action) ||
!flow_action[action->type].name)
goto notsup;
if (pf)
@@ -977,7 +977,7 @@ port_flow_complain(struct rte_flow_error *error)
char buf[32];
int err = rte_errno;
- if ((unsigned int)error->type > RTE_DIM(errstrlist) ||
+ if ((unsigned int)error->type >= RTE_DIM(errstrlist) ||
!errstrlist[error->type])
errstr = "unknown type";
else
@@ -1146,7 +1146,7 @@ port_flow_query(portid_t port_id, uint32_t rule,
printf("Flow rule #%u not found\n", rule);
return -ENOENT;
}
- if ((unsigned int)action > RTE_DIM(flow_action) ||
+ if ((unsigned int)action >= RTE_DIM(flow_action) ||
!flow_action[action].name)
name = "unknown";
else
--
2.1.4
^ permalink raw reply related
* [PATCH 2/5] ethdev: modify flow API's error setting function
From: Adrien Mazarguil @ 2017-01-10 13:08 UTC (permalink / raw)
To: dev; +Cc: Nelio Laranjeiro, Wei Zhao, Beilei Xing
In-Reply-To: <cover.1484046037.git.adrien.mazarguil@6wind.com>
Based on initial PMD implementations of the flow API, returning the error
structure which may be NULL is useless and always discarded.
Returning the error code instead appears to be much more convenient.
Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Cc: Wei Zhao <wei.zhao1@intel.com>
Cc: Beilei Xing <beilei.xing@intel.com>
---
lib/librte_ether/rte_flow.c | 24 ++++++++++++------------
lib/librte_ether/rte_flow_driver.h | 6 +++---
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/lib/librte_ether/rte_flow.c b/lib/librte_ether/rte_flow.c
index d98fb1b..aaa70d6 100644
--- a/lib/librte_ether/rte_flow.c
+++ b/lib/librte_ether/rte_flow.c
@@ -78,9 +78,9 @@ rte_flow_validate(uint8_t port_id,
return -rte_errno;
if (likely(!!ops->validate))
return ops->validate(dev, attr, pattern, actions, error);
- rte_flow_error_set(error, ENOSYS, RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
- NULL, rte_strerror(ENOSYS));
- return -rte_errno;
+ return -rte_flow_error_set(error, ENOSYS,
+ RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+ NULL, rte_strerror(ENOSYS));
}
/* Create a flow rule on a given port. */
@@ -116,9 +116,9 @@ rte_flow_destroy(uint8_t port_id,
return -rte_errno;
if (likely(!!ops->destroy))
return ops->destroy(dev, flow, error);
- rte_flow_error_set(error, ENOSYS, RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
- NULL, rte_strerror(ENOSYS));
- return -rte_errno;
+ return -rte_flow_error_set(error, ENOSYS,
+ RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+ NULL, rte_strerror(ENOSYS));
}
/* Destroy all flow rules associated with a port. */
@@ -133,9 +133,9 @@ rte_flow_flush(uint8_t port_id,
return -rte_errno;
if (likely(!!ops->flush))
return ops->flush(dev, error);
- rte_flow_error_set(error, ENOSYS, RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
- NULL, rte_strerror(ENOSYS));
- return -rte_errno;
+ return -rte_flow_error_set(error, ENOSYS,
+ RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+ NULL, rte_strerror(ENOSYS));
}
/* Query an existing flow rule. */
@@ -153,7 +153,7 @@ rte_flow_query(uint8_t port_id,
return -rte_errno;
if (likely(!!ops->query))
return ops->query(dev, flow, action, data, error);
- rte_flow_error_set(error, ENOSYS, RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
- NULL, rte_strerror(ENOSYS));
- return -rte_errno;
+ return -rte_flow_error_set(error, ENOSYS,
+ RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+ NULL, rte_strerror(ENOSYS));
}
diff --git a/lib/librte_ether/rte_flow_driver.h b/lib/librte_ether/rte_flow_driver.h
index cc97785..d020536 100644
--- a/lib/librte_ether/rte_flow_driver.h
+++ b/lib/librte_ether/rte_flow_driver.h
@@ -139,9 +139,9 @@ struct rte_flow_ops {
* Human-readable error message.
*
* @return
- * Pointer to flow error structure.
+ * Error code (\code).
*/
-static inline struct rte_flow_error *
+static inline int
rte_flow_error_set(struct rte_flow_error *error,
int code,
enum rte_flow_error_type type,
@@ -156,7 +156,7 @@ rte_flow_error_set(struct rte_flow_error *error,
};
}
rte_errno = code;
- return error;
+ return code;
}
/**
--
2.1.4
^ permalink raw reply related
* [PATCH 3/5] ethdev: clarify MARK and FLAG actions in flow API
From: Adrien Mazarguil @ 2017-01-10 13:08 UTC (permalink / raw)
To: dev; +Cc: John McNamara
In-Reply-To: <cover.1484046037.git.adrien.mazarguil@6wind.com>
Both actions share the PKT_RX_FDIR mbuf flag, as a result there is no way
to tell them apart. Moreover, the maximum allowed value for the MARK action
may not necessarily cover the entire 32-bit space.
Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: John McNamara <john.mcnamara@intel.com>
---
doc/guides/prog_guide/rte_flow.rst | 24 ++++++++++++------------
lib/librte_ether/rte_flow.h | 19 ++++++++++---------
2 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index f415a73..a6acbbf 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1049,31 +1049,31 @@ flow rules:
Action: ``MARK``
^^^^^^^^^^^^^^^^
-Attaches a 32 bit value to packets.
+Attaches an integer value to packets and sets ``PKT_RX_FDIR`` and
+``PKT_RX_FDIR_ID`` mbuf flags.
-This value is arbitrary and application-defined. For compatibility with FDIR
-it is returned in the ``hash.fdir.hi`` mbuf field. ``PKT_RX_FDIR_ID`` is
-also set in ``ol_flags``.
+This value is arbitrary and application-defined. Maximum allowed value
+depends on the underlying implementation. It is returned in the
+``hash.fdir.hi`` mbuf field.
.. _table_rte_flow_action_mark:
.. table:: MARK
- +--------+-------------------------------------+
- | Field | Value |
- +========+=====================================+
- | ``id`` | 32 bit value to return with packets |
- +--------+-------------------------------------+
+ +--------+--------------------------------------+
+ | Field | Value |
+ +========+======================================+
+ | ``id`` | integer value to return with packets |
+ +--------+--------------------------------------+
Action: ``FLAG``
^^^^^^^^^^^^^^^^
-Flag packets. Similar to `Action: MARK`_ but only affects ``ol_flags``.
+Flags packets. Similar to `Action: MARK`_ without a specific value; only
+sets the ``PKT_RX_FDIR`` mbuf flag.
- No configurable properties.
-Note: a distinctive flag must be defined for it.
-
.. _table_rte_flow_action_flag:
.. table:: FLAG
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 98084ac..c2b9fc5 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -556,7 +556,8 @@ enum rte_flow_action_type {
/**
* [META]
*
- * Attaches a 32 bit value to packets.
+ * Attaches an integer value to packets and sets PKT_RX_FDIR and
+ * PKT_RX_FDIR_ID mbuf flags.
*
* See struct rte_flow_action_mark.
*/
@@ -565,9 +566,8 @@ enum rte_flow_action_type {
/**
* [META]
*
- * Flag packets. Similar to MARK but only affects ol_flags.
- *
- * Note: a distinctive flag must be defined for it.
+ * Flags packets. Similar to MARK without a specific value; only
+ * sets the PKT_RX_FDIR mbuf flag.
*
* No associated configuration structure.
*/
@@ -640,14 +640,15 @@ enum rte_flow_action_type {
/**
* RTE_FLOW_ACTION_TYPE_MARK
*
- * Attaches a 32 bit value to packets.
+ * Attaches an integer value to packets and sets PKT_RX_FDIR and
+ * PKT_RX_FDIR_ID mbuf flags.
*
- * This value is arbitrary and application-defined. For compatibility with
- * FDIR it is returned in the hash.fdir.hi mbuf field. PKT_RX_FDIR_ID is
- * also set in ol_flags.
+ * This value is arbitrary and application-defined. Maximum allowed value
+ * depends on the underlying implementation. It is returned in the
+ * hash.fdir.hi mbuf field.
*/
struct rte_flow_action_mark {
- uint32_t id; /**< 32 bit value to return with packets. */
+ uint32_t id; /**< Integer value to return with packets. */
};
/**
--
2.1.4
^ permalink raw reply related
* [PATCH 4/5] ethdev: clarify RSS action in flow API
From: Adrien Mazarguil @ 2017-01-10 13:08 UTC (permalink / raw)
To: dev; +Cc: Jingjing Wu, John McNamara
In-Reply-To: <cover.1484046037.git.adrien.mazarguil@6wind.com>
Contrary to the current description, mbuf RSS hash result storage does not
overlap with the returned MARK value (hash.fdir.lo vs. hash.fdir.hi), and
both may be combined.
Reflect this change by allowing testpmd to display both values
simultaneously.
Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: Jingjing Wu <jingjing.wu@intel.com>
Cc: John McNamara <john.mcnamara@intel.com>
---
app/test-pmd/rxonly.c | 3 ++-
doc/guides/prog_guide/rte_flow.rst | 8 +++-----
lib/librte_ether/rte_flow.h | 8 +++-----
3 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/app/test-pmd/rxonly.c b/app/test-pmd/rxonly.c
index cf00576..dcc8346 100644
--- a/app/test-pmd/rxonly.c
+++ b/app/test-pmd/rxonly.c
@@ -148,7 +148,8 @@ pkt_burst_receive(struct fwd_stream *fs)
if (ol_flags & PKT_RX_RSS_HASH) {
printf(" - RSS hash=0x%x", (unsigned) mb->hash.rss);
printf(" - RSS queue=0x%x",(unsigned) fs->rx_queue);
- } else if (ol_flags & PKT_RX_FDIR) {
+ }
+ if (ol_flags & PKT_RX_FDIR) {
printf(" - FDIR matched ");
if (ol_flags & PKT_RX_FDIR_ID)
printf("ID=0x%x",
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index a6acbbf..93d0dc2 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1187,11 +1187,9 @@ Action: ``RSS``
Similar to QUEUE, except RSS is additionally performed on packets to spread
them among several queues according to the provided parameters.
-Note: RSS hash result is normally stored in the ``hash.rss`` mbuf field,
-however it conflicts with `Action: MARK`_ as they share the same space. When
-both actions are specified, the RSS hash is discarded and
-``PKT_RX_RSS_HASH`` is not set in ``ol_flags``. MARK has priority. The mbuf
-structure should eventually evolve to store both.
+Note: RSS hash result is stored in the ``hash.rss`` mbuf field which
+overlaps ``hash.fdir.lo``. Since `Action: MARK`_ sets the ``hash.fdir.hi``
+field only, both can be requested simultaneously.
- Terminating by default.
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index c2b9fc5..59dc1ef 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -696,11 +696,9 @@ struct rte_flow_action_dup {
* Similar to QUEUE, except RSS is additionally performed on packets to
* spread them among several queues according to the provided parameters.
*
- * Note: RSS hash result is normally stored in the hash.rss mbuf field,
- * however it conflicts with the MARK action as they share the same
- * space. When both actions are specified, the RSS hash is discarded and
- * PKT_RX_RSS_HASH is not set in ol_flags. MARK has priority. The mbuf
- * structure should eventually evolve to store both.
+ * Note: RSS hash result is stored in the hash.rss mbuf field which overlaps
+ * hash.fdir.lo. Since the MARK action sets the hash.fdir.hi field only,
+ * both can be requested simultaneously.
*
* Terminating by default.
*/
--
2.1.4
^ permalink raw reply related
* [PATCH 5/5] ethdev: define default item masks in flow API
From: Adrien Mazarguil @ 2017-01-10 13:08 UTC (permalink / raw)
To: dev; +Cc: John McNamara, Nelio Laranjeiro, Wei Zhao, Beilei Xing
In-Reply-To: <cover.1484046037.git.adrien.mazarguil@6wind.com>
Leaving default pattern item mask values up for interpretation by PMDs is
an undefined behavior that applications might find difficult to use in the
wild. It also needlessly complicates PMD implementation.
This commit addresses this by defining consistent default masks for each
item type.
Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: John McNamara <john.mcnamara@intel.com>
Cc: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Cc: Wei Zhao <wei.zhao1@intel.com>
Cc: Beilei Xing <beilei.xing@intel.com>
---
doc/guides/prog_guide/rte_flow.rst | 25 ++++++--
lib/librte_ether/rte_flow.h | 110 +++++++++++++++++++++++++++++---
2 files changed, 121 insertions(+), 14 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 93d0dc2..3bf8871 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -217,13 +217,11 @@ Usage restrictions and expected behavior:
values lower than those in ``spec`` are not supported.
- Setting ``spec`` and optionally ``last`` without ``mask`` causes the PMD
- to only take the fields it can recognize into account. There is no error
- checking for unsupported fields.
+ to use the default mask defined for that item (defined as
+ ``rte_flow_item_{name}_mask`` constants).
-- Not setting any of them (assuming item type allows it) uses default
- parameters that depend on the item type. Most of the time, particularly
- for protocol header items, it is equivalent to providing an empty (zeroed)
- ``mask``.
+- Not setting any of them (assuming item type allows it) is equivalent to
+ providing an empty (zeroed) ``mask`` for broad (nonspecific) matching.
- ``mask`` is a simple bit-mask applied before interpreting the contents of
``spec`` and ``last``, which may yield unexpected results if not used
@@ -550,6 +548,7 @@ duplicated between device instances by default.
- Can be specified multiple times to match traffic addressed to several VF
IDs.
- Can be combined with a PF item to match both PF and VF traffic.
+- Default ``mask`` matches any VF ID.
.. _table_rte_flow_item_vf:
@@ -583,6 +582,8 @@ not be contiguous.
As a device property, the list of allowed values as well as the value
associated with a port_id should be retrieved by other means.
+- Default ``mask`` matches any port index.
+
.. _table_rte_flow_item_port:
.. table:: PORT
@@ -616,6 +617,8 @@ stand for several protocol layers.
This is usually specified as the first pattern item when looking for a
protocol anywhere in a packet.
+- Default ``mask`` stands for any number of layers.
+
.. _table_rte_flow_item_any:
.. table:: ANY
@@ -673,6 +676,7 @@ Matching a zero-length pattern is allowed, doing so resets the relative
offset for subsequent items.
- This type does not support ranges (``last`` field).
+- Default ``mask`` matches all fields exactly.
.. _table_rte_flow_item_raw:
@@ -785,6 +789,7 @@ Matches an Ethernet header.
- ``dst``: destination MAC.
- ``src``: source MAC.
- ``type``: EtherType.
+- Default ``mask`` matches destination and source addresses only.
Item: ``VLAN``
^^^^^^^^^^^^^^
@@ -793,6 +798,7 @@ Matches an 802.1Q/ad VLAN tag.
- ``tpid``: tag protocol identifier.
- ``tci``: tag control information.
+- Default ``mask`` matches TCI only.
Item: ``IPV4``
^^^^^^^^^^^^^^
@@ -802,6 +808,7 @@ Matches an IPv4 header.
Note: IPv4 options are handled by dedicated pattern items.
- ``hdr``: IPv4 header definition (``rte_ip.h``).
+- Default ``mask`` matches source and destination addresses only.
Item: ``IPV6``
^^^^^^^^^^^^^^
@@ -811,6 +818,7 @@ Matches an IPv6 header.
Note: IPv6 options are handled by dedicated pattern items.
- ``hdr``: IPv6 header definition (``rte_ip.h``).
+- Default ``mask`` matches source and destination addresses only.
Item: ``ICMP``
^^^^^^^^^^^^^^
@@ -818,6 +826,7 @@ Item: ``ICMP``
Matches an ICMP header.
- ``hdr``: ICMP header definition (``rte_icmp.h``).
+- Default ``mask`` matches ICMP type and code only.
Item: ``UDP``
^^^^^^^^^^^^^
@@ -825,6 +834,7 @@ Item: ``UDP``
Matches a UDP header.
- ``hdr``: UDP header definition (``rte_udp.h``).
+- Default ``mask`` matches source and destination ports only.
Item: ``TCP``
^^^^^^^^^^^^^
@@ -832,6 +842,7 @@ Item: ``TCP``
Matches a TCP header.
- ``hdr``: TCP header definition (``rte_tcp.h``).
+- Default ``mask`` matches source and destination ports only.
Item: ``SCTP``
^^^^^^^^^^^^^^
@@ -839,6 +850,7 @@ Item: ``SCTP``
Matches a SCTP header.
- ``hdr``: SCTP header definition (``rte_sctp.h``).
+- Default ``mask`` matches source and destination ports only.
Item: ``VXLAN``
^^^^^^^^^^^^^^^
@@ -849,6 +861,7 @@ Matches a VXLAN header (RFC 7348).
- ``rsvd0``: reserved, normally 0x000000.
- ``vni``: VXLAN network identifier.
- ``rsvd1``: reserved, normally 0x00.
+- Default ``mask`` matches VNI only.
Actions
~~~~~~~
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 59dc1ef..06da341 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -282,7 +282,12 @@ enum rte_flow_item_type {
* A zeroed mask stands for any number of layers.
*/
struct rte_flow_item_any {
- uint32_t num; /* Number of layers covered. */
+ uint32_t num; /**< Number of layers covered. */
+};
+
+/** Default mask for RTE_FLOW_ITEM_TYPE_ANY. */
+static const struct rte_flow_item_any rte_flow_item_any_mask = {
+ .num = 0x00000000,
};
/**
@@ -307,6 +312,11 @@ struct rte_flow_item_vf {
uint32_t id; /**< Destination VF ID. */
};
+/** Default mask for RTE_FLOW_ITEM_TYPE_VF. */
+static const struct rte_flow_item_vf rte_flow_item_vf_mask = {
+ .id = 0x00000000,
+};
+
/**
* RTE_FLOW_ITEM_TYPE_PORT
*
@@ -331,6 +341,11 @@ struct rte_flow_item_port {
uint32_t index; /**< Physical port index. */
};
+/** Default mask for RTE_FLOW_ITEM_TYPE_PORT. */
+static const struct rte_flow_item_port rte_flow_item_port_mask = {
+ .index = 0x00000000,
+};
+
/**
* RTE_FLOW_ITEM_TYPE_RAW
*
@@ -359,6 +374,16 @@ struct rte_flow_item_raw {
uint8_t pattern[]; /**< Byte string to look for. */
};
+/** Default mask for RTE_FLOW_ITEM_TYPE_RAW. */
+static const struct rte_flow_item_raw rte_flow_item_raw_mask = {
+ .relative = 1,
+ .search = 1,
+ .reserved = 0x3fffffff,
+ .offset = 0xffffffff,
+ .limit = 0xffff,
+ .length = 0xffff,
+};
+
/**
* RTE_FLOW_ITEM_TYPE_ETH
*
@@ -370,6 +395,13 @@ struct rte_flow_item_eth {
uint16_t type; /**< EtherType. */
};
+/** Default mask for RTE_FLOW_ITEM_TYPE_ETH. */
+static const struct rte_flow_item_eth rte_flow_item_eth_mask = {
+ .dst.addr_bytes = "\xff\xff\xff\xff\xff\xff",
+ .src.addr_bytes = "\xff\xff\xff\xff\xff\xff",
+ .type = 0x0000,
+};
+
/**
* RTE_FLOW_ITEM_TYPE_VLAN
*
@@ -383,6 +415,12 @@ struct rte_flow_item_vlan {
uint16_t tci; /**< Tag control information. */
};
+/** Default mask for RTE_FLOW_ITEM_TYPE_VLAN. */
+static const struct rte_flow_item_vlan rte_flow_item_vlan_mask = {
+ .tpid = 0x0000,
+ .tci = 0xffff,
+};
+
/**
* RTE_FLOW_ITEM_TYPE_IPV4
*
@@ -394,6 +432,14 @@ struct rte_flow_item_ipv4 {
struct ipv4_hdr hdr; /**< IPv4 header definition. */
};
+/** Default mask for RTE_FLOW_ITEM_TYPE_IPV4. */
+static const struct rte_flow_item_ipv4 rte_flow_item_ipv4_mask = {
+ .hdr = {
+ .src_addr = 0xffffffff,
+ .dst_addr = 0xffffffff,
+ },
+};
+
/**
* RTE_FLOW_ITEM_TYPE_IPV6.
*
@@ -405,6 +451,18 @@ struct rte_flow_item_ipv6 {
struct ipv6_hdr hdr; /**< IPv6 header definition. */
};
+/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
+static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
+ .hdr = {
+ .src_addr =
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff",
+ .dst_addr =
+ "\xff\xff\xff\xff\xff\xff\xff\xff"
+ "\xff\xff\xff\xff\xff\xff\xff\xff",
+ },
+};
+
/**
* RTE_FLOW_ITEM_TYPE_ICMP.
*
@@ -414,6 +472,14 @@ struct rte_flow_item_icmp {
struct icmp_hdr hdr; /**< ICMP header definition. */
};
+/** Default mask for RTE_FLOW_ITEM_TYPE_ICMP. */
+static const struct rte_flow_item_icmp rte_flow_item_icmp_mask = {
+ .hdr = {
+ .icmp_type = 0xff,
+ .icmp_code = 0xff,
+ },
+};
+
/**
* RTE_FLOW_ITEM_TYPE_UDP.
*
@@ -423,6 +489,14 @@ struct rte_flow_item_udp {
struct udp_hdr hdr; /**< UDP header definition. */
};
+/** Default mask for RTE_FLOW_ITEM_TYPE_UDP. */
+static const struct rte_flow_item_udp rte_flow_item_udp_mask = {
+ .hdr = {
+ .src_port = 0xffff,
+ .dst_port = 0xffff,
+ },
+};
+
/**
* RTE_FLOW_ITEM_TYPE_TCP.
*
@@ -432,6 +506,14 @@ struct rte_flow_item_tcp {
struct tcp_hdr hdr; /**< TCP header definition. */
};
+/** Default mask for RTE_FLOW_ITEM_TYPE_TCP. */
+static const struct rte_flow_item_tcp rte_flow_item_tcp_mask = {
+ .hdr = {
+ .src_port = 0xffff,
+ .dst_port = 0xffff,
+ },
+};
+
/**
* RTE_FLOW_ITEM_TYPE_SCTP.
*
@@ -441,6 +523,14 @@ struct rte_flow_item_sctp {
struct sctp_hdr hdr; /**< SCTP header definition. */
};
+/** Default mask for RTE_FLOW_ITEM_TYPE_SCTP. */
+static const struct rte_flow_item_sctp rte_flow_item_sctp_mask = {
+ .hdr = {
+ .src_port = 0xffff,
+ .dst_port = 0xffff,
+ },
+};
+
/**
* RTE_FLOW_ITEM_TYPE_VXLAN.
*
@@ -453,6 +543,11 @@ struct rte_flow_item_vxlan {
uint8_t rsvd1; /**< Reserved, normally 0x00. */
};
+/** Default mask for RTE_FLOW_ITEM_TYPE_VXLAN. */
+static const struct rte_flow_item_vxlan rte_flow_item_vxlan_mask = {
+ .vni = "\xff\xff\xff",
+};
+
/**
* Matching pattern item definition.
*
@@ -464,15 +559,18 @@ struct rte_flow_item_vxlan {
* Patterns are terminated by END items.
*
* The spec field should be a valid pointer to a structure of the related
- * item type. It may be set to NULL in many cases to use default values.
+ * item type. It may remain unspecified (NULL) in many cases to request
+ * broad (nonspecific) matching. In such cases, last and mask must also be
+ * set to NULL.
*
* Optionally, last can point to a structure of the same type to define an
* inclusive range. This is mostly supported by integer and address fields,
* may cause errors otherwise. Fields that do not support ranges must be set
* to 0 or to the same value as the corresponding fields in spec.
*
- * By default all fields present in spec are considered relevant (see note
- * below). This behavior can be altered by providing a mask structure of the
+ * Only the fields defined to nonzero values in the default masks (see
+ * rte_flow_item_{name}_mask constants) are considered relevant by
+ * default. This can be overridden by providing a mask structure of the
* same type with applicable bits set to one. It can also be used to
* partially filter out specific fields (e.g. as an alternate mean to match
* ranges of IP addresses).
@@ -482,10 +580,6 @@ struct rte_flow_item_vxlan {
* carefully. For example, if for an IPv4 address field, spec provides
* 10.1.2.3, last provides 10.3.4.5 and mask provides 255.255.0.0, the
* effective range becomes 10.1.0.0 to 10.3.255.255.
- *
- * Note: the defaults for data-matching items such as IPv4 when mask is not
- * specified actually depend on the underlying implementation since only
- * recognized fields can be taken into account.
*/
struct rte_flow_item {
enum rte_flow_item_type type; /**< Item type. */
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v8 00/25] Support VFD on i40e
From: Zhang, Helin @ 2017-01-10 13:24 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org
Cc: Lu, Wenzhuo, 'JOSHI, KAUSTUBH', 'DANIELS, EDWARD',
'ZELEZNIAK, ALEX'
In-Reply-To: <1484032580-60134-1-git-send-email-wenzhuo.lu@intel.com>
Acked-by: Helin Zhang <helin.zhang@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, January 10, 2017 3:16 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo
> Subject: [dpdk-dev] [PATCH v8 00/25] Support VFD on i40e
>
> 1, VF Daemon (VFD)
> VFD is an idea to control all the VFs from PF.
> As we need to support the scenario kernel PF + DPDK VF, DPDK follows the
> interface between kernel PF + kernel VF.
> We don't want to introduce too many new messages between PF and VF.
> So this patch set adds some new APIs to control VFs directly from PF.
> The new APIs include,
> 1) set VF MAC anti-spoofing
> 2) set VF VLAN anti-spoofing
> 3) set TX loopback
> 4) set VF unicast promiscuous mode
> 5) set VF multicast promiscuous mode
> 6) set VF MTU
> 7) get/reset VF stats
> 8) set VF MAC address
> 9) set VF VLAN stripping
> 10) VF VLAN insertion
> 12) set VF broadcast mode
> 12) set VF VLAN tag
> 13) set VF VLAN filter
> VFD also includes VF to PF mailbox message management by APP.
> When PF receives mailbox messages from VF, PF should call the callback
> provided by APP to know if they're permitted to be processed.
>
^ permalink raw reply
* Re: [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e
From: Vincent JARDIN @ 2017-01-10 13:29 UTC (permalink / raw)
To: Scott Daniels, dev; +Cc: kaustubh, az5157, Chen, Jing D
In-Reply-To: <586D647A.5040607@research.att.com>
Hi Scott,
Le 04/01/2017 à 22:09, Scott Daniels a écrit :
> With holidays we are a bit late with our thoughts, but would like to
> toss them into the mix.
Same, I hope I am not missing emails. I do appreciate your arguments, it
provides lot of light. See below,
> The original NAK is understandable, however having the ability to
> configure the PF via DPDK is advantageous for several reasons:
>
> 1) While some functions may be duplicated and/or available from the kernel
> driver, it is often not possible to introduce new kernel drivers into
> production without a large amount of additional testing of the entire
> platform which can cause a significant delay when introducing a DPDK based
> product. If the PF control is a part of the DPDK environment, then only
> the application needs to pass the operational testing before deployment; a
> much more simple task.
So we agree: you confirm that your foresee the benefits of using DPDK to
*bypass the role of the Kernel being the PF* of reference for the
hypervisor.
> 2) If the driver changes are upstreamed into the kernel proper, the
> difficulty of operational readiness testing increases as a new kernel is
> introduced, and further undermines the ability to quickly and easily
> release a DPDK based application into production. While the application
> may eventually fall back on driver and/or kernel support, this could be
> years away.
I do agree with the benefits of the agilities and the upsides it brings.
But they are other options to get the same agility without creating a
fragmentation of PFs.
For example, you do not have to update the whole kernel, you can just
update the PF kernel module that can be upgraded with the latest needed
features.
> 3) As DPDK is being used to configure the NIC, it just seems to make
> sense, for consistency, that the configuration capabilities should include
> the ability to configure the PF as is proposed.
From this perspective, the kernel modules are fine for the PF: most
kernels of hypervisors support it without the need to upgrade their kernels.
To summarize, I understand that you need a flexible way to upgrade PF
features without touching/changing the kernel. So let's check the kernel
module option? VFD brings some interesting capabilities, could it be a
way to push and stimulate the i40e features instead of using DPDK?
https://sourceforge.net/projects/e1000/files/i40e%20stable/
for instance could be better stimulated.
Best regards,
Vincent
^ permalink raw reply
* Re: [PATCH] doc: fix openssl formating text in documentation
From: De Lara Guarch, Pablo @ 2017-01-10 13:52 UTC (permalink / raw)
To: Mrzyglod, DanielX T, Mrozowicz, SlawomirX
Cc: dev@dpdk.org, Mrzyglod, DanielX T
In-Reply-To: <1484046261-112872-1-git-send-email-danielx.t.mrzyglod@intel.com>
Hi Daniel,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Daniel Mrzyglod
> Sent: Tuesday, January 10, 2017 11:04 AM
> To: Mrozowicz, SlawomirX
> Cc: dev@dpdk.org; Mrzyglod, DanielX T
> Subject: [dpdk-dev] [PATCH] doc: fix openssl formating text in
> documentation
No need to use documentation word again, "doc:" is enough.
>
> the code section was lacking indendation to be be corectly formatted.
Typo in "indendation" and "corectly", plus you should start with capital letter.
Thanks,
Pablo
>
> Signed-off-by: Daniel Mrzyglod <danielx.t.mrzyglod@intel.com>
> ---
> doc/guides/cryptodevs/openssl.rst | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: [PATCH] crypto/openssl: fix that remove unneeded check
From: De Lara Guarch, Pablo @ 2017-01-10 13:53 UTC (permalink / raw)
To: Doherty, Declan, Azarewicz, PiotrX T, dev@dpdk.org; +Cc: stable@dpdk.org
In-Reply-To: <0df6fc09-6d6e-f9fd-40e4-caae605469ff@intel.com>
> -----Original Message-----
> From: Doherty, Declan
> Sent: Tuesday, January 10, 2017 9:28 AM
> To: Azarewicz, PiotrX T; De Lara Guarch, Pablo; dev@dpdk.org
> Cc: stable@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] crypto/openssl: fix that remove unneeded
> check
>
> On 09/01/17 14:45, Piotr Azarewicz wrote:
> > EVP_CIPHER_CTX_set_padding() function always returns 1, so the check is
> > unneeded.
> >
> > Fixes: d61f70b4c918 ("crypto/libcrypto: add driver for OpenSSL library")
> >
> > Signed-off-by: Piotr Azarewicz <piotrx.t.azarewicz@intel.com>
> > ---
> > drivers/crypto/openssl/rte_openssl_pmd.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c
> b/drivers/crypto/openssl/rte_openssl_pmd.c
> > index 832ea1d..312154a 100644
> > --- a/drivers/crypto/openssl/rte_openssl_pmd.c
> > +++ b/drivers/crypto/openssl/rte_openssl_pmd.c
> > @@ -522,8 +522,7 @@
> > if (EVP_DecryptInit_ex(ctx, algo, NULL, key, iv) <= 0)
> > goto process_cipher_decrypt_err;
> >
> > - if (EVP_CIPHER_CTX_set_padding(ctx, 0) <= 0)
> > - goto process_cipher_decrypt_err;
> > + EVP_CIPHER_CTX_set_padding(ctx, 0);
> >
> > if (EVP_DecryptUpdate(ctx, dst, &dstlen, src, srclen) <= 0)
> > goto process_cipher_decrypt_err;
> >
>
> Acked-by: Declan Doherty <declan.doherty@intel.com>
Applied to dpdk-next-crypto.
Thanks,
Pablo
^ permalink raw reply
* Re: [PATCH] crypto test: add integrity check for mbuf data
From: De Lara Guarch, Pablo @ 2017-01-10 13:53 UTC (permalink / raw)
To: Kusztal, ArkadiuszX, Trahe, Fiona, dev@dpdk.org
Cc: Griffin, John, Jain, Deepak K, Trahe, Fiona
In-Reply-To: <80307F746F1522479831AB1253B7024E72157A@IRSMSX102.ger.corp.intel.com>
> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Monday, January 09, 2017 3:23 PM
> To: Trahe, Fiona; dev@dpdk.org
> Cc: Griffin, John; Jain, Deepak K; De Lara Guarch, Pablo; Trahe, Fiona
> Subject: RE: [dpdk-dev] [PATCH] crypto test: add integrity check for mbuf
> data
>
>
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Fiona Trahe
> > Sent: Thursday, December 22, 2016 4:51 PM
> > To: dev@dpdk.org
> > Cc: Griffin, John <john.griffin@intel.com>; Jain, Deepak K
> > <deepak.k.jain@intel.com>; De Lara Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>
> > Subject: [dpdk-dev] [PATCH] crypto test: add integrity check for mbuf
> data
> >
> > In block cipher test cases, add checks that the source and destination
> mbufs
> > are not modified except where expected.
> >
> > Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
> > ---
> > app/test/test_cryptodev_blockcipher.c | 139
> > ++++++++++++++++++++++++++++++++--
> > 1 file changed, 134 insertions(+), 5 deletions(-)
> >
> > --
> > 2.5.0
>
> Acked-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
Applied to dpdk-next-crypto.
Thanks,
Pablo
^ permalink raw reply
* Re: [PATCH 7/8] ethdev: break ethernet driver and pci_driver connection
From: Ferruh Yigit @ 2017-01-10 13:59 UTC (permalink / raw)
To: Stephen Hemminger, dev; +Cc: Stephen Hemminger, Shreyansh Jain
In-Reply-To: <20170107181756.1944-8-sthemmin@microsoft.com>
On 1/7/2017 6:17 PM, Stephen Hemminger wrote:
> There are multiple buses and device types now. Therefore it no longer
> makes sense that PCI driver information is part of the Ethernet driver
> structure.
>
> This patch removes pci_driver from eth_driver and introduces a
> new combined structure for use in all existing PMD's. The rationale
> is that although all existing PCI drivers are Ethernet drivers,
> it make sense that future projects may want to support PCI devices
> that are not Ethernet.
>
> It also removes the requirement that driver is first element in
> PCI driver structure.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
<...>
> /**
> + * @internal
> + * The structure associated with a PMD PCI Ethernet driver.
> + */
> +struct rte_pci_eth_driver {
> + struct rte_pci_driver pci_drv; /**< Underlying PCI driver. */
> + struct eth_driver eth_drv; /**< Ethernet driver. */
> +};
So do we need to add rte_vdev_eth_driver struct for virtual drivers, or
need to add rte_pci_cryptodev_driver struct for pci crypto devices?
Can this be done in a more generic way? After Shreyansh's patches, there
will be rte_device, rte_driver abstractions, can they be useful?
<...>
^ permalink raw reply
* Re: [PATCH v4] ethdev: fix port data mismatched in multiple process model
From: Yuanhan Liu @ 2017-01-10 14:33 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, stable, Bruce Richardson, Ferruh Yigit
In-Reply-To: <8073053.tGjfT9gznt@xps13>
On Mon, Jan 09, 2017 at 06:08:04PM +0100, Thomas Monjalon wrote:
> Hi Yuanhan,
>
> Nit: the title should be "v4 1/6"
Oops, my bad.
> Except that, good patch :)
>
> > Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
>
> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Thanks for review! Mind if I apply it to the next-virtio tree?
--yliu
^ permalink raw reply
* [PATCH] doc: fix openssl formating text
From: Daniel Mrzyglod @ 2017-01-10 14:44 UTC (permalink / raw)
To: slawomirx.mrozowicz; +Cc: dev, Daniel Mrzyglod
In-Reply-To: <1484046261-112872-1-git-send-email-danielx.t.mrzyglod@intel.com>
The code section was lacking indentation to be be correctly formatted.
Signed-off-by: Daniel Mrzyglod <danielx.t.mrzyglod@intel.com>
---
doc/guides/cryptodevs/openssl.rst | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/doc/guides/cryptodevs/openssl.rst b/doc/guides/cryptodevs/openssl.rst
index d2b5906..f1c39ba 100644
--- a/doc/guides/cryptodevs/openssl.rst
+++ b/doc/guides/cryptodevs/openssl.rst
@@ -98,15 +98,15 @@ To verify real traffic l2fwd-crypto example can be used with this command:
.. code-block:: console
-sudo ./build/l2fwd-crypto -c 0x3 -n 4 --vdev "crypto_openssl"
---vdev "crypto_openssl"-- -p 0x3 --chain CIPHER_HASH
---cipher_op ENCRYPT --cipher_algo AES_CBC
---cipher_key 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f
---iv 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:ff
---auth_op GENERATE --auth_algo SHA1_HMAC
---auth_key 11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11
-:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11
-:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11
+ sudo ./build/l2fwd-crypto -c 0x3 -n 4 --vdev "crypto_openssl"
+ --vdev "crypto_openssl"-- -p 0x3 --chain CIPHER_HASH
+ --cipher_op ENCRYPT --cipher_algo AES_CBC
+ --cipher_key 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f
+ --iv 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:ff
+ --auth_op GENERATE --auth_algo SHA1_HMAC
+ --auth_key 11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11
+ :11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11
+ :11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11
Limitations
-----------
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3] mempool: don't check mempool flags when cache is enabled
From: Olivier MATZ @ 2017-01-10 15:14 UTC (permalink / raw)
To: Wenfeng Liu
Cc: konstantin.ananyev, olivier.matz, dev,
konstantin.ananyev@intel.com
In-Reply-To: <1484036802-3031-1-git-send-email-liuwf@arraynetworks.com.cn>
Hi Wengfeng,
On Tue, 10 Jan 2017 08:26:42 +0000, Wenfeng Liu
<liuwf@arraynetworks.com.cn> wrote:
> Currently we will check mempool flags when we put/get objects from
> mempool. However, this makes cache useless when mempool is SC|SP,
> SC|MP, MC|SP cases.
> This patch makes cache available in above cases and improves
> performance.
>
> Signed-off-by: Wenfeng Liu <liuwf@arraynetworks.com.cn>
I agree with you and Konstantin. This should enhance performance in
single consumer/producer mode.
> @@ -1104,10 +1100,10 @@ static inline void
> __attribute__((always_inline)) */
> static inline void __attribute__((always_inline))
> rte_mempool_generic_put(struct rte_mempool *mp, void * const
> *obj_table,
> - unsigned n, struct rte_mempool_cache *cache,
> int flags)
> + unsigned n, struct rte_mempool_cache *cache,
> __rte_unused int flags) {
Small nit, seen with checkpatch:
WARNING:LONG_LINE: line over 80 characters
#43: FILE: lib/librte_mempool/rte_mempool.h:1103:
+ unsigned n, struct rte_mempool_cache *cache,
__rte_unused int flags)
The other warnings (Prefer 'unsigned int' to bare use of 'unsigned')
can be ignored, since it's not coming from your patch.
While there, I suggest another title that better reflects what is done:
"mempool: use cache in single producer or consumer mode"
Thanks,
Olivier
^ permalink raw reply
* Re: i40e_aq_get_phy_capabilities() fails when using SFP+ with no link
From: Olivier MATZ @ 2017-01-10 15:28 UTC (permalink / raw)
To: Christos Ricudis; +Cc: dev, helin.zhang, jingjing.wu
In-Reply-To: <2BF7FCC7-B2DF-43EE-B5F8-2F3271FB3DA1@gmail.com>
Hi Christos,
+CC i40e maintainers
On Tue, 10 Jan 2017 20:32:26 +0800, Christos Ricudis
<ricudis.christos@gmail.com> wrote:
> Hello,
>
> Using a X710 based 4-port 4x10Gbit NIC, I have came across the
> following issue on the i40e PMD:
>
> When an optical SFP+ (Finisar FTLX8571D3BCL) is used with no active
> link partner on the other end of the link (or fiber completely
> disconnected from the SFP+), i40e_aq_get_phy_capabilities() (called
> by i40e_dev_sync_phy_type() on port initialization), fails with a
> 0x05 return value (EIO) on the AQ response structure. The struct
> i40e_aq_get_phy_abilities_resp buffer passed to the Get Phy Abilities
> command is unmodified upon return.
>
> This prevents DPDK 16.11 from initializing the port, and ultimately
> fails with the following error:
>
> PMD: eth_i40e_dev_init(): Failed to sync phy type: -95
>
> The change introducing this issue was
> http://dpdk.org/ml/archives/dev/2016-September/047663.html
>
> Reading the X710 datasheet, I notice that no specific mention is
> given on the meaning of EIO as a response to Get PHY Abilities
> command (opcode 0x0600), whereas in most other commands, an explicit
> mention of the meaning of the possible error status responses is
> given.
>
> This behaviour is the same across the following NVM releases:
>
> FW 4.33 API 1.2 NVM 04.04.02 eetrack 800018a6
> FW 4.40 API 1.4 NVM 04.05.03 eetrack 80001cd8
> FW 5.0 API 1.5 NVM 05.00.04 eetrack 800024da
>
> I will try to get around the issue by falling back to PHY
> capabilities detection using the device ID in the case
> i40e_aq_get_phy_capabilities() fails, but conceptually the
> capabilities of the PHY should not be dependent on whether PHY
> detects an active link or not.
>
> I’d be happy to do more testing on this issue per your
> recommendations.
>
> Moreover, while trying to debug this issue, I managed to get both 3
> NIC adapters on my test system on a state where the PHY has
> apparently died - no link indication at all on any ports. A reboot
> solved this, and I am now trying to replicate this behaviour under
> more controlled conditions.
>
I'm currently running into a similar issue (I think). I can reproduce
it with testpmd with the following case:
set link_check off
port stop 0
# don't wait between these 2 commands
port start 0
I added some logs that are displayed after the port start:
PMD: i40e_set_tx_function(): Vector tx finally be used.
PMD: i40e_set_rx_function(): Vector rx enabled, please make sure RX
burst size no less than 4 (port=0).
PMD: i40e_dev_rx_queue_start(): >>
PMD: i40e_dev_tx_queue_start(): >>
PMD: i40e_dev_start(): applying link settings...
PMD: i40e_apply_link_speed(): abilities = 38, speed = 0
PMD: i40e_phy_conf_link(): i40e_aq_get_phy_capabilities failed -7
PMD: i40e_dev_start(): Fail to apply link setting
PMD: i40e_dev_clear_queues(): >>
The -7 corresponds to I40E_ERR_UNKNOWN_PHY. This happens in
i40e_aq_get_phy_capabilities() in the following code, which makes me
think it's the same problem than yours:
if (hw->aq.asq_last_status == I40E_AQ_RC_EIO)
status = I40E_ERR_UNKNOWN_PHY;
A workaround in my usecase is to wait a bit between the stop and the
start.
Any help is welcome.
Regards,
Olivier
^ permalink raw reply
* [PATCH 1/7] net/ixgbe/base: support Broadwell-DE XFI backplane
From: Wei Dai @ 2017-01-10 15:45 UTC (permalink / raw)
To: dev; +Cc: helin.zhang, konstantin.ananyev, Wei Dai
In-Reply-To: <1484063146-15796-1-git-send-email-wei.dai@intel.com>
This patch adds initial support for a Braodwell-DE XFI backplane
interface. The XFI backplane requires a custom tuned link.
Hardware/Firmware owns the link config for XF backplane and software
must not interfere with it.
Signed-off-by: Wei Dai <wei.dai@intel.com>
---
drivers/net/ixgbe/base/ixgbe_api.c | 1 +
drivers/net/ixgbe/base/ixgbe_type.h | 2 ++
drivers/net/ixgbe/base/ixgbe_x550.c | 11 +++++++++++
3 files changed, 14 insertions(+)
diff --git a/drivers/net/ixgbe/base/ixgbe_api.c b/drivers/net/ixgbe/base/ixgbe_api.c
index 0ddafcb..270a97d 100644
--- a/drivers/net/ixgbe/base/ixgbe_api.c
+++ b/drivers/net/ixgbe/base/ixgbe_api.c
@@ -205,6 +205,7 @@ s32 ixgbe_set_mac_type(struct ixgbe_hw *hw)
case IXGBE_DEV_ID_X550EM_X_10G_T:
case IXGBE_DEV_ID_X550EM_X_1G_T:
case IXGBE_DEV_ID_X550EM_X_SFP:
+ case IXGBE_DEV_ID_X550EM_X_XFI:
hw->mac.type = ixgbe_mac_X550EM_x;
hw->mvals = ixgbe_mvals_X550EM_x;
break;
diff --git a/drivers/net/ixgbe/base/ixgbe_type.h b/drivers/net/ixgbe/base/ixgbe_type.h
index b609f6e..dea210e 100644
--- a/drivers/net/ixgbe/base/ixgbe_type.h
+++ b/drivers/net/ixgbe/base/ixgbe_type.h
@@ -146,6 +146,7 @@ POSSIBILITY OF SUCH DAMAGE.
#define IXGBE_DEV_ID_X550EM_X_SFP 0x15AC
#define IXGBE_DEV_ID_X550EM_X_10G_T 0x15AD
#define IXGBE_DEV_ID_X550EM_X_1G_T 0x15AE
+#define IXGBE_DEV_ID_X550EM_X_XFI 0x15B0
#define IXGBE_DEV_ID_X550_VF_HV 0x1564
#define IXGBE_DEV_ID_X550_VF 0x1565
#define IXGBE_DEV_ID_X550EM_A_VF 0x15C5
@@ -3644,6 +3645,7 @@ enum ixgbe_phy_type {
ixgbe_phy_aq,
ixgbe_phy_x550em_kr,
ixgbe_phy_x550em_kx4,
+ ixgbe_phy_x550em_xfi,
ixgbe_phy_x550em_ext_t,
ixgbe_phy_cu_unknown,
ixgbe_phy_qt,
diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c b/drivers/net/ixgbe/base/ixgbe_x550.c
index 782ca91..2f7f446 100644
--- a/drivers/net/ixgbe/base/ixgbe_x550.c
+++ b/drivers/net/ixgbe/base/ixgbe_x550.c
@@ -450,6 +450,9 @@ STATIC s32 ixgbe_identify_phy_x550em(struct ixgbe_hw *hw)
case IXGBE_DEV_ID_X550EM_X_KX4:
hw->phy.type = ixgbe_phy_x550em_kx4;
break;
+ case IXGBE_DEV_ID_X550EM_X_XFI:
+ hw->phy.type = ixgbe_phy_x550em_xfi;
+ break;
case IXGBE_DEV_ID_X550EM_X_KR:
case IXGBE_DEV_ID_X550EM_A_KR:
case IXGBE_DEV_ID_X550EM_A_KR_L:
@@ -1573,6 +1576,7 @@ enum ixgbe_media_type ixgbe_get_media_type_X550em(struct ixgbe_hw *hw)
switch (hw->device_id) {
case IXGBE_DEV_ID_X550EM_X_KR:
case IXGBE_DEV_ID_X550EM_X_KX4:
+ case IXGBE_DEV_ID_X550EM_X_XFI:
case IXGBE_DEV_ID_X550EM_A_KR:
case IXGBE_DEV_ID_X550EM_A_KR_L:
media_type = ixgbe_media_type_backplane;
@@ -2395,6 +2399,12 @@ s32 ixgbe_init_phy_ops_X550em(struct ixgbe_hw *hw)
phy->ops.read_reg = ixgbe_read_phy_reg_x550em;
phy->ops.write_reg = ixgbe_write_phy_reg_x550em;
break;
+ case ixgbe_phy_x550em_xfi:
+ /* link is managed by HW */
+ phy->ops.setup_link = NULL;
+ phy->ops.read_reg = ixgbe_read_phy_reg_x550em;
+ phy->ops.write_reg = ixgbe_write_phy_reg_x550em;
+ break;
case ixgbe_phy_x550em_ext_t:
/* If internal link mode is XFI, then setup iXFI internal link,
* else setup KR now.
@@ -3669,6 +3679,7 @@ u32 ixgbe_get_supported_physical_layer_X550em(struct ixgbe_hw *hw)
switch (hw->phy.type) {
case ixgbe_phy_x550em_kr:
+ case ixgbe_phy_x550em_xfi:
physical_layer = IXGBE_PHYSICAL_LAYER_10GBASE_KR |
IXGBE_PHYSICAL_LAYER_1000BASE_KX;
break;
--
2.7.4
^ permalink raw reply related
* [PATCH 0/7] update ixgbe shared code to version 2017-01-05
From: Wei Dai @ 2017-01-10 15:45 UTC (permalink / raw)
To: dev; +Cc: helin.zhang, konstantin.ananyev, Wei Dai
This patch set updates ixgbe shared code to cid-ixgbe.2017.01.05.tar.gz .
The shared codes are in drivers/net/ixgbe/base/ and are developed by
another Intel team.
This patch add more supports to some Intel Broadwell-DE platforms.
A new device id and two PHY types are introduced and also
add some debug traces to help debugging.
Wei Dai (7):
net/ixgbe/base: support Broadwell-DE XFI backplane
net/ixgbe/base: remove a compiler warning
net/ixgbe/base: configure speeds for KR/KX backplane
net/ixgbe/base: support Marvell 1000BASE-T PHYs
net/ixgbe/base: use clause 22 MDIO functions for Marvell PHYs
net/ixgbe/base: add some debug traces
net/ixgbe/base: update version of shared code
drivers/net/ixgbe/base/README | 2 +-
drivers/net/ixgbe/base/ixgbe_api.c | 1 +
drivers/net/ixgbe/base/ixgbe_common.c | 9 +++-
drivers/net/ixgbe/base/ixgbe_phy.c | 20 +++++++--
drivers/net/ixgbe/base/ixgbe_type.h | 3 ++
drivers/net/ixgbe/base/ixgbe_x540.c | 11 ++++-
drivers/net/ixgbe/base/ixgbe_x550.c | 77 ++++++++++++++++++++++++++++++-----
7 files changed, 104 insertions(+), 19 deletions(-)
--
2.7.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox