* [PATCH v2 2/2] drivers/i40e: fix the hash filter invalid calculation in X722
From: Jeff Guo @ 2016-10-16 1:32 UTC (permalink / raw)
To: helin.zhang, jingjing.wu; +Cc: dev, jia.guo
In-Reply-To: <1476581554-110760-1-git-send-email-jia.guo@intel.com>
As X722 extracts IPv4 header to Field Vector different with XL710/X710,
need to corresponding to modify the fields of IPv4 header in input set
to map different default Field Vector Table of different NICs.
Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
v2:
fix compile error when x722 macro is not defined and simplify
the code to avoid duplication.
---
drivers/net/i40e/i40e_ethdev.c | 73 ++++++++++++++++++++++++++++++++++--------
1 file changed, 60 insertions(+), 13 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 920fd6d..7895c11 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -211,6 +211,16 @@
#define I40E_REG_INSET_L3_SRC_IP4 0x0001800000000000ULL
/* Destination IPv4 address */
#define I40E_REG_INSET_L3_DST_IP4 0x0000001800000000ULL
+#ifdef X722_SUPPORT
+/* Source IPv4 address for X722 */
+#define I40E_X722_REG_INSET_L3_SRC_IP4 0x0006000000000000ULL
+/* Destination IPv4 address for X722 */
+#define I40E_X722_REG_INSET_L3_DST_IP4 0x0000060000000000ULL
+/* IPv4 Protocol */
+#define I40E_X722_REG_INSET_L3_IP4_PROTO 0x0010000000000000ULL
+/* IPv4 Time to Live */
+#define I40E_X722_REG_INSET_L3_IP4_TTL 0x0010000000000000ULL
+#endif
/* IPv4 Type of Service (TOS) */
#define I40E_REG_INSET_L3_IP4_TOS 0x0040000000000000ULL
/* IPv4 Protocol */
@@ -7581,7 +7591,7 @@ i40e_parse_input_set(uint64_t *inset,
* and vice versa
*/
static uint64_t
-i40e_translate_input_set_reg(uint64_t input)
+i40e_translate_input_set_reg(enum i40e_mac_type type, uint64_t input)
{
uint64_t val = 0;
uint16_t i;
@@ -7589,17 +7599,13 @@ i40e_translate_input_set_reg(uint64_t input)
static const struct {
uint64_t inset;
uint64_t inset_reg;
- } inset_map[] = {
+ } inset_map_common[] = {
{I40E_INSET_DMAC, I40E_REG_INSET_L2_DMAC},
{I40E_INSET_SMAC, I40E_REG_INSET_L2_SMAC},
{I40E_INSET_VLAN_OUTER, I40E_REG_INSET_L2_OUTER_VLAN},
{I40E_INSET_VLAN_INNER, I40E_REG_INSET_L2_INNER_VLAN},
{I40E_INSET_LAST_ETHER_TYPE, I40E_REG_INSET_LAST_ETHER_TYPE},
- {I40E_INSET_IPV4_SRC, I40E_REG_INSET_L3_SRC_IP4},
- {I40E_INSET_IPV4_DST, I40E_REG_INSET_L3_DST_IP4},
{I40E_INSET_IPV4_TOS, I40E_REG_INSET_L3_IP4_TOS},
- {I40E_INSET_IPV4_PROTO, I40E_REG_INSET_L3_IP4_PROTO},
- {I40E_INSET_IPV4_TTL, I40E_REG_INSET_L3_IP4_TTL},
{I40E_INSET_IPV6_SRC, I40E_REG_INSET_L3_SRC_IP6},
{I40E_INSET_IPV6_DST, I40E_REG_INSET_L3_DST_IP6},
{I40E_INSET_IPV6_TC, I40E_REG_INSET_L3_IP6_TC},
@@ -7627,16 +7633,56 @@ i40e_translate_input_set_reg(uint64_t input)
{I40E_INSET_FLEX_PAYLOAD_W7, I40E_REG_INSET_FLEX_PAYLOAD_WORD7},
{I40E_INSET_FLEX_PAYLOAD_W8, I40E_REG_INSET_FLEX_PAYLOAD_WORD8},
};
+#ifdef X722_SUPPORT
+
+ /* some different registers map in x722*/
+ static const struct {
+ uint64_t inset;
+ uint64_t inset_reg;
+ } inset_map_diff_x722[] = {
+ {I40E_INSET_IPV4_SRC, I40E_X722_REG_INSET_L3_SRC_IP4},
+ {I40E_INSET_IPV4_DST, I40E_X722_REG_INSET_L3_DST_IP4},
+ {I40E_INSET_IPV4_PROTO, I40E_X722_REG_INSET_L3_IP4_PROTO},
+ {I40E_INSET_IPV4_TTL, I40E_X722_REG_INSET_L3_IP4_TTL},
+ };
+#endif
+
+ static const struct {
+ uint64_t inset;
+ uint64_t inset_reg;
+ } inset_map_diff_not_x722[] = {
+ {I40E_INSET_IPV4_SRC, I40E_REG_INSET_L3_SRC_IP4},
+ {I40E_INSET_IPV4_DST, I40E_REG_INSET_L3_DST_IP4},
+ {I40E_INSET_IPV4_PROTO, I40E_REG_INSET_L3_IP4_PROTO},
+ {I40E_INSET_IPV4_TTL, I40E_REG_INSET_L3_IP4_TTL},
+ };
if (input == 0)
return val;
/* Translate input set to register aware inset */
- for (i = 0; i < RTE_DIM(inset_map); i++) {
- if (input & inset_map[i].inset)
- val |= inset_map[i].inset_reg;
+#ifdef X722_SUPPORT
+ if (type == I40E_MAC_X722) {
+ for (i = 0; i < RTE_DIM(inset_map_diff_x722); i++) {
+ if (input & inset_map_diff_x722[i].inset)
+ val |= inset_map_diff_x722[i].inset_reg;
+ }
+ } else {
+ for (i = 0; i < RTE_DIM(inset_map_diff_not_x722); i++) {
+ if (input & inset_map_diff_not_x722[i].inset)
+ val |= inset_map_diff_not_x722[i].inset_reg;
+ }
+ }
+#else
+ for (i = 0; i < RTE_DIM(inset_map_diff_not_x722); i++) {
+ if (input & inset_map_diff_not_x722[i].inset)
+ val |= inset_map_diff_not_x722[i].inset_reg;
+ }
+#endif
+ for (i = 0; i < RTE_DIM(inset_map_common); i++) {
+ if (input & inset_map_common[i].inset)
+ val |= inset_map_common[i].inset_reg;
}
-
return val;
}
@@ -7719,7 +7765,8 @@ i40e_filter_input_set_init(struct i40e_pf *pf)
I40E_INSET_MASK_NUM_REG);
if (num < 0)
return;
- inset_reg = i40e_translate_input_set_reg(input_set);
+ inset_reg = i40e_translate_input_set_reg(hw->mac.type,
+ input_set);
i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 0),
(uint32_t)(inset_reg & UINT32_MAX));
@@ -7810,7 +7857,7 @@ i40e_hash_filter_inset_select(struct i40e_hw *hw,
if (num < 0)
return -EINVAL;
- inset_reg |= i40e_translate_input_set_reg(input_set);
+ inset_reg |= i40e_translate_input_set_reg(hw->mac.type, input_set);
i40e_check_write_reg(hw, I40E_GLQF_HASH_INSET(0, pctype),
(uint32_t)(inset_reg & UINT32_MAX));
@@ -7888,7 +7935,7 @@ i40e_fdir_filter_inset_select(struct i40e_pf *pf,
if (num < 0)
return -EINVAL;
- inset_reg |= i40e_translate_input_set_reg(input_set);
+ inset_reg |= i40e_translate_input_set_reg(hw->mac.type, input_set);
i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 0),
(uint32_t)(inset_reg & UINT32_MAX));
--
1.9.3
^ permalink raw reply related
* [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
From: Jeff Guo @ 2016-10-16 1:40 UTC (permalink / raw)
To: helin.zhang, jingjing.wu; +Cc: dev, jia.guo
In-Reply-To: <1474887098-115474-1-git-send-email-jia.guo@intel.com>
Since some register only be supported by X722 but may not be supported
by other NICs, so add X722 macro to distinguish that to avoid compile error
when the X722 macro is undefined.
Fixes: d0a349409bd7 (“i40e: support AQ based RSS config”)
Fixes: 001a1c0f98f4 ("ethdev: get registers width")
Fixes: a0454b5d2e08 (“i40e: update device ids”)
Fixes: 647d1eaf758b (“i40evf: support AQ based RSS config”)
Fixes: 3058891a2b02 (“net/i40e: move PCI device ids to the driver”)
Fixes: d9efd0136ac1 (“i40e: add EEPROM and registers dumping”)
Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
v2:
fix compile error when x722 macro is not define.
---
drivers/net/i40e/i40e_ethdev.c | 36 ++++++++++++++-
drivers/net/i40e/i40e_ethdev.h | 17 +++++++
drivers/net/i40e/i40e_ethdev_vf.c | 27 +++++++++++
drivers/net/i40e/i40e_regs.h | 96 +++++++++++++++++++++++++++++++++++++++
drivers/net/i40e/i40e_rxtx.c | 18 +++++++-
5 files changed, 191 insertions(+), 3 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index d0640b9..920fd6d 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -468,13 +468,17 @@ static const struct rte_pci_id pci_id_i40e_map[] = {
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T4) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_B) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_SFP28) },
+#ifdef X722_SUPPORT
+#ifdef X722_A0_SUPPORT
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0) },
+#endif /* X722_A0_SUPPORT */
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_1G_BASE_T_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T_X722) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_I_X722) },
+#endif /* X722_SUPPORT */
{ .vendor_id = 0, /* sentinel */ },
};
@@ -3182,6 +3186,7 @@ i40e_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
if (!lut)
return -EINVAL;
+#ifdef X722_SUPPORT
if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
ret = i40e_aq_get_rss_lut(hw, vsi->vsi_id, TRUE,
lut, lut_size);
@@ -3190,12 +3195,15 @@ i40e_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
return ret;
}
} else {
+#endif /* X722_SUPPORT */
uint32_t *lut_dw = (uint32_t *)lut;
uint16_t i, lut_size_dw = lut_size / 4;
for (i = 0; i < lut_size_dw; i++)
lut_dw[i] = I40E_READ_REG(hw, I40E_PFQF_HLUT(i));
+#ifdef X722_SUPPORT
}
+#endif /* X722_SUPPORT */
return 0;
}
@@ -3213,6 +3221,7 @@ i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
pf = I40E_VSI_TO_PF(vsi);
hw = I40E_VSI_TO_HW(vsi);
+#ifdef X722_SUPPORT
if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
ret = i40e_aq_set_rss_lut(hw, vsi->vsi_id, TRUE,
lut, lut_size);
@@ -3221,13 +3230,16 @@ i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
return ret;
}
} else {
+#endif /* X722_SUPPORT */
uint32_t *lut_dw = (uint32_t *)lut;
uint16_t i, lut_size_dw = lut_size / 4;
for (i = 0; i < lut_size_dw; i++)
I40E_WRITE_REG(hw, I40E_PFQF_HLUT(i), lut_dw[i]);
I40E_WRITE_FLUSH(hw);
+#ifdef X722_SUPPORT
}
+#endif /* X722_SUPPORT */
return 0;
}
@@ -3508,8 +3520,10 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
pf->lan_nb_qps = 1;
} else {
pf->flags |= I40E_FLAG_RSS;
+#ifdef X722_SUPPORT
if (hw->mac.type == I40E_MAC_X722)
pf->flags |= I40E_FLAG_RSS_AQ_CAPABLE;
+#endif /* X722_SUPPORT */
pf->lan_nb_qps = pf->lan_nb_qp_max;
}
qp_count += pf->lan_nb_qps;
@@ -6302,6 +6316,7 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len)
return -EINVAL;
}
+#ifdef X722_SUPPORT
if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
struct i40e_aqc_get_set_rss_key_data *key_dw =
(struct i40e_aqc_get_set_rss_key_data *)key;
@@ -6311,13 +6326,16 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len)
PMD_INIT_LOG(ERR, "Failed to configure RSS key "
"via AQ");
} else {
+#endif /* X722_SUPPORT */
uint32_t *hash_key = (uint32_t *)key;
uint16_t i;
for (i = 0; i <= I40E_PFQF_HKEY_MAX_INDEX; i++)
i40e_write_rx_ctl(hw, I40E_PFQF_HKEY(i), hash_key[i]);
I40E_WRITE_FLUSH(hw);
+#ifdef X722_SUPPORT
}
+#endif /* X722_SUPPORT */
return ret;
}
@@ -6332,6 +6350,7 @@ i40e_get_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t *key_len)
if (!key || !key_len)
return -EINVAL;
+#ifdef X722_SUPPORT
if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
ret = i40e_aq_get_rss_key(hw, vsi->vsi_id,
(struct i40e_aqc_get_set_rss_key_data *)key);
@@ -6340,12 +6359,16 @@ i40e_get_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t *key_len)
return ret;
}
} else {
+#endif /* X722_SUPPORT */
uint32_t *key_dw = (uint32_t *)key;
uint16_t i;
for (i = 0; i <= I40E_PFQF_HKEY_MAX_INDEX; i++)
key_dw[i] = i40e_read_rx_ctl(hw, I40E_PFQF_HKEY(i));
+#ifdef X722_SUPPORT
}
+#endif /* X722_SUPPORT */
+
*key_len = (I40E_PFQF_HKEY_MAX_INDEX + 1) * sizeof(uint32_t);
return 0;
@@ -9610,8 +9633,17 @@ static int i40e_get_regs(struct rte_eth_dev *dev,
const struct i40e_reg_info *reg_info;
if (ptr_data == NULL) {
- regs->length = I40E_GLGEN_STAT_CLEAR + 4;
- regs->width = sizeof(uint32_t);
+#ifdef X722_SUPPORT
+ if (hw->mac.type == I40E_MAC_X722) {
+ regs->length = I40E_GLGEN_STAT_CLEAR + 4;
+#else
+ regs->length = I40E_GLVEBVL_BPCH(
+ I40E_GLVEBVL_BPCH_MAX_INDEX) + 0x8;
+#endif /* X722_SUPPORT */
+ regs->width = sizeof(uint32_t);
+#ifdef X722_SUPPORT
+ }
+#endif /* X722_SUPPORT */
return 0;
}
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 57a8ae1..43711b8 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -125,7 +125,10 @@ enum i40e_flxpld_layer_idx {
#define I40E_FLAG_HEADER_SPLIT_ENABLED (1ULL << 5)
#define I40E_FLAG_FDIR (1ULL << 6)
#define I40E_FLAG_VXLAN (1ULL << 7)
+#ifdef X722_SUPPORT
#define I40E_FLAG_RSS_AQ_CAPABLE (1ULL << 8)
+#endif /* X722_SUPPORT */
+#ifdef X722_SUPPORT
#define I40E_FLAG_ALL (I40E_FLAG_RSS | \
I40E_FLAG_DCB | \
I40E_FLAG_VMDQ | \
@@ -135,6 +138,16 @@ enum i40e_flxpld_layer_idx {
I40E_FLAG_FDIR | \
I40E_FLAG_VXLAN | \
I40E_FLAG_RSS_AQ_CAPABLE)
+#else
+#define I40E_FLAG_ALL (I40E_FLAG_RSS | \
+ I40E_FLAG_DCB | \
+ I40E_FLAG_VMDQ | \
+ I40E_FLAG_SRIOV | \
+ I40E_FLAG_HEADER_SPLIT_DISABLED | \
+ I40E_FLAG_HEADER_SPLIT_ENABLED | \
+ I40E_FLAG_FDIR | \
+ I40E_FLAG_VXLAN)
+#endif /* X722_SUPPORT */
#define I40E_RSS_OFFLOAD_ALL ( \
ETH_RSS_FRAG_IPV4 | \
@@ -650,7 +663,11 @@ i40e_get_vsi_from_adapter(struct i40e_adapter *adapter)
return NULL;
hw = I40E_DEV_PRIVATE_TO_HW(adapter);
+#ifdef X722_SUPPORT
if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF) {
+#else
+ if (hw->mac.type == I40E_MAC_VF) {
+#endif /* X722_SUPPORT */
struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(adapter);
return &vf->vsi;
} else {
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
index 34eb274..aab9cae 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1112,9 +1112,17 @@ i40evf_get_link_status(struct rte_eth_dev *dev, struct rte_eth_link *link)
static const struct rte_pci_id pci_id_i40evf_map[] = {
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF_HV) },
+#ifdef X722_SUPPORT
+#ifdef X722_A0_SUPPORT
+#if defined(INTEGRATED_VF) || defined(VF_DRIVER)
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0_VF) },
+#endif /* INTEGRATED_VF || VF_DRIVER */
+#endif /* X722_A0_SUPPORT */
+#if defined(INTEGRATED_VF) || defined(VF_DRIVER) || defined(I40E_NDIS_SUPPORT)
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF) },
{ RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF_HV) },
+#endif /* INTEGRATED_VF || VF_DRIVER || I40E_NDIS_SUPPORT */
+#endif /* X722_SUPPORT */
{ .vendor_id = 0, /* sentinel */ },
};
@@ -1277,8 +1285,10 @@ i40evf_init_vf(struct rte_eth_dev *dev)
goto err_alloc;
}
+#ifdef X722_SUPPORT
if (hw->mac.type == I40E_MAC_X722_VF)
vf->flags = I40E_FLAG_RSS_AQ_CAPABLE;
+#endif /* X722_SUPPORT */
vf->vsi.vsi_id = vf->vsi_res->vsi_id;
vf->vsi.type = vf->vsi_res->vsi_type;
vf->vsi.nb_qps = vf->vsi_res->num_queue_pairs;
@@ -2340,6 +2350,7 @@ i40evf_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
if (!lut)
return -EINVAL;
+#ifdef X722_SUPPORT
if (vf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
ret = i40e_aq_get_rss_lut(hw, vsi->vsi_id, FALSE,
lut, lut_size);
@@ -2348,12 +2359,15 @@ i40evf_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
return ret;
}
} else {
+#endif /* X722_SUPPORT */
uint32_t *lut_dw = (uint32_t *)lut;
uint16_t i, lut_size_dw = lut_size / 4;
for (i = 0; i < lut_size_dw; i++)
lut_dw[i] = I40E_READ_REG(hw, I40E_VFQF_HLUT(i));
+#ifdef X722_SUPPORT
}
+#endif /* X722_SUPPORT */
return 0;
}
@@ -2371,6 +2385,7 @@ i40evf_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
vf = I40E_VSI_TO_VF(vsi);
hw = I40E_VSI_TO_HW(vsi);
+#ifdef X722_SUPPORT
if (vf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
ret = i40e_aq_set_rss_lut(hw, vsi->vsi_id, FALSE,
lut, lut_size);
@@ -2379,13 +2394,16 @@ i40evf_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
return ret;
}
} else {
+#endif /* X722_SUPPORT */
uint32_t *lut_dw = (uint32_t *)lut;
uint16_t i, lut_size_dw = lut_size / 4;
for (i = 0; i < lut_size_dw; i++)
I40E_WRITE_REG(hw, I40E_VFQF_HLUT(i), lut_dw[i]);
I40EVF_WRITE_FLUSH(hw);
+#ifdef X722_SUPPORT
}
+#endif /* X722_SUPPORT */
return 0;
}
@@ -2484,6 +2502,7 @@ i40evf_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len)
return -EINVAL;
}
+#ifdef X722_SUPPORT
if (vf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
struct i40e_aqc_get_set_rss_key_data *key_dw =
(struct i40e_aqc_get_set_rss_key_data *)key;
@@ -2493,13 +2512,16 @@ i40evf_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len)
PMD_INIT_LOG(ERR, "Failed to configure RSS key "
"via AQ");
} else {
+#endif /* X722_SUPPORT */
uint32_t *hash_key = (uint32_t *)key;
uint16_t i;
for (i = 0; i <= I40E_VFQF_HKEY_MAX_INDEX; i++)
i40e_write_rx_ctl(hw, I40E_VFQF_HKEY(i), hash_key[i]);
I40EVF_WRITE_FLUSH(hw);
+#ifdef X722_SUPPORT
}
+#endif /* X722_SUPPORT */
return ret;
}
@@ -2514,6 +2536,7 @@ i40evf_get_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t *key_len)
if (!key || !key_len)
return -EINVAL;
+#ifdef X722_SUPPORT
if (vf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
ret = i40e_aq_get_rss_key(hw, vsi->vsi_id,
(struct i40e_aqc_get_set_rss_key_data *)key);
@@ -2522,12 +2545,16 @@ i40evf_get_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t *key_len)
return ret;
}
} else {
+#endif /* X722_SUPPORT */
uint32_t *key_dw = (uint32_t *)key;
uint16_t i;
for (i = 0; i <= I40E_VFQF_HKEY_MAX_INDEX; i++)
key_dw[i] = i40e_read_rx_ctl(hw, I40E_VFQF_HKEY(i));
+#ifdef X722_SUPPORT
}
+#endif /* X722_SUPPORT */
+
*key_len = (I40E_VFQF_HKEY_MAX_INDEX + 1) * sizeof(uint32_t);
return 0;
diff --git a/drivers/net/i40e/i40e_regs.h b/drivers/net/i40e/i40e_regs.h
index 472c7a0..7be6ce3 100644
--- a/drivers/net/i40e/i40e_regs.h
+++ b/drivers/net/i40e/i40e_regs.h
@@ -52,7 +52,9 @@ static const struct i40e_reg_info i40e_regs_adminq[] = {
{I40E_VSILAN_QBASE(0), 383, 4, 0, 0, "VSILAN_QBASE"},
{I40E_VSIQF_CTL(0), 383, 4, 0, 0, "VSIQF_CTL"},
{I40E_PFQF_HKEY(0), 12, 128, 0, 0, "PFQF_HKEY"},
+#ifdef X722_SUPPORT
{I40E_PFQF_HREGION(0), 7, 128, 0, 0, "PFQF_HREGION"},
+#endif
{I40E_PFQF_HENA(0), 1, 128, 0, 0, "PFQF_HENA"},
{I40E_PFQF_FDALLOC, 0, 0, 0, 0, "PFQF_FDALLOC"},
{I40E_PRTQF_FD_INSET(0, 0), 63, 64, 1, 32, "PRTQF_FD_INSET"},
@@ -60,9 +62,11 @@ static const struct i40e_reg_info i40e_regs_adminq[] = {
{I40E_PRTQF_FD_MSK(0, 0), 63, 64, 1, 32, "PRTQF_FD_MSK"},
{I40E_PRTQF_FD_FLXINSET(0), 63, 32, 0, 0, "PRTQF_FD_FLXINSET"},
{I40E_PRTQF_CTL_0, 0, 0, 0, 0, "PRTQF_CTL_0"},
+#ifdef X722_SUPPORT
{I40E_GLQF_FD_MSK(0, 0), 1, 4, 63, 8, "GLQF_FD_MSK"},
{I40E_GLQF_HASH_INSET(0, 0), 1, 4, 63, 8, "GLQF_HASH_INSET"},
{I40E_GLQF_HASH_MSK(0, 0), 1, 4, 63, 8, "GLQF_HASH_MSK"},
+#endif
{I40E_GLQF_SWAP(0, 0), 1, 4, 63, 8, "GLQF_SWAP"},
{I40E_GLFCOE_RCTL, 0, 0, 0, 0, "GLFCOE_RCTL"},
{I40E_GLQF_CTL, 0, 0, 0, 0, "GLQF_CTL"},
@@ -72,6 +76,7 @@ static const struct i40e_reg_info i40e_regs_adminq[] = {
static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_QTX_TAIL1(0), 15, 4, 0, 0, "QTX_TAIL1"},
+#ifdef X722_SUPPORT
{I40E_VFPE_CQPDB(0), 127, 4, 0, 0, "VFPE_CQPDB"},
{I40E_VFPE_CQPTAIL(0), 127, 4, 0, 0, "VFPE_CQPTAIL"},
{I40E_VFPE_CCQPSTATUS(0), 127, 4, 0, 0, "VFPE_CCQPSTATUS"},
@@ -79,12 +84,15 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_VFPE_CCQPHIGH(0), 127, 4, 0, 0, "VFPE_CCQPHIGH"},
{I40E_VFPE_IPCONFIG0(0), 127, 4, 0, 0, "VFPE_IPCONFIG0"},
{I40E_VFPE_CQPERRCODES(0), 127, 4, 0, 0, "VFPE_CQPERRCODES"},
+#endif
{I40E_QRX_TAIL1(0), 15, 4, 0, 0, "QRX_TAIL1"},
{I40E_VFINT_ITRN1(0, 0), 2, 64, 15, 4, "VFINT_ITRN1"},
+#ifdef X722_SUPPORT
{I40E_VFPE_TCPNOWTIMER(0), 127, 4, 0, 0, "VFPE_TCPNOWTIMER"},
{I40E_VFPE_MRTEIDXMASK(0), 127, 4, 0, 0, "VFPE_MRTEIDXMASK"},
{I40E_VFPE_RCVUNEXPECTEDERROR(0), 127, 4, 0, 0,
"VFPE_RCVUNEXPECTEDERROR"},
+#endif
{I40E_VFINT_DYN_CTLN1(0), 15, 4, 0, 0, "VFINT_DYN_CTLN1"},
{I40E_VFINT_ICR01, 0, 0, 0, 0, "VFINT_ICR01"},
{I40E_VFINT_ITR01(0), 2, 4, 0, 0, "VFINT_ITR01"},
@@ -100,19 +108,24 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_VF_ATQBAH1, 0, 0, 0, 0, "VF_ATQBAH1"},
{I40E_VF_ATQBAL1, 0, 0, 0, 0, "VF_ATQBAL1"},
{I40E_VF_ARQLEN1, 0, 0, 0, 0, "VF_ARQLEN1"},
+#ifdef X722_SUPPORT
{I40E_PFPE_CQPDB, 0, 0, 0, 0, "PFPE_CQPDB"},
{I40E_PFPE_CQPTAIL, 0, 0, 0, 0, "PFPE_CQPTAIL"},
{I40E_PFPE_CCQPSTATUS, 0, 0, 0, 0, "PFPE_CCQPSTATUS"},
{I40E_PFPE_CCQPLOW, 0, 0, 0, 0, "PFPE_CCQPLOW"},
{I40E_PFPE_CCQPHIGH, 0, 0, 0, 0, "PFPE_CCQPHIGH"},
{I40E_PFPE_IPCONFIG0, 0, 0, 0, 0, "PFPE_IPCONFIG0"},
+#endif
{I40E_VF_ATQT1, 0, 0, 0, 0, "VF_ATQT1"},
+#ifdef X722_SUPPORT
{I40E_PFPE_TCPNOWTIMER, 0, 0, 0, 0, "PFPE_TCPNOWTIMER"},
{I40E_PFPE_MRTEIDXMASK, 0, 0, 0, 0, "PFPE_MRTEIDXMASK"},
{I40E_PFPE_RCVUNEXPECTEDERROR, 0, 0, 0, 0, "PFPE_RCVUNEXPECTEDERROR"},
{I40E_PFPE_UDACTRL, 0, 0, 0, 0, "PFPE_UDACTRL"},
{I40E_PFPE_UDAUCFBQPN, 0, 0, 0, 0, "PFPE_UDAUCFBQPN"},
+#endif
{I40E_VFGEN_RSTAT, 0, 0, 0, 0, "VFGEN_RSTAT"},
+#ifdef X722_SUPPORT
{I40E_PFPE_CQPERRCODES, 0, 0, 0, 0, "PFPE_CQPERRCODES"},
{I40E_PFPE_FLMXMITALLOCERR, 0, 0, 0, 0, "PFPE_FLMXMITALLOCERR"},
{I40E_PFPE_FLMQ1ALLOCERR, 0, 0, 0, 0, "PFPE_FLMQ1ALLOCERR"},
@@ -134,7 +147,9 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLPE_VFUDAUCFBQPN(0), 31, 4, 0, 0, "GLPE_VFUDAUCFBQPN"},
{I40E_GLPE_VFFLMXMITALLOCERR(0), 31, 4, 0, 0, "GLPE_VFFLMXMITALLOCERR"},
{I40E_GLPE_VFFLMQ1ALLOCERR(0), 31, 4, 0, 0, "GLPE_VFFLMQ1ALLOCERR"},
+#endif
{I40E_VFQF_HLUT(0), 15, 4, 0, 0, "VFQF_HLUT"},
+#ifdef X722_SUPPORT
{I40E_GLPE_CPUSTATUS0, 0, 0, 0, 0, "GLPE_CPUSTATUS0"},
{I40E_GLPE_CPUSTATUS1, 0, 0, 0, 0, "GLPE_CPUSTATUS1"},
{I40E_GLPE_CPUSTATUS2, 0, 0, 0, 0, "GLPE_CPUSTATUS2"},
@@ -158,8 +173,10 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_PRTPE_RUPM_CNTR, 0, 0, 0, 0, "PRTPE_RUPM_CNTR"},
{I40E_PRTPE_RUPM_PTXTCCNTR03, 0, 0, 0, 0, "PRTPE_RUPM_PTXTCCNTR03"},
{I40E_PRTPE_RUPM_PTCTCCNTR47, 0, 0, 0, 0, "PRTPE_RUPM_PTCTCCNTR47"},
+#endif
{I40E_VFCM_PE_ERRDATA, 0, 0, 0, 0, "VFCM_PE_ERRDATA"},
{I40E_PFPCI_VF_FLUSH_DONE, 0, 0, 0, 0, "PFPCI_VF_FLUSH_DONE"},
+#ifdef X722_SUPPORT
{I40E_GLPES_PFRXVLANERR(0), 15, 4, 0, 0, "GLPES_PFRXVLANERR"},
{I40E_GLPES_PFIP4RXOCTSLO(0), 15, 8, 0, 0, "GLPES_PFIP4RXOCTSLO"},
{I40E_GLPES_PFIP4RXOCTSHI(0), 15, 8, 0, 0, "GLPES_PFIP4RXOCTSHI"},
@@ -333,6 +350,7 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_PRTDCB_TCMSTC_RLPM(0), 7, 32, 0, 0, "PRTDCB_TCMSTC_RLPM"},
{I40E_PRTDCB_RLPMC, 0, 0, 0, 0, "PRTDCB_RLPMC"},
{I40E_PRTDCB_TCPMC_RLPM, 0, 0, 0, 0, "PRTDCB_TCPMC_RLPM"},
+#endif
{I40E_VFINT_ITRN(0, 0), 2, 2048, 511, 4, "VFINT_ITRN"},
{I40E_VFINT_DYN_CTLN(0), 511, 4, 0, 0, "VFINT_DYN_CTLN"},
{I40E_VPINT_LNKLSTN(0), 511, 4, 0, 0, "VPINT_LNKLSTN"},
@@ -376,7 +394,9 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_VPLAN_QTABLE(0, 0), 15, 1024, 127, 4, "VPLAN_QTABLE"},
{I40E_VPLAN_MAPENA(0), 127, 4, 0, 0, "VPLAN_MAPENA"},
{I40E_VFGEN_RSTAT1(0), 127, 4, 0, 0, "VFGEN_RSTAT1"},
+#ifdef X722_SUPPORT
{I40E_VPLAN_QBASE(0), 127, 4, 0, 0, "VPLAN_QBASE"},
+#endif
{I40E_PF_ATQBAL, 0, 0, 0, 0, "PF_ATQBAL"},
{I40E_GL_ATQBAL, 0, 0, 0, 0, "GL_ATQBAL"},
{I40E_PF_ARQBAL, 0, 0, 0, 0, "PF_ARQBAL"},
@@ -411,8 +431,10 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLDCB_GENC, 0, 0, 0, 0, "GLDCB_GENC"},
{I40E_GL_FWSTS, 0, 0, 0, 0, "GL_FWSTS"},
{I40E_GL_FWRESETCNT, 0, 0, 0, 0, "GL_FWRESETCNT"},
+#ifdef X722_SUPPORT
{I40E_GL_VF_CTRL_TX(0), 127, 4, 0, 0, "GL_VF_CTRL_TX"},
{I40E_GL_VF_CTRL_RX(0), 127, 4, 0, 0, "GL_VF_CTRL_RX"},
+#endif
{I40E_PRTTSYN_CTL1, 0, 0, 0, 0, "PRTTSYN_CTL1"},
{I40E_PRTTSYN_RXTIME_H(0), 3, 32, 0, 0, "PRTTSYN_RXTIME_H"},
{I40E_PRTTSYN_RXTIME_L(0), 3, 32, 0, 0, "PRTTSYN_RXTIME_L"},
@@ -420,10 +442,14 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_PRT_MNG_FTFT_MASK(0), 7, 32, 0, 0, "PRT_MNG_FTFT_MASK"},
{I40E_PRT_MNG_FTFT_LENGTH, 0, 0, 0, 0, "PRT_MNG_FTFT_LENGTH"},
{I40E_PRT_MNG_FTFT_DATA(0), 31, 32, 0, 0, "PRT_MNG_FTFT_DATA"},
+#ifdef X722_SUPPORT
{I40E_GL_PPRS_SPARE, 0, 0, 0, 0, "GL_PPRS_SPARE"},
+#endif
{I40E_PFGEN_STATE, 0, 0, 0, 0, "PFGEN_STATE"},
{I40E_PFINT_GPIO_ENA, 0, 0, 0, 0, "PFINT_GPIO_ENA"},
+#ifdef X722_SUPPORT
{I40E_GLGEN_MISC_SPARE, 0, 0, 0, 0, "GLGEN_MISC_SPARE"},
+#endif
{I40E_GLGEN_GPIO_CTL(0), 29, 4, 0, 0, "GLGEN_GPIO_CTL"},
{I40E_GLGEN_LED_CTL, 0, 0, 0, 0, "GLGEN_LED_CTL"},
{I40E_GLGEN_GPIO_STAT, 0, 0, 0, 0, "GLGEN_GPIO_STAT"},
@@ -470,6 +496,7 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLPCI_PM_MUX_NPQ, 0, 0, 0, 0, "GLPCI_PM_MUX_NPQ"},
{I40E_GLPCI_SPARE_BITS_0, 0, 0, 0, 0, "GLPCI_SPARE_BITS_0"},
{I40E_GLPCI_SPARE_BITS_1, 0, 0, 0, 0, "GLPCI_SPARE_BITS_1"},
+#ifdef X722_SUPPORT
{I40E_GLPCI_CUR_RLAN_ALWD, 0, 0, 0, 0, "GLPCI_CUR_RLAN_ALWD"},
{I40E_GLPCI_CUR_TLAN_ALWD, 0, 0, 0, 0, "GLPCI_CUR_TLAN_ALWD"},
{I40E_GLPCI_CUR_RXPE_ALWD, 0, 0, 0, 0, "GLPCI_CUR_RXPE_ALWD"},
@@ -484,9 +511,11 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLPCI_CUR_PMAT_RSVD, 0, 0, 0, 0, "GLPCI_CUR_PMAT_RSVD"},
{I40E_GLPCI_CUR_MNG_RSVD, 0, 0, 0, 0, "GLPCI_CUR_MNG_RSVD"},
{I40E_GLPCI_CUR_TDPU_RSVD, 0, 0, 0, 0, "GLPCI_CUR_TDPU_RSVD"},
+#endif
{I40E_PFPCI_VF_FLUSH_DONE1(0), 127, 4, 0, 0, "PFPCI_VF_FLUSH_DONE1"},
{I40E_PFPCI_PF_FLUSH_DONE, 0, 0, 0, 0, "PFPCI_PF_FLUSH_DONE"},
{I40E_PFPCI_VM_FLUSH_DONE, 0, 0, 0, 0, "PFPCI_VM_FLUSH_DONE"},
+#ifdef X722_SUPPORT
{I40E_GLPCI_NPQ_CFG, 0, 0, 0, 0, "GLPCI_NPQ_CFG"},
{I40E_GLPCI_CUR_CLNT_COMMON, 0, 0, 0, 0, "GLPCI_CUR_CLNT_COMMON"},
{I40E_GLPCI_CUR_CLNT_PIPEMON, 0, 0, 0, 0, "GLPCI_CUR_CLNT_PIPEMON"},
@@ -501,15 +530,20 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLPCI_WATMK_PMAT_ALWD, 0, 0, 0, 0, "GLPCI_WATMK_PMAT_ALWD"},
{I40E_GLPCI_WATMK_MNG_ALWD, 0, 0, 0, 0, "GLPCI_WATMK_MNG_ALWD"},
{I40E_GLPCI_WATMK_TPDU_ALWD, 0, 0, 0, 0, "GLPCI_WATMK_TPDU_ALWD"},
+#endif
{I40E_PRTDCB_TCMSTC(0), 7, 32, 0, 0, "PRTDCB_TCMSTC"},
+#ifdef X722_SUPPORT
{I40E_PRTDCB_TFMSTC(0), 7, 32, 0, 0, "PRTDCB_TFMSTC"},
+#endif
{I40E_PRTDCB_TDPMC, 0, 0, 0, 0, "PRTDCB_TDPMC"},
{I40E_PRTDCB_TCWSTC(0), 7, 32, 0, 0, "PRTDCB_TCWSTC"},
{I40E_PRTDCB_TCPMC, 0, 0, 0, 0, "PRTDCB_TCPMC"},
+#ifdef X722_SUPPORT
{I40E_GL_TUPM_SPARE, 0, 0, 0, 0, "GL_TUPM_SPARE"},
{I40E_GLPEOC_CACHESIZE, 0, 0, 0, 0, "GLPEOC_CACHESIZE"},
{I40E_GLPBLOC_CACHESIZE, 0, 0, 0, 0, "GLPBLOC_CACHESIZE"},
{I40E_GLFOC_CACHESIZE, 0, 0, 0, 0, "GLFOC_CACHESIZE"},
+#endif
{I40E_PRTRPB_DHW(0), 7, 32, 0, 0, "PRTRPB_DHW"},
{I40E_PRTRPB_DLW(0), 7, 32, 0, 0, "PRTRPB_DLW"},
{I40E_PRTRPB_DPS(0), 7, 32, 0, 0, "PRTRPB_DPS"},
@@ -536,6 +570,7 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLGEN_STAT, 0, 0, 0, 0, "GLGEN_STAT"},
{I40E_GL_MNG_HWARB_CTRL, 0, 0, 0, 0, "GL_MNG_HWARB_CTRL"},
{I40E_GL_MNG_FWSM, 0, 0, 0, 0, "GL_MNG_FWSM"},
+#ifdef X722_SUPPORT
{I40E_GLNVM_ALTIMERS, 0, 0, 0, 0, "GLNVM_ALTIMERS"},
{I40E_GLNVM_ULT, 0, 0, 0, 0, "GLNVM_ULT"},
{I40E_MEM_INIT_DONE_STAT, 0, 0, 0, 0, "MEM_INIT_DONE_STAT"},
@@ -553,6 +588,7 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_MNGSB_WDATA, 0, 0, 0, 0, "MNGSB_WDATA"},
{I40E_MNGSB_RHDR0, 0, 0, 0, 0, "MNGSB_RHDR0"},
{I40E_MNGSB_RDATA, 0, 0, 0, 0, "MNGSB_RDATA"},
+#endif
{I40E_PFPM_APM, 0, 0, 0, 0, "PFPM_APM"},
{I40E_PRTGEN_STATUS, 0, 0, 0, 0, "PRTGEN_STATUS"},
{I40E_PRTGEN_CNF, 0, 0, 0, 0, "PRTGEN_CNF"},
@@ -562,8 +598,10 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLGEN_CLKSTAT, 0, 0, 0, 0, "GLGEN_CLKSTAT"},
{I40E_GLGEN_RSTAT, 0, 0, 0, 0, "GLGEN_RSTAT"},
{I40E_GLGEN_RTRIG, 0, 0, 0, 0, "GLGEN_RTRIG"},
+#ifdef X722_SUPPORT
{I40E_GLGEN_PME_TO, 0, 0, 0, 0, "GLGEN_PME_TO"},
{I40E_GLGEN_CAR_DEBUG, 0, 0, 0, 0, "GLGEN_CAR_DEBUG"},
+#endif
{I40E_PFPCI_CNF, 0, 0, 0, 0, "PFPCI_CNF"},
{I40E_PFPCI_DEVID, 0, 0, 0, 0, "PFPCI_DEVID"},
{I40E_PFPCI_SUBSYSID, 0, 0, 0, 0, "PFPCI_SUBSYSID"},
@@ -589,7 +627,9 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLPCI_UPADD, 0, 0, 0, 0, "GLPCI_UPADD"},
{I40E_GLPCI_PCIERR, 0, 0, 0, 0, "GLPCI_PCIERR"},
{I40E_GLPCI_VENDORID, 0, 0, 0, 0, "GLPCI_VENDORID"},
+#ifdef X722_SUPPORT
{I40E_GL_UFUSE_SOC, 0, 0, 0, 0, "GL_UFUSE_SOC"},
+#endif
{I40E_PFHMC_SDCMD, 0, 0, 0, 0, "PFHMC_SDCMD"},
{I40E_PFHMC_SDDATALOW, 0, 0, 0, 0, "PFHMC_SDDATALOW"},
{I40E_PFHMC_SDDATAHIGH, 0, 0, 0, 0, "PFHMC_SDDATAHIGH"},
@@ -597,7 +637,9 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_PFHMC_ERRORINFO, 0, 0, 0, 0, "PFHMC_ERRORINFO"},
{I40E_PFHMC_ERRORDATA, 0, 0, 0, 0, "PFHMC_ERRORDATA"},
{I40E_GLHMC_SDPART(0), 15, 4, 0, 0, "GLHMC_SDPART"},
+#ifdef X722_SUPPORT
{I40E_GLHMC_PFPESDPART(0), 15, 4, 0, 0, "GLHMC_PFPESDPART"},
+#endif
{I40E_GLHMC_PFASSIGN(0), 15, 4, 0, 0, "GLHMC_PFASSIGN"},
{I40E_GLHMC_LANTXOBJSZ, 0, 0, 0, 0, "GLHMC_LANTXOBJSZ"},
{I40E_GLHMC_LANQMAX, 0, 0, 0, 0, "GLHMC_LANQMAX"},
@@ -605,6 +647,7 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLHMC_FCOEDDPOBJSZ, 0, 0, 0, 0, "GLHMC_FCOEDDPOBJSZ"},
{I40E_GLHMC_FCOEMAX, 0, 0, 0, 0, "GLHMC_FCOEMAX"},
{I40E_GLHMC_FCOEFOBJSZ, 0, 0, 0, 0, "GLHMC_FCOEFOBJSZ"},
+#ifdef X722_SUPPORT
{I40E_GLHMC_PEQPOBJSZ, 0, 0, 0, 0, "GLHMC_PEQPOBJSZ"},
{I40E_GLHMC_PECQOBJSZ, 0, 0, 0, 0, "GLHMC_PECQOBJSZ"},
{I40E_GLHMC_PESRQOBJSZ, 0, 0, 0, 0, "GLHMC_PESRQOBJSZ"},
@@ -621,10 +664,12 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLHMC_PEQ1OBJSZ, 0, 0, 0, 0, "GLHMC_PEQ1OBJSZ"},
{I40E_GLHMC_PEQ1MAX, 0, 0, 0, 0, "GLHMC_PEQ1MAX"},
{I40E_GLHMC_PEQ1FLMAX, 0, 0, 0, 0, "GLHMC_PEQ1FLMAX"},
+#endif
{I40E_GLHMC_FSIMCOBJSZ, 0, 0, 0, 0, "GLHMC_FSIMCOBJSZ"},
{I40E_GLHMC_FSIMCMAX, 0, 0, 0, 0, "GLHMC_FSIMCMAX"},
{I40E_GLHMC_FSIAVOBJSZ, 0, 0, 0, 0, "GLHMC_FSIAVOBJSZ"},
{I40E_GLHMC_FSIAVMAX, 0, 0, 0, 0, "GLHMC_FSIAVMAX"},
+#ifdef X722_SUPPORT
{I40E_GLHMC_PEPBLMAX, 0, 0, 0, 0, "GLHMC_PEPBLMAX"},
{I40E_GLHMC_PETIMEROBJSZ, 0, 0, 0, 0, "GLHMC_PETIMEROBJSZ"},
{I40E_GLHMC_PETIMERMAX, 0, 0, 0, 0, "GLHMC_PETIMERMAX"},
@@ -695,11 +740,14 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLHMC_VFPETIMERBASE(0), 31, 4, 0, 0, "GLHMC_VFPETIMERBASE"},
{I40E_GLHMC_VFPETIMERCNT(0), 31, 4, 0, 0, "GLHMC_VFPETIMERCNT"},
{I40E_GLPDOC_CACHESIZE, 0, 0, 0, 0, "GLPDOC_CACHESIZE"},
+#endif
{I40E_QTX_HEAD(0), 1535, 4, 0, 0, "QTX_HEAD"},
{I40E_VP_MDET_TX(0), 127, 4, 0, 0, "VP_MDET_TX"},
{I40E_PF_MDET_TX, 0, 0, 0, 0, "PF_MDET_TX"},
{I40E_GL_MDET_TX, 0, 0, 0, 0, "GL_MDET_TX"},
+#ifdef X722_SUPPORT
{I40E_GL_TLAN_SPARE, 0, 0, 0, 0, "GL_TLAN_SPARE"},
+#endif
{I40E_GLLAN_TXPRE_QDIS(0), 11, 4, 0, 0, "GLLAN_TXPRE_QDIS"},
{I40E_QTX_ENA(0), 1535, 4, 0, 0, "QTX_ENA"},
{I40E_QTX_CTL(0), 1535, 4, 0, 0, "QTX_CTL"},
@@ -709,7 +757,9 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_PFCM_LANCTXDATA(0), 3, 128, 0, 0, "PFCM_LANCTXDATA"},
{I40E_PFCM_LANCTXCTL, 0, 0, 0, 0, "PFCM_LANCTXCTL"},
{I40E_PFCM_LANCTXSTAT, 0, 0, 0, 0, "PFCM_LANCTXSTAT"},
+#ifdef X722_SUPPORT
{I40E_GLCM_LAN_CACHESIZE, 0, 0, 0, 0, "GLCM_LAN_CACHESIZE"},
+#endif
{I40E_QRX_ENA(0), 1535, 4, 0, 0, "QRX_ENA"},
{I40E_PRTDCB_RETSTCC(0), 7, 32, 0, 0, "PRTDCB_RETSTCC"},
{I40E_PRTDCB_RPPMC, 0, 0, 0, 0, "PRTDCB_RPPMC"},
@@ -721,6 +771,7 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_PF_MDET_RX, 0, 0, 0, 0, "PF_MDET_RX"},
{I40E_GLLAN_RCTL_0, 0, 0, 0, 0, "GLLAN_RCTL_0"},
{I40E_GL_MDET_RX, 0, 0, 0, 0, "GL_MDET_RX"},
+#ifdef X722_SUPPORT
{I40E_VFPE_CQARM(0), 127, 4, 0, 0, "VFPE_CQARM"},
{I40E_VFPE_CQACK(0), 127, 4, 0, 0, "VFPE_CQACK"},
{I40E_VFPE_AEQALLOC(0), 127, 4, 0, 0, "VFPE_AEQALLOC"},
@@ -738,14 +789,17 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLPE_VFCEQEDROPCNT(0), 31, 4, 0, 0, "GLPE_VFCEQEDROPCNT"},
{I40E_GLPE_VFAEQEDROPCNT(0), 31, 4, 0, 0, "GLPE_VFAEQEDROPCNT"},
{I40E_VFPE_WQEALLOC(0), 127, 4, 0, 0, "VFPE_WQEALLOC"},
+#endif
{I40E_VFCM_PE_ERRINFO1(0), 127, 4, 0, 0, "VFCM_PE_ERRINFO1"},
{I40E_VFCM_PE_ERRDATA1(0), 127, 4, 0, 0, "VFCM_PE_ERRDATA1"},
+#ifdef X722_SUPPORT
{I40E_PFPE_WQEALLOC, 0, 0, 0, 0, "PFPE_WQEALLOC"},
{I40E_PFCM_PE_ERRINFO, 0, 0, 0, 0, "PFCM_PE_ERRINFO"},
{I40E_PFCM_PE_ERRDATA, 0, 0, 0, 0, "PFCM_PE_ERRDATA"},
{I40E_GLHMC_DBQPPART(0), 15, 4, 0, 0, "GLHMC_DBQPPART"},
{I40E_GLHMC_VFDBQPPART(0), 31, 4, 0, 0, "GLHMC_VFDBQPPART"},
{I40E_GLCM_PE_CACHESIZE, 0, 0, 0, 0, "GLCM_PE_CACHESIZE"},
+#endif
{I40E_PFGEN_PORTNUM, 0, 0, 0, 0, "PFGEN_PORTNUM"},
{I40E_PF_VT_PFALLOC, 0, 0, 0, 0, "PF_VT_PFALLOC"},
{I40E_PRTDCB_TC2PFC, 0, 0, 0, 0, "PRTDCB_TC2PFC"},
@@ -756,8 +810,10 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_PRTGL_SAL, 0, 0, 0, 0, "PRTGL_SAL"},
{I40E_PRTGL_SAH, 0, 0, 0, 0, "PRTGL_SAH"},
{I40E_PRTDCB_MFLCN, 0, 0, 0, 0, "PRTDCB_MFLCN"},
+#ifdef X722_SUPPORT
{I40E_PRTMAC_LINK_DOWN_COUNTER, 0, 0, 0, 0,
"PRTMAC_LINK_DOWN_COUNTER"},
+#endif
{I40E_PRTMAC_HSEC_CTL_RX_PAUSE_ENABLE, 0, 0, 0, 0,
"PRTMAC_HSEC_CTL_RX_PAUSE_ENABLE"},
{I40E_PRTMAC_HSEC_CTL_TX_PAUSE_ENABLE, 0, 0, 0, 0,
@@ -817,12 +873,16 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_PRTDCB_FCCFG, 0, 0, 0, 0, "PRTDCB_FCCFG"},
{I40E_PRTDCB_TPFCTS(0), 7, 32, 0, 0, "PRTDCB_TPFCTS"},
{I40E_VFQF_HLUT1(0, 0), 15, 1024, 127, 4, "VFQF_HLUT1"},
+#ifdef X722_SUPPORT
{I40E_VSIQF_HLUT(0, 0), 15, 2048, 383, 4, "VSIQF_HLUT"},
+#endif
{I40E_VFQF_HKEY1(0, 0), 12, 1024, 127, 4, "VFQF_HKEY1"},
{I40E_VFQF_HREGION1(0, 0), 7, 1024, 127, 4, "VFQF_HREGION1"},
{I40E_VFQF_HENA1(0, 0), 1, 1024, 127, 4, "VFQF_HENA1"},
{I40E_PFQF_HLUT(0), 127, 128, 0, 0, "PFQF_HLUT"},
+#ifdef X722_SUPPORT
{I40E_X722_PFQF_HLUT(0), 127, 128, 0, 0, "X722_PFQF_HLUT"},
+#endif
{I40E_PFQF_CTL_1, 0, 0, 0, 0, "PFQF_CTL_1"},
{I40E_PFQF_FDSTAT, 0, 0, 0, 0, "PFQF_FDSTAT"},
{I40E_PRT_MNG_MIPAF6(0), 15, 32, 0, 0, "PRT_MNG_MIPAF6"},
@@ -839,21 +899,25 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_PRT_MNG_MANC, 0, 0, 0, 0, "PRT_MNG_MANC"},
{I40E_PRT_MNG_MNGONLY, 0, 0, 0, 0, "PRT_MNG_MNGONLY"},
{I40E_PRT_MNG_MSFM, 0, 0, 0, 0, "PRT_MNG_MSFM"},
+#ifdef X722_SUPPORT
{I40E_GLQF_APBVT(0), 2047, 4, 0, 0, "GLQF_APBVT"},
{I40E_GLQF_PCNT(0), 511, 4, 0, 0, "GLQF_PCNT"},
{I40E_GLQF_FD_PCTYPES(0), 63, 4, 0, 0, "GLQF_FD_PCTYPES"},
{I40E_GLQF_ORT(0), 63, 4, 0, 0, "GLQF_ORT"},
{I40E_GLQF_PIT(0), 23, 4, 0, 0, "GLQF_PIT"},
+#endif
{I40E_GL_PRS_FVBM(0), 3, 4, 0, 0, "GL_PRS_FVBM"},
{I40E_GLQF_FDCNT_0, 0, 0, 0, 0, "GLQF_FDCNT_0"},
{I40E_GL_MTG_FLU_MSK_H, 0, 0, 0, 0, "GL_MTG_FLU_MSK_H"},
{I40E_GL_SWR_DEF_ACT_EN(0), 1, 4, 0, 0, "GL_SWR_DEF_ACT_EN"},
{I40E_GLQF_HKEY(0), 12, 4, 0, 0, "GLQF_HKEY"},
{I40E_GL_SWR_DEF_ACT(0), 35, 4, 0, 0, "GL_SWR_DEF_ACT"},
+#ifdef X722_SUPPORT
{I40E_GLQF_FDEVICTFLAG, 0, 0, 0, 0, "GLQF_FDEVICTFLAG"},
{I40E_PFQF_CTL_2, 0, 0, 0, 0, "PFQF_CTL_2"},
{I40E_GLQF_FDEVICTENA(0), 1, 4, 0, 0, "GLQF_FDEVICTENA"},
{I40E_VSIQF_HKEY(0, 0), 12, 2048, 383, 4, "VSIQF_HKEY"},
+#endif
{I40E_GLPRT_GORCL(0), 3, 8, 0, 0, "GLPRT_GORCL"},
{I40E_GLPRT_GORCH(0), 3, 8, 0, 0, "GLPRT_GORCH"},
{I40E_GLPRT_MLFC(0), 3, 8, 0, 0, "GLPRT_MLFC"},
@@ -991,7 +1055,39 @@ static const struct i40e_reg_info i40e_regs_others[] = {
{I40E_GLVEBVL_MPCH(0), 127, 8, 0, 0, "GLVEBVL_MPCH"},
{I40E_GLVEBVL_BPCL(0), 127, 8, 0, 0, "GLVEBVL_BPCL"},
{I40E_GLVEBVL_BPCH(0), 127, 8, 0, 0, "GLVEBVL_BPCH"},
+#ifdef X722_SUPPORT
{I40E_GLGEN_STAT_HALT, 0, 0, 0, 0, "GLGEN_STAT_HALT"},
{I40E_GLGEN_STAT_CLEAR, 0, 0, 0, 0, "GLGEN_STAT_CLEAR"},
+#endif
{0, 0, 0, 0, 0, NULL}
};
+
+#ifndef X722_SUPPORT
+#define I40E_GLQF_FD_MSK(_i, _j) \
+ (0x00267200 + ((_i) * 4 + (_j) * 8)) \
+ /* _i=0...1, _j=0...63 */ /* Reset: CORER */
+#define I40E_GLQF_FD_MSK_MAX_INDEX 1
+#define I40E_GLQF_FD_MSK_MASK_SHIFT 0
+#define I40E_GLQF_FD_MSK_MASK_MASK \
+ I40E_MASK(0xFFFF, I40E_GLQF_FD_MSK_MASK_SHIFT)
+#define I40E_GLQF_FD_MSK_OFFSET_SHIFT 16
+#define I40E_GLQF_FD_MSK_OFFSET_MASK \
+ I40E_MASK(0x3F, I40E_GLQF_FD_MSK_OFFSET_SHIFT)
+#define I40E_GLQF_HASH_INSET(_i, _j) \
+ (0x00267600 + ((_i) * 4 + (_j) * 8)) \
+ /* _i=0...1, _j=0...63 */ /* Reset: CORER */
+#define I40E_GLQF_HASH_INSET_MAX_INDEX 1
+#define I40E_GLQF_HASH_INSET_INSET_SHIFT 0
+#define I40E_GLQF_HASH_INSET_INSET_MASK \
+ I40E_MASK(0xFFFFFFFF, I40E_GLQF_HASH_INSET_INSET_SHIFT)
+#define I40E_GLQF_HASH_MSK(_i, _j) \
+ (0x00267A00 + ((_i) * 4 + (_j) * 8)) \
+ /* _i=0...1, _j=0...63 */ /* Reset: CORER */
+#define I40E_GLQF_HASH_MSK_MAX_INDEX 1
+#define I40E_GLQF_HASH_MSK_MASK_SHIFT 0
+#define I40E_GLQF_HASH_MSK_MASK_MASK \
+ I40E_MASK(0xFFFF, I40E_GLQF_HASH_MSK_MASK_SHIFT)
+#define I40E_GLQF_HASH_MSK_OFFSET_SHIFT 16
+#define I40E_GLQF_HASH_MSK_OFFSET_MASK \
+ I40E_MASK(0x3F, I40E_GLQF_HASH_MSK_OFFSET_SHIFT)
+#endif
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 2cb2e30..4868786 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -2199,7 +2199,11 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t base, bsf, tc_mapping;
int use_def_burst_func = 1;
+#ifdef X722_SUPPORT
if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF) {
+#else
+ if (hw->mac.type == I40E_MAC_VF) {
+#endif /* X722_SUPPORT */
struct i40e_vf *vf =
I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
vsi = &vf->vsi;
@@ -2239,7 +2243,12 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
rxq->nb_rx_desc = nb_desc;
rxq->rx_free_thresh = rx_conf->rx_free_thresh;
rxq->queue_id = queue_idx;
+
+#ifdef X722_SUPPORT
if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF)
+#else
+ if (hw->mac.type == I40E_MAC_VF)
+#endif /* X722_SUPPORT */
rxq->reg_idx = queue_idx;
else /* PF device */
rxq->reg_idx = vsi->base_queue +
@@ -2416,7 +2425,11 @@ i40e_dev_tx_queue_setup(struct rte_eth_dev *dev,
uint16_t tx_rs_thresh, tx_free_thresh;
uint16_t i, base, bsf, tc_mapping;
+#ifdef X722_SUPPORT
if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF) {
+#else
+ if (hw->mac.type == I40E_MAC_VF) {
+#endif /* X722_SUPPORT */
struct i40e_vf *vf =
I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
vsi = &vf->vsi;
@@ -2544,12 +2557,15 @@ i40e_dev_tx_queue_setup(struct rte_eth_dev *dev,
txq->hthresh = tx_conf->tx_thresh.hthresh;
txq->wthresh = tx_conf->tx_thresh.wthresh;
txq->queue_id = queue_idx;
+#ifdef X722_SUPPORT
if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF)
+#else
+ if (hw->mac.type == I40E_MAC_VF)
+#endif /* X722_SUPPORT */
txq->reg_idx = queue_idx;
else /* PF device */
txq->reg_idx = vsi->base_queue +
i40e_get_queue_offset_by_qindex(pf, queue_idx);
-
txq->port_id = dev->data->port_id;
txq->txq_flags = tx_conf->txq_flags;
txq->vsi = vsi;
--
1.9.3
^ permalink raw reply related
* [PATCH v2 2/2] drivers/i40e: fix the hash filter invalid calculation in X722
From: Jeff Guo @ 2016-10-16 1:40 UTC (permalink / raw)
To: helin.zhang, jingjing.wu; +Cc: dev, jia.guo
In-Reply-To: <1476582005-110811-1-git-send-email-jia.guo@intel.com>
As X722 extracts IPv4 header to Field Vector different with XL710/X710,
need to corresponding to modify the fields of IPv4 header in input set
to map different default Field Vector Table of different NICs.
Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
v2:
fix compile error when x722 macro is not defined and simplify
the code to avoid duplication.
---
drivers/net/i40e/i40e_ethdev.c | 73 ++++++++++++++++++++++++++++++++++--------
1 file changed, 60 insertions(+), 13 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 920fd6d..7895c11 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -211,6 +211,16 @@
#define I40E_REG_INSET_L3_SRC_IP4 0x0001800000000000ULL
/* Destination IPv4 address */
#define I40E_REG_INSET_L3_DST_IP4 0x0000001800000000ULL
+#ifdef X722_SUPPORT
+/* Source IPv4 address for X722 */
+#define I40E_X722_REG_INSET_L3_SRC_IP4 0x0006000000000000ULL
+/* Destination IPv4 address for X722 */
+#define I40E_X722_REG_INSET_L3_DST_IP4 0x0000060000000000ULL
+/* IPv4 Protocol */
+#define I40E_X722_REG_INSET_L3_IP4_PROTO 0x0010000000000000ULL
+/* IPv4 Time to Live */
+#define I40E_X722_REG_INSET_L3_IP4_TTL 0x0010000000000000ULL
+#endif
/* IPv4 Type of Service (TOS) */
#define I40E_REG_INSET_L3_IP4_TOS 0x0040000000000000ULL
/* IPv4 Protocol */
@@ -7581,7 +7591,7 @@ i40e_parse_input_set(uint64_t *inset,
* and vice versa
*/
static uint64_t
-i40e_translate_input_set_reg(uint64_t input)
+i40e_translate_input_set_reg(enum i40e_mac_type type, uint64_t input)
{
uint64_t val = 0;
uint16_t i;
@@ -7589,17 +7599,13 @@ i40e_translate_input_set_reg(uint64_t input)
static const struct {
uint64_t inset;
uint64_t inset_reg;
- } inset_map[] = {
+ } inset_map_common[] = {
{I40E_INSET_DMAC, I40E_REG_INSET_L2_DMAC},
{I40E_INSET_SMAC, I40E_REG_INSET_L2_SMAC},
{I40E_INSET_VLAN_OUTER, I40E_REG_INSET_L2_OUTER_VLAN},
{I40E_INSET_VLAN_INNER, I40E_REG_INSET_L2_INNER_VLAN},
{I40E_INSET_LAST_ETHER_TYPE, I40E_REG_INSET_LAST_ETHER_TYPE},
- {I40E_INSET_IPV4_SRC, I40E_REG_INSET_L3_SRC_IP4},
- {I40E_INSET_IPV4_DST, I40E_REG_INSET_L3_DST_IP4},
{I40E_INSET_IPV4_TOS, I40E_REG_INSET_L3_IP4_TOS},
- {I40E_INSET_IPV4_PROTO, I40E_REG_INSET_L3_IP4_PROTO},
- {I40E_INSET_IPV4_TTL, I40E_REG_INSET_L3_IP4_TTL},
{I40E_INSET_IPV6_SRC, I40E_REG_INSET_L3_SRC_IP6},
{I40E_INSET_IPV6_DST, I40E_REG_INSET_L3_DST_IP6},
{I40E_INSET_IPV6_TC, I40E_REG_INSET_L3_IP6_TC},
@@ -7627,16 +7633,56 @@ i40e_translate_input_set_reg(uint64_t input)
{I40E_INSET_FLEX_PAYLOAD_W7, I40E_REG_INSET_FLEX_PAYLOAD_WORD7},
{I40E_INSET_FLEX_PAYLOAD_W8, I40E_REG_INSET_FLEX_PAYLOAD_WORD8},
};
+#ifdef X722_SUPPORT
+
+ /* some different registers map in x722*/
+ static const struct {
+ uint64_t inset;
+ uint64_t inset_reg;
+ } inset_map_diff_x722[] = {
+ {I40E_INSET_IPV4_SRC, I40E_X722_REG_INSET_L3_SRC_IP4},
+ {I40E_INSET_IPV4_DST, I40E_X722_REG_INSET_L3_DST_IP4},
+ {I40E_INSET_IPV4_PROTO, I40E_X722_REG_INSET_L3_IP4_PROTO},
+ {I40E_INSET_IPV4_TTL, I40E_X722_REG_INSET_L3_IP4_TTL},
+ };
+#endif
+
+ static const struct {
+ uint64_t inset;
+ uint64_t inset_reg;
+ } inset_map_diff_not_x722[] = {
+ {I40E_INSET_IPV4_SRC, I40E_REG_INSET_L3_SRC_IP4},
+ {I40E_INSET_IPV4_DST, I40E_REG_INSET_L3_DST_IP4},
+ {I40E_INSET_IPV4_PROTO, I40E_REG_INSET_L3_IP4_PROTO},
+ {I40E_INSET_IPV4_TTL, I40E_REG_INSET_L3_IP4_TTL},
+ };
if (input == 0)
return val;
/* Translate input set to register aware inset */
- for (i = 0; i < RTE_DIM(inset_map); i++) {
- if (input & inset_map[i].inset)
- val |= inset_map[i].inset_reg;
+#ifdef X722_SUPPORT
+ if (type == I40E_MAC_X722) {
+ for (i = 0; i < RTE_DIM(inset_map_diff_x722); i++) {
+ if (input & inset_map_diff_x722[i].inset)
+ val |= inset_map_diff_x722[i].inset_reg;
+ }
+ } else {
+ for (i = 0; i < RTE_DIM(inset_map_diff_not_x722); i++) {
+ if (input & inset_map_diff_not_x722[i].inset)
+ val |= inset_map_diff_not_x722[i].inset_reg;
+ }
+ }
+#else
+ for (i = 0; i < RTE_DIM(inset_map_diff_not_x722); i++) {
+ if (input & inset_map_diff_not_x722[i].inset)
+ val |= inset_map_diff_not_x722[i].inset_reg;
+ }
+#endif
+ for (i = 0; i < RTE_DIM(inset_map_common); i++) {
+ if (input & inset_map_common[i].inset)
+ val |= inset_map_common[i].inset_reg;
}
-
return val;
}
@@ -7719,7 +7765,8 @@ i40e_filter_input_set_init(struct i40e_pf *pf)
I40E_INSET_MASK_NUM_REG);
if (num < 0)
return;
- inset_reg = i40e_translate_input_set_reg(input_set);
+ inset_reg = i40e_translate_input_set_reg(hw->mac.type,
+ input_set);
i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 0),
(uint32_t)(inset_reg & UINT32_MAX));
@@ -7810,7 +7857,7 @@ i40e_hash_filter_inset_select(struct i40e_hw *hw,
if (num < 0)
return -EINVAL;
- inset_reg |= i40e_translate_input_set_reg(input_set);
+ inset_reg |= i40e_translate_input_set_reg(hw->mac.type, input_set);
i40e_check_write_reg(hw, I40E_GLQF_HASH_INSET(0, pctype),
(uint32_t)(inset_reg & UINT32_MAX));
@@ -7888,7 +7935,7 @@ i40e_fdir_filter_inset_select(struct i40e_pf *pf,
if (num < 0)
return -EINVAL;
- inset_reg |= i40e_translate_input_set_reg(input_set);
+ inset_reg |= i40e_translate_input_set_reg(hw->mac.type, input_set);
i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 0),
(uint32_t)(inset_reg & UINT32_MAX));
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v4 11/17] eal/soc: add default scan for Soc devices
From: Shreyansh Jain @ 2016-10-16 7:12 UTC (permalink / raw)
To: Jan Viktorin
Cc: dev@dpdk.org, thomas.monjalon@6wind.com, david.marchand@6wind.com
In-Reply-To: <20161016025658.5182b5b9@jvn>
Hi Jan,
> -----Original Message-----
> From: Jan Viktorin [mailto:viktorin@rehivetech.com]
> Sent: Sunday, October 16, 2016 6:27 AM
> To: Shreyansh Jain <shreyansh.jain@nxp.com>
> Cc: dev@dpdk.org; thomas.monjalon@6wind.com; david.marchand@6wind.com
> Subject: Re: [PATCH v4 11/17] eal/soc: add default scan for Soc devices
>
> On Sat, 15 Oct 2016 19:15:02 +0530
> Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>
> > From: Jan Viktorin <viktorin@rehivetech.com>
> >
> > Default implementation which scans the sysfs platform devices hierarchy.
> > For each device, extract the ueven and convert into rte_soc_device.
> >
> > The information populated can then be used in probe to match against
> > the drivers registered.
> >
> > Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
> > [Shreyansh: restructure commit to be an optional implementation]
> > Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
>
> [...]
>
> > +
> > +int
> > +rte_eal_soc_scan(void)
>
> What about naming it rte_eal_soc_scan_default? This would underline the
> fact that this function can be replaced.
Yes, that would be in sync with match default. I will do it.
>
> Second, this is for the 7/17 patch:
>
> -/* register a driver */
> void
> rte_eal_soc_register(struct rte_soc_driver *driver)
> {
> + /* For a valid soc driver, match and scan function
> + * should be provided.
> + */
> + RTE_VERIFY(driver != NULL);
> + RTE_VERIFY(driver->match_fn != NULL);
> + RTE_VERIFY(driver->scan_fn != NULL);
>
> What about setting the match_fn and scan_fn to default implementations if
> they
> are NULL? This would make the standard/default approach easier to use.
>
> TAILQ_INSERT_TAIL(&soc_driver_list, driver, next);
> }
I am not in favor of a forced default. What if user never intended it - it would lead to wrong scan being used and only intimation which can provided to user is a log.
Selecting such functions should be a model of PMD - one which is enforced.
>
> > +{
> > + struct dirent *e;
> > + DIR *dir;
> > + char dirname[PATH_MAX];
> > +
> > + dir = opendir(soc_get_sysfs_path());
> > + if (dir == NULL) {
> > + RTE_LOG(ERR, EAL, "%s(): opendir failed: %s\n",
> > + __func__, strerror(errno));
> > + return -1;
> > + }
> > +
> > + while ((e = readdir(dir)) != NULL) {
> > + if (e->d_name[0] == '.')
> > + continue;
> > +
> > + snprintf(dirname, sizeof(dirname), "%s/%s",
> > + soc_get_sysfs_path(), e->d_name);
> > + if (soc_scan_one(dirname, e->d_name) < 0)
> > + goto error;
> > + }
> > + closedir(dir);
> > + return 0;
> > +
> > +error:
> > + closedir(dir);
> > + return -1;
> > +}
> > +
> > /* Init the SoC EAL subsystem */
> > int
> > rte_eal_soc_init(void)
>
>
>
> --
> Jan Viktorin E-mail: Viktorin@RehiveTech.com
> System Architect Web: www.RehiveTech.com
> RehiveTech
> Brno, Czech Republic
Thanks for your quick comments.
I have not yet taken all the inputs you had provided in review of v3 - I will be replying to those soon marking out what I have taken and what I have not.
-
Shreyansh
^ permalink raw reply
* Re: [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
From: Ananyev, Konstantin @ 2016-10-16 13:31 UTC (permalink / raw)
To: Guo, Jia, Zhang, Helin, Wu, Jingjing; +Cc: dev@dpdk.org, Guo, Jia
In-Reply-To: <1476582005-110811-1-git-send-email-jia.guo@intel.com>
Hi Jeff,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jeff Guo
> Sent: Sunday, October 16, 2016 2:40 AM
> To: Zhang, Helin <helin.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>
> Subject: [dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
>
> Since some register only be supported by X722 but may not be supported
> by other NICs, so add X722 macro to distinguish that to avoid compile error
> when the X722 macro is undefined.
Two probably silly questions:
1) So who will setup X722_SUPPORT macro?
Is that a user responsibility when he is building dpdk i40e PMD?
If so, why it is not a rte_config option?
2) Why this all has to be build time decision?
Why nor run-time?
Why i40e driver can't support all devices (including x722)
and invoke different config functions (write different registers)
based on device type/id information?
As it does for other device types/ids?
Konstantin
>
> Fixes: d0a349409bd7 (“i40e: support AQ based RSS config”)
> Fixes: 001a1c0f98f4 ("ethdev: get registers width")
> Fixes: a0454b5d2e08 (“i40e: update device ids”)
> Fixes: 647d1eaf758b (“i40evf: support AQ based RSS config”)
> Fixes: 3058891a2b02 (“net/i40e: move PCI device ids to the driver”)
> Fixes: d9efd0136ac1 (“i40e: add EEPROM and registers dumping”)
> Signed-off-by: Jeff Guo <jia.guo@intel.com>
>
> ---
> v2:
> fix compile error when x722 macro is not define.
> ---
> drivers/net/i40e/i40e_ethdev.c | 36 ++++++++++++++-
> drivers/net/i40e/i40e_ethdev.h | 17 +++++++
> drivers/net/i40e/i40e_ethdev_vf.c | 27 +++++++++++
> drivers/net/i40e/i40e_regs.h | 96 +++++++++++++++++++++++++++++++++++++++
> drivers/net/i40e/i40e_rxtx.c | 18 +++++++-
> 5 files changed, 191 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index d0640b9..920fd6d 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -468,13 +468,17 @@ static const struct rte_pci_id pci_id_i40e_map[] = {
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T4) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_B) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_SFP28) },
> +#ifdef X722_SUPPORT
> +#ifdef X722_A0_SUPPORT
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0) },
> +#endif /* X722_A0_SUPPORT */
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_X722) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_X722) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_X722) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_1G_BASE_T_X722) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T_X722) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_I_X722) },
> +#endif /* X722_SUPPORT */
> { .vendor_id = 0, /* sentinel */ },
> };
>
> @@ -3182,6 +3186,7 @@ i40e_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
> if (!lut)
> return -EINVAL;
>
> +#ifdef X722_SUPPORT
> if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
> ret = i40e_aq_get_rss_lut(hw, vsi->vsi_id, TRUE,
> lut, lut_size);
> @@ -3190,12 +3195,15 @@ i40e_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
> return ret;
> }
> } else {
> +#endif /* X722_SUPPORT */
> uint32_t *lut_dw = (uint32_t *)lut;
> uint16_t i, lut_size_dw = lut_size / 4;
>
> for (i = 0; i < lut_size_dw; i++)
> lut_dw[i] = I40E_READ_REG(hw, I40E_PFQF_HLUT(i));
> +#ifdef X722_SUPPORT
> }
> +#endif /* X722_SUPPORT */
>
> return 0;
> }
> @@ -3213,6 +3221,7 @@ i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
> pf = I40E_VSI_TO_PF(vsi);
> hw = I40E_VSI_TO_HW(vsi);
>
> +#ifdef X722_SUPPORT
> if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
> ret = i40e_aq_set_rss_lut(hw, vsi->vsi_id, TRUE,
> lut, lut_size);
> @@ -3221,13 +3230,16 @@ i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
> return ret;
> }
> } else {
> +#endif /* X722_SUPPORT */
> uint32_t *lut_dw = (uint32_t *)lut;
> uint16_t i, lut_size_dw = lut_size / 4;
>
> for (i = 0; i < lut_size_dw; i++)
> I40E_WRITE_REG(hw, I40E_PFQF_HLUT(i), lut_dw[i]);
> I40E_WRITE_FLUSH(hw);
> +#ifdef X722_SUPPORT
> }
> +#endif /* X722_SUPPORT */
>
> return 0;
> }
> @@ -3508,8 +3520,10 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
> pf->lan_nb_qps = 1;
> } else {
> pf->flags |= I40E_FLAG_RSS;
> +#ifdef X722_SUPPORT
> if (hw->mac.type == I40E_MAC_X722)
> pf->flags |= I40E_FLAG_RSS_AQ_CAPABLE;
> +#endif /* X722_SUPPORT */
> pf->lan_nb_qps = pf->lan_nb_qp_max;
> }
> qp_count += pf->lan_nb_qps;
> @@ -6302,6 +6316,7 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len)
> return -EINVAL;
> }
>
> +#ifdef X722_SUPPORT
> if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
> struct i40e_aqc_get_set_rss_key_data *key_dw =
> (struct i40e_aqc_get_set_rss_key_data *)key;
> @@ -6311,13 +6326,16 @@ i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len)
> PMD_INIT_LOG(ERR, "Failed to configure RSS key "
> "via AQ");
> } else {
> +#endif /* X722_SUPPORT */
> uint32_t *hash_key = (uint32_t *)key;
> uint16_t i;
>
> for (i = 0; i <= I40E_PFQF_HKEY_MAX_INDEX; i++)
> i40e_write_rx_ctl(hw, I40E_PFQF_HKEY(i), hash_key[i]);
> I40E_WRITE_FLUSH(hw);
> +#ifdef X722_SUPPORT
> }
> +#endif /* X722_SUPPORT */
>
> return ret;
> }
> @@ -6332,6 +6350,7 @@ i40e_get_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t *key_len)
> if (!key || !key_len)
> return -EINVAL;
>
> +#ifdef X722_SUPPORT
> if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
> ret = i40e_aq_get_rss_key(hw, vsi->vsi_id,
> (struct i40e_aqc_get_set_rss_key_data *)key);
> @@ -6340,12 +6359,16 @@ i40e_get_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t *key_len)
> return ret;
> }
> } else {
> +#endif /* X722_SUPPORT */
> uint32_t *key_dw = (uint32_t *)key;
> uint16_t i;
>
> for (i = 0; i <= I40E_PFQF_HKEY_MAX_INDEX; i++)
> key_dw[i] = i40e_read_rx_ctl(hw, I40E_PFQF_HKEY(i));
> +#ifdef X722_SUPPORT
> }
> +#endif /* X722_SUPPORT */
> +
> *key_len = (I40E_PFQF_HKEY_MAX_INDEX + 1) * sizeof(uint32_t);
>
> return 0;
> @@ -9610,8 +9633,17 @@ static int i40e_get_regs(struct rte_eth_dev *dev,
> const struct i40e_reg_info *reg_info;
>
> if (ptr_data == NULL) {
> - regs->length = I40E_GLGEN_STAT_CLEAR + 4;
> - regs->width = sizeof(uint32_t);
> +#ifdef X722_SUPPORT
> + if (hw->mac.type == I40E_MAC_X722) {
> + regs->length = I40E_GLGEN_STAT_CLEAR + 4;
> +#else
> + regs->length = I40E_GLVEBVL_BPCH(
> + I40E_GLVEBVL_BPCH_MAX_INDEX) + 0x8;
> +#endif /* X722_SUPPORT */
> + regs->width = sizeof(uint32_t);
> +#ifdef X722_SUPPORT
> + }
> +#endif /* X722_SUPPORT */
> return 0;
> }
>
> diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
> index 57a8ae1..43711b8 100644
> --- a/drivers/net/i40e/i40e_ethdev.h
> +++ b/drivers/net/i40e/i40e_ethdev.h
> @@ -125,7 +125,10 @@ enum i40e_flxpld_layer_idx {
> #define I40E_FLAG_HEADER_SPLIT_ENABLED (1ULL << 5)
> #define I40E_FLAG_FDIR (1ULL << 6)
> #define I40E_FLAG_VXLAN (1ULL << 7)
> +#ifdef X722_SUPPORT
> #define I40E_FLAG_RSS_AQ_CAPABLE (1ULL << 8)
> +#endif /* X722_SUPPORT */
> +#ifdef X722_SUPPORT
> #define I40E_FLAG_ALL (I40E_FLAG_RSS | \
> I40E_FLAG_DCB | \
> I40E_FLAG_VMDQ | \
> @@ -135,6 +138,16 @@ enum i40e_flxpld_layer_idx {
> I40E_FLAG_FDIR | \
> I40E_FLAG_VXLAN | \
> I40E_FLAG_RSS_AQ_CAPABLE)
> +#else
> +#define I40E_FLAG_ALL (I40E_FLAG_RSS | \
> + I40E_FLAG_DCB | \
> + I40E_FLAG_VMDQ | \
> + I40E_FLAG_SRIOV | \
> + I40E_FLAG_HEADER_SPLIT_DISABLED | \
> + I40E_FLAG_HEADER_SPLIT_ENABLED | \
> + I40E_FLAG_FDIR | \
> + I40E_FLAG_VXLAN)
> +#endif /* X722_SUPPORT */
>
> #define I40E_RSS_OFFLOAD_ALL ( \
> ETH_RSS_FRAG_IPV4 | \
> @@ -650,7 +663,11 @@ i40e_get_vsi_from_adapter(struct i40e_adapter *adapter)
> return NULL;
>
> hw = I40E_DEV_PRIVATE_TO_HW(adapter);
> +#ifdef X722_SUPPORT
> if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF) {
> +#else
> + if (hw->mac.type == I40E_MAC_VF) {
> +#endif /* X722_SUPPORT */
> struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(adapter);
> return &vf->vsi;
> } else {
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
> index 34eb274..aab9cae 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -1112,9 +1112,17 @@ i40evf_get_link_status(struct rte_eth_dev *dev, struct rte_eth_link *link)
> static const struct rte_pci_id pci_id_i40evf_map[] = {
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF_HV) },
> +#ifdef X722_SUPPORT
> +#ifdef X722_A0_SUPPORT
> +#if defined(INTEGRATED_VF) || defined(VF_DRIVER)
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0_VF) },
> +#endif /* INTEGRATED_VF || VF_DRIVER */
> +#endif /* X722_A0_SUPPORT */
> +#if defined(INTEGRATED_VF) || defined(VF_DRIVER) || defined(I40E_NDIS_SUPPORT)
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF) },
> { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF_HV) },
> +#endif /* INTEGRATED_VF || VF_DRIVER || I40E_NDIS_SUPPORT */
> +#endif /* X722_SUPPORT */
> { .vendor_id = 0, /* sentinel */ },
> };
>
> @@ -1277,8 +1285,10 @@ i40evf_init_vf(struct rte_eth_dev *dev)
> goto err_alloc;
> }
>
> +#ifdef X722_SUPPORT
> if (hw->mac.type == I40E_MAC_X722_VF)
> vf->flags = I40E_FLAG_RSS_AQ_CAPABLE;
> +#endif /* X722_SUPPORT */
> vf->vsi.vsi_id = vf->vsi_res->vsi_id;
> vf->vsi.type = vf->vsi_res->vsi_type;
> vf->vsi.nb_qps = vf->vsi_res->num_queue_pairs;
> @@ -2340,6 +2350,7 @@ i40evf_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
> if (!lut)
> return -EINVAL;
>
> +#ifdef X722_SUPPORT
> if (vf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
> ret = i40e_aq_get_rss_lut(hw, vsi->vsi_id, FALSE,
> lut, lut_size);
> @@ -2348,12 +2359,15 @@ i40evf_get_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
> return ret;
> }
> } else {
> +#endif /* X722_SUPPORT */
> uint32_t *lut_dw = (uint32_t *)lut;
> uint16_t i, lut_size_dw = lut_size / 4;
>
> for (i = 0; i < lut_size_dw; i++)
> lut_dw[i] = I40E_READ_REG(hw, I40E_VFQF_HLUT(i));
> +#ifdef X722_SUPPORT
> }
> +#endif /* X722_SUPPORT */
>
> return 0;
> }
> @@ -2371,6 +2385,7 @@ i40evf_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
> vf = I40E_VSI_TO_VF(vsi);
> hw = I40E_VSI_TO_HW(vsi);
>
> +#ifdef X722_SUPPORT
> if (vf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
> ret = i40e_aq_set_rss_lut(hw, vsi->vsi_id, FALSE,
> lut, lut_size);
> @@ -2379,13 +2394,16 @@ i40evf_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size)
> return ret;
> }
> } else {
> +#endif /* X722_SUPPORT */
> uint32_t *lut_dw = (uint32_t *)lut;
> uint16_t i, lut_size_dw = lut_size / 4;
>
> for (i = 0; i < lut_size_dw; i++)
> I40E_WRITE_REG(hw, I40E_VFQF_HLUT(i), lut_dw[i]);
> I40EVF_WRITE_FLUSH(hw);
> +#ifdef X722_SUPPORT
> }
> +#endif /* X722_SUPPORT */
>
> return 0;
> }
> @@ -2484,6 +2502,7 @@ i40evf_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len)
> return -EINVAL;
> }
>
> +#ifdef X722_SUPPORT
> if (vf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
> struct i40e_aqc_get_set_rss_key_data *key_dw =
> (struct i40e_aqc_get_set_rss_key_data *)key;
> @@ -2493,13 +2512,16 @@ i40evf_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len)
> PMD_INIT_LOG(ERR, "Failed to configure RSS key "
> "via AQ");
> } else {
> +#endif /* X722_SUPPORT */
> uint32_t *hash_key = (uint32_t *)key;
> uint16_t i;
>
> for (i = 0; i <= I40E_VFQF_HKEY_MAX_INDEX; i++)
> i40e_write_rx_ctl(hw, I40E_VFQF_HKEY(i), hash_key[i]);
> I40EVF_WRITE_FLUSH(hw);
> +#ifdef X722_SUPPORT
> }
> +#endif /* X722_SUPPORT */
>
> return ret;
> }
> @@ -2514,6 +2536,7 @@ i40evf_get_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t *key_len)
> if (!key || !key_len)
> return -EINVAL;
>
> +#ifdef X722_SUPPORT
> if (vf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
> ret = i40e_aq_get_rss_key(hw, vsi->vsi_id,
> (struct i40e_aqc_get_set_rss_key_data *)key);
> @@ -2522,12 +2545,16 @@ i40evf_get_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t *key_len)
> return ret;
> }
> } else {
> +#endif /* X722_SUPPORT */
> uint32_t *key_dw = (uint32_t *)key;
> uint16_t i;
>
> for (i = 0; i <= I40E_VFQF_HKEY_MAX_INDEX; i++)
> key_dw[i] = i40e_read_rx_ctl(hw, I40E_VFQF_HKEY(i));
> +#ifdef X722_SUPPORT
> }
> +#endif /* X722_SUPPORT */
> +
> *key_len = (I40E_VFQF_HKEY_MAX_INDEX + 1) * sizeof(uint32_t);
>
> return 0;
> diff --git a/drivers/net/i40e/i40e_regs.h b/drivers/net/i40e/i40e_regs.h
> index 472c7a0..7be6ce3 100644
> --- a/drivers/net/i40e/i40e_regs.h
> +++ b/drivers/net/i40e/i40e_regs.h
> @@ -52,7 +52,9 @@ static const struct i40e_reg_info i40e_regs_adminq[] = {
> {I40E_VSILAN_QBASE(0), 383, 4, 0, 0, "VSILAN_QBASE"},
> {I40E_VSIQF_CTL(0), 383, 4, 0, 0, "VSIQF_CTL"},
> {I40E_PFQF_HKEY(0), 12, 128, 0, 0, "PFQF_HKEY"},
> +#ifdef X722_SUPPORT
> {I40E_PFQF_HREGION(0), 7, 128, 0, 0, "PFQF_HREGION"},
> +#endif
> {I40E_PFQF_HENA(0), 1, 128, 0, 0, "PFQF_HENA"},
> {I40E_PFQF_FDALLOC, 0, 0, 0, 0, "PFQF_FDALLOC"},
> {I40E_PRTQF_FD_INSET(0, 0), 63, 64, 1, 32, "PRTQF_FD_INSET"},
> @@ -60,9 +62,11 @@ static const struct i40e_reg_info i40e_regs_adminq[] = {
> {I40E_PRTQF_FD_MSK(0, 0), 63, 64, 1, 32, "PRTQF_FD_MSK"},
> {I40E_PRTQF_FD_FLXINSET(0), 63, 32, 0, 0, "PRTQF_FD_FLXINSET"},
> {I40E_PRTQF_CTL_0, 0, 0, 0, 0, "PRTQF_CTL_0"},
> +#ifdef X722_SUPPORT
> {I40E_GLQF_FD_MSK(0, 0), 1, 4, 63, 8, "GLQF_FD_MSK"},
> {I40E_GLQF_HASH_INSET(0, 0), 1, 4, 63, 8, "GLQF_HASH_INSET"},
> {I40E_GLQF_HASH_MSK(0, 0), 1, 4, 63, 8, "GLQF_HASH_MSK"},
> +#endif
> {I40E_GLQF_SWAP(0, 0), 1, 4, 63, 8, "GLQF_SWAP"},
> {I40E_GLFCOE_RCTL, 0, 0, 0, 0, "GLFCOE_RCTL"},
> {I40E_GLQF_CTL, 0, 0, 0, 0, "GLQF_CTL"},
> @@ -72,6 +76,7 @@ static const struct i40e_reg_info i40e_regs_adminq[] = {
>
> static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_QTX_TAIL1(0), 15, 4, 0, 0, "QTX_TAIL1"},
> +#ifdef X722_SUPPORT
> {I40E_VFPE_CQPDB(0), 127, 4, 0, 0, "VFPE_CQPDB"},
> {I40E_VFPE_CQPTAIL(0), 127, 4, 0, 0, "VFPE_CQPTAIL"},
> {I40E_VFPE_CCQPSTATUS(0), 127, 4, 0, 0, "VFPE_CCQPSTATUS"},
> @@ -79,12 +84,15 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_VFPE_CCQPHIGH(0), 127, 4, 0, 0, "VFPE_CCQPHIGH"},
> {I40E_VFPE_IPCONFIG0(0), 127, 4, 0, 0, "VFPE_IPCONFIG0"},
> {I40E_VFPE_CQPERRCODES(0), 127, 4, 0, 0, "VFPE_CQPERRCODES"},
> +#endif
> {I40E_QRX_TAIL1(0), 15, 4, 0, 0, "QRX_TAIL1"},
> {I40E_VFINT_ITRN1(0, 0), 2, 64, 15, 4, "VFINT_ITRN1"},
> +#ifdef X722_SUPPORT
> {I40E_VFPE_TCPNOWTIMER(0), 127, 4, 0, 0, "VFPE_TCPNOWTIMER"},
> {I40E_VFPE_MRTEIDXMASK(0), 127, 4, 0, 0, "VFPE_MRTEIDXMASK"},
> {I40E_VFPE_RCVUNEXPECTEDERROR(0), 127, 4, 0, 0,
> "VFPE_RCVUNEXPECTEDERROR"},
> +#endif
> {I40E_VFINT_DYN_CTLN1(0), 15, 4, 0, 0, "VFINT_DYN_CTLN1"},
> {I40E_VFINT_ICR01, 0, 0, 0, 0, "VFINT_ICR01"},
> {I40E_VFINT_ITR01(0), 2, 4, 0, 0, "VFINT_ITR01"},
> @@ -100,19 +108,24 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_VF_ATQBAH1, 0, 0, 0, 0, "VF_ATQBAH1"},
> {I40E_VF_ATQBAL1, 0, 0, 0, 0, "VF_ATQBAL1"},
> {I40E_VF_ARQLEN1, 0, 0, 0, 0, "VF_ARQLEN1"},
> +#ifdef X722_SUPPORT
> {I40E_PFPE_CQPDB, 0, 0, 0, 0, "PFPE_CQPDB"},
> {I40E_PFPE_CQPTAIL, 0, 0, 0, 0, "PFPE_CQPTAIL"},
> {I40E_PFPE_CCQPSTATUS, 0, 0, 0, 0, "PFPE_CCQPSTATUS"},
> {I40E_PFPE_CCQPLOW, 0, 0, 0, 0, "PFPE_CCQPLOW"},
> {I40E_PFPE_CCQPHIGH, 0, 0, 0, 0, "PFPE_CCQPHIGH"},
> {I40E_PFPE_IPCONFIG0, 0, 0, 0, 0, "PFPE_IPCONFIG0"},
> +#endif
> {I40E_VF_ATQT1, 0, 0, 0, 0, "VF_ATQT1"},
> +#ifdef X722_SUPPORT
> {I40E_PFPE_TCPNOWTIMER, 0, 0, 0, 0, "PFPE_TCPNOWTIMER"},
> {I40E_PFPE_MRTEIDXMASK, 0, 0, 0, 0, "PFPE_MRTEIDXMASK"},
> {I40E_PFPE_RCVUNEXPECTEDERROR, 0, 0, 0, 0, "PFPE_RCVUNEXPECTEDERROR"},
> {I40E_PFPE_UDACTRL, 0, 0, 0, 0, "PFPE_UDACTRL"},
> {I40E_PFPE_UDAUCFBQPN, 0, 0, 0, 0, "PFPE_UDAUCFBQPN"},
> +#endif
> {I40E_VFGEN_RSTAT, 0, 0, 0, 0, "VFGEN_RSTAT"},
> +#ifdef X722_SUPPORT
> {I40E_PFPE_CQPERRCODES, 0, 0, 0, 0, "PFPE_CQPERRCODES"},
> {I40E_PFPE_FLMXMITALLOCERR, 0, 0, 0, 0, "PFPE_FLMXMITALLOCERR"},
> {I40E_PFPE_FLMQ1ALLOCERR, 0, 0, 0, 0, "PFPE_FLMQ1ALLOCERR"},
> @@ -134,7 +147,9 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLPE_VFUDAUCFBQPN(0), 31, 4, 0, 0, "GLPE_VFUDAUCFBQPN"},
> {I40E_GLPE_VFFLMXMITALLOCERR(0), 31, 4, 0, 0, "GLPE_VFFLMXMITALLOCERR"},
> {I40E_GLPE_VFFLMQ1ALLOCERR(0), 31, 4, 0, 0, "GLPE_VFFLMQ1ALLOCERR"},
> +#endif
> {I40E_VFQF_HLUT(0), 15, 4, 0, 0, "VFQF_HLUT"},
> +#ifdef X722_SUPPORT
> {I40E_GLPE_CPUSTATUS0, 0, 0, 0, 0, "GLPE_CPUSTATUS0"},
> {I40E_GLPE_CPUSTATUS1, 0, 0, 0, 0, "GLPE_CPUSTATUS1"},
> {I40E_GLPE_CPUSTATUS2, 0, 0, 0, 0, "GLPE_CPUSTATUS2"},
> @@ -158,8 +173,10 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_PRTPE_RUPM_CNTR, 0, 0, 0, 0, "PRTPE_RUPM_CNTR"},
> {I40E_PRTPE_RUPM_PTXTCCNTR03, 0, 0, 0, 0, "PRTPE_RUPM_PTXTCCNTR03"},
> {I40E_PRTPE_RUPM_PTCTCCNTR47, 0, 0, 0, 0, "PRTPE_RUPM_PTCTCCNTR47"},
> +#endif
> {I40E_VFCM_PE_ERRDATA, 0, 0, 0, 0, "VFCM_PE_ERRDATA"},
> {I40E_PFPCI_VF_FLUSH_DONE, 0, 0, 0, 0, "PFPCI_VF_FLUSH_DONE"},
> +#ifdef X722_SUPPORT
> {I40E_GLPES_PFRXVLANERR(0), 15, 4, 0, 0, "GLPES_PFRXVLANERR"},
> {I40E_GLPES_PFIP4RXOCTSLO(0), 15, 8, 0, 0, "GLPES_PFIP4RXOCTSLO"},
> {I40E_GLPES_PFIP4RXOCTSHI(0), 15, 8, 0, 0, "GLPES_PFIP4RXOCTSHI"},
> @@ -333,6 +350,7 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_PRTDCB_TCMSTC_RLPM(0), 7, 32, 0, 0, "PRTDCB_TCMSTC_RLPM"},
> {I40E_PRTDCB_RLPMC, 0, 0, 0, 0, "PRTDCB_RLPMC"},
> {I40E_PRTDCB_TCPMC_RLPM, 0, 0, 0, 0, "PRTDCB_TCPMC_RLPM"},
> +#endif
> {I40E_VFINT_ITRN(0, 0), 2, 2048, 511, 4, "VFINT_ITRN"},
> {I40E_VFINT_DYN_CTLN(0), 511, 4, 0, 0, "VFINT_DYN_CTLN"},
> {I40E_VPINT_LNKLSTN(0), 511, 4, 0, 0, "VPINT_LNKLSTN"},
> @@ -376,7 +394,9 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_VPLAN_QTABLE(0, 0), 15, 1024, 127, 4, "VPLAN_QTABLE"},
> {I40E_VPLAN_MAPENA(0), 127, 4, 0, 0, "VPLAN_MAPENA"},
> {I40E_VFGEN_RSTAT1(0), 127, 4, 0, 0, "VFGEN_RSTAT1"},
> +#ifdef X722_SUPPORT
> {I40E_VPLAN_QBASE(0), 127, 4, 0, 0, "VPLAN_QBASE"},
> +#endif
> {I40E_PF_ATQBAL, 0, 0, 0, 0, "PF_ATQBAL"},
> {I40E_GL_ATQBAL, 0, 0, 0, 0, "GL_ATQBAL"},
> {I40E_PF_ARQBAL, 0, 0, 0, 0, "PF_ARQBAL"},
> @@ -411,8 +431,10 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLDCB_GENC, 0, 0, 0, 0, "GLDCB_GENC"},
> {I40E_GL_FWSTS, 0, 0, 0, 0, "GL_FWSTS"},
> {I40E_GL_FWRESETCNT, 0, 0, 0, 0, "GL_FWRESETCNT"},
> +#ifdef X722_SUPPORT
> {I40E_GL_VF_CTRL_TX(0), 127, 4, 0, 0, "GL_VF_CTRL_TX"},
> {I40E_GL_VF_CTRL_RX(0), 127, 4, 0, 0, "GL_VF_CTRL_RX"},
> +#endif
> {I40E_PRTTSYN_CTL1, 0, 0, 0, 0, "PRTTSYN_CTL1"},
> {I40E_PRTTSYN_RXTIME_H(0), 3, 32, 0, 0, "PRTTSYN_RXTIME_H"},
> {I40E_PRTTSYN_RXTIME_L(0), 3, 32, 0, 0, "PRTTSYN_RXTIME_L"},
> @@ -420,10 +442,14 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_PRT_MNG_FTFT_MASK(0), 7, 32, 0, 0, "PRT_MNG_FTFT_MASK"},
> {I40E_PRT_MNG_FTFT_LENGTH, 0, 0, 0, 0, "PRT_MNG_FTFT_LENGTH"},
> {I40E_PRT_MNG_FTFT_DATA(0), 31, 32, 0, 0, "PRT_MNG_FTFT_DATA"},
> +#ifdef X722_SUPPORT
> {I40E_GL_PPRS_SPARE, 0, 0, 0, 0, "GL_PPRS_SPARE"},
> +#endif
> {I40E_PFGEN_STATE, 0, 0, 0, 0, "PFGEN_STATE"},
> {I40E_PFINT_GPIO_ENA, 0, 0, 0, 0, "PFINT_GPIO_ENA"},
> +#ifdef X722_SUPPORT
> {I40E_GLGEN_MISC_SPARE, 0, 0, 0, 0, "GLGEN_MISC_SPARE"},
> +#endif
> {I40E_GLGEN_GPIO_CTL(0), 29, 4, 0, 0, "GLGEN_GPIO_CTL"},
> {I40E_GLGEN_LED_CTL, 0, 0, 0, 0, "GLGEN_LED_CTL"},
> {I40E_GLGEN_GPIO_STAT, 0, 0, 0, 0, "GLGEN_GPIO_STAT"},
> @@ -470,6 +496,7 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLPCI_PM_MUX_NPQ, 0, 0, 0, 0, "GLPCI_PM_MUX_NPQ"},
> {I40E_GLPCI_SPARE_BITS_0, 0, 0, 0, 0, "GLPCI_SPARE_BITS_0"},
> {I40E_GLPCI_SPARE_BITS_1, 0, 0, 0, 0, "GLPCI_SPARE_BITS_1"},
> +#ifdef X722_SUPPORT
> {I40E_GLPCI_CUR_RLAN_ALWD, 0, 0, 0, 0, "GLPCI_CUR_RLAN_ALWD"},
> {I40E_GLPCI_CUR_TLAN_ALWD, 0, 0, 0, 0, "GLPCI_CUR_TLAN_ALWD"},
> {I40E_GLPCI_CUR_RXPE_ALWD, 0, 0, 0, 0, "GLPCI_CUR_RXPE_ALWD"},
> @@ -484,9 +511,11 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLPCI_CUR_PMAT_RSVD, 0, 0, 0, 0, "GLPCI_CUR_PMAT_RSVD"},
> {I40E_GLPCI_CUR_MNG_RSVD, 0, 0, 0, 0, "GLPCI_CUR_MNG_RSVD"},
> {I40E_GLPCI_CUR_TDPU_RSVD, 0, 0, 0, 0, "GLPCI_CUR_TDPU_RSVD"},
> +#endif
> {I40E_PFPCI_VF_FLUSH_DONE1(0), 127, 4, 0, 0, "PFPCI_VF_FLUSH_DONE1"},
> {I40E_PFPCI_PF_FLUSH_DONE, 0, 0, 0, 0, "PFPCI_PF_FLUSH_DONE"},
> {I40E_PFPCI_VM_FLUSH_DONE, 0, 0, 0, 0, "PFPCI_VM_FLUSH_DONE"},
> +#ifdef X722_SUPPORT
> {I40E_GLPCI_NPQ_CFG, 0, 0, 0, 0, "GLPCI_NPQ_CFG"},
> {I40E_GLPCI_CUR_CLNT_COMMON, 0, 0, 0, 0, "GLPCI_CUR_CLNT_COMMON"},
> {I40E_GLPCI_CUR_CLNT_PIPEMON, 0, 0, 0, 0, "GLPCI_CUR_CLNT_PIPEMON"},
> @@ -501,15 +530,20 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLPCI_WATMK_PMAT_ALWD, 0, 0, 0, 0, "GLPCI_WATMK_PMAT_ALWD"},
> {I40E_GLPCI_WATMK_MNG_ALWD, 0, 0, 0, 0, "GLPCI_WATMK_MNG_ALWD"},
> {I40E_GLPCI_WATMK_TPDU_ALWD, 0, 0, 0, 0, "GLPCI_WATMK_TPDU_ALWD"},
> +#endif
> {I40E_PRTDCB_TCMSTC(0), 7, 32, 0, 0, "PRTDCB_TCMSTC"},
> +#ifdef X722_SUPPORT
> {I40E_PRTDCB_TFMSTC(0), 7, 32, 0, 0, "PRTDCB_TFMSTC"},
> +#endif
> {I40E_PRTDCB_TDPMC, 0, 0, 0, 0, "PRTDCB_TDPMC"},
> {I40E_PRTDCB_TCWSTC(0), 7, 32, 0, 0, "PRTDCB_TCWSTC"},
> {I40E_PRTDCB_TCPMC, 0, 0, 0, 0, "PRTDCB_TCPMC"},
> +#ifdef X722_SUPPORT
> {I40E_GL_TUPM_SPARE, 0, 0, 0, 0, "GL_TUPM_SPARE"},
> {I40E_GLPEOC_CACHESIZE, 0, 0, 0, 0, "GLPEOC_CACHESIZE"},
> {I40E_GLPBLOC_CACHESIZE, 0, 0, 0, 0, "GLPBLOC_CACHESIZE"},
> {I40E_GLFOC_CACHESIZE, 0, 0, 0, 0, "GLFOC_CACHESIZE"},
> +#endif
> {I40E_PRTRPB_DHW(0), 7, 32, 0, 0, "PRTRPB_DHW"},
> {I40E_PRTRPB_DLW(0), 7, 32, 0, 0, "PRTRPB_DLW"},
> {I40E_PRTRPB_DPS(0), 7, 32, 0, 0, "PRTRPB_DPS"},
> @@ -536,6 +570,7 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLGEN_STAT, 0, 0, 0, 0, "GLGEN_STAT"},
> {I40E_GL_MNG_HWARB_CTRL, 0, 0, 0, 0, "GL_MNG_HWARB_CTRL"},
> {I40E_GL_MNG_FWSM, 0, 0, 0, 0, "GL_MNG_FWSM"},
> +#ifdef X722_SUPPORT
> {I40E_GLNVM_ALTIMERS, 0, 0, 0, 0, "GLNVM_ALTIMERS"},
> {I40E_GLNVM_ULT, 0, 0, 0, 0, "GLNVM_ULT"},
> {I40E_MEM_INIT_DONE_STAT, 0, 0, 0, 0, "MEM_INIT_DONE_STAT"},
> @@ -553,6 +588,7 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_MNGSB_WDATA, 0, 0, 0, 0, "MNGSB_WDATA"},
> {I40E_MNGSB_RHDR0, 0, 0, 0, 0, "MNGSB_RHDR0"},
> {I40E_MNGSB_RDATA, 0, 0, 0, 0, "MNGSB_RDATA"},
> +#endif
> {I40E_PFPM_APM, 0, 0, 0, 0, "PFPM_APM"},
> {I40E_PRTGEN_STATUS, 0, 0, 0, 0, "PRTGEN_STATUS"},
> {I40E_PRTGEN_CNF, 0, 0, 0, 0, "PRTGEN_CNF"},
> @@ -562,8 +598,10 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLGEN_CLKSTAT, 0, 0, 0, 0, "GLGEN_CLKSTAT"},
> {I40E_GLGEN_RSTAT, 0, 0, 0, 0, "GLGEN_RSTAT"},
> {I40E_GLGEN_RTRIG, 0, 0, 0, 0, "GLGEN_RTRIG"},
> +#ifdef X722_SUPPORT
> {I40E_GLGEN_PME_TO, 0, 0, 0, 0, "GLGEN_PME_TO"},
> {I40E_GLGEN_CAR_DEBUG, 0, 0, 0, 0, "GLGEN_CAR_DEBUG"},
> +#endif
> {I40E_PFPCI_CNF, 0, 0, 0, 0, "PFPCI_CNF"},
> {I40E_PFPCI_DEVID, 0, 0, 0, 0, "PFPCI_DEVID"},
> {I40E_PFPCI_SUBSYSID, 0, 0, 0, 0, "PFPCI_SUBSYSID"},
> @@ -589,7 +627,9 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLPCI_UPADD, 0, 0, 0, 0, "GLPCI_UPADD"},
> {I40E_GLPCI_PCIERR, 0, 0, 0, 0, "GLPCI_PCIERR"},
> {I40E_GLPCI_VENDORID, 0, 0, 0, 0, "GLPCI_VENDORID"},
> +#ifdef X722_SUPPORT
> {I40E_GL_UFUSE_SOC, 0, 0, 0, 0, "GL_UFUSE_SOC"},
> +#endif
> {I40E_PFHMC_SDCMD, 0, 0, 0, 0, "PFHMC_SDCMD"},
> {I40E_PFHMC_SDDATALOW, 0, 0, 0, 0, "PFHMC_SDDATALOW"},
> {I40E_PFHMC_SDDATAHIGH, 0, 0, 0, 0, "PFHMC_SDDATAHIGH"},
> @@ -597,7 +637,9 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_PFHMC_ERRORINFO, 0, 0, 0, 0, "PFHMC_ERRORINFO"},
> {I40E_PFHMC_ERRORDATA, 0, 0, 0, 0, "PFHMC_ERRORDATA"},
> {I40E_GLHMC_SDPART(0), 15, 4, 0, 0, "GLHMC_SDPART"},
> +#ifdef X722_SUPPORT
> {I40E_GLHMC_PFPESDPART(0), 15, 4, 0, 0, "GLHMC_PFPESDPART"},
> +#endif
> {I40E_GLHMC_PFASSIGN(0), 15, 4, 0, 0, "GLHMC_PFASSIGN"},
> {I40E_GLHMC_LANTXOBJSZ, 0, 0, 0, 0, "GLHMC_LANTXOBJSZ"},
> {I40E_GLHMC_LANQMAX, 0, 0, 0, 0, "GLHMC_LANQMAX"},
> @@ -605,6 +647,7 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLHMC_FCOEDDPOBJSZ, 0, 0, 0, 0, "GLHMC_FCOEDDPOBJSZ"},
> {I40E_GLHMC_FCOEMAX, 0, 0, 0, 0, "GLHMC_FCOEMAX"},
> {I40E_GLHMC_FCOEFOBJSZ, 0, 0, 0, 0, "GLHMC_FCOEFOBJSZ"},
> +#ifdef X722_SUPPORT
> {I40E_GLHMC_PEQPOBJSZ, 0, 0, 0, 0, "GLHMC_PEQPOBJSZ"},
> {I40E_GLHMC_PECQOBJSZ, 0, 0, 0, 0, "GLHMC_PECQOBJSZ"},
> {I40E_GLHMC_PESRQOBJSZ, 0, 0, 0, 0, "GLHMC_PESRQOBJSZ"},
> @@ -621,10 +664,12 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLHMC_PEQ1OBJSZ, 0, 0, 0, 0, "GLHMC_PEQ1OBJSZ"},
> {I40E_GLHMC_PEQ1MAX, 0, 0, 0, 0, "GLHMC_PEQ1MAX"},
> {I40E_GLHMC_PEQ1FLMAX, 0, 0, 0, 0, "GLHMC_PEQ1FLMAX"},
> +#endif
> {I40E_GLHMC_FSIMCOBJSZ, 0, 0, 0, 0, "GLHMC_FSIMCOBJSZ"},
> {I40E_GLHMC_FSIMCMAX, 0, 0, 0, 0, "GLHMC_FSIMCMAX"},
> {I40E_GLHMC_FSIAVOBJSZ, 0, 0, 0, 0, "GLHMC_FSIAVOBJSZ"},
> {I40E_GLHMC_FSIAVMAX, 0, 0, 0, 0, "GLHMC_FSIAVMAX"},
> +#ifdef X722_SUPPORT
> {I40E_GLHMC_PEPBLMAX, 0, 0, 0, 0, "GLHMC_PEPBLMAX"},
> {I40E_GLHMC_PETIMEROBJSZ, 0, 0, 0, 0, "GLHMC_PETIMEROBJSZ"},
> {I40E_GLHMC_PETIMERMAX, 0, 0, 0, 0, "GLHMC_PETIMERMAX"},
> @@ -695,11 +740,14 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLHMC_VFPETIMERBASE(0), 31, 4, 0, 0, "GLHMC_VFPETIMERBASE"},
> {I40E_GLHMC_VFPETIMERCNT(0), 31, 4, 0, 0, "GLHMC_VFPETIMERCNT"},
> {I40E_GLPDOC_CACHESIZE, 0, 0, 0, 0, "GLPDOC_CACHESIZE"},
> +#endif
> {I40E_QTX_HEAD(0), 1535, 4, 0, 0, "QTX_HEAD"},
> {I40E_VP_MDET_TX(0), 127, 4, 0, 0, "VP_MDET_TX"},
> {I40E_PF_MDET_TX, 0, 0, 0, 0, "PF_MDET_TX"},
> {I40E_GL_MDET_TX, 0, 0, 0, 0, "GL_MDET_TX"},
> +#ifdef X722_SUPPORT
> {I40E_GL_TLAN_SPARE, 0, 0, 0, 0, "GL_TLAN_SPARE"},
> +#endif
> {I40E_GLLAN_TXPRE_QDIS(0), 11, 4, 0, 0, "GLLAN_TXPRE_QDIS"},
> {I40E_QTX_ENA(0), 1535, 4, 0, 0, "QTX_ENA"},
> {I40E_QTX_CTL(0), 1535, 4, 0, 0, "QTX_CTL"},
> @@ -709,7 +757,9 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_PFCM_LANCTXDATA(0), 3, 128, 0, 0, "PFCM_LANCTXDATA"},
> {I40E_PFCM_LANCTXCTL, 0, 0, 0, 0, "PFCM_LANCTXCTL"},
> {I40E_PFCM_LANCTXSTAT, 0, 0, 0, 0, "PFCM_LANCTXSTAT"},
> +#ifdef X722_SUPPORT
> {I40E_GLCM_LAN_CACHESIZE, 0, 0, 0, 0, "GLCM_LAN_CACHESIZE"},
> +#endif
> {I40E_QRX_ENA(0), 1535, 4, 0, 0, "QRX_ENA"},
> {I40E_PRTDCB_RETSTCC(0), 7, 32, 0, 0, "PRTDCB_RETSTCC"},
> {I40E_PRTDCB_RPPMC, 0, 0, 0, 0, "PRTDCB_RPPMC"},
> @@ -721,6 +771,7 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_PF_MDET_RX, 0, 0, 0, 0, "PF_MDET_RX"},
> {I40E_GLLAN_RCTL_0, 0, 0, 0, 0, "GLLAN_RCTL_0"},
> {I40E_GL_MDET_RX, 0, 0, 0, 0, "GL_MDET_RX"},
> +#ifdef X722_SUPPORT
> {I40E_VFPE_CQARM(0), 127, 4, 0, 0, "VFPE_CQARM"},
> {I40E_VFPE_CQACK(0), 127, 4, 0, 0, "VFPE_CQACK"},
> {I40E_VFPE_AEQALLOC(0), 127, 4, 0, 0, "VFPE_AEQALLOC"},
> @@ -738,14 +789,17 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLPE_VFCEQEDROPCNT(0), 31, 4, 0, 0, "GLPE_VFCEQEDROPCNT"},
> {I40E_GLPE_VFAEQEDROPCNT(0), 31, 4, 0, 0, "GLPE_VFAEQEDROPCNT"},
> {I40E_VFPE_WQEALLOC(0), 127, 4, 0, 0, "VFPE_WQEALLOC"},
> +#endif
> {I40E_VFCM_PE_ERRINFO1(0), 127, 4, 0, 0, "VFCM_PE_ERRINFO1"},
> {I40E_VFCM_PE_ERRDATA1(0), 127, 4, 0, 0, "VFCM_PE_ERRDATA1"},
> +#ifdef X722_SUPPORT
> {I40E_PFPE_WQEALLOC, 0, 0, 0, 0, "PFPE_WQEALLOC"},
> {I40E_PFCM_PE_ERRINFO, 0, 0, 0, 0, "PFCM_PE_ERRINFO"},
> {I40E_PFCM_PE_ERRDATA, 0, 0, 0, 0, "PFCM_PE_ERRDATA"},
> {I40E_GLHMC_DBQPPART(0), 15, 4, 0, 0, "GLHMC_DBQPPART"},
> {I40E_GLHMC_VFDBQPPART(0), 31, 4, 0, 0, "GLHMC_VFDBQPPART"},
> {I40E_GLCM_PE_CACHESIZE, 0, 0, 0, 0, "GLCM_PE_CACHESIZE"},
> +#endif
> {I40E_PFGEN_PORTNUM, 0, 0, 0, 0, "PFGEN_PORTNUM"},
> {I40E_PF_VT_PFALLOC, 0, 0, 0, 0, "PF_VT_PFALLOC"},
> {I40E_PRTDCB_TC2PFC, 0, 0, 0, 0, "PRTDCB_TC2PFC"},
> @@ -756,8 +810,10 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_PRTGL_SAL, 0, 0, 0, 0, "PRTGL_SAL"},
> {I40E_PRTGL_SAH, 0, 0, 0, 0, "PRTGL_SAH"},
> {I40E_PRTDCB_MFLCN, 0, 0, 0, 0, "PRTDCB_MFLCN"},
> +#ifdef X722_SUPPORT
> {I40E_PRTMAC_LINK_DOWN_COUNTER, 0, 0, 0, 0,
> "PRTMAC_LINK_DOWN_COUNTER"},
> +#endif
> {I40E_PRTMAC_HSEC_CTL_RX_PAUSE_ENABLE, 0, 0, 0, 0,
> "PRTMAC_HSEC_CTL_RX_PAUSE_ENABLE"},
> {I40E_PRTMAC_HSEC_CTL_TX_PAUSE_ENABLE, 0, 0, 0, 0,
> @@ -817,12 +873,16 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_PRTDCB_FCCFG, 0, 0, 0, 0, "PRTDCB_FCCFG"},
> {I40E_PRTDCB_TPFCTS(0), 7, 32, 0, 0, "PRTDCB_TPFCTS"},
> {I40E_VFQF_HLUT1(0, 0), 15, 1024, 127, 4, "VFQF_HLUT1"},
> +#ifdef X722_SUPPORT
> {I40E_VSIQF_HLUT(0, 0), 15, 2048, 383, 4, "VSIQF_HLUT"},
> +#endif
> {I40E_VFQF_HKEY1(0, 0), 12, 1024, 127, 4, "VFQF_HKEY1"},
> {I40E_VFQF_HREGION1(0, 0), 7, 1024, 127, 4, "VFQF_HREGION1"},
> {I40E_VFQF_HENA1(0, 0), 1, 1024, 127, 4, "VFQF_HENA1"},
> {I40E_PFQF_HLUT(0), 127, 128, 0, 0, "PFQF_HLUT"},
> +#ifdef X722_SUPPORT
> {I40E_X722_PFQF_HLUT(0), 127, 128, 0, 0, "X722_PFQF_HLUT"},
> +#endif
> {I40E_PFQF_CTL_1, 0, 0, 0, 0, "PFQF_CTL_1"},
> {I40E_PFQF_FDSTAT, 0, 0, 0, 0, "PFQF_FDSTAT"},
> {I40E_PRT_MNG_MIPAF6(0), 15, 32, 0, 0, "PRT_MNG_MIPAF6"},
> @@ -839,21 +899,25 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_PRT_MNG_MANC, 0, 0, 0, 0, "PRT_MNG_MANC"},
> {I40E_PRT_MNG_MNGONLY, 0, 0, 0, 0, "PRT_MNG_MNGONLY"},
> {I40E_PRT_MNG_MSFM, 0, 0, 0, 0, "PRT_MNG_MSFM"},
> +#ifdef X722_SUPPORT
> {I40E_GLQF_APBVT(0), 2047, 4, 0, 0, "GLQF_APBVT"},
> {I40E_GLQF_PCNT(0), 511, 4, 0, 0, "GLQF_PCNT"},
> {I40E_GLQF_FD_PCTYPES(0), 63, 4, 0, 0, "GLQF_FD_PCTYPES"},
> {I40E_GLQF_ORT(0), 63, 4, 0, 0, "GLQF_ORT"},
> {I40E_GLQF_PIT(0), 23, 4, 0, 0, "GLQF_PIT"},
> +#endif
> {I40E_GL_PRS_FVBM(0), 3, 4, 0, 0, "GL_PRS_FVBM"},
> {I40E_GLQF_FDCNT_0, 0, 0, 0, 0, "GLQF_FDCNT_0"},
> {I40E_GL_MTG_FLU_MSK_H, 0, 0, 0, 0, "GL_MTG_FLU_MSK_H"},
> {I40E_GL_SWR_DEF_ACT_EN(0), 1, 4, 0, 0, "GL_SWR_DEF_ACT_EN"},
> {I40E_GLQF_HKEY(0), 12, 4, 0, 0, "GLQF_HKEY"},
> {I40E_GL_SWR_DEF_ACT(0), 35, 4, 0, 0, "GL_SWR_DEF_ACT"},
> +#ifdef X722_SUPPORT
> {I40E_GLQF_FDEVICTFLAG, 0, 0, 0, 0, "GLQF_FDEVICTFLAG"},
> {I40E_PFQF_CTL_2, 0, 0, 0, 0, "PFQF_CTL_2"},
> {I40E_GLQF_FDEVICTENA(0), 1, 4, 0, 0, "GLQF_FDEVICTENA"},
> {I40E_VSIQF_HKEY(0, 0), 12, 2048, 383, 4, "VSIQF_HKEY"},
> +#endif
> {I40E_GLPRT_GORCL(0), 3, 8, 0, 0, "GLPRT_GORCL"},
> {I40E_GLPRT_GORCH(0), 3, 8, 0, 0, "GLPRT_GORCH"},
> {I40E_GLPRT_MLFC(0), 3, 8, 0, 0, "GLPRT_MLFC"},
> @@ -991,7 +1055,39 @@ static const struct i40e_reg_info i40e_regs_others[] = {
> {I40E_GLVEBVL_MPCH(0), 127, 8, 0, 0, "GLVEBVL_MPCH"},
> {I40E_GLVEBVL_BPCL(0), 127, 8, 0, 0, "GLVEBVL_BPCL"},
> {I40E_GLVEBVL_BPCH(0), 127, 8, 0, 0, "GLVEBVL_BPCH"},
> +#ifdef X722_SUPPORT
> {I40E_GLGEN_STAT_HALT, 0, 0, 0, 0, "GLGEN_STAT_HALT"},
> {I40E_GLGEN_STAT_CLEAR, 0, 0, 0, 0, "GLGEN_STAT_CLEAR"},
> +#endif
> {0, 0, 0, 0, 0, NULL}
> };
> +
> +#ifndef X722_SUPPORT
> +#define I40E_GLQF_FD_MSK(_i, _j) \
> + (0x00267200 + ((_i) * 4 + (_j) * 8)) \
> + /* _i=0...1, _j=0...63 */ /* Reset: CORER */
> +#define I40E_GLQF_FD_MSK_MAX_INDEX 1
> +#define I40E_GLQF_FD_MSK_MASK_SHIFT 0
> +#define I40E_GLQF_FD_MSK_MASK_MASK \
> + I40E_MASK(0xFFFF, I40E_GLQF_FD_MSK_MASK_SHIFT)
> +#define I40E_GLQF_FD_MSK_OFFSET_SHIFT 16
> +#define I40E_GLQF_FD_MSK_OFFSET_MASK \
> + I40E_MASK(0x3F, I40E_GLQF_FD_MSK_OFFSET_SHIFT)
> +#define I40E_GLQF_HASH_INSET(_i, _j) \
> + (0x00267600 + ((_i) * 4 + (_j) * 8)) \
> + /* _i=0...1, _j=0...63 */ /* Reset: CORER */
> +#define I40E_GLQF_HASH_INSET_MAX_INDEX 1
> +#define I40E_GLQF_HASH_INSET_INSET_SHIFT 0
> +#define I40E_GLQF_HASH_INSET_INSET_MASK \
> + I40E_MASK(0xFFFFFFFF, I40E_GLQF_HASH_INSET_INSET_SHIFT)
> +#define I40E_GLQF_HASH_MSK(_i, _j) \
> + (0x00267A00 + ((_i) * 4 + (_j) * 8)) \
> + /* _i=0...1, _j=0...63 */ /* Reset: CORER */
> +#define I40E_GLQF_HASH_MSK_MAX_INDEX 1
> +#define I40E_GLQF_HASH_MSK_MASK_SHIFT 0
> +#define I40E_GLQF_HASH_MSK_MASK_MASK \
> + I40E_MASK(0xFFFF, I40E_GLQF_HASH_MSK_MASK_SHIFT)
> +#define I40E_GLQF_HASH_MSK_OFFSET_SHIFT 16
> +#define I40E_GLQF_HASH_MSK_OFFSET_MASK \
> + I40E_MASK(0x3F, I40E_GLQF_HASH_MSK_OFFSET_SHIFT)
> +#endif
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index 2cb2e30..4868786 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -2199,7 +2199,11 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
> uint16_t base, bsf, tc_mapping;
> int use_def_burst_func = 1;
>
> +#ifdef X722_SUPPORT
> if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF) {
> +#else
> + if (hw->mac.type == I40E_MAC_VF) {
> +#endif /* X722_SUPPORT */
> struct i40e_vf *vf =
> I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
> vsi = &vf->vsi;
> @@ -2239,7 +2243,12 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
> rxq->nb_rx_desc = nb_desc;
> rxq->rx_free_thresh = rx_conf->rx_free_thresh;
> rxq->queue_id = queue_idx;
> +
> +#ifdef X722_SUPPORT
> if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF)
> +#else
> + if (hw->mac.type == I40E_MAC_VF)
> +#endif /* X722_SUPPORT */
> rxq->reg_idx = queue_idx;
> else /* PF device */
> rxq->reg_idx = vsi->base_queue +
> @@ -2416,7 +2425,11 @@ i40e_dev_tx_queue_setup(struct rte_eth_dev *dev,
> uint16_t tx_rs_thresh, tx_free_thresh;
> uint16_t i, base, bsf, tc_mapping;
>
> +#ifdef X722_SUPPORT
> if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF) {
> +#else
> + if (hw->mac.type == I40E_MAC_VF) {
> +#endif /* X722_SUPPORT */
> struct i40e_vf *vf =
> I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
> vsi = &vf->vsi;
> @@ -2544,12 +2557,15 @@ i40e_dev_tx_queue_setup(struct rte_eth_dev *dev,
> txq->hthresh = tx_conf->tx_thresh.hthresh;
> txq->wthresh = tx_conf->tx_thresh.wthresh;
> txq->queue_id = queue_idx;
> +#ifdef X722_SUPPORT
> if (hw->mac.type == I40E_MAC_VF || hw->mac.type == I40E_MAC_X722_VF)
> +#else
> + if (hw->mac.type == I40E_MAC_VF)
> +#endif /* X722_SUPPORT */
> txq->reg_idx = queue_idx;
> else /* PF device */
> txq->reg_idx = vsi->base_queue +
> i40e_get_queue_offset_by_qindex(pf, queue_idx);
> -
> txq->port_id = dev->data->port_id;
> txq->txq_flags = tx_conf->txq_flags;
> txq->vsi = vsi;
> --
> 1.9.3
^ permalink raw reply
* Re: 17.02 Roadmap
From: O'Driscoll, Tim @ 2016-10-16 20:21 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger; +Cc: dev@dpdk.org
In-Reply-To: <1558423.Do1gQogAzQ@xps13>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, October 14, 2016 9:19 PM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: dev@dpdk.org; O'Driscoll, Tim <tim.odriscoll@intel.com>
> Subject: Re: [dpdk-dev] 17.02 Roadmap
>
> 2016-10-14 10:29, Stephen Hemminger:
> > It seems like a lot of these feature are focused too narrowly on
> exposing
> > features that exist on specific Intel hardware. The concept of a
> general
> > purpose Dataplane Development Kit is that applications can be written
> that
> > have a generic API (like any operating system) that will run on a wide
> > variety of hardware. This concept seems to getting lost as the DPDK
> is
> > becoming more of a platform for exposing what ever cool hardware
> features
> > exist.
> >
> > I would propose that no new feature be allowed in the DPDK unless it
> > can be supported on all device types. Yes that means you have to build
> > and test software emulation layers for all other devices. The current
> > model is more of a hardware test bed.
>
> Thanks for the reminder Stephen. It is good goal.
> I think the software emulation idea is finding its way.
> About forbidding new hardware feature without emulation support,
> it has to be discussed.
We have a roadmap discussion on Thursday morning at the Userspace event in
Dublin. The aim is to discuss any gaps in the roadmap and see what can be
done to address them. I think this would be a great topic to discuss then.
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-10-17 4:18 UTC (permalink / raw)
To: Eads, Gage
Cc: dev@dpdk.org, thomas.monjalon@6wind.com, Richardson, Bruce,
Vangati, Narender, hemant.agrawal@nxp.com
In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E01E179E0@FMSMSX108.amr.corp.intel.com>
On Fri, Oct 14, 2016 at 03:00:57PM +0000, Eads, Gage wrote:
> Thanks Jerin, this looks good. I've put a few notes/questions inline.
Thanks Gage.
>
> > +
> > +/**
> > + * Get the device identifier for the named event device.
> > + *
> > + * @param name
> > + * Event device name to select the event device identifier.
> > + *
> > + * @return
> > + * Returns event device identifier on success.
> > + * - <0: Failure to find named event device.
> > + */
> > +extern uint8_t
> > +rte_event_dev_get_dev_id(const char *name);
>
> This return type should be int8_t, or some signed type, to support the failure case.
Makes sense. I will change to int to make consistent with rte_cryptodev_get_dev_id()
>
> > +};
> > +
> > +/**
> > + * Schedule one or more events in the event dev.
> > + *
> > + * An event dev implementation may define this is a NOOP, for instance if
> > + * the event dev performs its scheduling in hardware.
> > + *
> > + * @param dev_id
> > + * The identifier of the device.
> > + */
> > +extern void
> > +rte_event_schedule(uint8_t dev_id);
>
> One idea: Have the function return the number of scheduled packets (or 0 for implementations that do scheduling in hardware). This could be a helpful diagnostic for the software scheduler.
How about returning an implementation specific value ?
Rather than defining certain function associated with returned value.
Just to make sure it works with all HW/SW implementations. Something like below,
/**
* Schedule one or more events in the event dev.
*
* An event dev implementation may define this is a NOOP, for instance if
* the event dev performs its scheduling in hardware.
*
* @param dev_id
* The identifier of the device.
* @return
* Implementation specific value from the event driver for diagnostic purpose
*/
extern int
rte_event_schedule(uint8_t dev_id);
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-10-17 5:10 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, thomas.monjalon, narender.vangati, hemant.agrawal, gage.eads
In-Reply-To: <20161014160220.GA204068@bricha3-MOBL3.ger.corp.intel.com>
On Fri, Oct 14, 2016 at 05:02:21PM +0100, Bruce Richardson wrote:
> On Wed, Oct 12, 2016 at 01:00:16AM +0530, Jerin Jacob wrote:
> > Thanks to Intel and NXP folks for the positive and constructive feedback
> > I've received so far. Here is the updated RFC(v2).
> >
> > I've attempted to address as many comments as possible.
> >
> > This series adds rte_eventdev.h to the DPDK tree with
> > adequate documentation in doxygen format.
> >
> > Updates are also available online:
> >
> > Related draft header file (this patch):
> > https://rawgit.com/jerinjacobk/libeventdev/master/rte_eventdev.h
> >
> > PDF version(doxgen output):
> > https://rawgit.com/jerinjacobk/libeventdev/master/librte_eventdev_v2.pdf
> >
> > Repo:
> > https://github.com/jerinjacobk/libeventdev
> >
>
> Thanks for all the work on this.
Thanks
>
> <snip>
> > +/* Event device configuration bitmap flags */
> > +#define RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT (1 << 0)
> > +/**< Override the global *dequeue_wait_ns* and use per dequeue wait in ns.
> > + * \see rte_event_dequeue_wait_time(), rte_event_dequeue()
> > + */
>
> Can you clarify why this is needed? If an app wants to use the same
> dequeue wait times for all dequeues can it not specify that itself via
> the wait time parameter, rather than having a global dequeue wait value?
The rational for choosing this scheme to have optimized
rte_event_dequeue() for some implementation without loosing application
portability and need.
We mostly have two different types of HW schemes to define the wait time
HW1) Have only global wait value for the eventdev across all the
dequeue
HW2) Per queue wait value
In-terms of applications,
APP1) Trivial application does not need different dequeue value for each
dequeue
APP2) Non trivial applications does need different dequeue values
This config option can take advantage if application demands only APP1
on HW1 without loosing application potablity.(i.e if application demand
for APP2 scheme then HW1 based implementation can have different function
pointer to implement dequeue function)
The overall theme of the proposal to have more configuration options(like
RTE_EVENT_QUEUE_CFG_SINGLE_CONSUMER) to have high performance SW/HW implementations
^ permalink raw reply
* Re: [PATCH v2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
From: Lu, Wenzhuo @ 2016-10-17 6:12 UTC (permalink / raw)
To: Iremonger, Bernard, dev@dpdk.org, Shah, Rahul R
In-Reply-To: <1476451768-21278-1-git-send-email-bernard.iremonger@intel.com>
Hi Bernard, Rahul,
> -----Original Message-----
> From: Iremonger, Bernard
> Sent: Friday, October 14, 2016 9:29 PM
> To: dev@dpdk.org; Shah, Rahul R; Lu, Wenzhuo
> Cc: Iremonger, Bernard
> Subject: [PATCH v2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
>
> modify ixgbe_dcb_tx_hw_config function.
> modify ixgbe_dev_mq_rx_configure function.
> modify ixgbe_configure_dcb function.
Would you like to add more details about why we need to modify these functions and what has been done? Thanks.
>
> Changes in v2:
> Rebased to DPDK v16.11-rc1
>
> Signed-off-by: Rahul R Shah <rahul.r.shah@intel.com>
> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 9 ++++-----
> drivers/net/ixgbe/ixgbe_rxtx.c | 37 +++++++++++++++++++++----------------
> 2 files changed, 25 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 4ca5747..114698d 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -1977,6 +1977,8 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
> /* check multi-queue mode */
> switch (dev_conf->rxmode.mq_mode) {
> case ETH_MQ_RX_VMDQ_DCB:
Should we store the mq mode here?
> + PMD_INIT_LOG(INFO, "ETH_MQ_RX_VMDQ_DCB
> mode supported in SRIOV");
> + break;
> case ETH_MQ_RX_VMDQ_DCB_RSS:
> /* DCB/RSS VMDQ in SRIOV mode, not implement yet
> */
> PMD_INIT_LOG(ERR, "SRIOV active,"
> @@ -2012,11 +2014,8 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
>
> switch (dev_conf->txmode.mq_mode) {
> case ETH_MQ_TX_VMDQ_DCB:
> - /* DCB VMDQ in SRIOV mode, not implement yet */
> - PMD_INIT_LOG(ERR, "SRIOV is active,"
> - " unsupported VMDQ mq_mode
> tx %d.",
> - dev_conf->txmode.mq_mode);
> - return -EINVAL;
> + PMD_INIT_LOG(INFO, "ETH_MQ_TX_VMDQ_DCB mode
> supported in SRIOV");
> + break;
> default: /* ETH_MQ_TX_VMDQ_ONLY or ETH_MQ_TX_NONE
> */
> dev->data->dev_conf.txmode.mq_mode =
> ETH_MQ_TX_VMDQ_ONLY;
> break;
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c index
> 2ce8234..bb13889 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -1,7 +1,7 @@
> /*-
> * BSD LICENSE
> *
> - * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> + * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> * Copyright 2014 6WIND S.A.
> * All rights reserved.
> *
> @@ -3313,15 +3313,16 @@ ixgbe_vmdq_dcb_configure(struct rte_eth_dev
> *dev)
>
> /**
> * ixgbe_dcb_config_tx_hw_config - Configure general DCB TX parameters
> - * @hw: pointer to hardware structure
> + * @dev: pointer to eth_dev structure
> * @dcb_config: pointer to ixgbe_dcb_config structure
> */
> static void
> -ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
> +ixgbe_dcb_tx_hw_config(struct rte_eth_dev *dev,
> struct ixgbe_dcb_config *dcb_config) {
> uint32_t reg;
> uint32_t q;
> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data-
> >dev_private);
>
> PMD_INIT_FUNC_TRACE();
> if (hw->mac.type != ixgbe_mac_82598EB) { @@ -3339,11 +3340,17 @@
> ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
> if (dcb_config->vt_mode)
> reg |= IXGBE_MTQC_VT_ENA;
> IXGBE_WRITE_REG(hw, IXGBE_MTQC, reg);
> -
> - /* Disable drop for all queues */
> - for (q = 0; q < 128; q++)
> - IXGBE_WRITE_REG(hw, IXGBE_QDE,
> - (IXGBE_QDE_WRITE | (q <<
> IXGBE_QDE_IDX_SHIFT)));
> + if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
> + /* Disable drop for all queues in VMDQ mode*/
> + for (q = 0; q < 128; q++)
> + IXGBE_WRITE_REG(hw, IXGBE_QDE,
> + (IXGBE_QDE_WRITE | (q <<
> IXGBE_QDE_IDX_SHIFT) | IXGBE_QDE_ENABLE));
> + } else {
> + /* Enable drop for all queues in SRIOV mode */
> + for (q = 0; q < 128; q++)
> + IXGBE_WRITE_REG(hw, IXGBE_QDE,
> + (IXGBE_QDE_WRITE | (q <<
> IXGBE_QDE_IDX_SHIFT)));
> + }
I think it has nothing to do with mq mode. Do I miss something?
>
> /* Enable the Tx desc arbiter */
> reg = IXGBE_READ_REG(hw, IXGBE_RTTDCS); @@ -3378,7
> +3385,7 @@ ixgbe_vmdq_dcb_hw_tx_config(struct rte_eth_dev *dev,
> vmdq_tx_conf->nb_queue_pools == ETH_16_POOLS ?
> 0xFFFF : 0xFFFFFFFF);
>
> /*Configure general DCB TX parameters*/
> - ixgbe_dcb_tx_hw_config(hw, dcb_config);
> + ixgbe_dcb_tx_hw_config(dev, dcb_config);
> }
>
> static void
> @@ -3661,7 +3668,7 @@ ixgbe_dcb_hw_configure(struct rte_eth_dev *dev,
> /*get DCB TX configuration parameters from rte_eth_conf*/
> ixgbe_dcb_tx_config(dev, dcb_config);
> /*Configure general DCB TX parameters*/
> - ixgbe_dcb_tx_hw_config(hw, dcb_config);
> + ixgbe_dcb_tx_hw_config(dev, dcb_config);
> break;
> default:
> PMD_INIT_LOG(ERR, "Incorrect DCB TX mode configuration");
> @@ -3810,9 +3817,6 @@ void ixgbe_configure_dcb(struct rte_eth_dev *dev)
> (dev_conf->rxmode.mq_mode != ETH_MQ_RX_DCB_RSS))
> return;
>
> - if (dev->data->nb_rx_queues != ETH_DCB_NUM_QUEUES)
> - return;
I remember it's a limitation of implementation. The reason is the resource allocation. Why could we remove it now?
> -
> /** Configure DCB hardware **/
> ixgbe_dcb_hw_configure(dev, dcb_cfg);
> }
> @@ -4082,12 +4086,13 @@ ixgbe_dev_mq_rx_configure(struct rte_eth_dev
> *dev)
> case ETH_MQ_RX_VMDQ_RSS:
> ixgbe_config_vf_rss(dev);
> break;
> -
> - /* FIXME if support DCB/RSS together with VMDq & SRIOV */
> case ETH_MQ_RX_VMDQ_DCB:
> + ixgbe_vmdq_dcb_configure(dev);
> + break;
> + /* FIXME if support DCB/RSS together with VMDq & SRIOV */
> case ETH_MQ_RX_VMDQ_DCB_RSS:
> PMD_INIT_LOG(ERR,
> - "Could not support DCB with VMDq & SRIOV");
> + "Could not support DCB/RSS with VMDq &
> SRIOV");
> return -1;
> default:
> ixgbe_config_vf_default(dev);
> --
> 2.10.1
^ permalink raw reply
* Re: [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
From: Guo, Jia @ 2016-10-17 7:44 UTC (permalink / raw)
To: Ananyev, Konstantin, Zhang, Helin, Wu, Jingjing; +Cc: dev@dpdk.org
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0C1FF9@irsmsx105.ger.corp.intel.com>
hi, Konstantin
Thanks your constructive suggestion. I don't think your question is
silly and we also think about the code style simply and effective, but
may be i would interpret the reason why we do that.
1) Sure, user definitely can choose to define the macro or not when
building dpdk i40e PMD, but i don't think it is
necessary to invoke a ret_config option to let up layer user freedom use
it, because only the older version i40e driver does not support X722,
the newer version i40e driver will always support X722, so the macro
will be default hard code in the makefile. and we will use mac.type to
distinguish the difference register configure in run time. So we may
consider the macro just like a flag that highlight the difference of the
shared code between X710 and X722, that would benify the X710/X722 pmd
development but hardly no use to exposure to the up layer user.
2) i think the answer also could find from above. But i think if we
develop go to a certain stage in the future, mute the macro or use
script to remove them like the way from hw driver, for support all
device types maybe not a bad idea, right?
On 10/16/2016 9:31 PM, Ananyev, Konstantin wrote:
> Hi Jeff,
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jeff Guo
>> Sent: Sunday, October 16, 2016 2:40 AM
>> To: Zhang, Helin <helin.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
>> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>
>> Subject: [dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
>>
>> Since some register only be supported by X722 but may not be supported
>> by other NICs, so add X722 macro to distinguish that to avoid compile error
>> when the X722 macro is undefined.
>
> Two probably silly questions:
> 1) So who will setup X722_SUPPORT macro?
> Is that a user responsibility when he is building dpdk i40e PMD?
> If so, why it is not a rte_config option?
> 2) Why this all has to be build time decision?
> Why nor run-time?
> Why i40e driver can't support all devices (including x722)
> and invoke different config functions (write different registers)
> based on device type/id information?
> As it does for other device types/ids?
>
> Konstantin
^ permalink raw reply
* Re: [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
From: Ananyev, Konstantin @ 2016-10-17 9:54 UTC (permalink / raw)
To: Guo, Jia, Zhang, Helin, Wu, Jingjing; +Cc: dev@dpdk.org
In-Reply-To: <b9708e79-5000-cc35-bd89-33573c61978b@intel.com>
Hi Jeff,
>
> hi, Konstantin
> Thanks your constructive suggestion. I don't think your question is
> silly and we also think about the code style simply and effective, but
> may be i would interpret the reason why we do that.
>
> 1) Sure, user definitely can choose to define the macro or not when
> building dpdk i40e PMD, but i don't think it is
> necessary to invoke a ret_config option to let up layer user freedom use
> it, because only the older version i40e driver does not support X722,
> the newer version i40e driver will always support X722, so the macro
> will be default hard code in the makefile. and we will use mac.type to
> distinguish the difference register configure in run time. So we may
> consider the macro just like a flag that highlight the difference of the
> shared code between X710 and X722, that would benify the X710/X722 pmd
> development but hardly no use to exposure to the up layer user.
>
> 2) i think the answer also could find from above. But i think if we
> develop go to a certain stage in the future, mute the macro or use
> script to remove them like the way from hw driver, for support all
> device types maybe not a bad idea, right?
Sorry, but I still didn't get it.
If i40e driver will always support X722 then why do we need that macro at all?
Why just not to remove it completely then?
Same about run-time vs build-time choice:
If let say i40e_get_rss_key() has to behave in a different way, why not to create
i40e_get_rss_key_x722() and use it when hw mactype is x7222?
Or at least inside i40e_get_rss_key() do something like:
if (hw->mac.type == I40E_MAC_X722) {...} else {...}
?
Why instead you have to pollute whole i40e code with all these #ifdef x7222/#else ...?
Obviously that looks pretty ugly and hard to maintain.
Konstantin
>
>
> On 10/16/2016 9:31 PM, Ananyev, Konstantin wrote:
> > Hi Jeff,
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jeff Guo
> >> Sent: Sunday, October 16, 2016 2:40 AM
> >> To: Zhang, Helin <helin.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
> >> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>
> >> Subject: [dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
> >>
> >> Since some register only be supported by X722 but may not be supported
> >> by other NICs, so add X722 macro to distinguish that to avoid compile error
> >> when the X722 macro is undefined.
> >
> > Two probably silly questions:
> > 1) So who will setup X722_SUPPORT macro?
> > Is that a user responsibility when he is building dpdk i40e PMD?
> > If so, why it is not a rte_config option?
> > 2) Why this all has to be build time decision?
> > Why nor run-time?
> > Why i40e driver can't support all devices (including x722)
> > and invoke different config functions (write different registers)
> > based on device type/id information?
> > As it does for other device types/ids?
> >
> > Konstantin
^ permalink raw reply
* Re: [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile
From: Chilikin, Andrey @ 2016-10-17 10:14 UTC (permalink / raw)
To: Ananyev, Konstantin, Guo, Jia, Zhang, Helin, Wu, Jingjing; +Cc: dev@dpdk.org
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0C23DD@irsmsx105.ger.corp.intel.com>
In addition to Konstantin's point - some configuration settings, like RSS input set and PTYPEs, could be firmware dependent and change between fw versions for the same X710/X722 device. Moving mapping tables to the dev private data and initializing it on device start up will make code much cleaner.
Regards,
/Andrey
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Monday, October 17, 2016 10:55 AM
> To: Guo, Jia <jia.guo@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Wu,
> Jingjing <jingjing.wu@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence
> result in compile
>
> Hi Jeff,
>
> >
> > hi, Konstantin
> > Thanks your constructive suggestion. I don't think your question is
> > silly and we also think about the code style simply and effective, but
> > may be i would interpret the reason why we do that.
> >
> > 1) Sure, user definitely can choose to define the macro or not when
> > building dpdk i40e PMD, but i don't think it is necessary to invoke a
> > ret_config option to let up layer user freedom use it, because only
> > the older version i40e driver does not support X722, the newer version
> > i40e driver will always support X722, so the macro will be default
> > hard code in the makefile. and we will use mac.type to distinguish the
> > difference register configure in run time. So we may consider the
> > macro just like a flag that highlight the difference of the shared
> > code between X710 and X722, that would benify the X710/X722 pmd
> > development but hardly no use to exposure to the up layer user.
> >
> > 2) i think the answer also could find from above. But i think if we
> > develop go to a certain stage in the future, mute the macro or use
> > script to remove them like the way from hw driver, for support all
> > device types maybe not a bad idea, right?
>
> Sorry, but I still didn't get it.
> If i40e driver will always support X722 then why do we need that macro at all?
> Why just not to remove it completely then?
> Same about run-time vs build-time choice:
> If let say i40e_get_rss_key() has to behave in a different way, why not to create
> i40e_get_rss_key_x722() and use it when hw mactype is x7222?
> Or at least inside i40e_get_rss_key() do something like:
> if (hw->mac.type == I40E_MAC_X722) {...} else {...} ?
> Why instead you have to pollute whole i40e code with all these #ifdef
> x7222/#else ...?
> Obviously that looks pretty ugly and hard to maintain.
> Konstantin
>
>
>
> >
> >
> > On 10/16/2016 9:31 PM, Ananyev, Konstantin wrote:
> > > Hi Jeff,
> > >
> > >> -----Original Message-----
> > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jeff Guo
> > >> Sent: Sunday, October 16, 2016 2:40 AM
> > >> To: Zhang, Helin <helin.zhang@intel.com>; Wu, Jingjing
> > >> <jingjing.wu@intel.com>
> > >> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>
> > >> Subject: [dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro
> > >> absence result in compile
> > >>
> > >> Since some register only be supported by X722 but may not be
> > >> supported by other NICs, so add X722 macro to distinguish that to
> > >> avoid compile error when the X722 macro is undefined.
> > >
> > > Two probably silly questions:
> > > 1) So who will setup X722_SUPPORT macro?
> > > Is that a user responsibility when he is building dpdk i40e PMD?
> > > If so, why it is not a rte_config option?
> > > 2) Why this all has to be build time decision?
> > > Why nor run-time?
> > > Why i40e driver can't support all devices (including x722) and
> > > invoke different config functions (write different registers) based
> > > on device type/id information?
> > > As it does for other device types/ids?
> > >
> > > Konstantin
^ permalink raw reply
* [PATCH] kni: fix build with kernel 4.9
From: Ferruh Yigit @ 2016-10-17 10:23 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit
compile error:
CC [M] .../lib/librte_eal/linuxapp/kni/igb_main.o
.../lib/librte_eal/linuxapp/kni/igb_main.c:2317:21:
error: initialization from incompatible pointer type
[-Werror=incompatible-pointer-types]
.ndo_set_vf_vlan = igb_ndo_set_vf_vlan,
^~~~~~~~~~~~~~~~~~~
Linux kernel 4.9 updates API for ndo_set_vf_vlan:
Linux: 79aab093a0b5 ("net: Update API for VF vlan protocol 802.1ad support")
Use new API for Linux kernels >= 4.9
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c | 19 +++++++++++++++++++
lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 4 ++++
2 files changed, 23 insertions(+)
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
index 23e2d64..f4dca5a 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
@@ -195,7 +195,11 @@ static void igb_process_mdd_event(struct igb_adapter *);
#ifdef IFLA_VF_MAX
static int igb_ndo_set_vf_mac( struct net_device *netdev, int vf, u8 *mac);
static int igb_ndo_set_vf_vlan(struct net_device *netdev,
+#ifdef HAVE_VF_VLAN_PROTO
+ int vf, u16 vlan, u8 qos, __be16 vlan_proto);
+#else
int vf, u16 vlan, u8 qos);
+#endif
#ifdef HAVE_VF_SPOOFCHK_CONFIGURE
static int igb_ndo_set_vf_spoofchk(struct net_device *netdev, int vf,
bool setting);
@@ -6412,7 +6416,11 @@ static void igb_set_vmvir(struct igb_adapter *adapter, u32 vid, u32 vf)
}
static int igb_ndo_set_vf_vlan(struct net_device *netdev,
+#ifdef HAVE_VF_VLAN_PROTO
+ int vf, u16 vlan, u8 qos, __be16 vlan_proto)
+#else
int vf, u16 vlan, u8 qos)
+#endif
{
int err = 0;
struct igb_adapter *adapter = netdev_priv(netdev);
@@ -6420,6 +6428,12 @@ static int igb_ndo_set_vf_vlan(struct net_device *netdev,
/* VLAN IDs accepted range 0-4094 */
if ((vf >= adapter->vfs_allocated_count) || (vlan > VLAN_VID_MASK-1) || (qos > 7))
return -EINVAL;
+
+#ifdef HAVE_VF_VLAN_PROTO
+ if (vlan_proto != htons(ETH_P_8021Q))
+ return -EPROTONOSUPPORT;
+#endif
+
if (vlan || qos) {
err = igb_vlvf_set(adapter, vlan, !!vlan, vf);
if (err)
@@ -6580,7 +6594,12 @@ static inline void igb_vf_reset(struct igb_adapter *adapter, u32 vf)
if (adapter->vf_data[vf].pf_vlan)
igb_ndo_set_vf_vlan(adapter->netdev, vf,
adapter->vf_data[vf].pf_vlan,
+#ifdef HAVE_VF_VLAN_PROTO
+ adapter->vf_data[vf].pf_qos,
+ htons(ETH_P_8021Q));
+#else
adapter->vf_data[vf].pf_qos);
+#endif
else
igb_clear_vf_vfta(adapter, vf);
#endif
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
index 69e0e7a..84826b2 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
@@ -3929,4 +3929,8 @@ skb_set_hash(struct sk_buff *skb, __u32 hash, __always_unused int type)
#define vlan_tx_tag_present skb_vlan_tag_present
#endif
+#if ( LINUX_VERSION_CODE >= KERNEL_VERSION(4,9,0) )
+#define HAVE_VF_VLAN_PROTO
+#endif /* >= 4.9.0 */
+
#endif /* _KCOMPAT_H_ */
--
2.7.4
^ permalink raw reply related
* Re: Project Governance and Linux Foundation
From: Hobywan Kenoby @ 2016-10-17 10:23 UTC (permalink / raw)
To: O'Driscoll, Tim, dev@dpdk.org, users@dpdk.org
In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA675F0B5A@IRSMSX108.ger.corp.intel.com>
Hi Tim,
The Linux kernel community has a governance close to DPDK. It did allow
companies to grow largebusinesses and indivuals to take an
active and even influencial roles based on their technical expertise and
merits.
I don't really understand what can be gained by moving to Linux
Foundation, but I am almost sure that no individual expert will be able
to take any leaderhip role as those roles will be fulfilled by Platinum,
Gold or Silver members: right ?
VPP is a virtual switch that has its own event model that may compete with the new model proposed by Intel, Cavium and NXP. What would be the acceptability of such a proposal if DPDK would have been folded into FD.IO?
Intellectual property is probably properly handled in this community (I
don't really know a lot about this): are there things to be done on DPDK
to match was proved to be sufficient in Linux kernel?
The current DPDK version can run on virtually all processors (Intel, IBM
and ARM) and leverage all NICs: is there **really** anyone questionning
openness of the community?
- HK
________________________________
From: dev <dev-bounces@dpdk.org> on behalf of O'Driscoll, Tim <tim.odriscoll@intel.com>
Sent: Monday, October 10, 2016 10:33 AM
To: dev@dpdk.org; users@dpdk.org
Subject: [dpdk-dev] Project Governance and Linux Foundation
This email is being sent on behalf of: Cavium, Cisco, Intel, NXP & Red Hat.
Since its creation as an open source project in 2013, DPDK has grown significantly. The number of DPDK users, contributors, commercial products that use DPDK and open source projects that depend on it have all increased consistently over that time. DPDK is now a key ingredient in networking and NFV, and we need to ensure that the project structure and governance are appropriate for such a critical project, and that they facilitate the project's continued growth.
For over a year now we've been discussing moving DPDK to the Linux Foundation. We believe it's now time to conclude that discussion and make the move. The benefits of doing this would include:
- The infrastructure for a project like DPDK should not be owned and controlled by any single company.
- Remove any remaining perception that DPDK is not truly open.
- Allow the project to avail of the infrastructure and services provided by the Linux Foundation. These include things like: Ability to host infrastructure for integration and testing (the FD.io CSIT lab is an example of this - see https://wiki.fd.io/view/CSIT/CSIT_LF_testbed); Support for legal issues including trademarks and branding, and the ability to sign agreements on behalf of the project; Ability to pool resources for events and brand promotion; Safe haven for community IP resources.
CSIT/CSIT LF testbed - fd.io<https://wiki.fd.io/view/CSIT/CSIT_LF_testbed>
wiki.fd.io
FD.IO CSIT testbed - Server HW Configuration. CSIT testbed contains following three HW configuration types of UCS x86 servers, across total of ten servers provided:
We don't propose to debate the details here. Instead, an open discussion session on DPDK Project Growth has been included in the agenda for the DPDK Summit Userspace 2016 event in Dublin. We propose using that session to agree that the DPDK project will move to the Linux Foundation, and then to move on to discussing the specifics. Things that we'll need to consider include:
- Whether DPDK moves to the Linux Foundation as an independent project or as part of a larger project like FD.io.
- Creation of a project charter similar to those created for FD.io (https://fd.io/governance/technical-community-charter) and Open vSwitch (see http://openvswitch.org/pipermail/discuss/attachments/20160619/5a2df53e/attachment-0001.pdf).
[https://fd.io/sites/cpstandard/files/theme/backgrounds/bg.jpg]<https://fd.io/governance/technical-community-charter>
Technical Community Charter | FD.io<https://fd.io/governance/technical-community-charter>
fd.io
3.3.4 Project Reviews. For each review, there will be a publicly visible wiki/web template filled out containing relevant review information. The review document must ...
- Agreement on budget, membership levels etc. A draft budget was created by the LF during previous discussions (https://docs.google.com/spreadsheets/d/1-3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=302618256), but it is possible to adopt an even more lightweight model.
We could look at alternatives to the Linux Foundation, but a) we've been talking to the LF for over a year now, and b) the preponderance of networking projects in LF, like ODL, FD.io, and OVS, makes it a natural destination for DPDK.
As highlighted in previous discussions on this topic, it's important to stress that the intent is not to make significant changes to the technical governance and decision making of the project. The project has a strong set of maintainers and a Technical Board in place already. What's required is to supplement that with an open governance structure taking advantage of the services offered by the Linux Foundation.
The purpose of this email is to outline what we want to achieve during that discussion session in Dublin, and to allow people to consider the issue and prepare in advance. If people want to comment via email on the mailing list, that's obviously fine, but we believe that an open and frank discussion when people meet in person in Dublin is the best way to progress this.
For reference, below is a brief history of the previous discussions on this topic:
September 2015:
- A DPDK community call was held to discuss project growth and possible improvements. This was the first public discussion on possible governance changes. The agreed next step was to discuss this in more detail at the 2015 DPDK Summit Userspace event Dublin. Minutes of the call are at: http://dpdk.org/ml/archives/dev/2015-September/024120.html.
October 2015:
- An open discussion session on project governance was held at the 2015 DPDK Summit Userspace event. For technical governance, we agreed to investigate creating a technical steering committee. For non-technical governance (including things like event planning, legal and trademark issues, hosting of the website etc.), we agreed to work with the Linux Foundation on a proposal for a lightweight governance model for DPDK. Minutes of the discussion are at: http://dpdk.org/ml/archives/dev/2015-October/024825.html.
- The proposal for a technical steering committee was subsequently discussed on the mailing list (http://dpdk.org/ml/archives/dev/2015-October/026598.html) and agreed, leading to the creation of the DPDK Technical Board (http://dpdk.org/dev#board).
December 2015:
- A community call was held to discuss migration to the Linux Foundation. Mike Dolan (VP of Strategic Programs at The Linux Foundation) gave an overview of the LF and the services they can provide. We agreed to form a small sub-team (Dave Neary, Thomas Monjalon, Stephen Hemminger, Tim O'Driscoll) to work with the LF on a more detailed proposal. Minutes of the call are at: http://dpdk.org/ml/archives/dev/2015-December/030532.html.
February 2016:
- A community call was held to discuss the LF budget proposal (see https://docs.google.com/spreadsheets/d/1-3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=302618256). We agreed to discuss this further on the dev mailing list due to limited attendance on the call. Minutes of the call are at: http://dpdk.org/ml/archives/dev/2016-February/032720.html.
- A request was made on the dev and announce mailing lists too determine who supported the proposal to move to the Linux Foundation (http://dpdk.org/ml/archives/dev/2016-February/033192.html). There was public support from Intel (http://dpdk.org/ml/archives/dev/2016-February/033297.html) and Brocade (http://dpdk.org/ml/archives/dev/2016-February/033359.html). 6WIND requested postponing the move for a few months (http://dpdk.org/ml/archives/dev/2016-February/033299.html).
- The Fast Data (FD.io) project was established under the Linux Foundation (https://fd.io/news/announcement/2016/02/linux-foundation-forms-open-source-effort-advance-io-services).
[https://fd.io/sites/cpstandard/files/theme/backgrounds/bg.jpg]<https://fd.io/news/announcement/2016/02/linux-foundation-forms-open-source-effort-advance-io-services>
The Linux Foundation Forms Open Source Effort to Advance ...<https://fd.io/news/announcement/2016/02/linux-foundation-forms-open-source-effort-advance-io-services>
fd.io
Industry leaders unite for Fast Data (FD.io) Project; aims to establish a high-performance IO services framework for dynamic computing environments
June 2016:
- The Open vSwitch project proposed moving to the Linux Foundation (http://openvswitch.org/pipermail/discuss/2016-June/021761.html).
[ovs-discuss] Request for comments on Open vSwitch joining ...<http://openvswitch.org/pipermail/discuss/2016-June/021761.html>
openvswitch.org
Since roughly October, some of the OVS committers have been talking over the idea of bringing Open vSwitch into a foundation. Originally the group discussing the idea ...
August 2016:
- The Open vSwitch project moved to the Linux Foundation (https://www.linuxfoundation.org/announcements/open-vswitch-joins-linux-foundation-open-networking-ecosystem).
Open vSwitch Joins Linux Foundation Open Networking ...<https://www.linuxfoundation.org/announcements/open-vswitch-joins-linux-foundation-open-networking-ecosystem>
www.linuxfoundation.org
SAN FRANCISCO - AUGUST 09, 2016 - The Linux Foundation, the nonprofit advancing professional open source management for mass collaboration today is announcing ...
^ permalink raw reply
* [PATCH] examples/ip_pipeline: fix gcc v6.2.1 build error
From: Jasvinder Singh @ 2016-10-17 10:51 UTC (permalink / raw)
To: dev; +Cc: cristian.dumitrescu
This patch fixes the misleading indentation error on compiling ip_pipeline
app with gcc v6.2.1.
Fixes: 3f2c9f3bb6c6 ("examples/ip_pipeline: add TAP port")
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
---
examples/ip_pipeline/app.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/examples/ip_pipeline/app.h b/examples/ip_pipeline/app.h
index 564996e..f8b84e0 100644
--- a/examples/ip_pipeline/app.h
+++ b/examples/ip_pipeline/app.h
@@ -1152,7 +1152,7 @@ app_tap_get_writer(struct app_params *app,
struct app_pktq_tap_params *tap,
uint32_t *pktq_out_id)
{
- struct app_pipeline_params *writer;
+ struct app_pipeline_params *writer = NULL;
uint32_t pos = tap - app->tap_params;
uint32_t n_pipelines = RTE_MIN(app->n_pipelines,
RTE_DIM(app->pipeline_params));
@@ -1168,10 +1168,11 @@ app_tap_get_writer(struct app_params *app,
struct app_pktq_out_params *pktq = &p->pktq_out[j];
if ((pktq->type == APP_PKTQ_OUT_TAP) &&
- (pktq->id == pos))
+ (pktq->id == pos)) {
n_writers++;
writer = p;
id = j;
+ }
}
}
--
2.5.5
^ permalink raw reply related
* [PATCH] net/mlx5: fix link status report
From: Nelio Laranjeiro @ 2016-10-17 11:10 UTC (permalink / raw)
To: dev; +Cc: Olga Shern, Adrien Mazarguil
From: Olga Shern <olgas@mellanox.com>
This commit fixes link status report on device start up when
lcs callback is configured.
Fixes: 62072098b54e ("mlx5: support setting link up or down")
Signed-off-by: Olga Shern <olgas@mellanox.com>
---
drivers/net/mlx5/mlx5.c | 1 +
drivers/net/mlx5/mlx5.h | 1 +
drivers/net/mlx5/mlx5_ethdev.c | 2 +-
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 2583a37..f066419 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -671,6 +671,7 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct rte_pci_device *pci_dev)
/* Bring Ethernet device up. */
DEBUG("forcing Ethernet interface up");
priv_set_flags(priv, ~IFF_UP, IFF_UP);
+ mlx5_link_update_unlocked(priv->dev, 1);
continue;
port_error:
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index d24c4f4..000fb38 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -191,6 +191,7 @@ int priv_set_flags(struct priv *, unsigned int, unsigned int);
int mlx5_dev_configure(struct rte_eth_dev *);
void mlx5_dev_infos_get(struct rte_eth_dev *, struct rte_eth_dev_info *);
const uint32_t *mlx5_dev_supported_ptypes_get(struct rte_eth_dev *dev);
+int mlx5_link_update_unlocked(struct rte_eth_dev *, int);
int mlx5_link_update(struct rte_eth_dev *, int);
int mlx5_dev_set_mtu(struct rte_eth_dev *, uint16_t);
int mlx5_dev_get_flow_ctrl(struct rte_eth_dev *, struct rte_eth_fc_conf *);
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 7ee2006..b8b3ea9 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -642,7 +642,7 @@ mlx5_dev_supported_ptypes_get(struct rte_eth_dev *dev)
* @param wait_to_complete
* Wait for request completion (ignored).
*/
-static int
+int
mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
{
struct priv *priv = mlx5_get_priv(dev);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Maxime Coquelin @ 2016-10-17 11:23 UTC (permalink / raw)
To: Wang, Zhihong, yuanhan.liu@linux.intel.com, Xie, Huawei,
dev@dpdk.org
Cc: vkaplans@redhat.com, mst@redhat.com, stephen@networkplumber.org
In-Reply-To: <70cc3b89-d680-1519-add3-f38b228e65b5@redhat.com>
On 10/14/2016 05:50 PM, Maxime Coquelin wrote:
>
>
> On 10/14/2016 09:24 AM, Wang, Zhihong wrote:
>>
>>
>>> -----Original Message-----
>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Maxime Coquelin
>>> Sent: Tuesday, September 27, 2016 4:43 PM
>>> To: yuanhan.liu@linux.intel.com; Xie, Huawei <huawei.xie@intel.com>;
>>> dev@dpdk.org
>>> Cc: vkaplans@redhat.com; mst@redhat.com;
>>> stephen@networkplumber.org; Maxime Coquelin
>>> <maxime.coquelin@redhat.com>
>>> Subject: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors
>>> support to
>>> the TX path
>>>
>>> Indirect descriptors are usually supported by virtio-net devices,
>>> allowing to dispatch a larger number of requests.
>>>
>>> When the virtio device sends a packet using indirect descriptors,
>>> only one slot is used in the ring, even for large packets.
>>>
>>> The main effect is to improve the 0% packet loss benchmark.
>>> A PVP benchmark using Moongen (64 bytes) on the TE, and testpmd
>>> (fwd io for host, macswap for VM) on DUT shows a +50% gain for
>>> zero loss.
>>>
>>> On the downside, micro-benchmark using testpmd txonly in VM and
>>> rxonly on host shows a loss between 1 and 4%.i But depending on
>>> the needs, feature can be disabled at VM boot time by passing
>>> indirect_desc=off argument to vhost-user device in Qemu.
>>>
>>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>>
>>
>> Hi Maxime,
>>
>> Seems this patch can't with Windows virtio guest in my test.
>> Have you done similar tests before?
>>
>> The way I test:
>>
>> 1. Make sure https://patchwork.codeaurora.org/patch/84339/ is applied
>>
>> 2. Start testpmd with iofwd between 2 vhost ports
>>
>> 3. Start 2 Windows guests connected to the 2 vhost ports
>>
>> 4. Disable firewall and assign IP to each guest using ipconfig
>>
>> 5. Use ping to test connectivity
>>
>> When I disable this patch by setting:
>>
>> 0ULL << VIRTIO_RING_F_INDIRECT_DESC,
>>
>> the connection is fine, but when I restore:
>>
>> 1ULL << VIRTIO_RING_F_INDIRECT_DESC,
>>
>> the connection is broken.
>
> Just noticed I didn't reply to all this morning.
> I sent a debug patch to Zhihong, which shows that indirect desc chaining
> looks OK.
>
> On my side, I just setup 2 Windows 2016 VMs, and confirm the issue.
> I'll continue the investigation early next week.
The root cause is identified.
When INDIRECT_DESC feature is negotiated, Windows guest uses indirect
for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD &
virtio-net kernel driver) use indirect only for Tx.
I'll implement indirect support for the Rx path in vhost lib, but the
change will be too big for -rc release.
I propose in the mean time to disable INDIRECT_DESC feature in vhost
lib, we can still enable it locally for testing.
Yuanhan, is it ok for you?
> Has anyone already tested Windows guest with vhost-net, which also has
> indirect descs support?
I tested and confirm it works with vhost-net.
Regards,
Maxime
^ permalink raw reply
* Re: [PATCH 0/3] Improvements in packet timestamps support
From: Nélio Laranjeiro @ 2016-10-17 11:24 UTC (permalink / raw)
To: Oleg Kuporosov; +Cc: dev
In-Reply-To: <1476369308-17021-1-git-send-email-olegk@mellanox.com>
On Thu, Oct 13, 2016 at 02:35:05PM +0000, Oleg Kuporosov wrote:
>
> Hello DPDK Developers,
>
> Financial Services Industry which is pretty eager for several DPDK
> features especially low latency while high throughput. The major issue
> so far for increasing DPDK adoption there is requirement for several
> applications (capturers, some trading algorithms) to support of accurate
> timestamping. The requirement mostly came from regulatory and customers
> need strictly follow it.
>
> Current state of timestamping support in DPDK looks pretty good:
> - there is API to enable/disable timestamping acquisition by
> rte_eth_timesync_enable/disable
> - get timestamps itself by timesync_read_rx/tx_timestamp
> - and even implementation of NTP IEEE 1588 for time synchronization
> by rte_eth_timesync_adjust_read/write_time APIs.
>
> But it misses the most important feature there – embedding timestamp
> in rte_mbuf aligning it with packet.
>
> We would like to change this to increase DPDK adoption for several new
> DPDK-based applications for FSI segment. It also might be very
> applicable for several RT media and debugging purposes of network
> flows/streams in other segments like HPC.
>
> There are several thoughts how to improve there:
> - include uint64_t timestamp field into rte_mbuf with minimal impact
> to throughput/latency. Keep it just simple uint64_t in ns (more than
> 580 years) would be enough for immediate needs while using full
> struct timespec with twice bigger size would have much stronger
> performance impact as missed cacheline0. It is possible as there is
> 6-bytes gap in 1st cacheline (fast path) and moving uint16_t
> vlan_tci_outer field to 2nd cacheline.
> - such move will only impact for pretty rare usable VLAN RX stripping
> mode for outer TCI (it used only for one NIC i40e from the whole
> set and keep minimal performance impact for timestamps.
> - PMD can fill the field in their callback completion routines
> depending on enabling this feature in runtime.
>
> We evaluated other possible options but looks it will have even worse
> performance impact.
>
>
> Oleg Kuporosov (3):
> mbuf: embedding timestamp into the packet
> app/testpmd: enabled control for packet timestamps
> net/mlx5: implementation of Rx packet timestamping support
>
> app/test-pmd/cmdline.c | 122 +++++++++++++++
> app/test-pmd/parameters.c | 4 +
> app/test-pmd/testpmd.c | 5 +
> app/test-pmd/testpmd.h | 1 +
> doc/guides/testpmd_app_ug/run_app.rst | 4 +
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 +
> drivers/net/mlx5/mlx5.c | 7 +-
> drivers/net/mlx5/mlx5.h | 10 +-
> drivers/net/mlx5/mlx5_defs.h | 4 +
> drivers/net/mlx5/mlx5_ethdev.c | 222 +++++++++++++++++++++++++++-
> drivers/net/mlx5/mlx5_rxq.c | 2 +
> drivers/net/mlx5/mlx5_rxtx.c | 19 ++-
> drivers/net/mlx5/mlx5_rxtx.h | 7 +-
> drivers/net/mlx5/mlx5_time.h | 53 +++++++
> drivers/net/mlx5/mlx5_trigger.c | 1 +
> lib/librte_eal/common/include/rte_time.h | 45 ++++++
> lib/librte_mbuf/rte_mbuf.h | 6 +-
> 17 files changed, 507 insertions(+), 12 deletions(-)
> create mode 100644 drivers/net/mlx5/mlx5_time.h
>
> Thanks,
> Oleg.
> --
> 1.8.3.1
Reviewed-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
--
Nélio Laranjeiro
6WIND
^ permalink raw reply
* Re: Project Governance and Linux Foundation
From: O'Driscoll, Tim @ 2016-10-17 11:52 UTC (permalink / raw)
To: Hobywan Kenoby, dev@dpdk.org, users@dpdk.org
In-Reply-To: <DB5PR06MB1686CA2F232716D9E2D2D0ACC0D00@DB5PR06MB1686.eurprd06.prod.outlook.com>
Hi HK,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Hobywan Kenoby
> Sent: Monday, October 17, 2016 11:24 AM
> To: O'Driscoll, Tim <tim.odriscoll@intel.com>; dev@dpdk.org;
> users@dpdk.org
> Subject: Re: [dpdk-dev] Project Governance and Linux Foundation
>
> Hi Tim,
>
>
> The Linux kernel community has a governance close to DPDK. It did allow
> companies to grow largebusinesses and indivuals to take an
> active and even influencial roles based on their technical expertise and
> merits.
>
> I don't really understand what can be gained by moving to Linux
> Foundation, but I am almost sure that no individual expert will be able
> to take any leaderhip role as those roles will be fulfilled by Platinum,
> Gold or Silver members: right ?
No. If DPDK were to move to LF as an independent project, then as discussed at the Userspace event in Dublin last year, and as documented in the original post below, the intention would be not to make any significant changes to the technical governance.
If DPDK were to move to FD.io the situation would be the same. The FD.io Technical Community Charter (https://fd.io/governance/technical-community-charter) specifies how Project Technical Leaders and Committers are nominated and approved, but there's no requirement for people in those roles to come from Platinum, Gold or Silver FD.io members. Those decisions are based purely on technical merit.
> VPP is a virtual switch that has its own event model that may compete
> with the new model proposed by Intel, Cavium and NXP. What would be the
> acceptability of such a proposal if DPDK would have been folded into
> FD.IO?
Acceptance of the libeventdev proposal would be no different if DPDK were part of FD.io. It would be reviewed and accepted based on its technical merit.
FD.io is an umbrella project comprising a number of individual sub-projects. Those sub-projects are free to make their own technical decisions. This is documented in the Guiding Principles section of the FD.io Technical Community Charter (https://fd.io/governance/technical-community-charter):
4.Technical decisions (including release decisions) for a project should be made by consensus of that project's Committers. If consensus cannot be reached, decisions are made by a majority vote of a project's Committers. Committers on a project may, by majority vote, delegate (or revoke delegation of) any portion of the project's decisions to an alternate open, documented, traceable decision making process.
> Intellectual property is probably properly handled in this community (I
> don't really know a lot about this): are there things to be done on DPDK
> to match was proved to be sufficient in Linux kernel?
I think Intellectual Property is already properly handled within DPDK. Being part of the Linux Foundation would provide a legal framework for dealing with any trademark or other legal issues that may occur in future.
> The current DPDK version can run on virtually all processors (Intel, IBM
> and ARM) and leverage all NICs: is there **really** anyone questionning
> openness of the community?
I still hear concerns on this, and based on discussions with others who put their names to the post below, they do too. I think it's a perception that we need to address.
>
> - HK
>
>
>
> ________________________________
> From: dev <dev-bounces@dpdk.org> on behalf of O'Driscoll, Tim
> <tim.odriscoll@intel.com>
> Sent: Monday, October 10, 2016 10:33 AM
> To: dev@dpdk.org; users@dpdk.org
> Subject: [dpdk-dev] Project Governance and Linux Foundation
>
> This email is being sent on behalf of: Cavium, Cisco, Intel, NXP & Red
> Hat.
>
>
> Since its creation as an open source project in 2013, DPDK has grown
> significantly. The number of DPDK users, contributors, commercial
> products that use DPDK and open source projects that depend on it have
> all increased consistently over that time. DPDK is now a key ingredient
> in networking and NFV, and we need to ensure that the project structure
> and governance are appropriate for such a critical project, and that
> they facilitate the project's continued growth.
>
> For over a year now we've been discussing moving DPDK to the Linux
> Foundation. We believe it's now time to conclude that discussion and
> make the move. The benefits of doing this would include:
> - The infrastructure for a project like DPDK should not be owned and
> controlled by any single company.
> - Remove any remaining perception that DPDK is not truly open.
> - Allow the project to avail of the infrastructure and services provided
> by the Linux Foundation. These include things like: Ability to host
> infrastructure for integration and testing (the FD.io CSIT lab is an
> example of this - see https://wiki.fd.io/view/CSIT/CSIT_LF_testbed);
> Support for legal issues including trademarks and branding, and the
> ability to sign agreements on behalf of the project; Ability to pool
> resources for events and brand promotion; Safe haven for community IP
> resources.
> CSIT/CSIT LF testbed -
> fd.io<https://wiki.fd.io/view/CSIT/CSIT_LF_testbed>
> wiki.fd.io
> FD.IO CSIT testbed - Server HW Configuration. CSIT testbed contains
> following three HW configuration types of UCS x86 servers, across total
> of ten servers provided:
>
>
>
>
> We don't propose to debate the details here. Instead, an open discussion
> session on DPDK Project Growth has been included in the agenda for the
> DPDK Summit Userspace 2016 event in Dublin. We propose using that
> session to agree that the DPDK project will move to the Linux
> Foundation, and then to move on to discussing the specifics. Things that
> we'll need to consider include:
> - Whether DPDK moves to the Linux Foundation as an independent project
> or as part of a larger project like FD.io.
> - Creation of a project charter similar to those created for FD.io
> (https://fd.io/governance/technical-community-charter) and Open vSwitch
> (see
> http://openvswitch.org/pipermail/discuss/attachments/20160619/5a2df53e/a
> ttachment-0001.pdf).
> [https://fd.io/sites/cpstandard/files/theme/backgrounds/bg.jpg]<https://
> fd.io/governance/technical-community-charter>
>
> Technical Community Charter | FD.io<https://fd.io/governance/technical-
> community-charter>
> fd.io
> 3.3.4 Project Reviews. For each review, there will be a publicly visible
> wiki/web template filled out containing relevant review information. The
> review document must ...
>
>
>
> - Agreement on budget, membership levels etc. A draft budget was created
> by the LF during previous discussions
> (https://docs.google.com/spreadsheets/d/1-
> 3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=302618256), but it
> is possible to adopt an even more lightweight model.
>
> We could look at alternatives to the Linux Foundation, but a) we've been
> talking to the LF for over a year now, and b) the preponderance of
> networking projects in LF, like ODL, FD.io, and OVS, makes it a natural
> destination for DPDK.
>
> As highlighted in previous discussions on this topic, it's important to
> stress that the intent is not to make significant changes to the
> technical governance and decision making of the project. The project has
> a strong set of maintainers and a Technical Board in place already.
> What's required is to supplement that with an open governance structure
> taking advantage of the services offered by the Linux Foundation.
>
> The purpose of this email is to outline what we want to achieve during
> that discussion session in Dublin, and to allow people to consider the
> issue and prepare in advance. If people want to comment via email on the
> mailing list, that's obviously fine, but we believe that an open and
> frank discussion when people meet in person in Dublin is the best way to
> progress this.
>
>
> For reference, below is a brief history of the previous discussions on
> this topic:
>
> September 2015:
> - A DPDK community call was held to discuss project growth and possible
> improvements. This was the first public discussion on possible
> governance changes. The agreed next step was to discuss this in more
> detail at the 2015 DPDK Summit Userspace event Dublin. Minutes of the
> call are at: http://dpdk.org/ml/archives/dev/2015-September/024120.html.
>
> October 2015:
> - An open discussion session on project governance was held at the 2015
> DPDK Summit Userspace event. For technical governance, we agreed to
> investigate creating a technical steering committee. For non-technical
> governance (including things like event planning, legal and trademark
> issues, hosting of the website etc.), we agreed to work with the Linux
> Foundation on a proposal for a lightweight governance model for DPDK.
> Minutes of the discussion are at: http://dpdk.org/ml/archives/dev/2015-
> October/024825.html.
>
> - The proposal for a technical steering committee was subsequently
> discussed on the mailing list (http://dpdk.org/ml/archives/dev/2015-
> October/026598.html) and agreed, leading to the creation of the DPDK
> Technical Board (http://dpdk.org/dev#board).
>
> December 2015:
> - A community call was held to discuss migration to the Linux
> Foundation. Mike Dolan (VP of Strategic Programs at The Linux
> Foundation) gave an overview of the LF and the services they can
> provide. We agreed to form a small sub-team (Dave Neary, Thomas
> Monjalon, Stephen Hemminger, Tim O'Driscoll) to work with the LF on a
> more detailed proposal. Minutes of the call are at:
> http://dpdk.org/ml/archives/dev/2015-December/030532.html.
>
> February 2016:
> - A community call was held to discuss the LF budget proposal (see
> https://docs.google.com/spreadsheets/d/1-
> 3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=302618256). We
> agreed to discuss this further on the dev mailing list due to limited
> attendance on the call. Minutes of the call are at:
> http://dpdk.org/ml/archives/dev/2016-February/032720.html.
>
> - A request was made on the dev and announce mailing lists too determine
> who supported the proposal to move to the Linux Foundation
> (http://dpdk.org/ml/archives/dev/2016-February/033192.html). There was
> public support from Intel (http://dpdk.org/ml/archives/dev/2016-
> February/033297.html) and Brocade (http://dpdk.org/ml/archives/dev/2016-
> February/033359.html). 6WIND requested postponing the move for a few
> months (http://dpdk.org/ml/archives/dev/2016-February/033299.html).
>
> - The Fast Data (FD.io) project was established under the Linux
> Foundation (https://fd.io/news/announcement/2016/02/linux-foundation-
> forms-open-source-effort-advance-io-services).
> [https://fd.io/sites/cpstandard/files/theme/backgrounds/bg.jpg]<https://
> fd.io/news/announcement/2016/02/linux-foundation-forms-open-source-
> effort-advance-io-services>
>
> The Linux Foundation Forms Open Source Effort to Advance
> ...<https://fd.io/news/announcement/2016/02/linux-foundation-forms-open-
> source-effort-advance-io-services>
> fd.io
> Industry leaders unite for Fast Data (FD.io) Project; aims to establish
> a high-performance IO services framework for dynamic computing
> environments
>
>
>
>
> June 2016:
> - The Open vSwitch project proposed moving to the Linux Foundation
> (http://openvswitch.org/pipermail/discuss/2016-June/021761.html).
> [ovs-discuss] Request for comments on Open vSwitch joining
> ...<http://openvswitch.org/pipermail/discuss/2016-June/021761.html>
> openvswitch.org
> Since roughly October, some of the OVS committers have been talking over
> the idea of bringing Open vSwitch into a foundation. Originally the
> group discussing the idea ...
>
>
>
>
> August 2016:
> - The Open vSwitch project moved to the Linux Foundation
> (https://www.linuxfoundation.org/announcements/open-vswitch-joins-linux-
> foundation-open-networking-ecosystem).
> Open vSwitch Joins Linux Foundation Open Networking
> ...<https://www.linuxfoundation.org/announcements/open-vswitch-joins-
> linux-foundation-open-networking-ecosystem>
> www.linuxfoundation.org
> SAN FRANCISCO - AUGUST 09, 2016 - The Linux Foundation, the nonprofit
> advancing professional open source management for mass collaboration
> today is announcing ...
>
>
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix init on secondary process
From: Ferruh Yigit @ 2016-10-17 12:05 UTC (permalink / raw)
To: Adrien Mazarguil, Olivier Gournet; +Cc: dev
In-Reply-To: <20161011094538.GO17252@6wind.com>
Hi Olivier,
On 10/11/2016 10:45 AM, Adrien Mazarguil wrote:
> Hi Olivier,
>
> Secondary process support's got overlooked during this refactoring, thanks
> for the patch. However can you describe the issue you're addressing as part
> of the commit log?
>
> I think problems started when txq got mistakenly converted to
> primary_txq_ctrl in 21c8bb4928c9 ("net/mlx5: split Tx queue structure"), you
> may add a Fixes line for that one as well.
>
> Otherwise, this patch looks fine to me.
>
Patch doesn't apply cleanly, can you please rebase the patch on top of
latest dpdk-next-net?
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH] net/bnx2x: fix icc build error
From: Ferruh Yigit @ 2016-10-17 12:11 UTC (permalink / raw)
To: dev; +Cc: Sony Chacko, Harish Patil, Rasesh Mody
In-Reply-To: <20160930144515.1770-1-ferruh.yigit@intel.com>
On 9/30/2016 3:45 PM, Ferruh Yigit wrote:
> When bnx2x debug config enabled, icc (ICC) 17.0.0 20160721
> gives the following compilation error:
>
> .../drivers/net/bnx2x/elink.c(6682):
> error #3656: variable "fw_ver1" may be used before its value is set
> PMD_DRV_LOG(DEBUG,
> ^
>
> According logic in the code, this error is a false positive,
> but since this is not in the fast path, fixing compiler error by
> assigning initial value to variable.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---
> drivers/net/bnx2x/elink.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/bnx2x/elink.c b/drivers/net/bnx2x/elink.c
> index 149cc97..d9a72f0 100644
> --- a/drivers/net/bnx2x/elink.c
> +++ b/drivers/net/bnx2x/elink.c
> @@ -6645,7 +6645,7 @@ static elink_status_t elink_8073_8727_external_rom_boot(struct bnx2x_softc *sc,
> uint8_t port)
> {
> uint32_t count = 0;
> - uint16_t fw_ver1, fw_msgout;
> + uint16_t fw_ver1 = 0, fw_msgout;
> elink_status_t rc = ELINK_STATUS_OK;
>
> /* Boot port from external ROM */
>
Since this is an compilation fix, I believe it is good to have this in
the release, can you please review the patch?
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH] examples/ip_pipeline: fix gcc v6.2.1 build error
From: Dumitrescu, Cristian @ 2016-10-17 12:40 UTC (permalink / raw)
To: Singh, Jasvinder, dev@dpdk.org
In-Reply-To: <1476701476-61706-1-git-send-email-jasvinder.singh@intel.com>
> -----Original Message-----
> From: Singh, Jasvinder
> Sent: Monday, October 17, 2016 11:51 AM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Subject: [PATCH] examples/ip_pipeline: fix gcc v6.2.1 build error
>
> This patch fixes the misleading indentation error on compiling ip_pipeline
> app with gcc v6.2.1.
>
> Fixes: 3f2c9f3bb6c6 ("examples/ip_pipeline: add TAP port")
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> ---
> examples/ip_pipeline/app.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
^ permalink raw reply
* Re: [dpdk-users] Project Governance and Linux Foundation
From: Thomas Monjalon @ 2016-10-17 12:40 UTC (permalink / raw)
To: users, dev; +Cc: O'Driscoll, Tim, Hobywan Kenoby
In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA675F6F33@IRSMSX108.ger.corp.intel.com>
2016-10-17 11:52, O'Driscoll, Tim:
> From: Hobywan Kenoby
> > The current DPDK version can run on virtually all processors (Intel, IBM
> > and ARM) and leverage all NICs: is there **really** anyone questionning
> > openness of the community?
>
> I still hear concerns on this, and based on discussions with others who
> put their names to the post below, they do too.
> I think it's a perception that we need to address.
It is simple to address this perception with fact checking.
The next releases will provide even more code for ARM and NPUs.
If someone submits some good code and is ignored, it is easy enough
to ping the mailing list and make it visible.
If someone sees any regression on his architecture, we care.
Please let's stop maintaining confusion on this topic.
DPDK *is* truly open.
^ permalink raw reply
* [PATCH v2] net/mlx5: fix init on secondary process
From: Olivier Gournet @ 2016-10-17 12:56 UTC (permalink / raw)
To: dev; +Cc: Adrien Mazarguil, Nelio Laranjeiro, Olivier Gournet
In-Reply-To: <1475072658-29534-1-git-send-email-ogournet@corp.free.fr>
Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
Fixes: 21c8bb4928c9 ("net/mlx5: split Tx queue structure")
Signed-off-by: Olivier Gournet <ogournet@corp.free.fr>
---
drivers/net/mlx5/mlx5_ethdev.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index c76e754..188ade9 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -1309,11 +1309,13 @@ mlx5_secondary_data_setup(struct priv *priv)
continue;
primary_txq_ctrl = container_of(primary_txq,
struct txq_ctrl, txq);
- txq_ctrl = rte_calloc_socket("TXQ", 1, sizeof(*txq_ctrl), 0,
+ txq_ctrl = rte_calloc_socket("TXQ", 1, sizeof(*txq_ctrl) +
+ (1 << primary_txq->elts_n) *
+ sizeof(struct rte_mbuf *), 0,
primary_txq_ctrl->socket);
if (txq_ctrl != NULL) {
if (txq_ctrl_setup(priv->dev,
- primary_txq_ctrl,
+ txq_ctrl,
1 << primary_txq->elts_n,
primary_txq_ctrl->socket,
NULL) == 0) {
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 1/3] eal/drivers: prefix driver REGISTER macros with EAL
From: Neil Horman @ 2016-10-17 13:09 UTC (permalink / raw)
To: Shreyansh Jain; +Cc: Thomas Monjalon, david.marchand@6wind.com, dev@dpdk.org
In-Reply-To: <DB5PR0401MB205420FE835BE96E45D7838390D90@DB5PR0401MB2054.eurprd04.prod.outlook.com>
On Sat, Oct 08, 2016 at 12:47:59PM +0000, Shreyansh Jain wrote:
>
>
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Friday, October 07, 2016 7:15 PM
> > To: Shreyansh Jain <shreyansh.jain@nxp.com>
> > Cc: david.marchand@6wind.com; dev@dpdk.org
> > Subject: Re: [PATCH 1/3] eal/drivers: prefix driver REGISTER macros with EAL
> >
> > 2016-10-07 19:03, Shreyansh Jain:
> > > DRIVER_REGISTER_PCI -> EAL_REGISTER_PCI
> > > DRIVER_REGISTER_PCI_TABLE -> EAL_REGISTER_PCI_TABLE
> >
> > Why not RTE_ prefix instead of EAL_?
>
> Because while searching for similar naming pattern I came across other macros like EAL_REGISTER_TAILQ which were within librte_eal/eal/* folders.
>
This is why we were suggesting to make the regex in the makefile more specific,
to avoid matching on the TAILQ macro.
> > Why 3 patches? As there is no specific comment in each, I think you can
> > squash.
>
> Because each of the patch are common and tightly related changes. The replacement touches a large number of files, even though the change itself is small. By splitting, it makes review (or minor misses) easier - at least for me.
> Anyways, if as a maintainer you prefer having a single bulk, I have no issues.
>
> I will send next version with RTE_* and the 'grep -E' suggestion from Neil.
>
> -
> Shreyansh
>
^ 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