* Re: [PATCH v3 3/4] net/ixgbe: add firmware version get
From: Ferruh Yigit @ 2017-01-04 12:01 UTC (permalink / raw)
To: Yang, Qiming, dev@dpdk.org, thomas.monjalon@6wind.com; +Cc: Horton, Remy
In-Reply-To: <F5DF4F0E3AFEF648ADC1C3C33AD4DBF16EDC9B80@SHSMSX101.ccr.corp.intel.com>
On 1/4/2017 9:48 AM, Yang, Qiming wrote:
> Yes, etrack_id is an unique value. But not all NICs have this value.
> I didn't find any value about fw version in fm10k.
Yes, you are right, following is from i40e datasheet:
"
The EEPROM Manager tool writes a unique 32-bit eTrack_ID number in two
sequential NVM words.
The eTrack_ID is written when EEPROM Manager tool creates an image on
the Intel network. The eTrack_ID DB tracks NVM images back to a specific
SCM build
"
So it is unique, and can be used to identify FW version. And yes it can
be enough on its own without having major minor FW version fields.
> I40e is 8 bit too.
> firmware-version: 5.04 0x800024ca
Right, I read it wrong, i40e also has 32bits etrack-id.
Thanks,
ferruh
^ permalink raw reply
* [PATCH v4 0/5] new API 'rte_eth_dev_fw_version_get'
From: Qiming Yang @ 2017-01-04 12:03 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, helin.zhang, remy.horton, Qiming Yang
In-Reply-To: <1482841816-54143-1-git-send-email-qiming.yang@intel.com>
Now, the example ethtool can only show the driver information. From
customers' point of view, it should be better if we can have the same
way that the Linux kernel ethtool does to show firmware-version.
These five patches added a new function ``rte_eth_dev_fw_version_get()``
to fetch firmware version related information and implement the
display in example ethtool.
Qiming Yang (5):
ethdev: add firmware version get
net/e1000: add firmware version get
net/ixgbe: add firmware version get
net/i40e: add firmware version get
ethtool: dispaly firmware version
doc/guides/nics/features/default.ini | 1 +
doc/guides/nics/features/i40e.ini | 1 +
doc/guides/nics/features/igb.ini | 1 +
doc/guides/nics/features/ixgbe.ini | 1 +
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_17_02.rst | 3 +++
drivers/net/e1000/igb_ethdev.c | 43 ++++++++++++++++++++++++++++++++++
drivers/net/i40e/i40e_ethdev.c | 15 ++++++++++++
drivers/net/ixgbe/ixgbe_ethdev.c | 17 ++++++++++++++
examples/ethtool/ethtool-app/ethapp.c | 1 +
examples/ethtool/lib/rte_ethtool.c | 12 ++++++++++
lib/librte_ether/rte_ethdev.c | 14 +++++++++++
lib/librte_ether/rte_ethdev.h | 23 ++++++++++++++++++
lib/librte_ether/rte_ether_version.map | 1 +
14 files changed, 133 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v4 1/5] ethdev: add firmware version get
From: Qiming Yang @ 2017-01-04 12:03 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, helin.zhang, remy.horton, Qiming Yang
In-Reply-To: <1483531428-14481-1-git-send-email-qiming.yang@intel.com>
This patch adds a new API 'rte_eth_dev_fw_version_get' for
fetching firmware version related information by a given device.
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
Acked-by: Remy Horton <remy.horton@intel.com>
---
v2 changes:
* modified some comment statements.
v3 changes:
* change API, use rte_eth_dev_fw_info_get(uint8_t port_id,
uint32_t *fw_major, uint32_t *fw_minor, uint32_t *fw_patch,
uint32_t *etrack_id) instead of rte_eth_dev_fwver_get(uint8_t port_id,
char *fw_version, int fw_length).
Add statusment in /doc/guides/nics/features/default.ini and
release_17_02.rst.
v4 changes:
* remove deprecation notice, rename API as rte_eth_dev_fw_version_get
---
---
doc/guides/nics/features/default.ini | 1 +
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_17_02.rst | 3 +++
lib/librte_ether/rte_ethdev.c | 14 ++++++++++++++
lib/librte_ether/rte_ethdev.h | 23 +++++++++++++++++++++++
lib/librte_ether/rte_ether_version.map | 1 +
6 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index f1bf9bf..ae40d57 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -50,6 +50,7 @@ Timesync =
Basic stats =
Extended stats =
Stats per queue =
+FW version =
EEPROM dump =
Registers dump =
Multiprocess aware =
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1438c77..291e03d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -30,10 +30,6 @@ Deprecation Notices
``nb_seg_max`` and ``nb_mtu_seg_max`` providing information about number of
segments limit to be transmitted by device for TSO/non-TSO packets.
-* In 17.02 ABI change is planned: the ``rte_eth_dev_info`` structure
- will be extended with a new member ``fw_version`` in order to store
- the NIC firmware version.
-
* ethdev: an API change is planned for 17.02 for the function
``_rte_eth_dev_callback_process``. In 17.02 the function will return an ``int``
instead of ``void`` and a fourth parameter ``void *ret_param`` will be added.
diff --git a/doc/guides/rel_notes/release_17_02.rst b/doc/guides/rel_notes/release_17_02.rst
index 180af82..d6958d4 100644
--- a/doc/guides/rel_notes/release_17_02.rst
+++ b/doc/guides/rel_notes/release_17_02.rst
@@ -52,6 +52,9 @@ New Features
See the :ref:`Generic flow API <Generic_flow_API>` documentation for more
information.
+* **Added firmware version get API.**
+ Added a new function ``rte_eth_dev_fw_version_get()`` to fetch firmware version
+ related information by a given device.
Resolved Issues
---------------
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 280f0db..a4b20b5 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1586,6 +1586,20 @@ rte_eth_dev_set_rx_queue_stats_mapping(uint8_t port_id, uint16_t rx_queue_id,
}
void
+rte_eth_dev_fw_version_get(uint8_t port_id, uint32_t *fw_major,
+ uint32_t *fw_minor, uint32_t *fw_patch, uint32_t *etrack_id)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_RET(port_id);
+ dev = &rte_eth_devices[port_id];
+
+ RTE_FUNC_PTR_OR_RET(*dev->dev_ops->fw_version_get);
+ (*dev->dev_ops->fw_version_get)(dev, fw_major, fw_minor,
+ fw_patch, etrack_id);
+}
+
+void
rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info)
{
struct rte_eth_dev *dev;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index fb51754..9c7efa1 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1150,6 +1150,11 @@ typedef uint32_t (*eth_rx_queue_count_t)(struct rte_eth_dev *dev,
typedef int (*eth_rx_descriptor_done_t)(void *rxq, uint16_t offset);
/**< @internal Check DD bit of specific RX descriptor */
+typedef void (*eth_fw_version_get_t)(struct rte_eth_dev *dev,
+ uint32_t *fw_major, uint32_t *fw_minor,
+ uint32_t *fw_patch, uint32_t *etrack_id);
+/**< @internal Get firmware version information of an Ethernet device. */
+
typedef void (*eth_rxq_info_get_t)(struct rte_eth_dev *dev,
uint16_t rx_queue_id, struct rte_eth_rxq_info *qinfo);
@@ -1457,6 +1462,7 @@ struct eth_dev_ops {
eth_txq_info_get_t txq_info_get; /**< retrieve TX queue information. */
eth_dev_supported_ptypes_get_t dev_supported_ptypes_get;
/**< Get packet types supported and identified by device. */
+ eth_fw_version_get_t fw_version_get; /**< Get firmware version. */
vlan_filter_set_t vlan_filter_set; /**< Filter VLAN Setup. */
vlan_tpid_set_t vlan_tpid_set; /**< Outer/Inner VLAN TPID Setup. */
@@ -2395,6 +2401,23 @@ void rte_eth_macaddr_get(uint8_t port_id, struct ether_addr *mac_addr);
void rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info);
/**
+ * Retrieve the firmware version of a device.
+ *
+ * @param port_id
+ * The port identifier of the device.
+ * @param fw_major
+ * A pointer to store the major firmware version of a device.
+ * @param fw_minor
+ * A pointer to store the minor firmware version of a device.
+ * @param fw_patch
+ * A pointer to store the firmware patch number of a device.
+ * @param etrack_id
+ * A pointer to store the nvm version of a device.
+ */
+void rte_eth_dev_fw_version_get(uint8_t port_id, uint32_t *fw_major,
+ uint32_t *fw_minor, uint32_t *fw_patch, uint32_t *etrack_id);
+
+/**
* Retrieve the supported packet types of an Ethernet device.
*
* When a packet type is announced as supported, it *must* be recognized by
diff --git a/lib/librte_ether/rte_ether_version.map b/lib/librte_ether/rte_ether_version.map
index a021781..0cf94ed 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -151,6 +151,7 @@ DPDK_17.02 {
global:
_rte_eth_dev_reset;
+ rte_eth_dev_fw_version_get;
rte_flow_create;
rte_flow_destroy;
rte_flow_flush;
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/5] net/e1000: add firmware version get
From: Qiming Yang @ 2017-01-04 12:03 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, helin.zhang, remy.horton, Qiming Yang
In-Reply-To: <1483531428-14481-1-git-send-email-qiming.yang@intel.com>
This patch adds a new function eth_igb_fw_version_get.
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
---
v3 changes:
* use eth_igb_fw_version_get(struct rte_eth_dev *dev, u32 *fw_major,
u32 *fw_minor, u32 *fw_minor, u32 *fw_patch, u32 *etrack_id) instead
of eth_igb_fw_version_get(struct rte_eth_dev *dev, char *fw_version,
int fw_length). Add statusment in /doc/guides/nics/features/igb.ini.
---
---
doc/guides/nics/features/igb.ini | 1 +
drivers/net/e1000/igb_ethdev.c | 43 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 44 insertions(+)
diff --git a/doc/guides/nics/features/igb.ini b/doc/guides/nics/features/igb.ini
index 9fafe72..26ae008 100644
--- a/doc/guides/nics/features/igb.ini
+++ b/doc/guides/nics/features/igb.ini
@@ -35,6 +35,7 @@ Packet type parsing = Y
Timesync = Y
Basic stats = Y
Extended stats = Y
+FW version = Y
EEPROM dump = Y
Registers dump = Y
BSD nic_uio = Y
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 4a15447..25344b7 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -120,6 +120,8 @@ static int eth_igb_xstats_get_names(struct rte_eth_dev *dev,
unsigned limit);
static void eth_igb_stats_reset(struct rte_eth_dev *dev);
static void eth_igb_xstats_reset(struct rte_eth_dev *dev);
+static void eth_igb_fw_version_get(struct rte_eth_dev *dev, u32 *fw_major,
+ u32 *fw_minor, u32 *fw_patch, u32 *etrack_id);
static void eth_igb_infos_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
static const uint32_t *eth_igb_supported_ptypes_get(struct rte_eth_dev *dev);
@@ -389,6 +391,7 @@ static const struct eth_dev_ops eth_igb_ops = {
.xstats_get_names = eth_igb_xstats_get_names,
.stats_reset = eth_igb_stats_reset,
.xstats_reset = eth_igb_xstats_reset,
+ .fw_version_get = eth_igb_fw_version_get,
.dev_infos_get = eth_igb_infos_get,
.dev_supported_ptypes_get = eth_igb_supported_ptypes_get,
.mtu_set = eth_igb_mtu_set,
@@ -1981,6 +1984,46 @@ eth_igbvf_stats_reset(struct rte_eth_dev *dev)
}
static void
+eth_igb_fw_version_get(struct rte_eth_dev *dev, u32 *fw_major, u32 *fw_minor,
+ u32 *fw_patch, u32 *etrack_id)
+{
+ struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct e1000_fw_version fw;
+
+ e1000_get_fw_version(hw, &fw);
+
+ switch (hw->mac.type) {
+ case e1000_i210:
+ case e1000_i211:
+ if (!(e1000_get_flash_presence_i210(hw))) {
+ *fw_major = fw.invm_major;
+ *fw_minor = fw.invm_minor;
+ break;
+ }
+ /* fall through */
+ default:
+ /* if option rom is valid, display its version too*/
+ if (fw.or_valid) {
+ *fw_major = fw.eep_major;
+ *fw_minor = fw.eep_minor;
+ *etrack_id = fw.etrack_id;
+ *fw_patch = fw.or_patch;
+ /* no option rom */
+ } else {
+ if (fw.etrack_id != 0X0000) {
+ *fw_major = fw.eep_major;
+ *fw_minor = fw.eep_minor;
+ *etrack_id = fw.etrack_id;
+ } else {
+ *fw_major = fw.eep_major;
+ *fw_minor = fw.eep_minor;
+ }
+ }
+ break;
+ }
+}
+
+static void
eth_igb_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
{
struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/5] net/ixgbe: add firmware version get
From: Qiming Yang @ 2017-01-04 12:03 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, helin.zhang, remy.horton, Qiming Yang
In-Reply-To: <1483531428-14481-1-git-send-email-qiming.yang@intel.com>
This patch add a new function ixgbe_fw_version_get.
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
---
v3 changes:
* use ixgbe_fw_version_get(struct rte_eth_dev *dev,
__rte_unused u32 *fw_major, __rte_unused u32 *fw_minor,
__rte_unused u32 *fw_patch, u32 *etrack_id) instead of
ixgbe_fw_version_get(struct rte_eth_dev *dev, char *fw_version,
int fw_length). Add statusment in /doc/guides/nics/features/ixgbe.ini.
---
---
doc/guides/nics/features/ixgbe.ini | 1 +
drivers/net/ixgbe/ixgbe_ethdev.c | 17 +++++++++++++++++
2 files changed, 18 insertions(+)
diff --git a/doc/guides/nics/features/ixgbe.ini b/doc/guides/nics/features/ixgbe.ini
index 4a5667f..b46287a 100644
--- a/doc/guides/nics/features/ixgbe.ini
+++ b/doc/guides/nics/features/ixgbe.ini
@@ -43,6 +43,7 @@ Timesync = Y
Basic stats = Y
Extended stats = Y
Stats per queue = Y
+FW_version = Y
EEPROM dump = Y
Registers dump = Y
Multiprocess aware = Y
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index ec2edad..e2234c0 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -193,6 +193,9 @@ static int ixgbe_dev_queue_stats_mapping_set(struct rte_eth_dev *eth_dev,
uint16_t queue_id,
uint8_t stat_idx,
uint8_t is_rx);
+static void ixgbe_fw_version_get(struct rte_eth_dev *dev,
+ __rte_unused u32 *fw_major, __rte_unused u32 *fw_minor,
+ __rte_unused u32 *fw_patch, u32 *etrack_id);
static void ixgbe_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
static const uint32_t *ixgbe_dev_supported_ptypes_get(struct rte_eth_dev *dev);
@@ -538,6 +541,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
.xstats_reset = ixgbe_dev_xstats_reset,
.xstats_get_names = ixgbe_dev_xstats_get_names,
.queue_stats_mapping_set = ixgbe_dev_queue_stats_mapping_set,
+ .fw_version_get = ixgbe_fw_version_get,
.dev_infos_get = ixgbe_dev_info_get,
.dev_supported_ptypes_get = ixgbe_dev_supported_ptypes_get,
.mtu_set = ixgbe_dev_mtu_set,
@@ -3029,6 +3033,19 @@ ixgbevf_dev_stats_reset(struct rte_eth_dev *dev)
}
static void
+ixgbe_fw_version_get(struct rte_eth_dev *dev, __rte_unused u32 *fw_major,
+ __rte_unused u32 *fw_minor, __rte_unused u32 *fw_patch, u32 *etrack_id)
+{
+ struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ u16 eeprom_verh, eeprom_verl;
+
+ ixgbe_read_eeprom(hw, 0x2e, &eeprom_verh);
+ ixgbe_read_eeprom(hw, 0x2d, &eeprom_verl);
+
+ *etrack_id = (eeprom_verh << 16) | eeprom_verl;
+}
+
+static void
ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
{
struct rte_pci_device *pci_dev = IXGBE_DEV_TO_PCI(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 4/5] net/i40e: add firmware version get
From: Qiming Yang @ 2017-01-04 12:03 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, helin.zhang, remy.horton, Qiming Yang
In-Reply-To: <1483531428-14481-1-git-send-email-qiming.yang@intel.com>
This patch add a new function i40e_fw_version_get.
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
---
v3 changes:
* use i40e_fw_version_get(struct rte_eth_dev *dev, u32 *fw_major,
u32 *fw_minor, __rte_unused u32 *fw_patch, u32 *etrack_id)
instead of i40e_fw_version_get(struct rte_eth_dev *dev,
char *fw_version, int fw_length). Add statusment in
/doc/guides/nics/features/i40e.ini.
---
---
doc/guides/nics/features/i40e.ini | 1 +
drivers/net/i40e/i40e_ethdev.c | 15 +++++++++++++++
2 files changed, 16 insertions(+)
diff --git a/doc/guides/nics/features/i40e.ini b/doc/guides/nics/features/i40e.ini
index 0d143bc..6dab9f7 100644
--- a/doc/guides/nics/features/i40e.ini
+++ b/doc/guides/nics/features/i40e.ini
@@ -46,3 +46,4 @@ Linux VFIO = Y
x86-32 = Y
x86-64 = Y
ARMv8 = Y
+FW version = Y
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 8f63044..1dbbcc4 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -324,6 +324,8 @@ static int i40e_dev_queue_stats_mapping_set(struct rte_eth_dev *dev,
uint16_t queue_id,
uint8_t stat_idx,
uint8_t is_rx);
+static void i40e_fw_version_get(struct rte_eth_dev *dev, u32 *fw_major,
+ u32 *fw_minor, __rte_unused u32 *fw_patch, u32 *etrack_id);
static void i40e_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
static int i40e_vlan_filter_set(struct rte_eth_dev *dev,
@@ -503,6 +505,7 @@ static const struct eth_dev_ops i40e_eth_dev_ops = {
.stats_reset = i40e_dev_stats_reset,
.xstats_reset = i40e_dev_stats_reset,
.queue_stats_mapping_set = i40e_dev_queue_stats_mapping_set,
+ .fw_version_get = i40e_fw_version_get,
.dev_infos_get = i40e_dev_info_get,
.dev_supported_ptypes_get = i40e_dev_supported_ptypes_get,
.vlan_filter_set = i40e_vlan_filter_set,
@@ -2590,6 +2593,18 @@ i40e_dev_queue_stats_mapping_set(__rte_unused struct rte_eth_dev *dev,
}
static void
+i40e_fw_version_get(struct rte_eth_dev *dev, u32 *fw_major, u32 *fw_minor,
+ __rte_unused u32 *fw_patch, u32 *etrack_id)
+{
+ struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ *fw_major = (hw->nvm.version >> 12) & 0xf;
+ *fw_minor = ((hw->nvm.version >> 4) & 0xff) * 10 +
+ (hw->nvm.version & 0xf);
+ *etrack_id = hw->nvm.eetrack;
+}
+
+static void
i40e_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
{
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 5/5] ethtool: dispaly firmware version
From: Qiming Yang @ 2017-01-04 12:03 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, helin.zhang, remy.horton, Qiming Yang
In-Reply-To: <1483531428-14481-1-git-send-email-qiming.yang@intel.com>
This patch enhances the ethtool example to support to show
firmware version, in the same way that the Linux kernel
ethtool does.
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
---
v4 changes:
* split bus info print from this patch set
---
---
examples/ethtool/ethtool-app/ethapp.c | 1 +
examples/ethtool/lib/rte_ethtool.c | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/examples/ethtool/ethtool-app/ethapp.c b/examples/ethtool/ethtool-app/ethapp.c
index 6aeaa06..85c31ac 100644
--- a/examples/ethtool/ethtool-app/ethapp.c
+++ b/examples/ethtool/ethtool-app/ethapp.c
@@ -185,6 +185,7 @@ pcmd_drvinfo_callback(__rte_unused void *ptr_params,
printf("Port %i driver: %s (ver: %s)\n",
id_port, info.driver, info.version
);
+ printf("firmware-version: %s\n", info.fw_version);
}
}
diff --git a/examples/ethtool/lib/rte_ethtool.c b/examples/ethtool/lib/rte_ethtool.c
index 6f0ce84..741468f 100644
--- a/examples/ethtool/lib/rte_ethtool.c
+++ b/examples/ethtool/lib/rte_ethtool.c
@@ -54,6 +54,12 @@ rte_ethtool_get_drvinfo(uint8_t port_id, struct ethtool_drvinfo *drvinfo)
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ uint32_t fw_major = 0;
+ uint32_t fw_minor = 0;
+ uint32_t etrack = 0;
+
+ rte_eth_dev_fw_version_get(port_id, &fw_major, &fw_minor,
+ NULL, &etrack);
memset(&dev_info, 0, sizeof(dev_info));
rte_eth_dev_info_get(port_id, &dev_info);
@@ -61,6 +67,12 @@ rte_ethtool_get_drvinfo(uint8_t port_id, struct ethtool_drvinfo *drvinfo)
dev_info.driver_name);
snprintf(drvinfo->version, sizeof(drvinfo->version), "%s",
rte_version());
+ if (strcmp(drvinfo->driver, "net_ixgbe") == 0)
+ snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
+ "0x%08x", etrack);
+ else
+ snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
+ "%d.%02d 0x%08x", fw_major, fw_minor, etrack);
if (dev_info.pci_dev)
snprintf(drvinfo->bus_info, sizeof(drvinfo->bus_info),
"%04x:%02x:%02x.%x",
--
2.7.4
^ permalink raw reply related
* [PATCH v4] ethtool: dispaly bus information
From: Qiming Yang @ 2017-01-04 12:18 UTC (permalink / raw)
To: dev; +Cc: ferruh.yigit, helin.zhang, remy.horton, Qiming Yang
In-Reply-To: <1482843968-6483-1-git-send-email-qiming.yang@intel.com>
This patch enhances the ethtool example to support to show
bus information, in the same way that the Linux kernel
ethtool does.
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
Acked-by: Remy Horton <remy.horton@intel.com>
---
v4 changes:
* split bus info print from patch set ethdev: add firmware version get
---
---
examples/ethtool/ethtool-app/ethapp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/examples/ethtool/ethtool-app/ethapp.c b/examples/ethtool/ethtool-app/ethapp.c
index 85c31ac..35269ea 100644
--- a/examples/ethtool/ethtool-app/ethapp.c
+++ b/examples/ethtool/ethtool-app/ethapp.c
@@ -186,6 +186,7 @@ pcmd_drvinfo_callback(__rte_unused void *ptr_params,
id_port, info.driver, info.version
);
printf("firmware-version: %s\n", info.fw_version);
+ printf("bus-info: %s\n", info.bus_info);
}
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] nfp: add support for new metadata api
From: Ferruh Yigit @ 2017-01-04 12:26 UTC (permalink / raw)
To: Alejandro Lucero, dev
In-Reply-To: <1482243237-28625-1-git-send-email-alejandro.lucero@netronome.com>
On 12/20/2016 2:13 PM, Alejandro Lucero wrote:
> NFP is a smart programmable NIC and firmware is deployed for specific
> system needs, like offloading OVS, vRouter, contrack or eBPF into the
> hardware. This often requires to give metadata to the host within
> packets delivered. Last NFP firmware implementations support richer
> metadata api facilitating interaction between firmware and host code.
>
> Old way of handling metadata needs to be still there for supporting
> old firmware.
>
> Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
Applied to dpdk-next-net/master, thanks.
^ permalink raw reply
* Re: [PATCH] nfp: add tso support
From: Ferruh Yigit @ 2017-01-04 12:27 UTC (permalink / raw)
To: Alejandro Lucero, dev
In-Reply-To: <1482229099-9629-1-git-send-email-alejandro.lucero@netronome.com>
On 12/20/2016 10:18 AM, Alejandro Lucero wrote:
> This patch implements NFP PMD support for TSO but it also requires
> a firmware advertising the capability.
>
> Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
Applied to dpdk-next-net/master, thanks.
^ permalink raw reply
* Re: XL710 with i40e driver drops packets on RX even on a small rates.
From: Martin Weiser @ 2017-01-04 12:33 UTC (permalink / raw)
To: dev, Ilya Maximets; +Cc: Helin Zhang, Jingjing Wu
In-Reply-To: <caab1c38-1f5c-9448-baa0-5f3d38f799bc@allegro-packets.com>
Hello,
I have performed some more thorough testing on 3 different machines to
illustrate the strange results with XL710.
Please note that all 3 systems were able to forward the traffic of Test
1 and Test 2 without packet loss when a 82599ES NIC was installed in the
same PCI slot as the XL710 in the tests below.
Here is the test setup and the test results:
## Test traffic
In all tests the t-rex traffic generator was used to generate traffic on
a XL710 card with the following parameters:
### Test 1
./t-rex-64 -f cap2/imix_1518.yaml -c 4 -d 60 -m 25 --flip
This resulted in a 60 second run with ~1.21 Gbps traffic on each of the
two interfaces with ~100000 packets per
second on each interface.
### Test 2
./t-rex-64 -f cap2/imix_1518.yaml -c 4 -d 60 -m 100 --flip
This resulted in a 60 second run with ~4.85 Gbps traffic on each of the
two interfaces with ~400000 packets per
second on each interface.
### Test 3
./t-rex-64 -f cap2/imix_1518.yaml -c 4 -d 60 -m 400 --flip
This resulted in a 60 second run with ~19.43 Gbps traffic on each of the
two interfaces with ~1600000 packets per
second on each interface.
## DPDK
On all systems a vanilla DPDK v16.11 testpmd was used with the following
parameters (PCI IDs differed between systems):
./build/app/testpmd -l 1,2 -w 0000:06:00.0 -w 0000:06:00.1 -- -i
## System 1
* Board: Supermicro X10SDV-TP8F
* CPU:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 86
Model name: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz
Stepping: 3
CPU MHz: 800.250
CPU max MHz: 2200.0000
CPU min MHz: 800.0000
BogoMIPS: 4399.58
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
NUMA node0 CPU(s): 0-7
Flags: fpu vme de pse tsc msr pae mce cx8 apic
sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht
tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid
dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx
f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi
flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms
invpcid rtm cqm rdseed adx smap xsaveopt cqm_llc cqm_occup_llc
cqm_mbm_total cqm_mbm_local dtherm arat pln pts
* Memory channels: 2
* Memory: 2 * 8192 MB DDR4 @ 2133 MHz
* NIC firmware: FW 5.0 API 1.5 NVM 05.00.04 eetrack 80002505
* i40e version: 1.4.25-k
* OS: Ubuntu 16.04.1 LTS
* Kernel: 4.4.0-57-generic
* Kernel parameters: isolcpus=1,2,3,5,6,7 default_hugepagesz=1G
hugepagesz=1G hugepages=1
### Test 1
Mostly no packet loss. Sometimes ~10 packets missed of ~600000 on each
interface when testpmd was not started in
interactive mode.
### Test 2
100-300 packets of ~24000000 missed on each interface.
### Test 3
4000-5000 packets of ~96000000 missed on each interface.
## System 2
* Board: Supermicro X10SDV-7TP8F
* CPU:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Thread(s) per core: 2
Core(s) per socket: 16
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 86
Model name: 06/56
Stepping: 4
CPU MHz: 1429.527
CPU max MHz: 2300.0000
CPU min MHz: 800.0000
BogoMIPS: 3400.37
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 24576K
NUMA node0 CPU(s): 0-31
Flags: fpu vme de pse tsc msr pae mce cx8 apic
sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht
tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid
dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx
f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi
flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms
invpcid rtm cqm rdseed adx smap xsaveopt cqm_llc cqm_occup_llc
cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts
* Memory channels: 2
* Memory: 4 * 16384 MB DDR4 @ 2133 MHz
* NIC firmware: FW 5.0 API 1.5 NVM 05.00.04 eetrack 80002505
* i40e version: 1.4.25-k
* OS: Ubuntu 16.04.1 LTS
* Kernel: 4.4.0-57-generic
* Kernel parameters:
isolcpus=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31
default_hugepagesz=1G hugepagesz=1G hugepages=1
### Test 1
Mostly no packet loss of ~600000.
### Test 2
400000-500000 packets of ~24000000 missed on each interface.
### Test 3
1200000-1400000 packets of ~96000000 missed on each interface.
## System 3
* Board: Supermicro X9SRW-F
* CPU:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 12
On-line CPU(s) list: 0-11
Thread(s) per core: 2
Core(s) per socket: 6
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 62
Model name: Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz
Stepping: 4
CPU MHz: 1200.253
CPU max MHz: 3900.0000
CPU min MHz: 1200.0000
BogoMIPS: 7000.29
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 12288K
NUMA node0 CPU(s): 0-11
Flags: fpu vme de pse tsc msr pae mce cx8 apic
sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht
tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca
sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand
lahf_lm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
xsaveopt dtherm arat pln pts
* Memory channels: 4
* Memory: 4 * 8192 MB DDR3 @ 1600 MHz
* NIC firmware: FW 5.0 API 1.5 NVM 05.00.04 eetrack 80002537
* i40e version: 1.4.25-k
* OS: Ubuntu 16.04.1 LTS
* Kernel: 4.4.0-57-generic
* Kernel parameters: default_hugepagesz=1G hugepagesz=1G hugepages=1
isolcpus=1-5,7-11
### Test 1
No packets lost.
### Test 2
No packets lost.
### Test 3
No packets lost.
Best regards,
Martin
On 03.01.17 13:18, Martin Weiser wrote:
> Hello,
>
> we are also seeing this issue on one of our test systems while it does
> not occur on other test systems with the same DPDK version (we tested
> 16.11 and current master).
>
> The system that we can reproduce this issue on also has a X552 ixgbe NIC
> which can forward the exact same traffic using the same testpmd
> parameters without a problem.
> Even if we install a 82599ES ixgbe NIC in the same PCI slot that the
> XL710 was in the 82599ES can forward the traffic without any drops.
>
> Like in the issue reported by Ilya all packet drops occur on the testpmd
> side and are accounted as 'imissed'. Increasing the number of rx
> descriptors only helps a little at low packet rates.
>
> Drops start occurring at pretty low packet rates like 100000 packets per
> second.
>
> Any suggestions would be greatly appreciated.
>
> Best regards,
> Martin
>
>
>
> On 22.08.16 14:06, Ilya Maximets wrote:
>> Hello, All.
>>
>> I've faced with a really bad situation with packet drops on a small
>> packet rates (~45 Kpps) while using XL710 NIC with i40e DPDK driver.
>>
>> The issue was found while testing PHY-VM-PHY scenario with OVS and
>> confirmed on PHY-PHY scenario with testpmd.
>>
>> DPDK version 16.07 was used in all cases.
>> XL710 firmware-version: f5.0.40043 a1.5 n5.04 e2505
>>
>> Test description (PHY-PHY):
>>
>> * Following cmdline was used:
>>
>> # n_desc=2048
>> # ./testpmd -c 0xf -n 2 --socket-mem=8192,0 -w 0000:05:00.0 -v \
>> -- --burst=32 --txd=${n_desc} --rxd=${n_desc} \
>> --rxq=1 --txq=1 --nb-cores=1 \
>> --eth-peer=0,a0:00:00:00:00:00 --forward-mode=mac
>>
>> * DPDK-Pktgen application was used as a traffic generator.
>> Single flow generated.
>>
>> Results:
>>
>> * Packet size: 128B, rate: 90% of 10Gbps (~7.5 Mpps):
>>
>> On the generator's side:
>>
>> Total counts:
>> Tx : 759034368 packets
>> Rx : 759033239 packets
>> Lost : 1129 packets
>>
>> Average rates:
>> Tx : 7590344 pps
>> Rx : 7590332 pps
>> Lost : 11 pps
>>
>> All of this dropped packets are RX-dropped on testpmd's side:
>>
>> +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++
>> RX-packets: 759033239 RX-dropped: 1129 RX-total: 759034368
>> TX-packets: 759033239 TX-dropped: 0 TX-total: 759033239
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> At the same time 10G NIC with IXGBE driver works perfectly
>> without any packet drops in the same scenario.
>>
>> Much worse situation with PHY-VM-PHY scenario with OVS:
>>
>> * testpmd application used inside guest to forward incoming packets.
>> (almost same cmdline as for PHY-PHY)
>>
>> * For packet size 256 B on rate 1% of 10Gbps (~45 Kpps):
>>
>> Total counts:
>> Tx : 1358112 packets
>> Rx : 1357990 packets
>> Lost : 122 packets
>>
>> Average rates:
>> Tx : 45270 pps
>> Rx : 45266 pps
>> Lost : 4 pps
>>
>> All of this 122 dropped packets can be found in rx_dropped counter:
>>
>> # ovs-vsctl get interface dpdk0 statistics:rx_dropped
>> 122
>>
>> And again, no issues with IXGBE on the exactly same scenario.
>>
>>
>> Results of my investigation:
>>
>> * I found that all of this packets are 'imissed'. This means that rx
>> descriptor ring was overflowed.
>>
>> * I've modified i40e driver to check the real number of free descriptors
>> that was not still filled by the NIC and found that HW fills
>> rx descriptors with uneven rate. Looks like it fills them using
>> a huge batches.
>>
>> * So, root cause of packet drops with XL710 is somehow uneven rate of
>> filling of the hw rx descriptors by the NIC. This leads to exhausting
>> of rx descriptors and packet drops by the hardware. 10G IXGBE NIC works
>> more smoothly and driver is able to refill hw ring with rx descriptors
>> in time.
>>
>> * The issue becomes worse with OVS because of much bigger latencies
>> between 'rte_eth_rx_burst()' calls.
>>
>> The easiest solution for this problem is to increase number of RX descriptors.
>> Increasing up to 4096 eliminates packet drops but decreases the performance a lot:
>>
>> For OVS PHY-VM-PHY scenario by 10%
>> For OVS PHY-PHY scenario by 20%
>> For tespmd PHY-PHY scenario by 17% (22.1 Mpps --> 18.2 Mpps for 64B packets)
>>
>> As a result we have a trade-off between zero drop rate on small packet rates and
>> the higher maximum performance that is very sad.
>>
>> Using of 16B descriptors doesn't really help with performance.
>> Upgrading the firmware from version 4.4 to 5.04 didn't help with drops.
>>
>> Any thoughts? Can anyone reproduce this?
>>
>> Best regards, Ilya Maximets.
^ permalink raw reply
* Re: [PATCH v2] crypto/aesni_mb: enablement of avx512 support in IPsec_mb library
From: De Lara Guarch, Pablo @ 2017-01-04 12:54 UTC (permalink / raw)
To: De Lara Guarch, Pablo, Doherty, Declan, dev@dpdk.org; +Cc: Doherty, Declan
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D897476B9093@IRSMSX108.ger.corp.intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of De Lara Guarch,
> Pablo
> Sent: Thursday, December 22, 2016 8:27 AM
> To: Doherty, Declan; dev@dpdk.org
> Cc: Doherty, Declan
> Subject: Re: [dpdk-dev] [PATCH v2] crypto/aesni_mb: enablement of
> avx512 support in IPsec_mb library
>
>
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Declan Doherty
> > Sent: Wednesday, December 21, 2016 10:05 PM
> > To: dev@dpdk.org
> > Cc: Doherty, Declan
> > Subject: [dpdk-dev] [PATCH v2] crypto/aesni_mb: enablement of avx512
> > support in IPsec_mb library
> >
> > Release v0.44 of Intel(R) Multi-Buffer Crypto for IPsec library adds
> > support for AVX512 instructions. This patch enables the new AVX512
> > accelerated functions from the aesni_mb_pmd crypto poll mode driver.
> >
> > This patch set requires that the aesni_mb_pmd is linked against the
> > version 0.44 or greater of the Multi-Buffer Crypto for IPsec library.
> >
> > Signed-off-by: Declan Doherty <declan.doherty@intel.com>
>
> Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Applied to dpdk-next-crypto.
Thanks,
Pablo
^ permalink raw reply
* Re: [PATCH 2/2] app/testpmd: remove explicit ixgbe link request
From: Jerin Jacob @ 2017-01-04 12:59 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, konstantin.ananyev, helin.zhang, thomas.monjalon
In-Reply-To: <408187b4-83b0-603f-011b-583d5d0e9716@intel.com>
On Wed, Jan 04, 2017 at 11:44:21AM +0000, Ferruh Yigit wrote:
> On 1/4/2017 11:01 AM, Jerin Jacob wrote:
> > On Tue, Jan 03, 2017 at 01:30:26PM +0000, Ferruh Yigit wrote:
> >> On 12/27/2016 10:09 AM, Jerin Jacob wrote:
> >>> Removed explicit ixgbe driver linkage request from
> >>> app/testpmd makefile to mk/rte.app.mk to
> >>> 1)Maintain the correct link ordering(from higher level libraries
> >>> to lower level libraries)
> >>> 2)In shared lib configuration, any application can use ixgbe
> >>> exposed pmd specific APIs not just testpmd.
> > ----
> >
> >>
> >> I believe it is good to keep it in testpmd Makefile, updating rte.app.mk
> >> to have it will:
> >> - link library to the applications which does not use PMD specific APIs
> >> and want to load PMD dynamically.
> >> - link library to the application that won't use driver at all. This may
> >> break the distributed binaries, since testpmd will now be dependent to a
> >> specific PMD.
> >
> > No strong opinion here as it is specific to ixgbe. But can we include
> > ixgbe only for shared library in testpmd so that it won't effect any
> > symbol generation in static build.
>
> I think this is better, I am OK with below patch, thanks.
OK. I will post the v2 based on following patch then.
>
> >
> >
> > [dpdk-master] $ git diff
> > diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
> > index 5988c3e..050663a 100644
> > --- a/app/test-pmd/Makefile
> > +++ b/app/test-pmd/Makefile
> > @@ -59,7 +59,9 @@ SRCS-y += csumonly.c
> > SRCS-y += icmpecho.c
> > SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> >
> > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > _LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > +endif
> >
> > CFLAGS_cmdline.o := -D_GNU_SOURCE
> >
> >
> >>
> >>>
> >>> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> >>> ---
> >>> app/test-pmd/Makefile | 2 --
> >>> mk/rte.app.mk | 2 +-
> >>> 2 files changed, 1 insertion(+), 3 deletions(-)
> >>>
> >>> diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
> >>> index 5988c3e..96e0c67 100644
> >>> --- a/app/test-pmd/Makefile
> >>> +++ b/app/test-pmd/Makefile
> >>> @@ -59,8 +59,6 @@ SRCS-y += csumonly.c
> >>> SRCS-y += icmpecho.c
> >>> SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> >>>
> >>> -_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> >>> -
> >>> CFLAGS_cmdline.o := -D_GNU_SOURCE
> >>>
> >>> # this application needs libraries first
> >>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk
> >>> index f75f0e2..aee235c 100644
> >>> --- a/mk/rte.app.mk
> >>> +++ b/mk/rte.app.mk
> >>> @@ -101,6 +101,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_CFGFILE) += -lrte_cfgfile
> >>>
> >>> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += -lrte_pmd_bond
> >>> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += -lrte_pmd_xenvirt -lxenstore
> >>> +_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> >>>
> >>> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> >>> # plugins (link only if static libraries)
> >>> @@ -114,7 +115,6 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += -lrte_pmd_ena
> >>> _LDLIBS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += -lrte_pmd_enic
> >>> _LDLIBS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += -lrte_pmd_fm10k
> >>> _LDLIBS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += -lrte_pmd_i40e
> >>> -_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> >>> _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -lrte_pmd_mlx4 -libverbs
> >>> _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += -lrte_pmd_mlx5 -libverbs
> >>> _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lrte_pmd_mpipe -lgxio
> >>>
> >>
>
^ permalink raw reply
* Re: [PATCH v2 14/29] eal/arm64: change barrier definitions to macros
From: Jerin Jacob @ 2017-01-04 13:03 UTC (permalink / raw)
To: Tiwei Bie
Cc: Jianbo Liu, dev, Ananyev, Konstantin, Thomas Monjalon,
Bruce Richardson, Jan Viktorin, Santosh Shukla
In-Reply-To: <20170104110030.GA22291@debian>
On Wed, Jan 04, 2017 at 07:00:30PM +0800, Tiwei Bie wrote:
> On Wed, Jan 04, 2017 at 03:39:14PM +0530, Jerin Jacob wrote:
> > On Tue, Jan 03, 2017 at 03:55:45PM +0800, Jianbo Liu wrote:
> > > On 27 December 2016 at 17:49, Jerin Jacob
> > > <jerin.jacob@caviumnetworks.com> wrote:
> > > > Change rte_?wb definitions to macros in order to
> > >
> > > use rte_*mb?
> >
> > IMHO, regex ? is appropriate here.
> > https://en.wikipedia.org/wiki/Regular_expression
> >
>
> The APIs you're changing are:
>
> > +#define rte_mb() dsb(sy)
> > +#define rte_wmb() dsb(st)
> > +#define rte_rmb() dsb(ld)
>
> If it's a regex, shouldn't it be: rte_[wr]?mb or rte_.?mb
>
> If ? is a wildcard used by shell, it should at least be: rte_?mb
> But rte_*mb is easier to recognize, and matches all of them. :-)
OK. I will wait for further comments on this patchset(especially comments
on driver changes) and post v3 to fix this
>
> Best regards,
> Tiwei Bie
>
> > >
> > > > keep consistent with other barrier definitions in
> > > > the file.
> > > >
> > > > Suggested-by: Jianbo Liu <jianbo.liu@linaro.org>
> > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > > ---
> > > > .../common/include/arch/arm/rte_atomic_64.h | 36 ++--------------------
> > > > 1 file changed, 3 insertions(+), 33 deletions(-)
> > > >
> > > > diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > > > index ef0efc7..dc3a0f3 100644
> > > > --- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > > > +++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > > > @@ -46,41 +46,11 @@ extern "C" {
> > > > #define dsb(opt) { asm volatile("dsb " #opt : : : "memory"); }
> > > > #define dmb(opt) { asm volatile("dmb " #opt : : : "memory"); }
> > > >
> > > > -/**
> > > > - * General memory barrier.
> > > > - *
> > > > - * Guarantees that the LOAD and STORE operations generated before the
> > > > - * barrier occur before the LOAD and STORE operations generated after.
> > > > - * This function is architecture dependent.
> > > > - */
> > > > -static inline void rte_mb(void)
> > > > -{
> > > > - dsb(sy);
> > > > -}
> > > > +#define rte_mb() dsb(sy)
> > > >
> > > > -/**
> > > > - * Write memory barrier.
> > > > - *
> > > > - * Guarantees that the STORE operations generated before the barrier
> > > > - * occur before the STORE operations generated after.
> > > > - * This function is architecture dependent.
> > > > - */
> > > > -static inline void rte_wmb(void)
> > > > -{
> > > > - dsb(st);
> > > > -}
> > > > +#define rte_wmb() dsb(st)
> > > >
> > > > -/**
> > > > - * Read memory barrier.
> > > > - *
> > > > - * Guarantees that the LOAD operations generated before the barrier
> > > > - * occur before the LOAD operations generated after.
> > > > - * This function is architecture dependent.
> > > > - */
> > >
> > > How about keep the comments for all these macros?
> >
> > lib/librte_eal/common/include/generic/rte_atomic.h file has description
> > for all the barriers.All other arch are doing in the same-way.
> >
> > >
> > > > -static inline void rte_rmb(void)
> > > > -{
> > > > - dsb(ld);
> > > > -}
> > > > +#define rte_rmb() dsb(ld)
> > > >
> > > > #define rte_smp_mb() dmb(ish)
> > > >
> > > > --
> > > > 2.5.5
> > > >
^ permalink raw reply
* Re: [PATCH v2 3/5] test: add distributor_perf autotest
From: Jerin Jacob @ 2017-01-04 13:09 UTC (permalink / raw)
To: Hunt, David; +Cc: dev, bruce.richardson
In-Reply-To: <088a8953-9c8f-0665-7a53-505cd1c389bc@intel.com>
On Mon, Jan 02, 2017 at 04:24:01PM +0000, Hunt, David wrote:
>
>
> On 22/12/2016 12:19 PM, Jerin Jacob wrote:
> > On Thu, Dec 22, 2016 at 04:37:06AM +0000, David Hunt wrote:
> > > + struct rte_distributor_burst *d = arg;
> > > + unsigned int count = 0;
> > > + unsigned int num = 0;
> > > + unsigned int id = __sync_fetch_and_add(&worker_idx, 1);
> > Use rte_atomic equivalent
>
> Jerin,
> I'm looking for an equivalent, but I can't seem to find one. Here I'm
> assigning 'id' with the incremented value of worker_idx in one statement.
> However, rte_atomic32_add just increments the variable and returns void, so
> I'd have to use two statements, losing the atomicity.
>
> static inline void
> rte_atomic32_add(rte_atomic32_t *v, int32_t inc)
It would have been better rte_atomic32_add returns the old value.
>
> There's a second reason why I can't use the rte_atomics, and that's because
> worker_idx is a volatile.
may be you could change worker_idx as rte_atomic32_t
>
> Maybe we could add new atomic functions in the future to address this?
Yes. I guess, the fixing the return value of rte_atomic*_[add/sub] may
be enough
>
> Thanks,
> Dave.
^ permalink raw reply
* Re: [PATCH v2 23/29] net/i40e: use eal I/O device memory read/write API
From: Tiwei Bie @ 2017-01-04 13:53 UTC (permalink / raw)
To: Jerin Jacob
Cc: dev, konstantin.ananyev, thomas.monjalon, bruce.richardson,
jianbo.liu, viktorin, santosh.shukla, Helin Zhang, Jingjing Wu,
Satha Rao
In-Reply-To: <1482832175-27199-24-git-send-email-jerin.jacob@caviumnetworks.com>
On Tue, Dec 27, 2016 at 03:19:29PM +0530, Jerin Jacob wrote:
> From: Santosh Shukla <santosh.shukla@caviumnetworks.com>
>
> Replace the raw I/O device memory read/write access with eal abstraction
> for I/O device memory read/write access to fix portability issues across
> different architectures.
>
[...]
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index 7ae7d9f..5c41a90 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -1228,7 +1228,7 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
> (unsigned) txq->port_id, (unsigned) txq->queue_id,
> (unsigned) tx_id, (unsigned) nb_tx);
>
> - I40E_PCI_REG_WRITE(txq->qtx_tail, tx_id);
> + I40E_PCI_REG_WRITE_RELAXED(txq->qtx_tail, tx_id);
> txq->tx_tail = tx_id;
>
> return nb_tx;
> @@ -1380,7 +1380,7 @@ tx_xmit_pkts(struct i40e_tx_queue *txq,
>
> /* Update the tx tail register */
> rte_wmb();
> - I40E_PCI_REG_WRITE(txq->qtx_tail, txq->tx_tail);
> + I40E_PCI_REG_WRITE_RELAXED(txq->qtx_tail, txq->tx_tail);
>
> return nb_pkts;
> }
Besides i40e_xmit_pkts() and tx_xmit_pkts(), i40e_rx_alloc_bufs() which is
called by rx_recv_pkts() is also in the fast path. So I40E_PCI_REG_WRITE()
called by it should also be replaced by the relaxed version:
diff --git i/drivers/net/i40e/i40e_rxtx.c w/drivers/net/i40e/i40e_rxtx.c
index 7ae7d9f..55a707a 100644
--- i/drivers/net/i40e/i40e_rxtx.c
+++ w/drivers/net/i40e/i40e_rxtx.c
@@ -581,7 +581,7 @@ i40e_rx_alloc_bufs(struct i40e_rx_queue *rxq)
/* Update rx tail regsiter */
rte_wmb();
- I40E_PCI_REG_WRITE(rxq->qrx_tail, rxq->rx_free_trigger);
+ I40E_PCI_REG_WRITE_RELAXED(rxq->qrx_tail, rxq->rx_free_trigger);
rxq->rx_free_trigger =
(uint16_t)(rxq->rx_free_trigger + rxq->rx_free_thresh);
Thanks & regards,
Tiwei Bie
> --
> 2.5.5
>
^ permalink raw reply related
* [PATCH] net/ena: use correct field for Rx offload features
From: Jakub Palider @ 2017-01-04 13:58 UTC (permalink / raw)
To: dev; +Cc: Jakub Palider
Previously the capability bitmap for Rx offloads was mistakenly taken
from Tx capability bitmap field. This patch fixes the problem.
Signed-off-by: Jakub Palider <jpa@semihalf.com>
---
drivers/net/ena/ena_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index dcee8ed..34e5577 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -1466,7 +1466,7 @@ static void ena_infos_get(struct rte_eth_dev *dev,
DEV_TX_OFFLOAD_UDP_CKSUM |
DEV_TX_OFFLOAD_TCP_CKSUM;
- if (feat.offload.tx &
+ if (feat.offload.rx_supported &
ENA_ADMIN_FEATURE_OFFLOAD_DESC_RX_L4_IPV4_CSUM_MASK)
rx_feat |= DEV_RX_OFFLOAD_IPV4_CKSUM |
DEV_RX_OFFLOAD_UDP_CKSUM |
--
2.5.0
^ permalink raw reply related
* Re: [PATCH v4 2/5] net/e1000: add firmware version get
From: Ferruh Yigit @ 2017-01-04 13:59 UTC (permalink / raw)
To: Qiming Yang, dev; +Cc: helin.zhang, remy.horton
In-Reply-To: <1483531428-14481-3-git-send-email-qiming.yang@intel.com>
On 1/4/2017 12:03 PM, Qiming Yang wrote:
> This patch adds a new function eth_igb_fw_version_get.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
<...>
>
> static void
> +eth_igb_fw_version_get(struct rte_eth_dev *dev, u32 *fw_major, u32 *fw_minor,
> + u32 *fw_patch, u32 *etrack_id)
> +{
<...>
> + default:
> + /* if option rom is valid, display its version too*/
> + if (fw.or_valid) {
> + *fw_major = fw.eep_major;
> + *fw_minor = fw.eep_minor;
> + *etrack_id = fw.etrack_id;
> + *fw_patch = fw.or_patch;
> + /* no option rom */
> + } else {
> + if (fw.etrack_id != 0X0000) {
> + *fw_major = fw.eep_major;
> + *fw_minor = fw.eep_minor;
> + *etrack_id = fw.etrack_id;
indentation is wrong here. Also it looks like major, minor assignment is
common and can be moved from if statement.
> + } else {
> + *fw_major = fw.eep_major;
> + *fw_minor = fw.eep_minor;
> + }
> + }
> + break;
> + }
> +}
<...>
^ permalink raw reply
* Re: [PATCH v4 4/5] net/i40e: add firmware version get
From: Ferruh Yigit @ 2017-01-04 14:00 UTC (permalink / raw)
To: Qiming Yang, dev; +Cc: helin.zhang, remy.horton
In-Reply-To: <1483531428-14481-5-git-send-email-qiming.yang@intel.com>
On 1/4/2017 12:03 PM, Qiming Yang wrote:
> This patch add a new function i40e_fw_version_get.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
<...>
>
> diff --git a/doc/guides/nics/features/i40e.ini b/doc/guides/nics/features/i40e.ini
> index 0d143bc..6dab9f7 100644
> --- a/doc/guides/nics/features/i40e.ini
> +++ b/doc/guides/nics/features/i40e.ini
> @@ -46,3 +46,4 @@ Linux VFIO = Y
> x86-32 = Y
> x86-64 = Y
> ARMv8 = Y
> +FW version = Y
Please put same location with default.ini
<...>
^ permalink raw reply
* Re: [PATCH v4 5/5] ethtool: dispaly firmware version
From: Ferruh Yigit @ 2017-01-04 14:00 UTC (permalink / raw)
To: Qiming Yang, dev; +Cc: helin.zhang, remy.horton
In-Reply-To: <1483531428-14481-6-git-send-email-qiming.yang@intel.com>
On 1/4/2017 12:03 PM, Qiming Yang wrote:
> This patch enhances the ethtool example to support to show
> firmware version, in the same way that the Linux kernel
> ethtool does.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
<...>
>
> @@ -61,6 +67,12 @@ rte_ethtool_get_drvinfo(uint8_t port_id, struct ethtool_drvinfo *drvinfo)
> dev_info.driver_name);
> snprintf(drvinfo->version, sizeof(drvinfo->version), "%s",
> rte_version());
> + if (strcmp(drvinfo->driver, "net_ixgbe") == 0)
Do you need this check. I think it is not good idea to add this kind of
checks into ethtool app. Why not just print "%d.%d.%d %#X, major, minor,
patch, etrack" for all cases ?
> + snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
> + "0x%08x", etrack);
> + else
> + snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
> + "%d.%02d 0x%08x", fw_major, fw_minor, etrack);
> if (dev_info.pci_dev)
> snprintf(drvinfo->bus_info, sizeof(drvinfo->bus_info),
> "%04x:%02x:%02x.%x",
>
^ permalink raw reply
* Re: [PATCH] nfp: add support for new metadata api
From: Ferruh Yigit @ 2017-01-04 14:15 UTC (permalink / raw)
To: Alejandro Lucero, dev
In-Reply-To: <1482243237-28625-1-git-send-email-alejandro.lucero@netronome.com>
On 12/20/2016 2:13 PM, Alejandro Lucero wrote:
> NFP is a smart programmable NIC and firmware is deployed for specific
> system needs, like offloading OVS, vRouter, contrack or eBPF into the
> hardware. This often requires to give metadata to the host within
> packets delivered. Last NFP firmware implementations support richer
> metadata api facilitating interaction between firmware and host code.
>
> Old way of handling metadata needs to be still there for supporting
> old firmware.
>
> Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
> ---
<...>
> +
> + } else if (NFP_DESC_META_LEN(rxd)) {
> + meta_offset = (uint8_t *)mbuf->buf_addr;
> + meta_info = rte_be_to_cpu_32(*(uint32_t *)meta_offset);
> + meta_offset += 4;
> + /* NFP PMD just supports metadata for hashing */
> + switch (meta_info & NFP_NET_META_FIELD_MASK) {
> + case NFP_NET_META_HASH:
> + meta_info >>= NFP_NET_META_FIELD_SIZE;
> + hash = rte_be_to_cpu_32(*(uint32_t *)meta_offset);
> + hash_type = meta_info && NFP_NET_META_FIELD_MASK;
I already applied this patch but above "&&" looks wrong.
Most probably intention is "bitwise AND" (&), do you want me fix this as
"&" or remove the patch completely to replace with new version?
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH v5 3/8] ethdev: reserve capability flags for PMD-specific API
From: Ananyev, Konstantin @ 2017-01-04 14:21 UTC (permalink / raw)
To: Bie, Tiwei, dev@dpdk.org
Cc: adrien.mazarguil@6wind.com, Lu, Wenzhuo, Mcnamara, John,
olivier.matz@6wind.com, thomas.monjalon@6wind.com, Zhang, Helin,
Dai, Wei, Wang, Xiao W
In-Reply-To: <1483514502-32841-4-git-send-email-tiwei.bie@intel.com>
Hi Twei,
> -----Original Message-----
> From: Bie, Tiwei
> Sent: Wednesday, January 4, 2017 7:22 AM
> To: dev@dpdk.org
> Cc: adrien.mazarguil@6wind.com; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Mcnamara, John <john.mcnamara@intel.com>;
> olivier.matz@6wind.com; thomas.monjalon@6wind.com; Ananyev, Konstantin <konstantin.ananyev@intel.com>; Zhang, Helin
> <helin.zhang@intel.com>; Dai, Wei <wei.dai@intel.com>; Wang, Xiao W <xiao.w.wang@intel.com>
> Subject: [PATCH v5 3/8] ethdev: reserve capability flags for PMD-specific API
>
> Reserve a Tx capability flag and a Rx capability flag, that can be
> used by PMD to define its own capability flags when implementing the
> PMD-specific API.
>
> Suggested-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> ---
> lib/librte_ether/rte_ethdev.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index d465825..8800b39 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -857,6 +857,7 @@ struct rte_eth_conf {
> #define DEV_RX_OFFLOAD_TCP_LRO 0x00000010
> #define DEV_RX_OFFLOAD_QINQ_STRIP 0x00000020
> #define DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM 0x00000040
> +#define DEV_RX_OFFLOAD_RESERVED_0 0x00000080 /**< Used for PMD-specific API. */
>
> /**
> * TX offload capabilities of a device.
> @@ -874,6 +875,7 @@ struct rte_eth_conf {
> #define DEV_TX_OFFLOAD_GRE_TNL_TSO 0x00000400 /**< Used for tunneling packet. */
> #define DEV_TX_OFFLOAD_IPIP_TNL_TSO 0x00000800 /**< Used for tunneling packet. */
> #define DEV_TX_OFFLOAD_GENEVE_TNL_TSO 0x00001000 /**< Used for tunneling packet. */
> +#define DEV_TX_OFFLOAD_RESERVED_0 0x00002000 /**< Used for PMD-specific API. */
>
> /**
> * Ethernet device information
> --
> 2.7.4
I am not sure how that supposed to work and how user should know that DEV_RX_OFFLOAD_RESERVED_0
is actually a MACSEC for ixgbe?
Another question what to do if you would like to create a bonded device over two devices with different NIC types?
As I understand you can end up in situation when DEV_RX_OFFLOAD_RESERVED_0 would mean different capabilities.
Why not to have this MACSEC capability and ol_flag value as generic ones, as you have them in previous versions of your patch?
Konstantin
^ permalink raw reply
* Re: [PATCH] net/ena: use correct field for Rx offload features
From: Ferruh Yigit @ 2017-01-04 14:27 UTC (permalink / raw)
To: Jakub Palider, dev
In-Reply-To: <1483538334-9714-1-git-send-email-jpa@semihalf.com>
On 1/4/2017 1:58 PM, Jakub Palider wrote:
> Previously the capability bitmap for Rx offloads was mistakenly taken
> from Tx capability bitmap field. This patch fixes the problem.
>
> Signed-off-by: Jakub Palider <jpa@semihalf.com>
Applied to dpdk-next-net/master, thanks.
^ permalink raw reply
* Re: [PATCH] nfp: add support for new metadata api
From: Alejandro Lucero @ 2017-01-04 14:43 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
In-Reply-To: <e3a64529-d0e0-c229-41f7-5618bdc35a15@intel.com>
Hi Ferruh,
On Wed, Jan 4, 2017 at 3:15 PM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> On 12/20/2016 2:13 PM, Alejandro Lucero wrote:
> > NFP is a smart programmable NIC and firmware is deployed for specific
> > system needs, like offloading OVS, vRouter, contrack or eBPF into the
> > hardware. This often requires to give metadata to the host within
> > packets delivered. Last NFP firmware implementations support richer
> > metadata api facilitating interaction between firmware and host code.
> >
> > Old way of handling metadata needs to be still there for supporting
> > old firmware.
> >
> > Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
> > ---
>
> <...>
>
> > +
> > + } else if (NFP_DESC_META_LEN(rxd)) {
> > + meta_offset = (uint8_t *)mbuf->buf_addr;
> > + meta_info = rte_be_to_cpu_32(*(uint32_t *)meta_offset);
> > + meta_offset += 4;
> > + /* NFP PMD just supports metadata for hashing */
> > + switch (meta_info & NFP_NET_META_FIELD_MASK) {
> > + case NFP_NET_META_HASH:
> > + meta_info >>= NFP_NET_META_FIELD_SIZE;
> > + hash = rte_be_to_cpu_32(*(uint32_t *)meta_offset);
> > + hash_type = meta_info && NFP_NET_META_FIELD_MASK;
>
> I already applied this patch but above "&&" looks wrong.
> Most probably intention is "bitwise AND" (&), do you want me fix this as
> "&" or remove the patch completely to replace with new version?
>
>
Yes, that is wrong. I wonder how related tests did not fail. I'll check
that right now.
Maybe it is better to wait for another patch version or at least to be sure
that simple change is good enough.
Let me to peer into those tests and re-run them with that fix applied.
> Thanks,
> ferruh
>
>
^ permalink raw reply
* Re: [PATCH v5 3/8] ethdev: reserve capability flags for PMD-specific API
From: Tiwei Bie @ 2017-01-04 14:39 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: dev@dpdk.org, adrien.mazarguil@6wind.com, Lu, Wenzhuo,
Mcnamara, John, olivier.matz@6wind.com, thomas.monjalon@6wind.com,
Zhang, Helin, Dai, Wei, Wang, Xiao W
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0FEE0C@irsmsx105.ger.corp.intel.com>
On Wed, Jan 04, 2017 at 10:21:08PM +0800, Ananyev, Konstantin wrote:
> Hi Twei,
>
> > -----Original Message-----
> > From: Bie, Tiwei
> > Sent: Wednesday, January 4, 2017 7:22 AM
> > To: dev@dpdk.org
> > Cc: adrien.mazarguil@6wind.com; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Mcnamara, John <john.mcnamara@intel.com>;
> > olivier.matz@6wind.com; thomas.monjalon@6wind.com; Ananyev, Konstantin <konstantin.ananyev@intel.com>; Zhang, Helin
> > <helin.zhang@intel.com>; Dai, Wei <wei.dai@intel.com>; Wang, Xiao W <xiao.w.wang@intel.com>
> > Subject: [PATCH v5 3/8] ethdev: reserve capability flags for PMD-specific API
> >
> > Reserve a Tx capability flag and a Rx capability flag, that can be
> > used by PMD to define its own capability flags when implementing the
> > PMD-specific API.
> >
> > Suggested-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> > Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> > ---
> > lib/librte_ether/rte_ethdev.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> > index d465825..8800b39 100644
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -857,6 +857,7 @@ struct rte_eth_conf {
> > #define DEV_RX_OFFLOAD_TCP_LRO 0x00000010
> > #define DEV_RX_OFFLOAD_QINQ_STRIP 0x00000020
> > #define DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM 0x00000040
> > +#define DEV_RX_OFFLOAD_RESERVED_0 0x00000080 /**< Used for PMD-specific API. */
> >
> > /**
> > * TX offload capabilities of a device.
> > @@ -874,6 +875,7 @@ struct rte_eth_conf {
> > #define DEV_TX_OFFLOAD_GRE_TNL_TSO 0x00000400 /**< Used for tunneling packet. */
> > #define DEV_TX_OFFLOAD_IPIP_TNL_TSO 0x00000800 /**< Used for tunneling packet. */
> > #define DEV_TX_OFFLOAD_GENEVE_TNL_TSO 0x00001000 /**< Used for tunneling packet. */
> > +#define DEV_TX_OFFLOAD_RESERVED_0 0x00002000 /**< Used for PMD-specific API. */
> >
> > /**
> > * Ethernet device information
> > --
> > 2.7.4
>
> I am not sure how that supposed to work and how user should know that DEV_RX_OFFLOAD_RESERVED_0
> is actually a MACSEC for ixgbe?
Users are not supposed to use DEV_RX_OFFLOAD_RESERVED_0, instead, they
should use the capabilities and the likes defined in rte_pmd_ixgbe.h
where the PMD-specifics APIs are declared:
/**
* If these flags are advertised by the PMD, the NIC supports the MACsec
* offload. The incoming MACsec traffics can be offloaded transparently
* after the MACsec offload is configured correctly by the application.
* And the application can set the PKT_TX_IXGBE_MACSEC flag in mbufs to
* enable the MACsec offload for the packets to be transmitted.
*/
#define DEV_RX_OFFLOAD_IXGBE_MACSEC_STRIP DEV_RX_OFFLOAD_RESERVED_0
#define DEV_TX_OFFLOAD_IXGBE_MACSEC_INSERT DEV_TX_OFFLOAD_RESERVED_0
/**
* This event will occur when the PN counter in a MACsec connection
* reach the exhaustion threshold.
*/
#define RTE_ETH_EVENT_IXGBE_MACSEC RTE_ETH_EVENT_RESERVED_0
/**
* Offload the MACsec. This flag must be set by the application in mbuf
* to enable this offload feature for a packet to be transmitted.
*/
#define PKT_TX_IXGBE_MACSEC PKT_TX_RESERVED_0
PMD-specific APIs can only be used on the corresponding driver/device,
so different PMD can share the same reserved bit to represent different
things when implementing their own PMD-specific APIs.
> Another question what to do if you would like to create a bonded device over two devices with different NIC types?
> As I understand you can end up in situation when DEV_RX_OFFLOAD_RESERVED_0 would mean different capabilities.
> Why not to have this MACSEC capability and ol_flag value as generic ones, as you have them in previous versions of your patch?
Those flags are only used in PMD-specific APIs. I don't think we could
use the PMD-specific APIs provided by a certain PMD on a bonded device.
Thanks & regards,
Tiwei Bie
^ 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