[dpdk-dev] [PATCH v4 1/2] mbuf: introduce new Tx offload flag for MPLS-in-UDP

[Rasesh Mody]

From: Harish Patil 

Some PMDs need to know the tunnel type in order to handle advance TX
features. This patch adds a new TX offload flag for MPLS-in-UDP packets.

Signed-off-by: Harish Patil 
---
 lib/librte_mbuf/rte_mbuf.c |3 +++
 lib/librte_mbuf/rte_mbuf.h |2 ++
 2 files changed, 5 insertions(+)

diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 0e3e36a..c853b52 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -410,6 +410,7 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask)
case PKT_TX_TUNNEL_IPIP: return "PKT_TX_TUNNEL_IPIP";
case PKT_TX_TUNNEL_GENEVE: return "PKT_TX_TUNNEL_GENEVE";
case PKT_TX_MACSEC: return "PKT_TX_MACSEC";
+   case PKT_TX_TUNNEL_MPLSINUDP: return "PKT_TX_TUNNEL_MPLSINUDP";
default: return NULL;
}
 }
@@ -440,6 +441,8 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask)
  "PKT_TX_TUNNEL_NONE" },
{ PKT_TX_TUNNEL_GENEVE, PKT_TX_TUNNEL_MASK,
  "PKT_TX_TUNNEL_NONE" },
+   { PKT_TX_TUNNEL_MPLSINUDP, PKT_TX_TUNNEL_MASK,
+ "PKT_TX_TUNNEL_NONE" },
{ PKT_TX_MACSEC, PKT_TX_MACSEC, NULL },
};
const char *name;
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index fe605c7..78318be 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -208,6 +208,8 @@
 #define PKT_TX_TUNNEL_GRE (0x2ULL << 45)
 #define PKT_TX_TUNNEL_IPIP(0x3ULL << 45)
 #define PKT_TX_TUNNEL_GENEVE  (0x4ULL << 45)
+/**< TX packet with MPLS-in-UDP RFC 7510 header. */
+#define PKT_TX_TUNNEL_MPLSINUDP (0x5ULL << 45)
 /* add new TX TUNNEL type here */
 #define PKT_TX_TUNNEL_MASK(0xFULL << 45)
 
-- 
1.7.10.3

[dpdk-dev] [PATCH v4 2/2] net/qede: add Tx offloads for MPLS-in-UDP packets

[Rasesh Mody]

From: Harish Patil 

Add support for inner/outer L3/L4 TX csum offload for MPLS-in-UDP packets.
The driver checks for PKT_TX_TUNNEL_MPLSINUDP in Tx ol_flags and updates TX
BD elements with appropriate offsets/length of tunnel headers.
The pseudo csum calculation is removed from qede_xmit_prep_pkts() since its
not needed.

Note: Some lines are exceeding 80 columns and is intentionally
not fixed since it affects code readability.

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
---
 drivers/net/qede/qede_rxtx.c |  198 --
 drivers/net/qede/qede_rxtx.h |3 +-
 2 files changed, 152 insertions(+), 49 deletions(-)

diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
index f65c833..f0fbfe8 100644
--- a/drivers/net/qede/qede_rxtx.c
+++ b/drivers/net/qede/qede_rxtx.c
@@ -1445,7 +1445,9 @@ static inline uint32_t 
qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
uint64_t ol_flags;
struct rte_mbuf *m;
uint16_t i;
+#ifdef RTE_LIBRTE_ETHDEV_DEBUG
int ret;
+#endif
 
for (i = 0; i < nb_pkts; i++) {
m = tx_pkts[i];
@@ -1478,14 +1480,6 @@ static inline uint32_t 
qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
break;
}
 #endif
-   /* TBD: pseudo csum calcuation required if
-* ETH_TX_DATA_2ND_BD_L4_PSEUDO_CSUM_MODE not set?
-*/
-   ret = rte_net_intel_cksum_prepare(m);
-   if (ret != 0) {
-   rte_errno = ret;
-   break;
-   }
}
 
 #ifdef RTE_LIBRTE_QEDE_DEBUG_TX
@@ -1496,6 +1490,27 @@ static inline uint32_t 
qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
return i;
 }
 
+#define MPLSINUDP_HDR_SIZE (12)
+
+#ifdef RTE_LIBRTE_QEDE_DEBUG_TX
+static inline void
+qede_mpls_tunn_tx_sanity_check(struct rte_mbuf *mbuf,
+  struct qede_tx_queue *txq)
+{
+   if (((mbuf->outer_l2_len + mbuf->outer_l3_len) / 2) > 0xff)
+   PMD_TX_LOG(ERR, txq, "tunn_l4_hdr_start_offset overflow\n");
+   if (((mbuf->outer_l2_len + mbuf->outer_l3_len +
+   MPLSINUDP_HDR_SIZE) / 2) > 0xff)
+   PMD_TX_LOG(ERR, txq, "tunn_hdr_size overflow\n");
+   if (((mbuf->l2_len - MPLSINUDP_HDR_SIZE) / 2) >
+   ETH_TX_DATA_2ND_BD_TUNN_INNER_L2_HDR_SIZE_W_MASK)
+   PMD_TX_LOG(ERR, txq, "inner_l2_hdr_size overflow\n");
+   if (((mbuf->l2_len - MPLSINUDP_HDR_SIZE + mbuf->l3_len) / 2) >
+   ETH_TX_DATA_2ND_BD_L4_HDR_START_OFFSET_W_MASK)
+   PMD_TX_LOG(ERR, txq, "inner_l2_hdr_size overflow\n");
+}
+#endif
+
 uint16_t
 qede_xmit_pkts(void *p_txq, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
 {
@@ -1510,9 +1525,10 @@ static inline uint32_t 
qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
uint16_t nb_frags;
uint16_t nb_pkt_sent = 0;
uint8_t nbds;
-   bool ipv6_ext_flg;
bool lso_flg;
+   bool mplsoudp_flg;
__rte_unused bool tunn_flg;
+   bool tunn_ipv6_ext_flg;
struct eth_tx_1st_bd *bd1;
struct eth_tx_2nd_bd *bd2;
struct eth_tx_3rd_bd *bd3;
@@ -1529,6 +1545,10 @@ static inline uint32_t 
qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
uint16_t mss;
uint16_t bd3_bf;
 
+   uint8_t tunn_l4_hdr_start_offset;
+   uint8_t tunn_hdr_size;
+   uint8_t inner_l2_hdr_size;
+   uint16_t inner_l4_hdr_offset;
 
if (unlikely(txq->nb_tx_avail < txq->tx_free_thresh)) {
PMD_TX_LOG(DEBUG, txq, "send=%u avail=%u free_thresh=%u",
@@ -1540,7 +1560,6 @@ static inline uint32_t 
qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
bd_prod = rte_cpu_to_le_16(ecore_chain_get_prod_idx(&txq->tx_pbl));
while (nb_tx_pkts--) {
/* Init flags/values */
-   ipv6_ext_flg = false;
tunn_flg = false;
lso_flg = false;
nbds = 0;
@@ -1555,6 +1574,10 @@ static inline uint32_t 
qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
bd2_bf2 = 0;
mss = 0;
bd3_bf = 0;
+   mplsoudp_flg = false;
+   tunn_ipv6_ext_flg = false;
+   tunn_hdr_size = 0;
+   tunn_l4_hdr_start_offset = 0;
 
mbuf = *tx_pkts++;
assert(mbuf);
@@ -1566,20 +1589,18 @@ static inline uint32_t 
qede_rx_cqe_to_tunn_pkt_type(uint16_t flags)
tx_ol_flags = mbuf->ol_flags;
bd1_bd_flags_bf |= 1 << ETH_TX_1ST_BD_FLAGS_START_BD_SHIFT;
 
-#define RTE_ETH_IS_IPV6_HDR_EXT(ptype) ((ptype) & RTE_PTYPE_L3_IPV6_EXT)
-   if (RTE_ETH_IS_IPV6_HDR_EXT(mbuf->packet_type)) {
-   ipv6_ext_flg = true;
+   /* TX prepare would have already checked supported tunnel Tx
+* offloads. Don't rely on pkt_type marked by Rx, instead use
+ 

Re: [dpdk-dev] [PATCH] eventdev: add producer enqueue hint

[Jerin Jacob]

-Original Message-
> Date: Mon, 26 Jun 2017 15:44:10 +
> From: "Eads, Gage" 
> To: Jerin Jacob , "dev@dpdk.org"
>  
> CC: "Richardson, Bruce" , "Van Haaren, Harry"
>  , "hemant.agra...@nxp.com"
>  , "nipun.gu...@nxp.com" ,
>  "Vangati, Narender" , "Rao, Nikhil"
>  
> Subject: RE: [dpdk-dev] [PATCH] eventdev: add producer enqueue hint
> 
> 
> 
> > -Original Message-
> > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> > Sent: Monday, June 12, 2017 6:46 AM
> > To: dev@dpdk.org
> > Cc: Richardson, Bruce ; Van Haaren, Harry
> > ; hemant.agra...@nxp.com; Eads, Gage
> > ; nipun.gu...@nxp.com; Vangati, Narender
> > ; Rao, Nikhil ; Jerin 
> > Jacob
> > 
> > Subject: [dpdk-dev] [PATCH] eventdev: add producer enqueue hint
> > 
> > Some PMD like OCTEONTX can have optimized handling of events if the PMD
> > knows it is a producer pattern in advance.
> > For instance, OCTEONTX PMD can support burst mode if op ==
> > RTE_EVENT_OP_NEW.
> > 
> > Since the event producer initialize(set all_op_new == 1) the event object 
> > before
> > the main producer loop, This scheme does not call for any performance
> > regression on other PMDs.
> > 
> > Signed-off-by: Jerin Jacob 
> > ---
> > Another option is to add a flag in enqueue API or have parallel enqueue API.
> > ---
> >  drivers/event/octeontx/ssovf_worker.c | 12 ++--
> >  lib/librte_eventdev/rte_eventdev.h| 10 +-
> >  2 files changed, 19 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/event/octeontx/ssovf_worker.c
> > b/drivers/event/octeontx/ssovf_worker.c
> > index ad3fe684d..209c595cf 100644
> > --- a/drivers/event/octeontx/ssovf_worker.c
> > +++ b/drivers/event/octeontx/ssovf_worker.c
> > @@ -196,8 +196,16 @@ ssows_enq(void *port, const struct rte_event *ev)
> > uint16_t __hot  ssows_enq_burst(void *port, const struct rte_event ev[],
> > uint16_t nb_events)  {
> > -   RTE_SET_USED(nb_events);
> > -   return ssows_enq(port, ev);
> > +   uint16_t i;
> > +   struct ssows *ws = port;
> > +
> > +   if (ev[0].all_op_new) {
> > +   rte_smp_wmb();
> > +   for (i = 0; i < nb_events; i++)
> > +   ssows_new_event(ws, &ev[i]);
> > +   return i;
> > +   } else
> > +   return ssows_enq(port, ev);
> >  }
> > 
> >  void
> > diff --git a/lib/librte_eventdev/rte_eventdev.h
> > b/lib/librte_eventdev/rte_eventdev.h
> > index a248fe90e..1c1a46593 100644
> > --- a/lib/librte_eventdev/rte_eventdev.h
> > +++ b/lib/librte_eventdev/rte_eventdev.h
> > @@ -933,7 +933,15 @@ struct rte_event {
> >  * and is undefined on dequeue.
> >  * @see RTE_EVENT_OP_NEW, (RTE_EVENT_OP_*)
> >  */
> > -   uint8_t rsvd:4;
> > +   uint8_t all_op_new:1;
> > +   /**< Valid only with event enqueue operation - This hint
> > +* indicates that the enqueue request has only the
> > +* events with op == RTE_EVENT_OP_NEW.
> > +* The event producer, typically use this pattern to
> > +* inject the events to eventdev.
> > +* @see RTE_EVENT_OP_NEW
> > rte_event_enqueue_burst()
> > +*/
> > +   uint8_t rsvd:3;
> > /**< Reserved for future use */
> > uint8_t sched_type:2;
> > /**< Scheduler synchronization type
> > (RTE_SCHED_TYPE_*)
> > --
> > 2.13.1
> 
> I slightly prefer the parallel enqueue API -- I can see folks making the 
> mistake of setting all_op_new without setting the op to RTE_EVENT_OP_NEW, and 
> later adding a "forward-only" enqueue API could be interesting for the sw PMD 
> -- but this looks fine to me. Curious if others have any thoughts.

If forward-only parallel enqueue API interesting for the SW PMD then I
can drop this one and introduce forward-only API. Let me know if others
have any thoughts?

[dpdk-dev] [PATCH v2 0/2] net/i40e: extended list of operations for ddp processing

[Andrey Chilikin]

This patchset adds two new operations for dynamic device personalisation:
* remove already loaded profile and delete it from the list
* write profile without registering it

This patchset depends on:
[PATCH v2 00/16] net/i40e: base code update
http://dpdk.org/ml/archives/dev/2017-June/068732.html
http://dpdk.org/dev/patchwork/patch/25705/

v2:
- Local static functions replaced by corresponding new
  functions in i40e base code
- Test-pmd command added


Andrey Chilikin (2):
  net/i40e: extended list of operations for ddp processing
  app/testpmd: enable ddp remove profile feature

 app/test-pmd/cmdline.c  | 103 ++--
 app/test-pmd/config.c   |  21 ++
 app/test-pmd/testpmd.h  |   1 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |   7 ++
 drivers/net/i40e/rte_pmd_i40e.c |  87 ---
 drivers/net/i40e/rte_pmd_i40e.h |   6 +-
 6 files changed, 191 insertions(+), 34 deletions(-)

-- 
2.13.0

[dpdk-dev] [PATCH v2 1/2] net/i40e: extended list of operations for ddp processing

[Andrey Chilikin]

This patch adds ability to remove already loaded profile
or write profile without registering it

Signed-off-by: Andrey Chilikin 
---
 drivers/net/i40e/rte_pmd_i40e.c | 87 +
 drivers/net/i40e/rte_pmd_i40e.h |  6 ++-
 2 files changed, 66 insertions(+), 27 deletions(-)

diff --git a/drivers/net/i40e/rte_pmd_i40e.c b/drivers/net/i40e/rte_pmd_i40e.c
index f7ce62b..e292903 100644
--- a/drivers/net/i40e/rte_pmd_i40e.c
+++ b/drivers/net/i40e/rte_pmd_i40e.c
@@ -1557,11 +1557,7 @@ i40e_check_profile_info(uint8_t port, uint8_t 
*profile_info_sec)
 sizeof(struct i40e_profile_section_header));
for (i = 0; i < p_list->p_count; i++) {
p = &p_list->p_info[i];
-   if ((pinfo->track_id == p->track_id) &&
-   !memcmp(&pinfo->version, &p->version,
-   sizeof(struct i40e_ddp_version)) &&
-   !memcmp(&pinfo->name, &p->name,
-   I40E_DDP_NAME_SIZE)) {
+   if (pinfo->track_id == p->track_id) {
PMD_DRV_LOG(INFO, "Profile exists.");
rte_free(buff);
return 1;
@@ -1587,6 +1583,13 @@ rte_pmd_i40e_process_ddp_package(uint8_t port, uint8_t 
*buff,
int is_exist;
enum i40e_status_code status = I40E_SUCCESS;
 
+   if (op != RTE_PMD_I40E_PKG_OP_WR_ADD &&
+   op != RTE_PMD_I40E_PKG_OP_WR_ONLY &&
+   op != RTE_PMD_I40E_PKG_OP_WR_DEL) {
+   PMD_DRV_LOG(ERR, "Operation not supported.");
+   return -ENOTSUP;
+   }
+
RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
 
dev = &rte_eth_devices[port];
@@ -1623,6 +1626,10 @@ rte_pmd_i40e_process_ddp_package(uint8_t port, uint8_t 
*buff,
return -EINVAL;
}
track_id = ((struct i40e_metadata_segment *)metadata_seg_hdr)->track_id;
+   if (track_id == I40E_DDP_TRACKID_INVALID) {
+   PMD_DRV_LOG(ERR, "Invalid track_id");
+   return -EINVAL;
+   }
 
/* Find profile segment */
profile_seg_hdr = i40e_find_segment_in_package(SEGMENT_TYPE_I40E,
@@ -1642,40 +1649,68 @@ rte_pmd_i40e_process_ddp_package(uint8_t port, uint8_t 
*buff,
return -EINVAL;
}
 
+   /* Check if the profile already loaded */
+   i40e_generate_profile_info_sec(
+   ((struct i40e_profile_segment *)profile_seg_hdr)->name,
+   &((struct i40e_profile_segment *)profile_seg_hdr)->version,
+   track_id, profile_info_sec,
+   op == RTE_PMD_I40E_PKG_OP_WR_ADD);
+   is_exist = i40e_check_profile_info(port, profile_info_sec);
+   if (is_exist < 0) {
+   PMD_DRV_LOG(ERR, "Failed to check profile.");
+   rte_free(profile_info_sec);
+   return -EINVAL;
+   }
+
if (op == RTE_PMD_I40E_PKG_OP_WR_ADD) {
-   /* Check if the profile exists */
-   i40e_generate_profile_info_sec(
-((struct i40e_profile_segment *)profile_seg_hdr)->name,
-&((struct i40e_profile_segment *)profile_seg_hdr)->version,
-track_id, profile_info_sec, 1);
-   is_exist = i40e_check_profile_info(port, profile_info_sec);
-   if (is_exist > 0) {
+   if (is_exist) {
PMD_DRV_LOG(ERR, "Profile already exists.");
rte_free(profile_info_sec);
-   return 1;
-   } else if (is_exist < 0) {
-   PMD_DRV_LOG(ERR, "Failed to check profile.");
+   return -EEXIST;
+   }
+   } else if (op == RTE_PMD_I40E_PKG_OP_WR_DEL) {
+   if (!is_exist) {
+   PMD_DRV_LOG(ERR, "Profile does not exist.");
rte_free(profile_info_sec);
-   return -EINVAL;
+   return -EACCES;
}
+   }
 
-   /* Write profile to HW */
+   if (op == RTE_PMD_I40E_PKG_OP_WR_DEL) {
+   status = i40e_rollback_profile(
+   hw,
+   (struct i40e_profile_segment *)profile_seg_hdr,
+   track_id);
+   if (status) {
+   PMD_DRV_LOG(ERR, "Failed to write profile for delete.");
+   rte_free(profile_info_sec);
+   return status;
+   }
+   }
+   else {
status = i40e_write_profile(
-   hw,
-   (struct i40e_profile_segment *)profile_seg_hdr,
-   track_id);
+   hw,
+   (struct i40e_profile_segment *)profile_seg_hdr,
+   track_id);
if (status) {
-   PMD_DRV_LOG(ERR, "Failed to w

[dpdk-dev] [PATCH v2 2/2] app/testpmd: enable ddp remove profile feature

[Andrey Chilikin]

New command 'ddp del (port) (profile_path)' removes previously
loaded profile and deletes it from the list of the loaded profiles.

Signed-off-by: Andrey Chilikin 
---
 app/test-pmd/cmdline.c  | 103 ++--
 app/test-pmd/config.c   |  21 ++
 app/test-pmd/testpmd.h  |   1 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |   7 ++
 4 files changed, 125 insertions(+), 7 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 0afac68..73baaa6 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -602,9 +602,12 @@ static void cmd_help_long_parsed(void *parsed_result,
"E-tag set filter del e-tag-id (value) port (port_id)\n"
"Delete an E-tag forwarding filter on a port\n\n"
 
-   "ddp add (port_id) (profile_path)\n"
+   "ddp add (port_id) (profile_path[,output_path])\n"
"Load a profile package on a port\n\n"
 
+   "ddp del (port_id) (profile_path)\n"
+   "Delete a profile package from a port\n\n"
+
"ptype mapping get (port_id) (valid_only)\n"
"Get ptype mapping on a port\n\n"
 
@@ -12860,6 +12863,9 @@ cmd_ddp_add_parsed(
struct cmd_ddp_add_result *res = parsed_result;
uint8_t *buff;
uint32_t size;
+   char *filepath;
+   char *file_fld[2];
+   int file_num;
int ret = -ENOTSUP;
 
if (res->port_id > nb_ports) {
@@ -12872,9 +12878,18 @@ cmd_ddp_add_parsed(
return;
}
 
-   buff = open_ddp_package_file(res->filepath, &size);
-   if (!buff)
+   filepath = strdup(res->filepath);
+   if (filepath == NULL) {
+   printf("Failed to allocate memory\n");
return;
+   }
+   file_num = rte_strsplit(filepath, strlen(filepath), file_fld, 2, ',');
+
+   buff = open_ddp_package_file(file_fld[0], &size);
+   if (!buff) {
+   free((void *)filepath);
+   return;
+   }
 
 #ifdef RTE_LIBRTE_I40E_PMD
if (ret == -ENOTSUP)
@@ -12883,18 +12898,21 @@ cmd_ddp_add_parsed(
   RTE_PMD_I40E_PKG_OP_WR_ADD);
 #endif
 
-   if (ret < 0)
-   printf("Failed to load profile.\n");
-   else if (ret > 0)
+   if (ret == -EEXIST)
printf("Profile has already existed.\n");
+   else if (ret < 0)
+   printf("Failed to load profile.\n");
+   else if (file_num == 2)
+   save_ddp_package_file(file_fld[1], buff, size);
 
close_ddp_package_file(buff);
+   free((void *)filepath);
 }
 
 cmdline_parse_inst_t cmd_ddp_add = {
.f = cmd_ddp_add_parsed,
.data = NULL,
-   .help_str = "ddp add  ",
+   .help_str = "ddp add  ",
.tokens = {
(void *)&cmd_ddp_add_ddp,
(void *)&cmd_ddp_add_add,
@@ -12904,6 +12922,76 @@ cmdline_parse_inst_t cmd_ddp_add = {
},
 };
 
+/* Delete dynamic device personalization*/
+struct cmd_ddp_del_result {
+   cmdline_fixed_string_t ddp;
+   cmdline_fixed_string_t del;
+   uint8_t port_id;
+   char filepath[];
+};
+
+cmdline_parse_token_string_t cmd_ddp_del_ddp =
+   TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, ddp, "ddp");
+cmdline_parse_token_string_t cmd_ddp_del_del =
+   TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, del, "del");
+cmdline_parse_token_num_t cmd_ddp_del_port_id =
+   TOKEN_NUM_INITIALIZER(struct cmd_ddp_del_result, port_id, UINT8);
+cmdline_parse_token_string_t cmd_ddp_del_filepath =
+   TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, filepath, NULL);
+
+static void
+cmd_ddp_del_parsed(
+   void *parsed_result,
+   __attribute__((unused)) struct cmdline *cl,
+   __attribute__((unused)) void *data)
+{
+   struct cmd_ddp_del_result *res = parsed_result;
+   uint8_t *buff;
+   uint32_t size;
+   int ret = -ENOTSUP;
+
+   if (res->port_id > nb_ports) {
+   printf("Invalid port, range is [0, %d]\n", nb_ports - 1);
+   return;
+   }
+
+   if (!all_ports_stopped()) {
+   printf("Please stop all ports first\n");
+   return;
+   }
+
+   buff = open_ddp_package_file(res->filepath, &size);
+   if (!buff)
+   return;
+
+#ifdef RTE_LIBRTE_I40E_PMD
+   if (ret == -ENOTSUP)
+   ret = rte_pmd_i40e_process_ddp_package(res->port_id,
+  buff, size,
+  RTE_PMD_I40E_PKG_OP_WR_DEL);
+#endif
+
+   if (ret == -EACCES)
+   printf("Profile does not exist.\n");
+   else if (ret < 0)
+   printf("Failed to delete profile.\n");
+
+   close_ddp_package_file(buff);
+}
+
+cmdlin

Re: [dpdk-dev] [PATCH v4 4/4] app/testpmd: add isolated mode parameter

[Thomas Monjalon]

22/06/2017 03:13, Wu, Jingjing:
> From: Vasily Philipov [mailto:vasi...@mellanox.com]
> > From: Wu, Jingjing [mailto:jingjing...@intel.com]
> > >
> > > > +/*
> > > >   * Avoids to check link status when starting/stopping a port.
> > > >   */
> > > >  uint8_t no_link_check = 0; /* check by default */ @@ -1422,6
> > > > +1427,15 @@ static void eth_event_callback(uint8_t port_id,
> > > > if (port->need_reconfig > 0) {
> > > > port->need_reconfig = 0;
> > > >
> > > > +   if (isolated_mode) {
> > > > +   int ret = port_flow_isolate(pi, 1);
> > > > +   if (ret) {
> > > > +   printf("Failed to apply 
> > > > isolated"
> > > > +  " mode on port %d\n", 
> > > > pi);
> > > > +   return -1;
> > > > +   }
> > > > +   }
> > > > +
> > > Should it block the app startup if isolated-mode setting fails?
> > 
> > if isolated mode cannot be enabled on any port, that port cannot be 
> > initialized
> > and that causes testpmd to quit, at least it won't go against the user's 
> > wishes
> 
> If so, I prefer the isolated_mode to be port's argument but not global one.
> How about to add a command to configure the isolate mode?

There is already a command to configure isolate mode per-port:
http://dpdk.org/patch/25320
http://dpdk.org/doc/guides/testpmd_app_ug/testpmd_funcs.html#flow-syntax

I think it does not make sense to replicate this per-port command in
command line parameters.
All the other parameters are global:

http://dpdk.org/doc/guides/testpmd_app_ug/run_app.html#testpmd-command-line-options
The idea here is to have a global isolate mode with a general option.

Re: [dpdk-dev] [PATCH v7 0/2] Balanced allocation of hugepages

[Ilya Maximets]

On 26.06.2017 18:33, Sergio Gonzalez Monroy wrote:
> On 26/06/2017 11:44, Ilya Maximets wrote:
>> So, what do you think about this version?
>> Is it ready for merge or some additional changes needed?
> 
> I was just having another look at it and was wondering if we should re-set 
> the old policy instead of DEFAULT?

Yes. I tried to do that previously, but it requires some manipulations
get maximum nodemask size supported by kernel. So, I've implemented
this behaviour with help of libnuma which makes a lot of checks while
library initialisation (constructor). I'll send v8 with that soon.

> Also noticed that we probably should increase essential_memory by hugepage_sz 
> in
> case of SIGBUS? I think there is an issue if we have more than one size.

Good catch. Also fixed in v8. Additionally I found that we need to restore
old mempolicy in case of any error. So I replaced all the 'return i' to
the out to proper termination point.

> 
> Thanks,
> Sergio
> 
>> Best regards, Ilya Maximets.
>>
>> On 21.06.2017 13:08, Ilya Maximets wrote:
>>> Version 7:
>>> * RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
>>>
>>> Version 6:
>>> * Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>   returned. Enabled by default for x86, ppc and thunderx.
>>>
>>> Version 5:
>>> * Fixed shared build. (Automated build test will fail
>>>   anyway because libnuma-devel not installed on build servers)
>>>
>>> Version 4:
>>> * Fixed work on systems without NUMA by adding check for NUMA
>>>   support in kernel.
>>>
>>> Version 3:
>>> * Implemented hybrid schema for allocation.
>>> * Fixed not needed mempolicy change while remapping. (orig = 0)
>>> * Added patch to enable VHOST_NUMA by default.
>>>
>>> Version 2:
>>> * rebased (fuzz in Makefile)
>>>
>>> Ilya Maximets (2):
>>>mem: balanced allocation of hugepages
>>>config: enable vhost numa awareness by default
>>>
>>>   config/common_base   |   1 +
>>>   config/common_linuxapp   |   3 +
>>>   config/defconfig_arm-armv7a-linuxapp-gcc |   4 +
>>>   config/defconfig_arm64-armv8a-linuxapp-gcc   |   4 +
>>>   config/defconfig_arm64-thunderx-linuxapp-gcc |   4 +
>>>   lib/librte_eal/linuxapp/eal/Makefile |   3 +
>>>   lib/librte_eal/linuxapp/eal/eal_memory.c | 105 
>>> ++-
>>>   mk/rte.app.mk|   3 +
>>>   8 files changed, 123 insertions(+), 4 deletions(-)
>>>
> 
> 
> 
> 

Re: [dpdk-dev] [PATCH] eventdev: add producer enqueue hint

[Van Haaren, Harry]

> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> Sent: Tuesday, June 27, 2017 9:08 AM
> To: Eads, Gage 
> Cc: dev@dpdk.org; Richardson, Bruce ; Van Haaren, 
> Harry
> ; hemant.agra...@nxp.com; nipun.gu...@nxp.com; 
> Vangati,
> Narender ; Rao, Nikhil 
> Subject: Re: [dpdk-dev] [PATCH] eventdev: add producer enqueue hint



> > >  void
> > > diff --git a/lib/librte_eventdev/rte_eventdev.h
> > > b/lib/librte_eventdev/rte_eventdev.h
> > > index a248fe90e..1c1a46593 100644
> > > --- a/lib/librte_eventdev/rte_eventdev.h
> > > +++ b/lib/librte_eventdev/rte_eventdev.h
> > > @@ -933,7 +933,15 @@ struct rte_event {
> > >* and is undefined on dequeue.
> > >* @see RTE_EVENT_OP_NEW, (RTE_EVENT_OP_*)
> > >*/
> > > - uint8_t rsvd:4;
> > > + uint8_t all_op_new:1;
> > > + /**< Valid only with event enqueue operation - This hint
> > > +  * indicates that the enqueue request has only the
> > > +  * events with op == RTE_EVENT_OP_NEW.
> > > +  * The event producer, typically use this pattern to
> > > +  * inject the events to eventdev.
> > > +  * @see RTE_EVENT_OP_NEW
> > > rte_event_enqueue_burst()
> > > +  */
> > > + uint8_t rsvd:3;
> > >   /**< Reserved for future use */
> > >   uint8_t sched_type:2;
> > >   /**< Scheduler synchronization type
> > > (RTE_SCHED_TYPE_*)
> > > --
> > > 2.13.1
> >
> > I slightly prefer the parallel enqueue API -- I can see folks making the 
> > mistake of
> setting all_op_new without setting the op to RTE_EVENT_OP_NEW, and later 
> adding a
> "forward-only" enqueue API could be interesting for the sw PMD -- but this 
> looks fine to
> me. Curious if others have any thoughts.
> 
> If forward-only parallel enqueue API interesting for the SW PMD then I
> can drop this one and introduce forward-only API. Let me know if others
> have any thoughts?


To make sure I understand correctly, the "parallel API" idea is to add a new 
function pointer per-PMD, and dedicate it to enqueueing a burst of packets with 
the same OP? So the end result would be function(s) in the public API like this:

rte_event_enqueue_burst_new(port, new_events, n_events);
rte_event_enqueue_burst_forward(port, new_events, n_events);

Given these are a "specialization" of the generic enqueue_burst() function, the 
PMD is not obliged to implement them. If they are NULL, the eventdev.c 
infrastructure can just point the burst_new() and burst_forward() to the 
generic enqueue without any performance delta?

The cost is some added code in the public header and infrastructure.
The gain is that we don't overload the current API with new behavior. 


Assuming my description of the parallel proposal above is correct, +1 for the 
parallel function approach. I like APIs that "do what they say on the tin" :)

[dpdk-dev] [PATCH v8 2/2] config: enable vhost numa awareness by default

[Ilya Maximets]

It is safe to enable LIBRTE_VHOST_NUMA by default for all
configurations where libnuma is already a default dependency.

Signed-off-by: Ilya Maximets 
---
 config/common_linuxapp| 1 +
 config/defconfig_arm-armv7a-linuxapp-gcc  | 1 +
 config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/config/common_linuxapp b/config/common_linuxapp
index 64bef87..74c7d64 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -42,6 +42,7 @@ CONFIG_RTE_KNI_KMOD=y
 CONFIG_RTE_LIBRTE_KNI=y
 CONFIG_RTE_LIBRTE_PMD_KNI=y
 CONFIG_RTE_LIBRTE_VHOST=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=y
 CONFIG_RTE_LIBRTE_PMD_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
 CONFIG_RTE_LIBRTE_PMD_TAP=y
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
b/config/defconfig_arm-armv7a-linuxapp-gcc
index e06b1d4..00bc2ab 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -49,6 +49,7 @@ CONFIG_RTE_TOOLCHAIN_GCC=y
 
 # NUMA is not supported on ARM
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n
 
 # ARM doesn't have support for vmware TSC map
 CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc 
b/config/defconfig_arm64-dpaa2-linuxapp-gcc
index f78449d..b061fb0 100644
--- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -47,6 +47,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=256
 
 # Doesn't support NUMA
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n
 
 #
 # Compile Support Libraries for DPAA2
-- 
2.7.4

[dpdk-dev] [PATCH v8 0/2] Balanced allocation of hugepages

[Ilya Maximets]

Version 8:
* helper functions from libnuma used to set mempolicy and
  work with cpu mask.
* Function now restores previous mempolicy instead of MPOL_DEFAULT.
* Fixed essential_memory on SIGBUS.
* Fixed restoring of mempolicy in case of errors (goto out).
* Enabled by default for all linuxapp except armv7 and dpaa2.

Version 7:
* RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES

Version 6:
* Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
  returned. Enabled by default for x86, ppc and thunderx.

Version 5:
* Fixed shared build. (Automated build test will fail
  anyway because libnuma-devel not installed on build servers)

Version 4:
* Fixed work on systems without NUMA by adding check for NUMA
  support in kernel.

Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.

Version 2:
* rebased (fuzz in Makefile)

Ilya Maximets (2):
  mem: balanced allocation of hugepages
  config: enable vhost numa awareness by default

 config/common_base|   1 +
 config/common_linuxapp|   2 +
 config/defconfig_arm-armv7a-linuxapp-gcc  |   4 +
 config/defconfig_arm64-dpaa2-linuxapp-gcc |   4 +
 lib/librte_eal/linuxapp/eal/Makefile  |   3 +
 lib/librte_eal/linuxapp/eal/eal_memory.c  | 117 --
 mk/rte.app.mk |   3 +
 7 files changed, 126 insertions(+), 8 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH v8 1/2] mem: balanced allocation of hugepages

[Ilya Maximets]

Currently EAL allocates hugepages one by one not paying attention
from which NUMA node allocation was done.

Such behaviour leads to allocation failure if number of available
hugepages for application limited by cgroups or hugetlbfs and
memory requested not only from the first socket.

Example:
# 90 x 1GB hugepages availavle in a system

cgcreate -g hugetlb:/test
# Limit to 32GB of hugepages
cgset -r hugetlb.1GB.limit_in_bytes=34359738368 test
# Request 4GB from each of 2 sockets
cgexec -g hugetlb:test testpmd --socket-mem=4096,4096 ...

EAL: SIGBUS: Cannot mmap more hugepages of size 1024 MB
EAL: 32 not 90 hugepages of size 1024 MB allocated
EAL: Not enough memory available on socket 1!
 Requested: 4096MB, available: 0MB
PANIC in rte_eal_init():
Cannot init memory

This happens beacause all allocated pages are
on socket 0.

Fix this issue by setting mempolicy MPOL_PREFERRED for each hugepage
to one of requested nodes using following schema:

1) Allocate essential hugepages:
1.1) Allocate as many hugepages from numa N to
 only fit requested memory for this numa.
1.2) repeat 1.1 for all numa nodes.
2) Try to map all remaining free hugepages in a round-robin
   fashion.
3) Sort pages and choose the most suitable.

In this case all essential memory will be allocated and all remaining
pages will be fairly distributed between all requested nodes.

New config option RTE_EAL_NUMA_AWARE_HUGEPAGES introduced and
enabled by default for linuxapp except armv7 and dpaa2.
Enabling of this option adds libnuma as a dependency for EAL.

Fixes: 77988fc08dc5 ("mem: fix allocating all free hugepages")

Signed-off-by: Ilya Maximets 
---
 config/common_base|   1 +
 config/common_linuxapp|   1 +
 config/defconfig_arm-armv7a-linuxapp-gcc  |   3 +
 config/defconfig_arm64-dpaa2-linuxapp-gcc |   3 +
 lib/librte_eal/linuxapp/eal/Makefile  |   3 +
 lib/librte_eal/linuxapp/eal/eal_memory.c  | 117 --
 mk/rte.app.mk |   3 +
 7 files changed, 123 insertions(+), 8 deletions(-)

diff --git a/config/common_base b/config/common_base
index f6aafd1..660588a 100644
--- a/config/common_base
+++ b/config/common_base
@@ -103,6 +103,7 @@ CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
 CONFIG_RTE_EAL_IGB_UIO=n
 CONFIG_RTE_EAL_VFIO=n
 CONFIG_RTE_MALLOC_DEBUG=n
+CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
 
 #
 # Recognize/ignore the AVX/AVX512 CPU flags for performance/power testing.
diff --git a/config/common_linuxapp b/config/common_linuxapp
index b3cf41b..64bef87 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -35,6 +35,7 @@
 CONFIG_RTE_EXEC_ENV="linuxapp"
 CONFIG_RTE_EXEC_ENV_LINUXAPP=y
 
+CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
 CONFIG_RTE_EAL_IGB_UIO=y
 CONFIG_RTE_EAL_VFIO=y
 CONFIG_RTE_KNI_KMOD=y
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
b/config/defconfig_arm-armv7a-linuxapp-gcc
index 19607eb..e06b1d4 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -47,6 +47,9 @@ CONFIG_RTE_ARCH_STRICT_ALIGN=y
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y
 
+# NUMA is not supported on ARM
+CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
+
 # ARM doesn't have support for vmware TSC map
 CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
 
diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc 
b/config/defconfig_arm64-dpaa2-linuxapp-gcc
index 2304ab6..f78449d 100644
--- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -45,6 +45,9 @@ CONFIG_RTE_CACHE_LINE_SIZE=64
 
 CONFIG_RTE_PKTMBUF_HEADROOM=256
 
+# Doesn't support NUMA
+CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
+
 #
 # Compile Support Libraries for DPAA2
 #
diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
b/lib/librte_eal/linuxapp/eal/Makefile
index 640afd0..8651e27 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -50,6 +50,9 @@ LDLIBS += -ldl
 LDLIBS += -lpthread
 LDLIBS += -lgcc_s
 LDLIBS += -lrt
+ifeq ($(CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES),y)
+LDLIBS += -lnuma
+endif
 
 # specific to linuxapp exec-env
 SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) := eal.c
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c 
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index e17c9cb..6d2b199 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -54,6 +54,10 @@
 #include 
 #include 
 #include 
+#ifdef RTE_EAL_NUMA_AWARE_HUGEPAGES
+#include 
+#include 
+#endif
 
 #include 
 #include 
@@ -348,6 +352,14 @@ static int huge_wrap_sigsetjmp(void)
return sigsetjmp(huge_jmpenv, 1);
 }
 
+#ifdef RTE_EAL_NUMA_AWARE_HUGEPAGES
+/* Callback for numa library. */
+void numa_error(char *where)
+{
+   RTE_LOG(ERR, EAL, "%s failed: %

Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages

[Hemant Agrawal]

On 6/21/2017 4:52 PM, Jerin Jacob wrote:

-Original Message-

Date: Wed, 21 Jun 2017 13:36:58 +0300
From: Ilya Maximets 
To: Jerin Jacob , Thomas Monjalon
 
CC: Sergio Gonzalez Monroy , Hemant
 Agrawal , dev@dpdk.org, Bruce Richardson
 , David Marchand ,
 Heetae Ahn , Yuanhan Liu ,
 Jianfeng Tan , Neil Horman
 , Yulong Pei 
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0

On 21.06.2017 13:29, Jerin Jacob wrote:

-Original Message-

Date: Wed, 21 Jun 2017 11:58:12 +0200
From: Thomas Monjalon 
To: Jerin Jacob 
Cc: Sergio Gonzalez Monroy , Hemant
 Agrawal , Ilya Maximets ,
 dev@dpdk.org, Bruce Richardson , David
 Marchand , Heetae Ahn
 , Yuanhan Liu , Jianfeng
 Tan , Neil Horman , Yulong
 Pei 
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages

21/06/2017 11:27, Jerin Jacob:

-Original Message-

Date: Wed, 21 Jun 2017 10:49:14 +0200
From: Thomas Monjalon 
To: Jerin Jacob 
Cc: Sergio Gonzalez Monroy , Hemant
 Agrawal , Ilya Maximets ,
 dev@dpdk.org, Bruce Richardson , David
 Marchand , Heetae Ahn
 , Yuanhan Liu , Jianfeng
 Tan , Neil Horman , Yulong
 Pei 
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages

21/06/2017 10:41, Jerin Jacob:

1. There are many machines (arm/ppc), which do not support NUMA.

https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA



I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources, but
Jerin proved that there is support for it.

http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl


Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 
kernel.
I guess we are talking about build time time dependency with libnuma here.
Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
libnuma if it is present in rootfs. Just that at runtime, it will return
NUMA support not available. Correct?

How hard is detect the presence of "numaif.h" if existing build system does not
support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
if build environment has "numaif.h".

Some example in linux kernel build system:
http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh


I think we should not try to detect numaif.h, because it should be
an error on platform supporting NUMA.


I have installed libnuma on a NUMA and non NUMA machine.
Compiled and ran following code on those machine and it could detect
the numa availability. Could you add more details on the "error on
platform supporting NUMA".


I was saying that we do not need to detect NUMA.
If we are building DPDK for a NUMA architecture and libnuma is not
available, then it will be a problem that the user must catch.
The easiest way to catch it, is to fail on the include of numaif.h.


libnuma is not really _architecture_ depended.

Ilya Maximets patch disables NUMA support in common arm64 config.I
think, It is not correct, We should not disable on any archs generic config.

IMO, It should be enabled by default in common config and then we can
detect the presence of numaif.h, if not available OR a target does not need it
explicitly, proceed with disabling
RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.


Detecting of headers is impossible until dpdk doesn't have dynamic build
configuration system like autotools, CMake or meson.
Right now we just can't do that.


I agree. Unless if we do something like linux kernel does it below
http://elixir.free-electrons.com/linux/latest/source/scripts/kconfig/lxdialog/check-lxdialog.sh

Either way, I think, you can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES in
generic arm64 config and disable on defconfig_arm64-dpaa2-linuxapp-gcc(as 
Hemant requested) or
any sub arch target that does not need in RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES.


No, this is not acceptable. it should not be enabled in generic arm64. 
It can be enabled in specific ARM platforms, which support NUMA 
architecture.
We also use generic ARM code on various of our platform when running 
with non-dpaa and/or virtio-net. So enabling it will break all those 
platforms.








No strong opinion on "failing the build" vs "printing a warning" in the
absence of numaif.h

Re: [dpdk-dev] [PATCH v8 2/2] config: enable vhost numa awareness by default

[Hemant Agrawal]

On 6/27/2017 2:16 PM, Ilya Maximets wrote:

It is safe to enable LIBRTE_VHOST_NUMA by default for all
configurations where libnuma is already a default dependency.

Signed-off-by: Ilya Maximets 
---
 config/common_linuxapp| 1 +
 config/defconfig_arm-armv7a-linuxapp-gcc  | 1 +
 config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/config/common_linuxapp b/config/common_linuxapp
index 64bef87..74c7d64 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -42,6 +42,7 @@ CONFIG_RTE_KNI_KMOD=y
 CONFIG_RTE_LIBRTE_KNI=y
 CONFIG_RTE_LIBRTE_PMD_KNI=y
 CONFIG_RTE_LIBRTE_VHOST=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=y
 CONFIG_RTE_LIBRTE_PMD_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
 CONFIG_RTE_LIBRTE_PMD_TAP=y
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
b/config/defconfig_arm-armv7a-linuxapp-gcc
index e06b1d4..00bc2ab 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -49,6 +49,7 @@ CONFIG_RTE_TOOLCHAIN_GCC=y

 # NUMA is not supported on ARM
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n

 # ARM doesn't have support for vmware TSC map
 CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc 
b/config/defconfig_arm64-dpaa2-linuxapp-gcc
index f78449d..b061fb0 100644
--- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -47,6 +47,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=256

 # Doesn't support NUMA
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n

 #
 # Compile Support Libraries for DPAA2



-1
It should also be disabled for generic ARM64. This patch is breaking 
generic arm64 config tests on our platforms and creating a unnecessary 
dependency.

Re: [dpdk-dev] [PATCH v8 2/2] config: enable vhost numa awareness by default

[Thomas Monjalon]

27/06/2017 10:46, Ilya Maximets:
> It is safe to enable LIBRTE_VHOST_NUMA by default for all
> configurations where libnuma is already a default dependency.
> 
> Signed-off-by: Ilya Maximets 
> ---
>  config/common_linuxapp| 1 +
>  config/defconfig_arm-armv7a-linuxapp-gcc  | 1 +
>  config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
>  3 files changed, 3 insertions(+)

I forgot to ask you to update devtools/test-build.sh.
DPDK_DEP_NUMA can be removed.

Re: [dpdk-dev] [PATCH v7 2/2] config: enable vhost numa awareness by default

[Hemant Agrawal]

On 6/21/2017 3:38 PM, Ilya Maximets wrote:

It is safe to enable LIBRTE_VHOST_NUMA by default for all
configurations where libnuma is already a default dependency.

Signed-off-by: Ilya Maximets 
---
 config/common_linuxapp   | 1 +
 config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
 config/defconfig_arm64-armv8a-linuxapp-gcc   | 1 +
 config/defconfig_arm64-thunderx-linuxapp-gcc | 1 +
 4 files changed, 4 insertions(+)

diff --git a/config/common_linuxapp b/config/common_linuxapp
index 050526f..2e44434 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -43,6 +43,7 @@ CONFIG_RTE_KNI_KMOD=y
 CONFIG_RTE_LIBRTE_KNI=y
 CONFIG_RTE_LIBRTE_PMD_KNI=y
 CONFIG_RTE_LIBRTE_VHOST=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=y
 CONFIG_RTE_LIBRTE_PMD_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
 CONFIG_RTE_LIBRTE_PMD_TAP=y
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
b/config/defconfig_arm-armv7a-linuxapp-gcc
index e06b1d4..00bc2ab 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -49,6 +49,7 @@ CONFIG_RTE_TOOLCHAIN_GCC=y

 # NUMA is not supported on ARM
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n

 # ARM doesn't have support for vmware TSC map
 CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 2c67cdc..d190afb 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -49,6 +49,7 @@ CONFIG_RTE_CACHE_LINE_SIZE=128

 # Most ARMv8 systems doesn't support NUMA
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n

 CONFIG_RTE_EAL_IGB_UIO=n

diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc 
b/config/defconfig_arm64-thunderx-linuxapp-gcc
index 3e79fa8..7b07b7d 100644
--- a/config/defconfig_arm64-thunderx-linuxapp-gcc
+++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
@@ -39,6 +39,7 @@ CONFIG_RTE_MAX_LCORE=96

 # ThunderX supports NUMA
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=y

 #
 # Compile PMD for octeontx sso event device


This particular version of patch is:
Acked-by: Hemant Agrawal 

Re: [dpdk-dev] [PATCH v8 2/2] config: enable vhost numa awareness by default

[Thomas Monjalon]

27/06/2017 11:18, Hemant Agrawal:
> On 6/27/2017 2:16 PM, Ilya Maximets wrote:
> > It is safe to enable LIBRTE_VHOST_NUMA by default for all
> > configurations where libnuma is already a default dependency.
> >
> > Signed-off-by: Ilya Maximets 
> > ---
> >  config/common_linuxapp| 1 +
> >  config/defconfig_arm-armv7a-linuxapp-gcc  | 1 +
> >  config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
> >  3 files changed, 3 insertions(+)
[...]
> > --- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
> > +++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
> > @@ -47,6 +47,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=256
> >
> >  # Doesn't support NUMA
> >  CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
> > +CONFIG_RTE_LIBRTE_VHOST_NUMA=n
> >
> >  #
> >  # Compile Support Libraries for DPAA2
> >
> 
> -1
> It should also be disabled for generic ARM64. This patch is breaking 
> generic arm64 config tests on our platforms and creating a unnecessary 
> dependency.

What do you mean? Which ARM64 platform is it breaking?
We can specifically disable it on more platforms.

Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages

[Thomas Monjalon]

27/06/2017 11:13, Hemant Agrawal:
> On 6/21/2017 4:52 PM, Jerin Jacob wrote:
> > From: Ilya Maximets 
> >>> From: Thomas Monjalon 
> >> 21/06/2017 10:41, Jerin Jacob:
> > 1. There are many machines (arm/ppc), which do not support NUMA.
> >
> > https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
> >
> 
>  I did find that link too, last modified 4 years ago.
>  Despite that, I could not find any ARM references in libnuma 
>  sources, but
>  Jerin proved that there is support for it.
> 
>  http://oss.sgi.com/projects/libnuma/
>  https://github.com/numactl/numactl
> >>>
> >>> Those Linaro links are very old. ARM64 NUMA supported has been added 
> >>> in 4.7 kernel.
> >>> I guess we are talking about build time time dependency with libnuma 
> >>> here.
> >>> Correct? I think, Even with old arm64 kernel(< 4.6), You can build 
> >>> against
> >>> libnuma if it is present in rootfs. Just that at runtime, it will 
> >>> return
> >>> NUMA support not available. Correct?
> >>>
> >>> How hard is detect the presence of "numaif.h" if existing build 
> >>> system does not
> >>> support it? If it trivial, we can enable 
> >>> RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> >>> if build environment has "numaif.h".
> >>>
> >>> Some example in linux kernel build system:
> >>> http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh
> >>
> >> I think we should not try to detect numaif.h, because it should be
> >> an error on platform supporting NUMA.
> >
> > I have installed libnuma on a NUMA and non NUMA machine.
> > Compiled and ran following code on those machine and it could detect
> > the numa availability. Could you add more details on the "error on
> > platform supporting NUMA".
> 
>  I was saying that we do not need to detect NUMA.
>  If we are building DPDK for a NUMA architecture and libnuma is not
>  available, then it will be a problem that the user must catch.
>  The easiest way to catch it, is to fail on the include of numaif.h.
> >>>
> >>> libnuma is not really _architecture_ depended.
> >>>
> >>> Ilya Maximets patch disables NUMA support in common arm64 config.I
> >>> think, It is not correct, We should not disable on any archs generic 
> >>> config.
> >>>
> >>> IMO, It should be enabled by default in common config and then we can
> >>> detect the presence of numaif.h, if not available OR a target does not 
> >>> need it
> >>> explicitly, proceed with disabling
> >>> RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.
> >>
> >> Detecting of headers is impossible until dpdk doesn't have dynamic build
> >> configuration system like autotools, CMake or meson.
> >> Right now we just can't do that.
> >
> > I agree. Unless if we do something like linux kernel does it below
> > http://elixir.free-electrons.com/linux/latest/source/scripts/kconfig/lxdialog/check-lxdialog.sh
> >
> > Either way, I think, you can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES in
> > generic arm64 config and disable on defconfig_arm64-dpaa2-linuxapp-gcc(as 
> > Hemant requested) or
> > any sub arch target that does not need in 
> > RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES.
> 
> No, this is not acceptable. it should not be enabled in generic arm64. 
> It can be enabled in specific ARM platforms, which support NUMA 
> architecture.
> We also use generic ARM code on various of our platform when running 
> with non-dpaa and/or virtio-net. So enabling it will break all those 
> platforms.

Which platforms?
It is your non-upstreamed code. You have to deal with it.
You should disable NUMA in the config of these platforms.

[dpdk-dev] [PATCH] net/tap: restore state of remote device when stopping

[Thomas Monjalon]

When exiting a DPDK application, the TAP remote was left
with the link down even if it was initially up.

The device flags of the remote netdevice are saved when probing,
and restored when calling the stop function.

Signed-off-by: Thomas Monjalon 
---
 drivers/net/tap/rte_eth_tap.c | 18 +-
 drivers/net/tap/rte_eth_tap.h |  2 ++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index 7cfa0a85d..5128152ee 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -565,11 +565,22 @@ tap_ioctl(struct pmd_internals *pmd, unsigned long 
request,
 static int
 tap_link_set_down(struct rte_eth_dev *dev)
 {
+   int err, remote_err;
struct pmd_internals *pmd = dev->data->dev_private;
struct ifreq ifr = { .ifr_flags = IFF_UP };
 
dev->data->dev_link.link_status = ETH_LINK_DOWN;
-   return tap_ioctl(pmd, SIOCSIFFLAGS, &ifr, 0, LOCAL_AND_REMOTE);
+   err = tap_ioctl(pmd, SIOCSIFFLAGS, &ifr, 0, LOCAL_ONLY);
+
+   if (pmd->remote_if_index) {
+   /* Restore initial remote state */
+   remote_err = ioctl(pmd->ioctl_sock, SIOCSIFFLAGS,
+   &pmd->remote_initial_ifr);
+   if (remote_err < 0)
+   err = -1;
+   }
+
+   return err;
 }
 
 static int
@@ -1320,6 +1331,11 @@ eth_dev_tap_create(struct rte_vdev_device *vdev, char 
*tap_name,
}
snprintf(pmd->remote_iface, RTE_ETH_NAME_MAX_LEN,
 "%s", remote_iface);
+
+   /* Save state of remote device */
+   tap_ioctl(pmd, SIOCGIFFLAGS, &pmd->remote_initial_ifr, 0, 
REMOTE_ONLY);
+
+   /* Replicate remote MAC address */
if (tap_ioctl(pmd, SIOCGIFHWADDR, &ifr, 0, REMOTE_ONLY) < 0) {
RTE_LOG(ERR, PMD, "%s: failed to get %s MAC address.",
pmd->name, pmd->remote_iface);
diff --git a/drivers/net/tap/rte_eth_tap.h b/drivers/net/tap/rte_eth_tap.h
index ad497b3d1..08a72d279 100644
--- a/drivers/net/tap/rte_eth_tap.h
+++ b/drivers/net/tap/rte_eth_tap.h
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -83,6 +84,7 @@ struct pmd_internals {
char name[RTE_ETH_NAME_MAX_LEN];  /* Internal Tap device name */
uint16_t nb_queues;   /* Number of queues supported */
struct ether_addr eth_addr;   /* Mac address of the device port */
+   struct ifreq remote_initial_ifr;  /* remote netdevice flags on init */
int remote_if_index;  /* remote netdevice IF_INDEX */
int if_index; /* IF_INDEX for the port */
int ioctl_sock;   /* socket for ioctl calls */
-- 
2.13.1

Re: [dpdk-dev] [PATCH 1/3] examples/eventdev_pipeline: added sample app

[Jerin Jacob]

-Original Message-
> Date: Mon, 26 Jun 2017 15:46:47 +0100
> From: "Hunt, David" 
> To: Jerin Jacob , Harry van Haaren
>  
> CC: dev@dpdk.org, Gage Eads , Bruce Richardson
>  
> Subject: Re: [dpdk-dev] [PATCH 1/3] examples/eventdev_pipeline: added
>  sample app
> User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
>  Thunderbird/45.8.0
> 
> Hi Jerin,

Hi David,

Looks like you have sent the old version. The below mentioned comments
are not addressed in v2.
> 
> I'm assisting Harry on the sample app, and have just pushed up a V2 patch
> based on your feedback. I've addressed most of your suggestions, comments
> below. There may still a couple of outstanding questions that need further
> discussion.

A few general comments:
1) Nikhil/Gage's proposal on ethdev rx to eventdev adapter will change the major
portion(eventdev setup and producer()) of this application
2) Producing one lcore worth of packets, really cant show as example
eventdev application as it will be pretty bad in low-end machine.
At least application infrastructure should not limit.

Considering above points, Should we wait for rx adapter to complete
first? I would like to show this as real world application to use eventdev.

Thoughts?

On the same note:
Can we finalize on rx adapter proposal? I can work on v1 of patch and
common code if Nikhil or Gage don't have bandwidth. Let me know?

last followup:
http://dpdk.org/ml/archives/dev/2017-June/068776.html

> 
> Regards,
> Dave
> 
> On 10/5/2017 3:12 PM, Jerin Jacob wrote:
> > -Original Message-
> >> Date: Fri, 21 Apr 2017 10:51:37 +0100
> >> From: Harry van Haaren 
> >> To: dev@dpdk.org
> >> CC: jerin.ja...@caviumnetworks.com, Harry van Haaren
> >> , Gage Eads , Bruce
> >>  Richardson 
> >> Subject: [PATCH 1/3] examples/eventdev_pipeline: added sample app
> >> X-Mailer: git-send-email 2.7.4
> >>
> >> This commit adds a sample app for the eventdev library.
> >> The app has been tested with DPDK 17.05-rc2, hence this
> >> release (or later) is recommended.
> >>
> >> The sample app showcases a pipeline processing use-case,
> >> with event scheduling and processing defined per stage.
> >> The application recieves traffic as normal, with each
> >> packet traversing the pipeline. Once the packet has
> >> been processed by each of the pipeline stages, it is
> >> transmitted again.
> >>
> >> The app provides a framework to utilize cores for a single
> >> role or multiple roles. Examples of roles are the RX core,
> >> TX core, Scheduling core (in the case of the event/sw PMD),
> >> and worker cores.
> >>
> >> Various flags are available to configure numbers of stages,
> >> cycles of work at each stage, type of scheduling, number of
> >> worker cores, queue depths etc. For a full explaination,
> >> please refer to the documentation.
> >>
> >> Signed-off-by: Gage Eads 
> >> Signed-off-by: Bruce Richardson 
> >> Signed-off-by: Harry van Haaren 
> >
> > Thanks for the example application to share the SW view.
> > I could make it run on HW after some tweaking(not optimized though)
> >
> > [...]
> >> +#define MAX_NUM_STAGES 8
> >> +#define BATCH_SIZE 16
> >> +#define MAX_NUM_CORE 64
> >
> > How about RTE_MAX_LCORE?
> 
> Core usage in the sample app is held in a uint64_t. Adding arrays would be
> possible, but I feel that the extra effort would not give that much benefit.
> I've left as is for the moment, unless you see any strong requirement to go
> beyond 64 cores?

I think, it is OK. Again with service core infrastructure this will change.

> 
> >
> >> +
> >> +static unsigned int active_cores;
> >> +static unsigned int num_workers;
> >> +static unsigned long num_packets = (1L << 25); /* do ~32M packets */
> >> +static unsigned int num_fids = 512;
> >> +static unsigned int num_priorities = 1;
> >
> > looks like its not used.
> 
> Yes, Removed.
> 
> >
> >> +static unsigned int num_stages = 1;
> >> +static unsigned int worker_cq_depth = 16;
> >> +static int queue_type = RTE_EVENT_QUEUE_CFG_ATOMIC_ONLY;
> >> +static int16_t next_qid[MAX_NUM_STAGES+1] = {-1};
> >> +static int16_t qid[MAX_NUM_STAGES] = {-1};
> >
> > Moving all fastpath related variables under a structure with cache
> > aligned will help.
> 
> I tried a few different combinations of this, and saw no gains, some losses.
> So will leave as is for the moment, if that's OK.

I think, the one are using in fastpath better to allocate from huge page
using rte_malloc()

> 
> >
> >> +static int worker_cycles;
> >> +static int enable_queue_priorities;
> >> +
> >> +struct prod_data {
> >> +uint8_t dev_id;
> >> +uint8_t port_id;
> >> +int32_t qid;
> >> +unsigned num_nic_ports;
> >> +};
> 
> Yes, saw a percent or two gain when this plus following two data structs
> cache aligned.

looks like it not fixed in v2. Looks like you have sent the old
version.

> 
> >
> >> +
> >> +return 0;
> >> +}
> >> +
> >> +static int
> >> +producer(void)
> >> +{
> >> +static uint8_t eth_port;
> >> +struct rte_mbuf *m

Re: [dpdk-dev] [PATCH v8 2/2] config: enable vhost numa awareness by default

[Hemant Agrawal]

On 6/27/2017 2:51 PM, Thomas Monjalon wrote:

27/06/2017 11:18, Hemant Agrawal:

On 6/27/2017 2:16 PM, Ilya Maximets wrote:

It is safe to enable LIBRTE_VHOST_NUMA by default for all
configurations where libnuma is already a default dependency.

Signed-off-by: Ilya Maximets 
---
 config/common_linuxapp| 1 +
 config/defconfig_arm-armv7a-linuxapp-gcc  | 1 +
 config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
 3 files changed, 3 insertions(+)

[...]

--- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -47,6 +47,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=256

 # Doesn't support NUMA
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n

 #
 # Compile Support Libraries for DPAA2



-1
It should also be disabled for generic ARM64. This patch is breaking
generic arm64 config tests on our platforms and creating a unnecessary
dependency.


What do you mean? Which ARM64 platform is it breaking?
We can specifically disable it on more platforms.


Unlike x86, ARM only represent a core architecture.
Different platforms can integrate these cores differently in their SoCs.
The stock ARM v8 cores do not provide support for NUMA in my knowledge.
Some vendors have modified ARM cores (e.g. Cavium) to support NUMA 
architecture. However that is not a common phenomena.
NUMA config should not be default for generic ARM config. It should be 
enabled only for architecture supporting it.


So, *arm64-armv8a-linuxapp-gcc* config is being used by several vendors 
include NXP. e.g. We use this config on several of our low end systems 
(non-dpaa). Also, we use it when running in VM with virtio interfaces on 
all of our different platforms (non-dpaa, dpaa1, dpaa2 etc).

Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages

[Hemant Agrawal]

On 6/27/2017 2:56 PM, Thomas Monjalon wrote:

27/06/2017 11:13, Hemant Agrawal:

On 6/21/2017 4:52 PM, Jerin Jacob wrote:

From: Ilya Maximets 

From: Thomas Monjalon 

21/06/2017 10:41, Jerin Jacob:

1. There are many machines (arm/ppc), which do not support NUMA.

https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA



I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources, but
Jerin proved that there is support for it.

http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl


Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 
kernel.
I guess we are talking about build time time dependency with libnuma here.
Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
libnuma if it is present in rootfs. Just that at runtime, it will return
NUMA support not available. Correct?

How hard is detect the presence of "numaif.h" if existing build system does not
support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
if build environment has "numaif.h".

Some example in linux kernel build system:
http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh


I think we should not try to detect numaif.h, because it should be
an error on platform supporting NUMA.


I have installed libnuma on a NUMA and non NUMA machine.
Compiled and ran following code on those machine and it could detect
the numa availability. Could you add more details on the "error on
platform supporting NUMA".


I was saying that we do not need to detect NUMA.
If we are building DPDK for a NUMA architecture and libnuma is not
available, then it will be a problem that the user must catch.
The easiest way to catch it, is to fail on the include of numaif.h.


libnuma is not really _architecture_ depended.

Ilya Maximets patch disables NUMA support in common arm64 config.I
think, It is not correct, We should not disable on any archs generic config.

IMO, It should be enabled by default in common config and then we can
detect the presence of numaif.h, if not available OR a target does not need it
explicitly, proceed with disabling
RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.


Detecting of headers is impossible until dpdk doesn't have dynamic build
configuration system like autotools, CMake or meson.
Right now we just can't do that.


I agree. Unless if we do something like linux kernel does it below
http://elixir.free-electrons.com/linux/latest/source/scripts/kconfig/lxdialog/check-lxdialog.sh

Either way, I think, you can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES in
generic arm64 config and disable on defconfig_arm64-dpaa2-linuxapp-gcc(as 
Hemant requested) or
any sub arch target that does not need in RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES.


No, this is not acceptable. it should not be enabled in generic arm64.
It can be enabled in specific ARM platforms, which support NUMA
architecture.
We also use generic ARM code on various of our platform when running
with non-dpaa and/or virtio-net. So enabling it will break all those
platforms.


Which platforms?
It is your non-upstreamed code. You have to deal with it.
You should disable NUMA in the config of these platforms.



See my reply in other thread. This is nothing to do with up-streaming.

All NXP - low end non-dpaa platforms, which don't have any platform 
specific code, we use "arm64-armv8a-linuxapp-gcc" as the build config.


There is no need to create special configs for these platforms.
Creating a "non-NUMA" generic config will be an over-kill.

Re: [dpdk-dev] [PATCH v2 06/12] cryptodev: move vdev functions to a separate file

[De Lara Guarch, Pablo]

> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Tuesday, June 27, 2017 12:31 AM
> To: Doherty, Declan ; De Lara Guarch, Pablo
> 
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 06/12] cryptodev: move vdev functions
> to a separate file
> 
> 23/06/2017 14:52, Declan Doherty:
> > On 21/06/2017 7:28 AM, Pablo de Lara wrote:
> > > Move all functions handling virtual devices to a separate header
> > > file "rte_cryptodev_vdev.h", in order to leave only generic
> > > functions for any device in the rest of the files.
> > >
> > > Signed-off-by: Pablo de Lara 
> >
> > Acked-by: Declan Doherty 
> 
> This patch is moving some code from a .c to a .h.
> The consequence is that driver are now compiling new functions from the .h
> and require librte_kvargs to link with.
> It is a build error in shared lib mode.
> 
> Please keep the code in a .c file if possible.

Sorry about this. I just fixed it in the subtree, so pull it whenever you are 
ready.
Also, since ethdev have separated pci and vdev functions in separate .h files,
I preferred to be consistent and do the same.

Thanks,
Pablo

Re: [dpdk-dev] [PATCH v2 2/2] app/testpmd: enable ddp remove profile feature

[Ferruh Yigit]

On 6/27/2017 9:18 AM, Andrey Chilikin wrote:
> New command 'ddp del (port) (profile_path)' removes previously
> loaded profile and deletes it from the list of the loaded profiles.
> 
> Signed-off-by: Andrey Chilikin 

<...>

> @@ -12860,6 +12863,9 @@ cmd_ddp_add_parsed(
>   struct cmd_ddp_add_result *res = parsed_result;
>   uint8_t *buff;
>   uint32_t size;
> + char *filepath;
> + char *file_fld[2];
> + int file_num;
>   int ret = -ENOTSUP;
>  
>   if (res->port_id > nb_ports) {
> @@ -12872,9 +12878,18 @@ cmd_ddp_add_parsed(
>   return;
>   }
>  
> - buff = open_ddp_package_file(res->filepath, &size);
> - if (!buff)
> + filepath = strdup(res->filepath);
> + if (filepath == NULL) {
> + printf("Failed to allocate memory\n");
>   return;
> + }
> + file_num = rte_strsplit(filepath, strlen(filepath), file_fld, 2, ',');
> +
> + buff = open_ddp_package_file(file_fld[0], &size);
> + if (!buff) {
> + free((void *)filepath);
> + return;
> + }

<...>

Can you please export ddp_add related changes into different patch?

Thanks,
ferruh

Re: [dpdk-dev] [PATCH v8 2/2] config: enable vhost numa awareness by default

[Thomas Monjalon]

27/06/2017 11:41, Hemant Agrawal:
> On 6/27/2017 2:51 PM, Thomas Monjalon wrote:
> > 27/06/2017 11:18, Hemant Agrawal:
> >> On 6/27/2017 2:16 PM, Ilya Maximets wrote:
> >>> It is safe to enable LIBRTE_VHOST_NUMA by default for all
> >>> configurations where libnuma is already a default dependency.
> >>>
> >>> Signed-off-by: Ilya Maximets 
> >>> ---
> >>>  config/common_linuxapp| 1 +
> >>>  config/defconfig_arm-armv7a-linuxapp-gcc  | 1 +
> >>>  config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
> >>>  3 files changed, 3 insertions(+)
> > [...]
> >>> --- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
> >>> +++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
> >>> @@ -47,6 +47,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=256
> >>>
> >>>  # Doesn't support NUMA
> >>>  CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
> >>> +CONFIG_RTE_LIBRTE_VHOST_NUMA=n
> >>>
> >>>  #
> >>>  # Compile Support Libraries for DPAA2
> >>>
> >>
> >> -1
> >> It should also be disabled for generic ARM64. This patch is breaking
> >> generic arm64 config tests on our platforms and creating a unnecessary
> >> dependency.
> >
> > What do you mean? Which ARM64 platform is it breaking?
> > We can specifically disable it on more platforms.
> >
> Unlike x86, ARM only represent a core architecture.
> Different platforms can integrate these cores differently in their SoCs.
> The stock ARM v8 cores do not provide support for NUMA in my knowledge.
> Some vendors have modified ARM cores (e.g. Cavium) to support NUMA 
> architecture. However that is not a common phenomena.
> NUMA config should not be default for generic ARM config. It should be 
> enabled only for architecture supporting it.
> 
> So, *arm64-armv8a-linuxapp-gcc* config is being used by several vendors 
> include NXP. e.g. We use this config on several of our low end systems 
> (non-dpaa). Also, we use it when running in VM with virtio interfaces on 
> all of our different platforms (non-dpaa, dpaa1, dpaa2 etc).

We need more opinions from ARM and Cavium.

The general idea in DPDK config is to enable as much feature as we can.
It conflicts with the general availability of NUMA on ARMv8.

Re: [dpdk-dev] [PATCH v8 2/2] config: enable vhost numa awareness by default

[Jerin Jacob]

-Original Message-
> Date: Tue, 27 Jun 2017 15:11:07 +0530
> From: Hemant Agrawal 
> To: Thomas Monjalon 
> CC: Ilya Maximets , dev@dpdk.org, David Marchand
>  , Sergio Gonzalez Monroy
>  , Heetae Ahn ,
>  Yuanhan Liu , Jianfeng Tan ,
>  Neil Horman , Yulong Pei ,
>  Bruce Richardson , Jerin Jacob
>  
> Subject: Re: [PATCH v8 2/2] config: enable vhost numa awareness by default
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
>  Thunderbird/45.8.0
> 
> On 6/27/2017 2:51 PM, Thomas Monjalon wrote:
> > 27/06/2017 11:18, Hemant Agrawal:
> > > On 6/27/2017 2:16 PM, Ilya Maximets wrote:
> > > > It is safe to enable LIBRTE_VHOST_NUMA by default for all
> > > > configurations where libnuma is already a default dependency.
> > > > 
> > > > Signed-off-by: Ilya Maximets 
> > > > ---
> > > >  config/common_linuxapp| 1 +
> > > >  config/defconfig_arm-armv7a-linuxapp-gcc  | 1 +
> > > >  config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
> > > >  3 files changed, 3 insertions(+)
> > [...]
> > > > --- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
> > > > +++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
> > > > @@ -47,6 +47,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=256
> > > > 
> > > >  # Doesn't support NUMA
> > > >  CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
> > > > +CONFIG_RTE_LIBRTE_VHOST_NUMA=n
> > > > 
> > > >  #
> > > >  # Compile Support Libraries for DPAA2
> > > > 
> > > 
> > > -1
> > > It should also be disabled for generic ARM64. This patch is breaking
> > > generic arm64 config tests on our platforms and creating a unnecessary
> > > dependency.
> > 
> > What do you mean? Which ARM64 platform is it breaking?
> > We can specifically disable it on more platforms.
> > 
> Unlike x86, ARM only represent a core architecture.
> Different platforms can integrate these cores differently in their SoCs.
> The stock ARM v8 cores do not provide support for NUMA in my knowledge.

A72 is just _an_ implementation of armv8. Not ARMv8 specification
itself. By specification it is NUMA capable and there are NUMA
implementation too.

> Some vendors have modified ARM cores (e.g. Cavium) to support NUMA
> architecture. However that is not a common phenomena.
> NUMA config should not be default for generic ARM config. It should be
> enabled only for architecture supporting it.

It just an build time dependency. Right? If you feed the libnuma package,
it will NON NUMA as well. Right? ARM64 libnuma package is already
available for major distributions.

My point is, I don't want to make arm64 generic config an exceptional case,
If DPDK common config creates libnuma dependency then there is no reason
for arm64 not have it. It is same for x86 and powerpc, non numa systems
too. Right?

> 
> So, *arm64-armv8a-linuxapp-gcc* config is being used by several vendors
> include NXP. e.g. We use this config on several of our low end systems
> (non-dpaa). Also, we use it when running in VM with virtio interfaces on all
> of our different platforms (non-dpaa, dpaa1, dpaa2 etc).

On the same note, arm64-armv8a-linuxapp-gcc used by other vendors for Server 
machines
with NUMA and if want to keep creating new targets there is no end to it.

How hard is to install libnuma on VM? There is already package for it.


> 
> 
> 
> 
> 
> 
> 
> 

Re: [dpdk-dev] [PATCH] bond: update the NTT flag when partner's state changes from slow to fast

[Ferruh Yigit]

On 5/22/2017 8:52 AM, zhangsha.zh...@huawei.com wrote:
> From: Sha Zhang 
> 
> According to the standard, state machine of lacp should transmit lacpdu
> when partner's state changes from slow to fast, rather than from fast
>  to slow.
> 
> Signed-off-by: Sha Zhang 

Acked-by: Declan Doherty 

Applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [PATCH v5 04/12] bus: add bus iterator to find a device

[Bruce Richardson]

On Mon, Jun 26, 2017 at 02:22:02AM +0200, Gaetan Rivet wrote:
> From: Jan Blunck 
> 
> Signed-off-by: Jan Blunck 
> Signed-off-by: Gaetan Rivet 
> ---
>  lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  1 +
>  lib/librte_eal/common/eal_common_bus.c  | 24 +++
>  lib/librte_eal/common/include/rte_bus.h | 26 
> +
>  lib/librte_eal/linuxapp/eal/rte_eal_version.map |  1 +
>  4 files changed, 52 insertions(+)
> 

Same comment for previous patch on naming of "started" variable.

Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH] eventdev: add producer enqueue hint

[Jerin Jacob]

-Original Message-
> Date: Tue, 27 Jun 2017 08:44:34 +
> From: "Van Haaren, Harry" 
> To: Jerin Jacob , "Eads, Gage"
>  
> CC: "dev@dpdk.org" , "Richardson, Bruce"
>  , "hemant.agra...@nxp.com"
>  , "nipun.gu...@nxp.com" ,
>  "Vangati, Narender" , "Rao, Nikhil"
>  
> Subject: RE: [dpdk-dev] [PATCH] eventdev: add producer enqueue hint
> 
> > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> > Sent: Tuesday, June 27, 2017 9:08 AM
> > To: Eads, Gage 
> > Cc: dev@dpdk.org; Richardson, Bruce ; Van 
> > Haaren, Harry
> > ; hemant.agra...@nxp.com; nipun.gu...@nxp.com; 
> > Vangati,
> > Narender ; Rao, Nikhil 
> > Subject: Re: [dpdk-dev] [PATCH] eventdev: add producer enqueue hint
> 
> 
> 
> > > >  void
> > > > diff --git a/lib/librte_eventdev/rte_eventdev.h
> > > > b/lib/librte_eventdev/rte_eventdev.h
> > > > index a248fe90e..1c1a46593 100644
> > > > --- a/lib/librte_eventdev/rte_eventdev.h
> > > > +++ b/lib/librte_eventdev/rte_eventdev.h
> > > > @@ -933,7 +933,15 @@ struct rte_event {
> > > >  * and is undefined on dequeue.
> > > >  * @see RTE_EVENT_OP_NEW, (RTE_EVENT_OP_*)
> > > >  */
> > > > -   uint8_t rsvd:4;
> > > > +   uint8_t all_op_new:1;
> > > > +   /**< Valid only with event enqueue operation - 
> > > > This hint
> > > > +* indicates that the enqueue request has only 
> > > > the
> > > > +* events with op == RTE_EVENT_OP_NEW.
> > > > +* The event producer, typically use this 
> > > > pattern to
> > > > +* inject the events to eventdev.
> > > > +* @see RTE_EVENT_OP_NEW
> > > > rte_event_enqueue_burst()
> > > > +*/
> > > > +   uint8_t rsvd:3;
> > > > /**< Reserved for future use */
> > > > uint8_t sched_type:2;
> > > > /**< Scheduler synchronization type
> > > > (RTE_SCHED_TYPE_*)
> > > > --
> > > > 2.13.1
> > >
> > > I slightly prefer the parallel enqueue API -- I can see folks making the 
> > > mistake of
> > setting all_op_new without setting the op to RTE_EVENT_OP_NEW, and later 
> > adding a
> > "forward-only" enqueue API could be interesting for the sw PMD -- but this 
> > looks fine to
> > me. Curious if others have any thoughts.
> > 
> > If forward-only parallel enqueue API interesting for the SW PMD then I
> > can drop this one and introduce forward-only API. Let me know if others
> > have any thoughts?
> 
> 
> To make sure I understand correctly, the "parallel API" idea is to add a new 
> function pointer per-PMD, and dedicate it to enqueueing a burst of packets 
> with the same OP? So the end result would be function(s) in the public API 
> like this:
> 
> rte_event_enqueue_burst_new(port, new_events, n_events);
> rte_event_enqueue_burst_forward(port, new_events, n_events);
> 
> Given these are a "specialization" of the generic enqueue_burst() function, 
> the PMD is not obliged to implement them. If they are NULL, the eventdev.c 
> infrastructure can just point the burst_new() and burst_forward() to the 
> generic enqueue without any performance delta?
> 
> The cost is some added code in the public header and infrastructure.
> The gain is that we don't overload the current API with new behavior. 
> 
> 
> Assuming my description of the parallel proposal above is correct, +1 for the 
> parallel function approach. I like APIs that "do what they say on the tin" :)

Yes. We are on the same page. I will send the v2.

[dpdk-dev] [PATCH v9 0/2] Balanced allocation of hugepages

[Ilya Maximets]

Version 9:
* Removed DPDK_DEP_NUMA from test-build.sh . Not needed
  anymore.
* Fixed out of bound write to essential_memory in case
  where socket-mem not specified and SIGBUS occured.

Version 8:
* helper functions from libnuma used to set mempolicy and
  work with cpu mask.
* Function now restores previous mempolicy instead of MPOL_DEFAULT.
* Fixed essential_memory on SIGBUS.
* Fixed restoring of mempolicy in case of errors (goto out).
* Enabled by default for all linuxapp except armv7 and dpaa2.

Version 7:
* RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES

Version 6:
* Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
  returned. Enabled by default for x86, ppc and thunderx.

Version 5:
* Fixed shared build. (Automated build test will fail
  anyway because libnuma-devel not installed on build servers)

Version 4:
* Fixed work on systems without NUMA by adding check for NUMA
  support in kernel.

Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.

Version 2:
* rebased (fuzz in Makefile)

Ilya Maximets (2):
  mem: balanced allocation of hugepages
  config: enable vhost numa awareness by default

 config/common_base|   1 +
 config/common_linuxapp|   2 +
 config/defconfig_arm-armv7a-linuxapp-gcc  |   4 +
 config/defconfig_arm64-dpaa2-linuxapp-gcc |   4 +
 devtools/test-build.sh|   4 -
 lib/librte_eal/linuxapp/eal/Makefile  |   3 +
 lib/librte_eal/linuxapp/eal/eal_memory.c  | 120 --
 mk/rte.app.mk |   3 +
 8 files changed, 129 insertions(+), 12 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH v9 2/2] config: enable vhost numa awareness by default

[Ilya Maximets]

It is safe to enable LIBRTE_VHOST_NUMA by default for all
configurations where libnuma is already a default dependency.

DPDK_DEP_NUMA not needed anymore.

Signed-off-by: Ilya Maximets 
---
 config/common_linuxapp| 1 +
 config/defconfig_arm-armv7a-linuxapp-gcc  | 1 +
 config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
 devtools/test-build.sh| 4 
 4 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/config/common_linuxapp b/config/common_linuxapp
index 64bef87..74c7d64 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -42,6 +42,7 @@ CONFIG_RTE_KNI_KMOD=y
 CONFIG_RTE_LIBRTE_KNI=y
 CONFIG_RTE_LIBRTE_PMD_KNI=y
 CONFIG_RTE_LIBRTE_VHOST=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=y
 CONFIG_RTE_LIBRTE_PMD_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
 CONFIG_RTE_LIBRTE_PMD_TAP=y
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
b/config/defconfig_arm-armv7a-linuxapp-gcc
index e06b1d4..00bc2ab 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -49,6 +49,7 @@ CONFIG_RTE_TOOLCHAIN_GCC=y
 
 # NUMA is not supported on ARM
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n
 
 # ARM doesn't have support for vmware TSC map
 CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc 
b/config/defconfig_arm64-dpaa2-linuxapp-gcc
index f78449d..b061fb0 100644
--- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -47,6 +47,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=256
 
 # Doesn't support NUMA
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n
 
 #
 # Compile Support Libraries for DPAA2
diff --git a/devtools/test-build.sh b/devtools/test-build.sh
index 61bdce7..0dbc04a 100755
--- a/devtools/test-build.sh
+++ b/devtools/test-build.sh
@@ -41,7 +41,6 @@ default_path=$PATH
 # - DPDK_DEP_ISAL_CRYPTO (y/[n])
 # - DPDK_DEP_LDFLAGS
 # - DPDK_DEP_MOFED (y/[n])
-# - DPDK_DEP_NUMA (y/[n])
 # - DPDK_DEP_PCAP (y/[n])
 # - DPDK_DEP_SSL (y/[n])
 # - DPDK_DEP_SZE (y/[n])
@@ -124,7 +123,6 @@ reset_env ()
unset DPDK_DEP_ISAL_CRYPTO
unset DPDK_DEP_LDFLAGS
unset DPDK_DEP_MOFED
-   unset DPDK_DEP_NUMA
unset DPDK_DEP_PCAP
unset DPDK_DEP_SSL
unset DPDK_DEP_SZE
@@ -163,8 +161,6 @@ config () #   
sed -ri 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )
 
# Automatic configuration
-   test "$DPDK_DEP_NUMA" != y || \
-   sed -ri   's,(NUMA=)n,\1y,' $1/.config
sed -ri's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
sed -ri 's,(BYPASS=)n,\1y,' $1/.config
test "$DPDK_DEP_ARCHIVE" != y || \
-- 
2.7.4

[dpdk-dev] [PATCH v9 1/2] mem: balanced allocation of hugepages

[Ilya Maximets]

Currently EAL allocates hugepages one by one not paying attention
from which NUMA node allocation was done.

Such behaviour leads to allocation failure if number of available
hugepages for application limited by cgroups or hugetlbfs and
memory requested not only from the first socket.

Example:
# 90 x 1GB hugepages availavle in a system

cgcreate -g hugetlb:/test
# Limit to 32GB of hugepages
cgset -r hugetlb.1GB.limit_in_bytes=34359738368 test
# Request 4GB from each of 2 sockets
cgexec -g hugetlb:test testpmd --socket-mem=4096,4096 ...

EAL: SIGBUS: Cannot mmap more hugepages of size 1024 MB
EAL: 32 not 90 hugepages of size 1024 MB allocated
EAL: Not enough memory available on socket 1!
 Requested: 4096MB, available: 0MB
PANIC in rte_eal_init():
Cannot init memory

This happens beacause all allocated pages are
on socket 0.

Fix this issue by setting mempolicy MPOL_PREFERRED for each hugepage
to one of requested nodes using following schema:

1) Allocate essential hugepages:
1.1) Allocate as many hugepages from numa N to
 only fit requested memory for this numa.
1.2) repeat 1.1 for all numa nodes.
2) Try to map all remaining free hugepages in a round-robin
   fashion.
3) Sort pages and choose the most suitable.

In this case all essential memory will be allocated and all remaining
pages will be fairly distributed between all requested nodes.

New config option RTE_EAL_NUMA_AWARE_HUGEPAGES introduced and
enabled by default for linuxapp except armv7 and dpaa2.
Enabling of this option adds libnuma as a dependency for EAL.

Fixes: 77988fc08dc5 ("mem: fix allocating all free hugepages")

Signed-off-by: Ilya Maximets 
---
 config/common_base|   1 +
 config/common_linuxapp|   1 +
 config/defconfig_arm-armv7a-linuxapp-gcc  |   3 +
 config/defconfig_arm64-dpaa2-linuxapp-gcc |   3 +
 lib/librte_eal/linuxapp/eal/Makefile  |   3 +
 lib/librte_eal/linuxapp/eal/eal_memory.c  | 120 --
 mk/rte.app.mk |   3 +
 7 files changed, 126 insertions(+), 8 deletions(-)

diff --git a/config/common_base b/config/common_base
index f6aafd1..660588a 100644
--- a/config/common_base
+++ b/config/common_base
@@ -103,6 +103,7 @@ CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
 CONFIG_RTE_EAL_IGB_UIO=n
 CONFIG_RTE_EAL_VFIO=n
 CONFIG_RTE_MALLOC_DEBUG=n
+CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
 
 #
 # Recognize/ignore the AVX/AVX512 CPU flags for performance/power testing.
diff --git a/config/common_linuxapp b/config/common_linuxapp
index b3cf41b..64bef87 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -35,6 +35,7 @@
 CONFIG_RTE_EXEC_ENV="linuxapp"
 CONFIG_RTE_EXEC_ENV_LINUXAPP=y
 
+CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
 CONFIG_RTE_EAL_IGB_UIO=y
 CONFIG_RTE_EAL_VFIO=y
 CONFIG_RTE_KNI_KMOD=y
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
b/config/defconfig_arm-armv7a-linuxapp-gcc
index 19607eb..e06b1d4 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -47,6 +47,9 @@ CONFIG_RTE_ARCH_STRICT_ALIGN=y
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y
 
+# NUMA is not supported on ARM
+CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
+
 # ARM doesn't have support for vmware TSC map
 CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
 
diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc 
b/config/defconfig_arm64-dpaa2-linuxapp-gcc
index 2304ab6..f78449d 100644
--- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -45,6 +45,9 @@ CONFIG_RTE_CACHE_LINE_SIZE=64
 
 CONFIG_RTE_PKTMBUF_HEADROOM=256
 
+# Doesn't support NUMA
+CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
+
 #
 # Compile Support Libraries for DPAA2
 #
diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
b/lib/librte_eal/linuxapp/eal/Makefile
index 640afd0..8651e27 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -50,6 +50,9 @@ LDLIBS += -ldl
 LDLIBS += -lpthread
 LDLIBS += -lgcc_s
 LDLIBS += -lrt
+ifeq ($(CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES),y)
+LDLIBS += -lnuma
+endif
 
 # specific to linuxapp exec-env
 SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) := eal.c
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c 
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index e17c9cb..647d89c 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -54,6 +54,10 @@
 #include 
 #include 
 #include 
+#ifdef RTE_EAL_NUMA_AWARE_HUGEPAGES
+#include 
+#include 
+#endif
 
 #include 
 #include 
@@ -348,6 +352,14 @@ static int huge_wrap_sigsetjmp(void)
return sigsetjmp(huge_jmpenv, 1);
 }
 
+#ifdef RTE_EAL_NUMA_AWARE_HUGEPAGES
+/* Callback for numa library. */
+void numa_error(char *where)
+{
+   RTE_LOG(ERR, EAL, "%s failed: %

Re: [dpdk-dev] [PATCH v8 2/2] config: enable vhost numa awareness by default

[Ilya Maximets]

On 27.06.2017 12:19, Thomas Monjalon wrote:
> 27/06/2017 10:46, Ilya Maximets:
>> It is safe to enable LIBRTE_VHOST_NUMA by default for all
>> configurations where libnuma is already a default dependency.
>>
>> Signed-off-by: Ilya Maximets 
>> ---
>>  config/common_linuxapp| 1 +
>>  config/defconfig_arm-armv7a-linuxapp-gcc  | 1 +
>>  config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
>>  3 files changed, 3 insertions(+)
> 
> I forgot to ask you to update devtools/test-build.sh.
> DPDK_DEP_NUMA can be removed.

Ok. Fixed in v9.

[dpdk-dev] [PATCH v3 0/4] Rework cfgfile API to enable apps config file support

[Jacek Piasecki]

New API for cfgfile library allows to create a cfgfile at runtime, add new
section, add entry in a section, update existing entry and save cfgfile
structure to INI file - opens up the possibility to have applications
dynamically build up a proper DPDK configuration, rather than
having to have a pre-existing one. Due the new API functions, simplification
of load() function was made. One new unit test to TEST app was added. It
contains an example of a large INI file whose parsing requires multiple
reallocation of memory.

---
v3: 
split one patchset into two distinct patchsets:
1. cfgfile library and TEST app changes
2. EAL changes and examples (this patchset depends on cfgfile)
v2:
  lib eal:
Rework of rte_eal_configure(struct rte_cfgfile *cfg, char *prgname).
Now this function load data from cfg structure and did initial
initialization of EAL arguments. Vdev argument are stored in different
subsections eg. DPDK.vdev0, DPDK.vdev1 etc. After execution of this
function it is necessary to call rte_eal_init to complete EAL
initialization. There is no more merging arguments from different
sources (cfg file and command line).
Added non_eal_configure to testpmd application.
Function maintain the same functionality as rte_eal_configure but
for non-eal arguments. 
Added config JSON feature to testpmd last patch from patchset contain
example showing use of .json configuration files.

  lib cfgfile:
Rework of add_section(), add_entry() new implementation
New members allocated_entries/sections, free_entries/sections
in rte_cfgfile structure, change in array of pointers
**sections, **entries instead of *sections[], *entries[]
Add  set_entry() to update/overwrite already existing entry in cfgfile
struct
Add save() function to save on disc cfgfile structure in INI format
Rework of existing load() function  simplifying the code
Add unit test realloc_sections() in TEST app for testing realloc/malloc
of new API functions, add test for save() function

Jacek Piasecki (3):
  cfgfile: remove EAL dependency
  cfgfile: add new functions to API
  test/cfgfile: add new unit test

Kuba Kozak (1):
  cfgfile: rework of load function

 lib/librte_cfgfile/Makefile  |   1 +
 lib/librte_cfgfile/rte_cfgfile.c | 397 +++
 lib/librte_cfgfile/rte_cfgfile.h |  76 +
 lib/librte_cfgfile/rte_cfgfile_version.map   |  11 +
 test/test/test_cfgfile.c |  40 +++
 test/test/test_cfgfiles/etc/realloc_sections.ini | 128 
 6 files changed, 514 insertions(+), 139 deletions(-)
 create mode 100644 test/test/test_cfgfiles/etc/realloc_sections.ini

-- 
2.7.4

[dpdk-dev] [PATCH v3 1/4] cfgfile: remove EAL dependency

[Jacek Piasecki]

This patch removes the dependency to EAL in cfgfile library.

Signed-off-by: Jacek Piasecki 
---
 lib/librte_cfgfile/Makefile  |  1 +
 lib/librte_cfgfile/rte_cfgfile.c | 29 +
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/lib/librte_cfgfile/Makefile b/lib/librte_cfgfile/Makefile
index 755ef11..0bee43e 100644
--- a/lib/librte_cfgfile/Makefile
+++ b/lib/librte_cfgfile/Makefile
@@ -38,6 +38,7 @@ LIB = librte_cfgfile.a
 
 CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -I$(SRCDIR)/../librte_eal/common/include
 
 EXPORT_MAP := rte_cfgfile_version.map
 
diff --git a/lib/librte_cfgfile/rte_cfgfile.c b/lib/librte_cfgfile/rte_cfgfile.c
index b54a523..c6ae3e3 100644
--- a/lib/librte_cfgfile/rte_cfgfile.c
+++ b/lib/librte_cfgfile/rte_cfgfile.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "rte_cfgfile.h"
 
@@ -258,19 +257,25 @@ rte_cfgfile_load_with_params(const char *filename, int 
flags,
 
struct rte_cfgfile_section *sect =
cfg->sections[curr_section];
-   int n;
+
char *split[2] = {NULL};
-   n = rte_strsplit(buffer, sizeof(buffer), split, 2, '=');
-   if (flags & CFG_FLAG_EMPTY_VALUES) {
-   if ((n < 1) || (n > 2)) {
-   printf("Error at line %d - cannot split 
string, n=%d\n",
-  lineno, n);
-   goto error1;
-   }
+   split[0] = buffer;
+   split[1] = memchr(buffer, '=', len);
+
+   /* when delimeter not found */
+   if (split[1] == NULL) {
+   printf("Error at line %d - cannot "
+   "split string\n", lineno);
+   goto error1;
} else {
-   if (n != 2) {
-   printf("Error at line %d - cannot split 
string, n=%d\n",
-  lineno, n);
+   /* when delimeter found */
+   *split[1] = '\0';
+   split[1]++;
+
+   if (!(flags & CFG_FLAG_EMPTY_VALUES) &&
+   (*split[1] == '\0')) {
+   printf("Error at line %d - cannot "
+   "split string\n", lineno);
goto error1;
}
}
-- 
2.7.4

[dpdk-dev] [PATCH v3 2/4] cfgfile: add new functions to API

[Jacek Piasecki]

Extend existing cfgfile library with providing new API functions:

rte_cfgfile_create() - create new cfgfile object
rte_cfgfile_add_section() - add new section to existing cfgfile
object
rte_cfgfile_add_entry() - add new entry to existing cfgfile
object in specified section
rte_cfgfile_set_entry() - update existing entry in cfgfile object
rte_cfgfile_save() - save existing cfgfile object to INI file

This modification allows to create a cfgfile on
runtime and opens up the possibility to have applications
dynamically build up a proper DPDK configuration, rather than having
to have a pre-existing one.

Signed-off-by: Jacek Piasecki 
---
 lib/librte_cfgfile/rte_cfgfile.c   | 249 +++--
 lib/librte_cfgfile/rte_cfgfile.h   |  76 +
 lib/librte_cfgfile/rte_cfgfile_version.map |  11 ++
 3 files changed, 323 insertions(+), 13 deletions(-)

diff --git a/lib/librte_cfgfile/rte_cfgfile.c b/lib/librte_cfgfile/rte_cfgfile.c
index c6ae3e3..518b6ab 100644
--- a/lib/librte_cfgfile/rte_cfgfile.c
+++ b/lib/librte_cfgfile/rte_cfgfile.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "rte_cfgfile.h"
@@ -42,13 +43,17 @@
 struct rte_cfgfile_section {
char name[CFG_NAME_LEN];
int num_entries;
-   struct rte_cfgfile_entry *entries[0];
+   int free_entries;
+   int allocated_entries;
+   struct rte_cfgfile_entry **entries;
 };
 
 struct rte_cfgfile {
int flags;
int num_sections;
-   struct rte_cfgfile_section *sections[0];
+   int free_sections;
+   int allocated_sections;
+   struct rte_cfgfile_section **sections;
 };
 
 /** when we resize a file structure, how many extra entries
@@ -104,6 +109,65 @@ _strip(char *str, unsigned len)
return newlen;
 }
 
+static struct rte_cfgfile_section *
+_get_section(struct rte_cfgfile *cfg, const char *sectionname)
+{
+   int i;
+
+   for (i = 0; i < cfg->num_sections; i++) {
+   if (strncmp(cfg->sections[i]->name, sectionname,
+   sizeof(cfg->sections[0]->name)) == 0)
+   return cfg->sections[i];
+   }
+   return NULL;
+}
+
+static int
+_add_entry(struct rte_cfgfile_section *section, const char *entryname,
+   const char *entryvalue)
+{
+   int i;
+
+   /* resize entry structure if we don't have room for more entries */
+   if (section->free_entries == 0) {
+
+   struct rte_cfgfile_entry **n_entries =
+   realloc(section->entries,
+   sizeof(section->entries[0]) *
+   ((section->allocated_entries) +
+   CFG_ALLOC_ENTRY_BATCH));
+
+   if (n_entries == NULL)
+   return -ENOMEM;
+
+   section->entries = n_entries;
+
+   for (i = section->allocated_entries;
+   i < (section->allocated_entries) +
+   CFG_ALLOC_ENTRY_BATCH; i++) {
+   section->entries[i] =
+   malloc(sizeof(struct rte_cfgfile_entry));
+
+   if (section->entries[i] == NULL)
+   return -ENOMEM;
+   }
+   section->allocated_entries += CFG_ALLOC_ENTRY_BATCH;
+   section->free_entries += CFG_ALLOC_ENTRY_BATCH;
+   }
+
+   /* fill up entry fields with key name and value */
+   struct rte_cfgfile_entry *curr_entry =
+   section->entries[section->num_entries];
+
+   snprintf(curr_entry->name, sizeof(curr_entry->name), "%s", entryname);
+   snprintf(curr_entry->value, sizeof(curr_entry->value), "%s",
+   entryvalue);
+   section->num_entries++;
+   section->free_entries--;
+
+   return 0;
+}
+
 static int
 rte_cfgfile_check_params(const struct rte_cfgfile_parameters *params)
 {
@@ -332,6 +396,176 @@ rte_cfgfile_load_with_params(const char *filename, int 
flags,
return NULL;
 }
 
+struct rte_cfgfile *
+rte_cfgfile_create(int flags)
+{
+   int i, j;
+   struct rte_cfgfile *cfg = NULL;
+
+   cfg = malloc(sizeof(*cfg));
+   if (cfg == NULL)
+   return NULL;
+
+   memset(cfg, 0, sizeof((*cfg)));
+
+   cfg->flags = flags;
+
+   /* allocate first batch of sections and entries */
+   cfg->sections = malloc(sizeof(cfg->sections[0]) *
+   CFG_ALLOC_SECTION_BATCH);
+   if (cfg->sections == NULL)
+   return NULL;
+
+   for (i = 0; i < CFG_ALLOC_SECTION_BATCH; i++) {
+   cfg->sections[i] = malloc(sizeof(struct rte_cfgfile_section));
+   if (cfg->sections[i] == NULL)
+   return NULL;
+
+   memset(cfg->sections[i], 0,
+

[dpdk-dev] [PATCH v3 3/4] cfgfile: rework of load function

[Jacek Piasecki]

From: Kuba Kozak 

New functions added to cfgfile library make it possible
to significantly simplify the code of rte_cfgfile_load_with_params()

This patch shows the new body of this function.

Signed-off-by: Jacek Piasecki 
---
 lib/librte_cfgfile/rte_cfgfile.c | 143 +--
 1 file changed, 17 insertions(+), 126 deletions(-)

diff --git a/lib/librte_cfgfile/rte_cfgfile.c b/lib/librte_cfgfile/rte_cfgfile.c
index 518b6ab..5625c80 100644
--- a/lib/librte_cfgfile/rte_cfgfile.c
+++ b/lib/librte_cfgfile/rte_cfgfile.c
@@ -207,10 +207,6 @@ struct rte_cfgfile *
 rte_cfgfile_load_with_params(const char *filename, int flags,
 const struct rte_cfgfile_parameters *params)
 {
-   int allocated_sections = CFG_ALLOC_SECTION_BATCH;
-   int allocated_entries = 0;
-   int curr_section = -1;
-   int curr_entry = -1;
char buffer[CFG_NAME_LEN + CFG_VALUE_LEN + 4] = {0};
int lineno = 0;
struct rte_cfgfile *cfg = NULL;
@@ -222,28 +218,7 @@ rte_cfgfile_load_with_params(const char *filename, int 
flags,
if (f == NULL)
return NULL;
 
-   cfg = malloc(sizeof(*cfg) + sizeof(cfg->sections[0]) *
-   allocated_sections);
-   if (cfg == NULL)
-   goto error2;
-
-   memset(cfg->sections, 0, sizeof(cfg->sections[0]) * allocated_sections);
-
-   if (flags & CFG_FLAG_GLOBAL_SECTION) {
-   curr_section = 0;
-   allocated_entries = CFG_ALLOC_ENTRY_BATCH;
-   cfg->sections[curr_section] = malloc(
-   sizeof(*cfg->sections[0]) +
-   sizeof(cfg->sections[0]->entries[0]) *
-   allocated_entries);
-   if (cfg->sections[curr_section] == NULL) {
-   printf("Error - no memory for global section\n");
-   goto error1;
-   }
-
-   snprintf(cfg->sections[curr_section]->name,
-sizeof(cfg->sections[0]->name), "GLOBAL");
-   }
+   cfg = rte_cfgfile_create(flags);
 
while (fgets(buffer, sizeof(buffer), f) != NULL) {
char *pos = NULL;
@@ -254,6 +229,7 @@ rte_cfgfile_load_with_params(const char *filename, int 
flags,
"Check if line too long\n", lineno);
goto error1;
}
+   /* skip parsing if comment character found */
pos = memchr(buffer, params->comment_character, len);
if (pos != NULL) {
*pos = '\0';
@@ -261,6 +237,7 @@ rte_cfgfile_load_with_params(const char *filename, int 
flags,
}
 
len = _strip(buffer, len);
+   /* skip lines without useful content */
if (buffer[0] != '[' && memchr(buffer, '=', len) == NULL)
continue;
 
@@ -268,130 +245,44 @@ rte_cfgfile_load_with_params(const char *filename, int 
flags,
/* section heading line */
char *end = memchr(buffer, ']', len);
if (end == NULL) {
-   printf("Error line %d - no terminating '['"
+   printf("Error line %d - no terminating ']'"
"character found\n", lineno);
goto error1;
}
*end = '\0';
_strip(&buffer[1], end - &buffer[1]);
 
-   /* close off old section and add start new one */
-   if (curr_section >= 0)
-   cfg->sections[curr_section]->num_entries =
-   curr_entry + 1;
-   curr_section++;
-
-   /* resize overall struct if we don't have room for more
-   sections */
-   if (curr_section == allocated_sections) {
-   allocated_sections += CFG_ALLOC_SECTION_BATCH;
-   struct rte_cfgfile *n_cfg = realloc(cfg,
-   sizeof(*cfg) + sizeof(cfg->sections[0])
-   * allocated_sections);
-   if (n_cfg == NULL) {
-   curr_section--;
-   printf("Error - no more memory\n");
-   goto error1;
-   }
-   cfg = n_cfg;
-   }
-
-   /* allocate space for new section */
-   allocated_entries = CFG_ALLOC_ENTRY_BATCH;
-   curr_entry = -1;
-   cfg->sections[curr_section] = malloc(
-   sizeof(*cfg->sections[0]) +
-   

[dpdk-dev] [PATCH v3 4/4] test/cfgfile: add new unit test

[Jacek Piasecki]

Load huge realloc_sections.ini file to check malloc/realloc
ability of cfgfile library.

Signed-off-by: Jacek Piasecki 
---
 test/test/test_cfgfile.c |  40 +++
 test/test/test_cfgfiles/etc/realloc_sections.ini | 128 +++
 2 files changed, 168 insertions(+)
 create mode 100644 test/test/test_cfgfiles/etc/realloc_sections.ini

diff --git a/test/test/test_cfgfile.c b/test/test/test_cfgfile.c
index 4cc9b14..2278618 100644
--- a/test/test/test_cfgfile.c
+++ b/test/test/test_cfgfile.c
@@ -111,6 +111,7 @@ _test_cfgfile_sample(struct rte_cfgfile *cfgfile)
return 0;
 }
 
+
 static int
 test_cfgfile_sample1(void)
 {
@@ -154,6 +155,42 @@ test_cfgfile_sample2(void)
 }
 
 static int
+test_cfgfile_realloc_sections(void)
+{
+   struct rte_cfgfile *cfgfile;
+   int ret;
+   const char *value;
+
+   cfgfile = rte_cfgfile_load(CFG_FILES_ETC "/realloc_sections.ini", 0);
+   TEST_ASSERT_NOT_NULL(cfgfile, "Failed to load config file");
+
+   ret = rte_cfgfile_num_sections(cfgfile, NULL, 0);
+   TEST_ASSERT(ret == 9, "Unexpected number of sections: %d", ret);
+
+   ret = rte_cfgfile_has_section(cfgfile, "section9");
+   TEST_ASSERT(ret, "section9 missing");
+
+   ret = rte_cfgfile_section_num_entries(cfgfile, "section3");
+   TEST_ASSERT(ret == 21,
+   "section3 unexpected number of entries: %d", ret);
+
+   ret = rte_cfgfile_section_num_entries(cfgfile, "section9");
+   TEST_ASSERT(ret == 8, "section9 unexpected number of entries: %d", ret);
+
+   value = rte_cfgfile_get_entry(cfgfile, "section9", "key8");
+   TEST_ASSERT(strcmp("value8_section9", value) == 0,
+   "key unexpected value: %s", value);
+
+   ret = rte_cfgfile_save(cfgfile, "cfgfile_save.ini");
+   TEST_ASSERT_SUCCESS(ret, "Failed to save *.ini file");
+
+   ret = rte_cfgfile_close(cfgfile);
+   TEST_ASSERT_SUCCESS(ret, "Failed to close cfgfile");
+
+   return 0;
+}
+
+static int
 test_cfgfile_invalid_section_header(void)
 {
struct rte_cfgfile *cfgfile;
@@ -292,6 +329,9 @@ test_cfgfile(void)
if (test_cfgfile_sample2())
return -1;
 
+   if (test_cfgfile_realloc_sections())
+   return -1;
+
if (test_cfgfile_invalid_section_header())
return -1;
 
diff --git a/test/test/test_cfgfiles/etc/realloc_sections.ini 
b/test/test/test_cfgfiles/etc/realloc_sections.ini
new file mode 100644
index 000..e653e40
--- /dev/null
+++ b/test/test/test_cfgfiles/etc/realloc_sections.ini
@@ -0,0 +1,128 @@
+[section1]
+key1=value1_section1
+key2=value2_section1
+key3=value3_section1
+key4=value4_section1
+key5=value5_section1
+key6=value6_section1
+key7=value7_section1
+key8=value8_section1
+key9=value9_section1
+key10=value10_section1
+key11=value11_section1
+key12=value12_section1
+key13=value13_section1
+key14=value14_section1
+key15=value15_section1
+key16=value16_section1
+key17=value17_section1
+key18=value18_section1
+key19=value19_section1
+key20=value20_section1
+key21=value21_section1
+
+[section2]
+key1=value1_section2
+key2=value2_section2
+key3=value3_section2
+key4=value4_section2
+key5=value5_section2
+key6=value6_section2
+key7=value7_section2
+key8=value8_section2
+key9=value9_section2
+key10=value10_section2
+key11=value11_section2
+key12=value12_section2
+key13=value13_section2
+key14=value14_section2
+key15=value15_section2
+key16=value16_section2
+key17=value17_section2
+key18=value18_section2
+key19=value19_section2
+key20=value20_section2
+key21=value21_section2
+
+[section3]
+key1=value1_section3
+key2=value2_section3
+key3=value3_section3
+key4=value4_section3
+key5=value5_section3
+key6=value6_section3
+key7=value7_section3
+key8=value8_section3
+key9=value9_section3
+key10=value10_section3
+key11=value11_section3
+key12=value12_section3
+key13=value13_section3
+key14=value14_section3
+key15=value15_section3
+key16=value16_section3
+key17=value17_section3
+key18=value18_section3
+key19=value19_section3
+key20=value20_section3
+key21=value21_section3
+
+[section4]
+key1=value1_section4
+key2=value2_section4
+key3=value3_section4
+key4=value4_section4
+key5=value5_section4
+key6=value6_section4
+key7=value7_section4
+key8=value8_section4
+
+[section5]
+key1=value1_section5
+key2=value2_section5
+key3=value3_section5
+key4=value4_section5
+key5=value5_section5
+key6=value6_section5
+key7=value7_section5
+key8=value8_section5
+
+[section6]
+key1=value1_section6
+key2=value2_section6
+key3=value3_section6
+key4=value4_section6
+key5=value5_section6
+key6=value6_section6
+key7=value7_section6
+key8=value8_section6
+
+[section7]
+key1=value1_section7
+key2=value2_section7
+key3=value3_section7
+key4=value4_section7
+key5=value5_section7
+key6=value6_section7
+key7=value7_section7
+key8=value8_section7
+
+[section8]
+key1=value1_section8
+key2=value2_section8
+key3=value3_section8
+key4=value4_section8
+key5=value5_section8
+key6=

Re: [dpdk-dev] [PATCH v3 8/8] mk: always rebuild in the same order

[Luca Boccassi]

On Tue, 2017-06-27 at 01:22 +0200, Thomas Monjalon wrote:
> 23/06/2017 20:41, lbocc...@brocade.com:
> > From: Luca Boccassi 
> > 
> > In order to achieve reproducible builds, always check dependencies
> > in
> > the same order.
> > 
> > Signed-off-by: Luca Boccassi 
> > ---
> >  mk/internal/rte.compile-pre.mk | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> It seems something is missing in this patch,
> because it is always rebuilding all on the second build.

Indeed, thanks for spotting my mistake!

Sorting before comparing was changing the compared strings, so that was
not working. Duh!
Moving the sort as the "outer" call solves the problem, now rebuilds
correctly skip already built objects.

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [PATCH v3 7/8] mk: sort object files when building deps lists

[Luca Boccassi]

On Tue, 2017-06-27 at 01:20 +0200, Thomas Monjalon wrote:
> 23/06/2017 20:41, lbocc...@brocade.com:
> > From: Luca Boccassi 
> > 
> > In order to achieve reproducible builds, always use the same
> > order when listing object files to build dependencies lists.
> > 
> > Signed-off-by: Luca Boccassi 
> > ---
> >  mk/rte.app.mk | 4 ++--
> >  mk/rte.hostapp.mk | 4 ++--
> >  mk/rte.shared.mk  | 4 ++--
> >  3 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > --- a/mk/rte.app.mk
> > +++ b/mk/rte.app.mk
> > @@ -263,8 +263,8 @@ LDLIBS_NAMES += $(patsubst -Wl$(comma)-
> > l%,lib%.a,$(filter -Wl$(comma)-l%,$(LDLIB
> >  
> >  # list of found libraries files (useful for deps). If not found,
> > the
> >  # library is silently ignored and dep won't be checked
> > -LDLIBS_FILES := $(wildcard $(foreach dir,$(LDLIBS_PATH),\
> > -   $(addprefix $(dir)/,$(LDLIBS_NAMES
> > +LDLIBS_FILES := $(sort $(wildcard $(foreach dir,$(LDLIBS_PATH),\
> > +   $(addprefix $(dir)/,$(LDLIBS_NAMES)
> 
> You cannot sort libraries.
> Check - for instance - this comment above in this file:
>   # Eliminate duplicates without sorting, only keep the last
> occurrence
>   filter-libs = \

Not sure I follow - what's the reason for avoiding to sort the list of
libs to link against?

> Why sorting them?
> What is random in libraries list?

The issue is that the output of wildcard is not fully deterministic. It
can depend on the filesystem, and even on the locale settings [1].
Before GNU Make 3.82 (2009) it used to automatically sort the output,
but that was removed (to make it faster... sigh). [2]



-- 
Kind regards,
Luca Boccassi

[1] https://reproducible-builds.org/docs/stable-inputs/
[2] http://comments.gmane.org/gmane.comp.gnu.make.bugs/4260

[dpdk-dev] [PATCH v3 0/3] EAL change for using a config file for DPDK

[Jacek Piasecki]

This patchset introduce a mechanism for running dpdk application with parameters
provided by configuration file.

A new API for EAL takes a config file data type - either loaded from file,
or built up programmatically in the application - and extracts DPDK parameters
from it to be used when eal init is called. This allows apps to have
an alternative method to configure EAL, other than via command-line parameters.

Testpmd application is used to the demonstrate the new eal API.
If a --cfgfile-path  option is passed into command line non EAL section,
then the file is loaded and used by app. If a file called config.ini
is present in current working directory, and no --cfgfile-path option is
passed in, config.ini file will be loaded and used by app.

Last patch demonstrates the usage of JSON file format insted of config.ini
JSON file can be called the same way as above, thru --cfgfile-path 

---
v3: 
split one patchset into two distinct patchsets:
1. cfgfile library and TEST app changes
2. EAL changes and examples (this patchset depends on cfgfile)
v2:
  lib eal:
Rework of rte_eal_configure(struct rte_cfgfile *cfg, char *prgname).
Now this function load data from cfg structure and did initial
initialization of EAL arguments. Vdev argument are stored in different
subsections eg. DPDK.vdev0, DPDK.vdev1 etc. After execution of this
function it is necessary to call rte_eal_init to complete EAL
initialization. There is no more merging arguments from different
sources (cfg file and command line).
Added non_eal_configure to testpmd application.
Function maintain the same functionality as rte_eal_configure but
for non-eal arguments. 
Added config JSON feature to testpmd last patch from patchset contain
example showing use of .json configuration files.

  lib cfgfile:
Rework of add_section(), add_entry() new implementation
New members allocated_entries/sections, free_entries/sections
in rte_cfgfile structure, change in array of pointers
**sections, **entries instead of *sections[], *entries[]
Add  set_entry() to update/overwrite already existing entry in cfgfile
struct
Add save() function to save on disc cfgfile structure in INI format
Rework of existing load() function  simplifying the code
Add unit test realloc_sections() in TEST app for testing realloc/malloc
of new API functions, add test for save() function

Kuba Kozak (3):
  eal: add functions parsing EAL arguments
  app/testpmd: changed example to parse options from cfg file
  app/testpmd: add parse arguments from JSON config file

 app/test-pmd/Makefile   |6 +
 app/test-pmd/config.ini |   24 +
 app/test-pmd/config.json|   33 +
 app/test-pmd/parameters.c   | 1193 +--
 app/test-pmd/testpmd.c  |  159 ++-
 app/test-pmd/testpmd.h  |3 +-
 config/common_base  |6 +
 lib/Makefile|6 +-
 lib/librte_eal/bsdapp/eal/Makefile  |4 +
 lib/librte_eal/bsdapp/eal/eal.c |  249 -
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |4 +
 lib/librte_eal/common/eal_common_cpuflags.c |   14 +-
 lib/librte_eal/common/eal_common_lcore.c|   11 +-
 lib/librte_eal/common/eal_common_options.c  |5 +
 lib/librte_eal/common/include/rte_eal.h |   21 +
 lib/librte_eal/linuxapp/eal/Makefile|3 +
 lib/librte_eal/linuxapp/eal/eal.c   |  353 +--
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |4 +
 mk/rte.app.mk   |2 +-
 19 files changed, 1469 insertions(+), 631 deletions(-)
 create mode 100644 app/test-pmd/config.ini
 create mode 100644 app/test-pmd/config.json

-- 
2.7.4

[dpdk-dev] [PATCH v3 1/3] eal: add functions parsing EAL arguments

[Jacek Piasecki]

From: Kuba Kozak 

added function rte_eal_configure which configure
Environment Abstraction Layer (EAL) using
configuration structure.

Signed-off-by: Kuba Kozak 
Suggested-by: Bruce Richardson 
---
This patch depends on cfgfile patchset with:
"cfgfile: remove EAL dependency"
"cfgfile: add new functions to API"
"cfgfile: rework of load function"
"test/cfgfile: add new unit test"
---
 config/common_base  |   1 +
 lib/Makefile|   6 +-
 lib/librte_eal/bsdapp/eal/Makefile  |   4 +
 lib/librte_eal/bsdapp/eal/eal.c | 249 ++---
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |   4 +
 lib/librte_eal/common/eal_common_cpuflags.c |  14 +-
 lib/librte_eal/common/eal_common_lcore.c|  11 +-
 lib/librte_eal/common/eal_common_options.c  |   5 +
 lib/librte_eal/common/include/rte_eal.h |  21 ++
 lib/librte_eal/linuxapp/eal/Makefile|   3 +
 lib/librte_eal/linuxapp/eal/eal.c   | 353 ++--
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |   4 +
 mk/rte.app.mk   |   2 +-
 13 files changed, 543 insertions(+), 134 deletions(-)

diff --git a/config/common_base b/config/common_base
index f6aafd1..c1d0e69 100644
--- a/config/common_base
+++ b/config/common_base
@@ -569,6 +569,7 @@ CONFIG_RTE_LIBRTE_TIMER_DEBUG=n
 # Compile librte_cfgfile
 #
 CONFIG_RTE_LIBRTE_CFGFILE=y
+CONFIG_RTE_LIBRTE_CFGFILE_DEBUG=n
 
 #
 # Compile librte_cmdline
diff --git a/lib/Makefile b/lib/Makefile
index 07e1fd0..fc5df3a 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -32,7 +32,11 @@
 include $(RTE_SDK)/mk/rte.vars.mk
 
 DIRS-y += librte_compat
+DIRS-$(CONFIG_RTE_LIBRTE_CFGFILE) += librte_cfgfile
 DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal
+ifeq ($(CONFIG_RTE_LIBRTE_CFGFILE),y)
+DEPDIRS-librte_eal := librte_cfgfile
+endif
 DIRS-$(CONFIG_RTE_LIBRTE_RING) += librte_ring
 DEPDIRS-librte_ring := librte_eal
 DIRS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += librte_mempool
@@ -41,8 +45,6 @@ DIRS-$(CONFIG_RTE_LIBRTE_MBUF) += librte_mbuf
 DEPDIRS-librte_mbuf := librte_eal librte_mempool
 DIRS-$(CONFIG_RTE_LIBRTE_TIMER) += librte_timer
 DEPDIRS-librte_timer := librte_eal
-DIRS-$(CONFIG_RTE_LIBRTE_CFGFILE) += librte_cfgfile
-DEPDIRS-librte_cfgfile := librte_eal
 DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += librte_cmdline
 DEPDIRS-librte_cmdline := librte_eal
 DIRS-$(CONFIG_RTE_LIBRTE_ETHER) += librte_ether
diff --git a/lib/librte_eal/bsdapp/eal/Makefile 
b/lib/librte_eal/bsdapp/eal/Makefile
index a0f9950..d70eefb 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -50,6 +50,10 @@ EXPORT_MAP := rte_eal_version.map
 
 LIBABIVER := 4
 
+ifeq ($(CONFIG_RTE_LIBRTE_CFGFILE),y)
+LDLIBS += -lrte_cfgfile
+endif
+
 # specific to bsdapp exec-env
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_memory.c
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 05f0c1f..7baf848 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -73,6 +73,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "eal_private.h"
 #include "eal_thread.h"
@@ -309,6 +310,18 @@ eal_get_hugepage_mem_size(void)
 
 /* Parse the arguments for --log-level only */
 static void
+eal_log_level_cfg(struct rte_cfgfile *cfg)
+{
+   const char *entry;
+
+   entry = rte_cfgfile_get_entry(cfg, "DPDK", OPT_LOG_LEVEL);
+   if (entry)
+   eal_parse_common_option(OPT_LOG_LEVEL_NUM, entry,
+   &internal_config);
+}
+
+/* Parse the arguments for --log-level only */
+static void
 eal_log_level_parse(int argc, char **argv)
 {
int opt;
@@ -347,6 +360,58 @@ eal_log_level_parse(int argc, char **argv)
optarg = old_optarg;
 }
 
+/* Parse single argument */
+static int
+eal_parse_option(int opt, char *optarg, int option_index, char *prgname)
+{
+   int ret;
+
+   /* getopt is not happy, stop right now */
+   if (opt == '?') {
+   eal_usage(prgname);
+   ret = -1;
+   goto out;
+   }
+
+   ret = eal_parse_common_option(opt, optarg, &internal_config);
+   /* common parser is not happy */
+   if (ret < 0) {
+   eal_usage(prgname);
+   ret = -1;
+   goto out;
+   }
+   /* common parser handled this option */
+   if (ret == 0)
+   return 0;
+
+   switch (opt) {
+   case 'h':
+   eal_usage(prgname);
+   exit(EXIT_SUCCESS);
+   break;
+
+   default:
+   if (opt < OPT_LONG_MIN_NUM && isprint(opt)) {
+   RTE_LOG(ERR, EAL, "Option %c is not supported "
+   "on FreeBSD\n", opt);
+   } else if (opt >= OPT_LONG_MIN_NUM &&
+  opt < OPT_LONG_MAX_NUM) {
+   RTE_LOG(ERR, E

[dpdk-dev] [PATCH v3 2/3] app/testpmd: changed example to parse options from cfg file

[Jacek Piasecki]

From: Kuba Kozak 

This patch shows how to pass arguments to application
using config.ini file.

If a --cfgfile-path  option is passed into commandline
non EAL section, then the file is loaded and used by app.

If a config.ini file is present in current working
directory, and no --cfgfile-path option is passed in, config.ini
file will be loaded and used by app as default configuration.

Signed-off-by: Kuba Kozak 
Suggested-by: Bruce Richardson 
---
 app/test-pmd/config.ini   |   24 +
 app/test-pmd/parameters.c | 1193 ++---
 app/test-pmd/testpmd.c|   67 ++-
 app/test-pmd/testpmd.h|3 +-
 4 files changed, 790 insertions(+), 497 deletions(-)
 create mode 100644 app/test-pmd/config.ini

diff --git a/app/test-pmd/config.ini b/app/test-pmd/config.ini
new file mode 100644
index 000..54c83a2
--- /dev/null
+++ b/app/test-pmd/config.ini
@@ -0,0 +1,24 @@
+[DPDK]
+v =
+l = 0-4
+n = 4
+master-lcore = 0
+proc-type = primary
+
+[TEST-PMD]
+i =
+portmask = 0xff
+nb-cores = 4
+port-topology = paired
+
+[DPDK.vdev0]
+net_ring0 =
+
+[DPDK.vdev1]
+net_ring1 =
+
+[DPDK.vdev2]
+net_ring2 =
+
+[DPDK.vdev3]
+net_ring3 =
\ No newline at end of file
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index fbe6284..4202691 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -77,9 +77,96 @@
 #include 
 #endif
 #include 
+#ifdef RTE_LIBRTE_CFGFILE
+#include 
+#endif
 
 #include "testpmd.h"
 
+enum { TX, RX };
+
+static struct option lgopts[] = {
+   { "cfgfile-path",   1, 0, 1 },
+   { "help",   0, 0, 0 },
+#ifdef RTE_LIBRTE_CMDLINE
+   { "interactive",0, 0, 0 },
+   { "cmdline-file",   1, 0, 0 },
+   { "auto-start", 0, 0, 0 },
+   { "eth-peers-configfile",   1, 0, 0 },
+   { "eth-peer",   1, 0, 0 },
+#endif
+   { "ports",  1, 0, 0 },
+   { "nb-cores",   1, 0, 0 },
+   { "nb-ports",   1, 0, 0 },
+   { "coremask",   1, 0, 0 },
+   { "portmask",   1, 0, 0 },
+   { "numa",   0, 0, 0 },
+   { "no-numa",0, 0, 0 },
+   { "mp-anon",0, 0, 0 },
+   { "port-numa-config",   1, 0, 0 },
+   { "ring-numa-config",   1, 0, 0 },
+   { "socket-num", 1, 0, 0 },
+   { "mbuf-size",  1, 0, 0 },
+   { "total-num-mbufs",1, 0, 0 },
+   { "max-pkt-len",1, 0, 0 },
+   { "pkt-filter-mode",1, 0, 0 },
+   { "pkt-filter-report-hash", 1, 0, 0 },
+   { "pkt-filter-size",1, 0, 0 },
+   { "pkt-filter-drop-queue",  1, 0, 0 },
+#ifdef RTE_LIBRTE_LATENCY_STATS
+   { "latencystats",   1, 0, 0 },
+#endif
+#ifdef RTE_LIBRTE_BITRATE
+   { "bitrate-stats",  1, 0, 0 },
+#endif
+   { "disable-crc-strip",  0, 0, 0 },
+   { "enable-lro", 0, 0, 0 },
+   { "enable-rx-cksum",0, 0, 0 },
+   { "enable-scatter", 0, 0, 0 },
+   { "disable-hw-vlan",0, 0, 0 },
+   { "disable-hw-vlan-filter", 0, 0, 0 },
+   { "disable-hw-vlan-strip",  0, 0, 0 },
+   { "disable-hw-vlan-extend", 0, 0, 0 },
+   { "enable-drop-en",0, 0, 0 },
+   { "disable-rss",0, 0, 0 },
+   { "port-topology",  1, 0, 0 },
+   { "forward-mode",   1, 0, 0 },
+   { "rss-ip", 0, 0, 0 },
+   { "rss-udp",0, 0, 0 },
+   { "rxq",1, 0, 0 },
+   { "txq",1, 0, 0 },
+   { "rxd",1, 0, 0 },
+   { "txd",1, 0, 0 },
+   { "burst",  1, 0, 0 },
+   { "mbcache",1, 0, 0 },
+   { "txpt",   1, 0, 0 },
+   { "txht",   1, 0, 0 },
+   { "txwt",   1, 0, 0 },
+   { "txfreet",1, 0, 0 },
+   { "txrst",  1, 0, 0 },
+   { "txqflags",   1, 0, 0 },
+   { "rxpt",   1, 0, 0 },
+   { "rxht",   1, 0, 0 },
+   { "rxwt",   1, 0, 0 },
+   { "rxfreet",1, 0, 0 },
+   { "tx-queue-stats-mapping", 1, 0, 0 },
+   { "rx-queue-stats-mapping", 1, 0, 0 },
+   { "no-flush-rx",0, 0, 0 },
+   { "txpkts", 1, 0, 0 },
+   { "disable-link-check", 0, 0, 0 },
+   { "no-lsc-interrupt",   0, 0, 0 },
+   { "no-rmv-interrupt",   0, 0, 0 },
+   { "print-event",1, 0, 0 },
+   { "mask-event", 1, 0, 0 

[dpdk-dev] [PATCH v3 3/3] app/testpmd: add parse arguments from JSON config file

[Jacek Piasecki]

From: Kuba Kozak 

This patch shows usage of Jansson library to parse
application arguments from JSON config file.

https://github.com/akheron/jansson

If a --cfgfile-path  option is passed into commandline
non EAL section, then the disired JSON file is loaded and used
by app. In case when JSON doesn't exist an INI file is loaded.
The INI file can be passed also from --cfgfile-path option.

If a file called config.ini is present in current working
directory, and no --cfgfile-path option is passed in, config.ini
file will be loaded and used by app.

Signed-off-by: Kuba Kozak 
Suggested-by: Bruce Richardson 
---
 app/test-pmd/Makefile|  6 
 app/test-pmd/config.json | 33 +
 app/test-pmd/testpmd.c   | 94 +++-
 config/common_base   |  5 +++
 4 files changed, 137 insertions(+), 1 deletion(-)
 create mode 100644 app/test-pmd/config.json

diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
index c36be19..a1c84cc 100644
--- a/app/test-pmd/Makefile
+++ b/app/test-pmd/Makefile
@@ -83,6 +83,12 @@ endif
 
 endif
 
+ifeq ($(CONFIG_RTE_JSON_SUPPORT),y)
+ifeq ($(CONFIG_RTE_LIBRTE_CFGFILE),y)
+LDLIBS += -ljansson
+endif
+endif
+
 CFLAGS_cmdline.o := -D_GNU_SOURCE
 
 include $(RTE_SDK)/mk/rte.app.mk
diff --git a/app/test-pmd/config.json b/app/test-pmd/config.json
new file mode 100644
index 000..4589dbc
--- /dev/null
+++ b/app/test-pmd/config.json
@@ -0,0 +1,33 @@
+{
+   "DPDK":
+   {
+   "v": "",
+   "l": "0-4",
+   "n": "4",
+   "master-lcore": "0",
+   "proc-type": "primary"
+   },
+   "TEST-PMD":
+   {
+   "i": "",
+   "portmask": "0xff",
+   "nb-cores": "4",
+   "port-topology": "paired"
+   },
+   "DPDK.vdev0":
+   {
+   "net_ring0": ""
+   },
+   "DPDK.vdev1":
+   {
+   "net_ring1": ""
+   },
+   "DPDK.vdev2":
+   {
+   "net_ring2": ""
+   },
+   "DPDK.vdev3":
+   {
+   "net_ring3": ""
+   }
+}
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index cd69a6b..9ce1bbe 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -46,6 +46,10 @@
 
 #include 
 #include 
+
+#ifdef RTE_JSON_SUPPORT
+#include 
+#endif
 #include 
 
 #include 
@@ -2275,6 +2279,87 @@ cfgfile_load_path(int argc, char **argv)
}
return NULL;
 }
+
+#ifdef RTE_JSON_SUPPORT
+/*
+ * Decoding JSON structure to rte_cfgfile structure.
+ * Returns handler to cfgfile object, NULL if error.
+ */
+static struct
+rte_cfgfile *l3fwd_json_to_cfg(json_t *json, int flags)
+{
+   if (!json) {
+   printf("Error: JSON structure is NULL, nothing to parse\n");
+   return NULL;
+   }
+   /* create an empty instance of cfgfile structure */
+   struct rte_cfgfile *cfgfile = rte_cfgfile_create(flags);
+
+   if (!cfgfile)
+   return NULL;
+
+   const char *section;
+   json_t *entry;
+
+   /* set pointer to first section */
+   void *iter_section = json_object_iter(json);
+
+   while (iter_section) {
+
+   section = json_object_iter_key(iter_section);
+   entry = json_object_iter_value(iter_section);
+
+   /* add parsed section name of current section to cfgfile */
+   rte_cfgfile_add_section(cfgfile, section);
+
+   /* set pointer to first entry */
+   void *iter_entry = json_object_iter(entry);
+
+   while (iter_entry) {
+
+   const char *key;
+   const char *value;
+
+   key = json_object_iter_key(iter_entry);
+   value = json_string_value(
+   json_object_iter_value(iter_entry));
+
+   /* add parsed key and value of current entry */
+   /* to cfgfile */
+   rte_cfgfile_add_entry(cfgfile, section, key, value);
+
+   /* pointer to next entry */
+   iter_entry = json_object_iter_next(entry, iter_entry);
+   }
+   /* pointer to next section */
+   iter_section = json_object_iter_next(json, iter_section);
+   }
+   return cfgfile;
+}
+
+/*
+ * Check presence and load JSON file to rte_cfgfile structure.
+ * Returns handler to cfgfile object, NULL if error.
+ */
+static struct
+rte_cfgfile *l3fwd_load_json_to_cfg(const char *path)
+{
+   struct rte_cfgfile *cfgfile = NULL;
+   /* check if config file exist */
+   if (access(path, F_OK) != -1) {
+   /* parse JSON file */
+   json_error_t error;
+   json_t *json = json_load_file(path, 0, &error);
+
+   if (json)
+   cfgfile = l3fwd_json_to_cfg(json, 0);
+   else
+   fp

Re: [dpdk-dev] [PATCH v2] drivers/net: add support for IF-MIB and EtherLike-MIB for e1000

[Ferruh Yigit]

On 6/26/2017 10:42 AM, Radu Nicolau wrote:
> From: Michal Jastrzebski 
> 
> If-MIB xstats:
> ifNumber
> ifIndex
> ifType
> ifMtu
> ifSpeed
> ifPhysAddress
> ifOperStatus
> ifLastChange
> ifHighSpeed
> ifConnectorPresent
> ifCounterDiscontinuityTime
> 
> EtherLike-MIB xstats:
> dot3PauseOperMode
> dot3StatsDuplexStatus
> dot3StatsRateControlAbility
> dot3StatsRateControlStatus
> dot3ControlFunctionsSupported
> 
> -updated in v2: coding style
> 
> Signed-off-by: Piotr Azarewicz 
> Signed-off-by: Michal Jastrzebski 
> Signed-off-by: Radu Nicolau 

<...>

This patch implements MIBs for some Intel drivers using xstats, this is
easy way to get some information from PMDs.

But there was a outstanding comment to make this ethdev layer.

So I believe we have two options:

[1]
Each PMD implements MIBs using xstats, this is pragmatic solution and
each PMD can implement whichever MIBs they want.

[2]
Implement a ethdev layer API and add a new dev_ops to get MIBs, API can
use existing methods to get required information, and if it fails can
call dev_ops which can be similar to the xstats.
Because of API all PMDs can have a small amount of support by default
and they can implement dev_ops for more support.


Although 2) looks more generic and proper, I am not really sure if that
is overkill and if this worth to the effort and to have new API and
dev_ops, comparing current method is easy to implement, any comments?

Thanks,
ferruh

Re: [dpdk-dev] [PATCH v2] drivers/net: add support for IF-MIB and EtherLike-MIB for e1000

[Bruce Richardson]

On Tue, Jun 27, 2017 at 12:08:56PM +0100, Ferruh Yigit wrote:
> On 6/26/2017 10:42 AM, Radu Nicolau wrote:
> > From: Michal Jastrzebski 
> > 
> > If-MIB xstats:
> > ifNumber
> > ifIndex
> > ifType
> > ifMtu
> > ifSpeed
> > ifPhysAddress
> > ifOperStatus
> > ifLastChange
> > ifHighSpeed
> > ifConnectorPresent
> > ifCounterDiscontinuityTime
> > 
> > EtherLike-MIB xstats:
> > dot3PauseOperMode
> > dot3StatsDuplexStatus
> > dot3StatsRateControlAbility
> > dot3StatsRateControlStatus
> > dot3ControlFunctionsSupported
> > 
> > -updated in v2: coding style
> > 
> > Signed-off-by: Piotr Azarewicz 
> > Signed-off-by: Michal Jastrzebski 
> > Signed-off-by: Radu Nicolau 
> 
> <...>
> 
> This patch implements MIBs for some Intel drivers using xstats, this is
> easy way to get some information from PMDs.
> 
> But there was a outstanding comment to make this ethdev layer.
> 
> So I believe we have two options:
> 
> [1]
> Each PMD implements MIBs using xstats, this is pragmatic solution and
> each PMD can implement whichever MIBs they want.
> 
> [2]
> Implement a ethdev layer API and add a new dev_ops to get MIBs, API can
> use existing methods to get required information, and if it fails can
> call dev_ops which can be similar to the xstats.
> Because of API all PMDs can have a small amount of support by default
> and they can implement dev_ops for more support.
> 
> 
> Although 2) looks more generic and proper, I am not really sure if that
> is overkill and if this worth to the effort and to have new API and
> dev_ops, comparing current method is easy to implement, any comments?
> 

For 2, does the "use existing methods" include calling xstats? If so,
then we can just drop the requirement for 2 to have any new functions
implemented in the driver. Instead, have the information provided by
drivers in the normal xstats call, but have a new ethdev API to provide
that information to the app - basically hiding the xstats complexity
underneath.

/Bruce

Re: [dpdk-dev] [PATCH v2] drivers/net: add support for IF-MIB and EtherLike-MIB for e1000

[Ferruh Yigit]

On 6/27/2017 12:21 PM, Bruce Richardson wrote:
> On Tue, Jun 27, 2017 at 12:08:56PM +0100, Ferruh Yigit wrote:
>> On 6/26/2017 10:42 AM, Radu Nicolau wrote:
>>> From: Michal Jastrzebski 
>>>
>>> If-MIB xstats:
>>> ifNumber
>>> ifIndex
>>> ifType
>>> ifMtu
>>> ifSpeed
>>> ifPhysAddress
>>> ifOperStatus
>>> ifLastChange
>>> ifHighSpeed
>>> ifConnectorPresent
>>> ifCounterDiscontinuityTime
>>>
>>> EtherLike-MIB xstats:
>>> dot3PauseOperMode
>>> dot3StatsDuplexStatus
>>> dot3StatsRateControlAbility
>>> dot3StatsRateControlStatus
>>> dot3ControlFunctionsSupported
>>>
>>> -updated in v2: coding style
>>>
>>> Signed-off-by: Piotr Azarewicz 
>>> Signed-off-by: Michal Jastrzebski 
>>> Signed-off-by: Radu Nicolau 
>>
>> <...>
>>
>> This patch implements MIBs for some Intel drivers using xstats, this is
>> easy way to get some information from PMDs.
>>
>> But there was a outstanding comment to make this ethdev layer.
>>
>> So I believe we have two options:
>>
>> [1]
>> Each PMD implements MIBs using xstats, this is pragmatic solution and
>> each PMD can implement whichever MIBs they want.
>>
>> [2]
>> Implement a ethdev layer API and add a new dev_ops to get MIBs, API can
>> use existing methods to get required information, and if it fails can
>> call dev_ops which can be similar to the xstats.
>> Because of API all PMDs can have a small amount of support by default
>> and they can implement dev_ops for more support.
>>
>>
>> Although 2) looks more generic and proper, I am not really sure if that
>> is overkill and if this worth to the effort and to have new API and
>> dev_ops, comparing current method is easy to implement, any comments?
>>
> 
> For 2, does the "use existing methods" include calling xstats? If so,
> then we can just drop the requirement for 2 to have any new functions
> implemented in the driver. Instead, have the information provided by
> drivers in the normal xstats call, but have a new ethdev API to provide
> that information to the app - basically hiding the xstats complexity
> underneath.

I was thinking another dev_ops similar to xstats, but re-using xstats
can be better idea here.

so option 2 becomes:
[2] An eth_dev API to use existing APIs to get information from PMDs and
wrap MIBs related xstats calls.

But I believe if option 2 is overkill for this task question is still valid.

Thanks,
ferruh

[dpdk-dev] [PATCH v2] mbuf: reduce pktmbuf init cycles

[Jerin Jacob]

There is no need for initializing the complete
packet buffer with zero as the packet data area will be
overwritten by the NIC Rx HW anyway.

The testpmd configures the packet mempool
with around 180k buffers with
2176B size. In existing scheme, the init routine
needs to memset around ~370MB vs the proposed scheme
requires only around ~22MB on 128B cache aligned system.

Useful in running DPDK in HW simulators/emulators,
where millions of cycles have an impact on boot time.

Signed-off-by: Jerin Jacob 
---
v2:
- Removed RTE_PKTMBUF_HEADROOM from the memset area(Olivier)
---
 lib/librte_mbuf/rte_mbuf.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 0e3e36a58..ab436b9da 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -131,8 +131,7 @@ rte_pktmbuf_init(struct rte_mempool *mp,
RTE_ASSERT(mp->elt_size >= mbuf_size);
RTE_ASSERT(buf_len <= UINT16_MAX);
 
-   memset(m, 0, mp->elt_size);
-
+   memset(m, 0, mbuf_size);
/* start of buffer is after mbuf structure and priv data */
m->priv_size = priv_size;
m->buf_addr = (char *)m + mbuf_size;
-- 
2.13.2

[dpdk-dev] [PATCH] app/testpmd: update ddp add command parameters

[Andrey Chilikin]

This patch adds optional output file path to 'ddp add' command:
'ddp add (port) (profile_path[,output_path])'

Signed-off-by: Andrey Chilikin 
---
 app/test-pmd/cmdline.c  | 29 ++---
 app/test-pmd/config.c   | 21 +
 app/test-pmd/testpmd.h  |  1 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  2 +-
 4 files changed, 45 insertions(+), 8 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 632d6f03f..81d1f84fe 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -603,7 +603,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"E-tag set filter del e-tag-id (value) port (port_id)\n"
"Delete an E-tag forwarding filter on a port\n\n"
 
-   "ddp add (port_id) (profile_path)\n"
+   "ddp add (port_id) (profile_path[,output_path])\n"
"Load a profile package on a port\n\n"
 
"ptype mapping get (port_id) (valid_only)\n"
@@ -12955,6 +12955,9 @@ cmd_ddp_add_parsed(
struct cmd_ddp_add_result *res = parsed_result;
uint8_t *buff;
uint32_t size;
+   char *filepath;
+   char *file_fld[2];
+   int file_num;
int ret = -ENOTSUP;
 
if (res->port_id > nb_ports) {
@@ -12967,9 +12970,18 @@ cmd_ddp_add_parsed(
return;
}
 
-   buff = open_ddp_package_file(res->filepath, &size);
-   if (!buff)
+   filepath = strdup(res->filepath);
+   if (filepath == NULL) {
+   printf("Failed to allocate memory\n");
return;
+   }
+   file_num = rte_strsplit(filepath, strlen(filepath), file_fld, 2, ',');
+
+   buff = open_ddp_package_file(file_fld[0], &size);
+   if (!buff) {
+   free((void *)filepath);
+   return;
+   }
 
 #ifdef RTE_LIBRTE_I40E_PMD
if (ret == -ENOTSUP)
@@ -12978,18 +12990,21 @@ cmd_ddp_add_parsed(
   RTE_PMD_I40E_PKG_OP_WR_ADD);
 #endif
 
-   if (ret < 0)
-   printf("Failed to load profile.\n");
-   else if (ret > 0)
+   if (ret == -EEXIST)
printf("Profile has already existed.\n");
+   else if (ret < 0)
+   printf("Failed to load profile.\n");
+   else if (file_num == 2)
+   save_ddp_package_file(file_fld[1], buff, size);
 
close_ddp_package_file(buff);
+   free((void *)filepath);
 }
 
 cmdline_parse_inst_t cmd_ddp_add = {
.f = cmd_ddp_add_parsed,
.data = NULL,
-   .help_str = "ddp add  ",
+   .help_str = "ddp add  ",
.tokens = {
(void *)&cmd_ddp_add_ddp,
(void *)&cmd_ddp_add_add,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index b0b340e5c..2720bcb6d 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -3309,6 +3309,27 @@ open_ddp_package_file(const char *file_path, uint32_t 
*size)
 }
 
 int
+save_ddp_package_file(const char *file_path, uint8_t *buf, uint32_t size)
+{
+   FILE *fh = fopen(file_path, "wb");
+
+   if (fh == NULL) {
+   printf("%s: Failed to open %s\n", __func__, file_path);
+   return -1;
+   }
+
+   if (fwrite(buf, 1, size, fh) != size) {
+   fclose(fh);
+   printf("%s: File write operation failed\n", __func__);
+   return -1;
+   }
+
+   fclose(fh);
+
+   return 0;
+}
+
+int
 close_ddp_package_file(uint8_t *buf)
 {
if (buf) {
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 364502d1d..0334280de 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -633,6 +633,7 @@ void mcast_addr_remove(uint8_t port_id, struct ether_addr 
*mc_addr);
 void port_dcb_info_display(uint8_t port_id);
 
 uint8_t *open_ddp_package_file(const char *file_path, uint32_t *size);
+int save_ddp_package_file(const char *file_path, uint8_t *buf, uint32_t size);
 int close_ddp_package_file(uint8_t *buf);
 
 enum print_warning {
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 18ee8a3fe..e6b0b514a 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1230,7 +1230,7 @@ ddp add
 
 Load a dynamic device personalization (DDP) package::
 
-   testpmd> ddp add (port_id) (package_path)
+   testpmd> ddp add (port_id) (package_path[,output_path])
 
 ptype mapping
 ~
-- 
2.13.0

Re: [dpdk-dev] [PATCH v8 2/2] config: enable vhost numa awareness by default

[Hemant Agrawal]

On 6/27/2017 3:29 PM, Jerin Jacob wrote:

-Original Message-

Date: Tue, 27 Jun 2017 15:11:07 +0530
From: Hemant Agrawal 
To: Thomas Monjalon 
CC: Ilya Maximets , dev@dpdk.org, David Marchand
 , Sergio Gonzalez Monroy
 , Heetae Ahn ,
 Yuanhan Liu , Jianfeng Tan ,
 Neil Horman , Yulong Pei ,
 Bruce Richardson , Jerin Jacob
 
Subject: Re: [PATCH v8 2/2] config: enable vhost numa awareness by default
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0

On 6/27/2017 2:51 PM, Thomas Monjalon wrote:

27/06/2017 11:18, Hemant Agrawal:

On 6/27/2017 2:16 PM, Ilya Maximets wrote:

It is safe to enable LIBRTE_VHOST_NUMA by default for all
configurations where libnuma is already a default dependency.

Signed-off-by: Ilya Maximets 
---
 config/common_linuxapp| 1 +
 config/defconfig_arm-armv7a-linuxapp-gcc  | 1 +
 config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
 3 files changed, 3 insertions(+)

[...]

--- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -47,6 +47,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=256

 # Doesn't support NUMA
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n

 #
 # Compile Support Libraries for DPAA2



-1
It should also be disabled for generic ARM64. This patch is breaking
generic arm64 config tests on our platforms and creating a unnecessary
dependency.


What do you mean? Which ARM64 platform is it breaking?
We can specifically disable it on more platforms.


Unlike x86, ARM only represent a core architecture.
Different platforms can integrate these cores differently in their SoCs.
The stock ARM v8 cores do not provide support for NUMA in my knowledge.


A72 is just _an_ implementation of armv8. Not ARMv8 specification
itself. By specification it is NUMA capable and there are NUMA
implementation too.


Some vendors have modified ARM cores (e.g. Cavium) to support NUMA
architecture. However that is not a common phenomena.
NUMA config should not be default for generic ARM config. It should be
enabled only for architecture supporting it.


It just an build time dependency. Right? If you feed the libnuma package,
it will NON NUMA as well. Right? ARM64 libnuma package is already
available for major distributions.


yes, libnuma will work for non-NUMA.


My point is, I don't want to make arm64 generic config an exceptional case,
If DPDK common config creates libnuma dependency then there is no reason
for arm64 not have it. It is same for x86 and powerpc, non numa systems
too. Right?


x86 and powerpc configs are single vendor based.
Common should be common and generic.

Why to create a unnecessary dependency, when we know that the support is 
not uniform?  It adds difficulties e.g. For the ARM cross compilation, 
will also have to cross compile libnuma-dev. Makefile will need a path 
for specifying the lib and include paths for libnuma and numa.h.







So, *arm64-armv8a-linuxapp-gcc* config is being used by several vendors
include NXP. e.g. We use this config on several of our low end systems
(non-dpaa). Also, we use it when running in VM with virtio interfaces on all
of our different platforms (non-dpaa, dpaa1, dpaa2 etc).


On the same note, arm64-armv8a-linuxapp-gcc used by other vendors for Server 
machines
with NUMA and if want to keep creating new targets there is no end to it.

How hard is to install libnuma on VM? There is already package for it.

Re: [dpdk-dev] [PATCH v5 05/12] bus: introduce hotplug functionality

[Bruce Richardson]

On Mon, Jun 26, 2017 at 02:22:03AM +0200, Gaetan Rivet wrote:
> From: Jan Blunck 
> 
> Signed-off-by: Jan Blunck 
> Signed-off-by: Gaetan Rivet 
> ---
Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH v5 06/12] vdev: implement find_device bus operation

[Bruce Richardson]

On Mon, Jun 26, 2017 at 02:22:04AM +0200, Gaetan Rivet wrote:
> From: Jan Blunck 
> 
> Signed-off-by: Jan Blunck 
> Signed-off-by: Gaetan Rivet 
> ---
Acked-by: Bruce Richardson 

[dpdk-dev] [PATCH v2] net/tap: restore state of remote device when closing

[Thomas Monjalon]

When exiting a DPDK application, the TAP remote was left
with the link down even if it was initially up.

The device flags of the remote netdevice are saved when probing,
and restored when calling the close function.
The remote state is not set down when calling the stop function anymore.

Signed-off-by: Thomas Monjalon 
---
v2: move flags restore from stop to close function
---
 drivers/net/tap/rte_eth_tap.c | 13 -
 drivers/net/tap/rte_eth_tap.h |  2 ++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index 7cfa0a85d..df7423536 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -569,7 +569,7 @@ tap_link_set_down(struct rte_eth_dev *dev)
struct ifreq ifr = { .ifr_flags = IFF_UP };
 
dev->data->dev_link.link_status = ETH_LINK_DOWN;
-   return tap_ioctl(pmd, SIOCSIFFLAGS, &ifr, 0, LOCAL_AND_REMOTE);
+   return tap_ioctl(pmd, SIOCSIFFLAGS, &ifr, 0, LOCAL_ONLY);
 }
 
 static int
@@ -735,6 +735,12 @@ tap_dev_close(struct rte_eth_dev *dev)
internals->rxq[i].fd = -1;
internals->txq[i].fd = -1;
}
+
+   if (internals->remote_if_index) {
+   /* Restore initial remote state */
+   ioctl(internals->ioctl_sock, SIOCSIFFLAGS,
+   &internals->remote_initial_flags);
+   }
 }
 
 static void
@@ -1320,6 +1326,11 @@ eth_dev_tap_create(struct rte_vdev_device *vdev, char 
*tap_name,
}
snprintf(pmd->remote_iface, RTE_ETH_NAME_MAX_LEN,
 "%s", remote_iface);
+
+   /* Save state of remote device */
+   tap_ioctl(pmd, SIOCGIFFLAGS, &pmd->remote_initial_flags, 0, 
REMOTE_ONLY);
+
+   /* Replicate remote MAC address */
if (tap_ioctl(pmd, SIOCGIFHWADDR, &ifr, 0, REMOTE_ONLY) < 0) {
RTE_LOG(ERR, PMD, "%s: failed to get %s MAC address.",
pmd->name, pmd->remote_iface);
diff --git a/drivers/net/tap/rte_eth_tap.h b/drivers/net/tap/rte_eth_tap.h
index ad497b3d1..0d5a7df98 100644
--- a/drivers/net/tap/rte_eth_tap.h
+++ b/drivers/net/tap/rte_eth_tap.h
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -83,6 +84,7 @@ struct pmd_internals {
char name[RTE_ETH_NAME_MAX_LEN];  /* Internal Tap device name */
uint16_t nb_queues;   /* Number of queues supported */
struct ether_addr eth_addr;   /* Mac address of the device port */
+   struct ifreq remote_initial_flags;   /* Remote netdevice flags on init 
*/
int remote_if_index;  /* remote netdevice IF_INDEX */
int if_index; /* IF_INDEX for the port */
int ioctl_sock;   /* socket for ioctl calls */
-- 
2.13.1

Re: [dpdk-dev] [PATCH v5 07/12] vdev: implement hotplug functionality

[Bruce Richardson]

On Mon, Jun 26, 2017 at 02:22:05AM +0200, Gaetan Rivet wrote:
> Signed-off-by: Gaetan Rivet 
> ---
>  lib/librte_eal/common/eal_common_vdev.c | 36 
> +
>  1 file changed, 36 insertions(+)
> 
Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH v5 08/12] vdev: expose bus name

[Bruce Richardson]

On Mon, Jun 26, 2017 at 02:22:06AM +0200, Gaetan Rivet wrote:
> Signed-off-by: Gaetan Rivet 
> ---

The reason for this change is not explained, so either it explain it, or
better, IMHO, just merge with the next patch, since it's a one-line
change.

If kept as separate patch:

Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH v8 2/2] config: enable vhost numa awareness by default

[Jerin Jacob]

-Original Message-
> Date: Tue, 27 Jun 2017 17:47:44 +0530
> From: Hemant Agrawal 
> To: Jerin Jacob 
> CC: Thomas Monjalon , Ilya Maximets
>  , dev@dpdk.org, David Marchand
>  , Sergio Gonzalez Monroy
>  , Heetae Ahn ,
>  Yuanhan Liu , Jianfeng Tan ,
>  Neil Horman , Yulong Pei ,
>  Bruce Richardson 
> Subject: Re: [PATCH v8 2/2] config: enable vhost numa awareness by default
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
>  Thunderbird/45.8.0
> 
> On 6/27/2017 3:29 PM, Jerin Jacob wrote:
> > -Original Message-
> > > Date: Tue, 27 Jun 2017 15:11:07 +0530
> > > From: Hemant Agrawal 
> > > To: Thomas Monjalon 
> > > CC: Ilya Maximets , dev@dpdk.org, David Marchand
> > >  , Sergio Gonzalez Monroy
> > >  , Heetae Ahn 
> > > ,
> > >  Yuanhan Liu , Jianfeng Tan 
> > > ,
> > >  Neil Horman , Yulong Pei ,
> > >  Bruce Richardson , Jerin Jacob
> > >  
> > > Subject: Re: [PATCH v8 2/2] config: enable vhost numa awareness by default
> > > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
> > >  Thunderbird/45.8.0
> > > 
> > > On 6/27/2017 2:51 PM, Thomas Monjalon wrote:
> > > > 27/06/2017 11:18, Hemant Agrawal:
> > > > > On 6/27/2017 2:16 PM, Ilya Maximets wrote:
> > > > > > It is safe to enable LIBRTE_VHOST_NUMA by default for all
> > > > > > configurations where libnuma is already a default dependency.
> > > > > > 
> > > > > > Signed-off-by: Ilya Maximets 
> > > > > > ---
> > > > > >  config/common_linuxapp| 1 +
> > > > > >  config/defconfig_arm-armv7a-linuxapp-gcc  | 1 +
> > > > > >  config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
> > > > > >  3 files changed, 3 insertions(+)
> > > > [...]
> > > > > > --- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
> > > > > > +++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
> > > > > > @@ -47,6 +47,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=256
> > > > > > 
> > > > > >  # Doesn't support NUMA
> > > > > >  CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
> > > > > > +CONFIG_RTE_LIBRTE_VHOST_NUMA=n
> > > > > > 
> > > > > >  #
> > > > > >  # Compile Support Libraries for DPAA2
> > > > > > 
> > > > > 
> > > > > -1
> > > > > It should also be disabled for generic ARM64. This patch is breaking
> > > > > generic arm64 config tests on our platforms and creating a unnecessary
> > > > > dependency.
> > > > 
> > > > What do you mean? Which ARM64 platform is it breaking?
> > > > We can specifically disable it on more platforms.
> > > > 
> > > Unlike x86, ARM only represent a core architecture.
> > > Different platforms can integrate these cores differently in their SoCs.
> > > The stock ARM v8 cores do not provide support for NUMA in my knowledge.
> > 
> > A72 is just _an_ implementation of armv8. Not ARMv8 specification
> > itself. By specification it is NUMA capable and there are NUMA
> > implementation too.
> > 
> > > Some vendors have modified ARM cores (e.g. Cavium) to support NUMA
> > > architecture. However that is not a common phenomena.
> > > NUMA config should not be default for generic ARM config. It should be
> > > enabled only for architecture supporting it.
> > 
> > It just an build time dependency. Right? If you feed the libnuma package,
> > it will NON NUMA as well. Right? ARM64 libnuma package is already
> > available for major distributions.
> 
> yes, libnuma will work for non-NUMA.
> > 
> > My point is, I don't want to make arm64 generic config an exceptional case,
> > If DPDK common config creates libnuma dependency then there is no reason
> > for arm64 not have it. It is same for x86 and powerpc, non numa systems
> > too. Right?
> 
> x86 and powerpc configs are single vendor based.
> Common should be common and generic.

Yes. What I understand by common is that it should work on functionality on 
_all_ the
armv8 targets. If you don't include NUMA then it will have functionality issue
with NUMA targets.

The ARM64 Linux kernel took the similar approach. The default config has all
options and NUMA is _enabled_ even it is not supported on A72.

http://elixir.free-electrons.com/linux/latest/source/arch/arm64/configs/defconfig#L77


> 
> Why to create a unnecessary dependency, when we know that the support is not
> uniform?  It adds difficulties e.g. For the ARM cross compilation, will also
> have to cross compile libnuma-dev. Makefile will need a path for specifying
> the lib and include paths for libnuma and numa.h.

Yes. I agree. Cross compilation needs additional step. On the other
hand, If we don't include NUMA in common config, We need to add new targets on
all new SoCs(like thunderx2). IMO, In order to reduce the config, I think,
this is the better way.(and it is not hard to disable NUMA for cross
compilation mode if not interested)

> 
> 
> > 
> > > 
> > > So, *arm64-armv8a-linuxapp-gcc* config is being used by several vendors
> > > include NXP. e.g. We use this config on several of our low end systems
> > > (non-dpaa). Also, we use it when running in VM with virtio interfaces on 
> > > all
> > > of our d

[dpdk-dev] [PATCH v3 0/3] next-eventdev: evendev pipeline sample app

[David Hunt]

This patchset introduces a sample application that demonstrates
a pipeline model for packet processing. Running this sample app
with 17.05-rc2 or later is recommended.

Changes in patch v2:
  * None, incorrect patch upload

Changes in patch v3:
  * Re-work based on comments on mailing list. No major functional changes.
  * Checkpatch cleanup of a couple of typos

The sample app itself allows configuration of various pipelines using
command line arguments. Parameters like number of stages, number of
worker cores, which cores are assigned to specific tasks, and work-
cycles per-stage in the pipeline can be configured.

Documentation for eventdev is added for the programmers guide and
sample app user guide, providing sample commands to run the app with,
and expected output.

The sample app is presented here as an RFC to the next-eventdev tree
to work towards having eventdev PMD generic sample applications.

[1/3] examples/eventdev_pipeline: added sample app
[2/3] doc: add eventdev pipeline to sample app ug
[3/3] doc: add eventdev library to programmers guide

[dpdk-dev] [PATCH v3 1/3] examples/eventdev_pipeline: added sample app

[David Hunt]

From: Harry van Haaren 

This commit adds a sample app for the eventdev library.
The app has been tested with DPDK 17.05-rc2, hence this
release (or later) is recommended.

The sample app showcases a pipeline processing use-case,
with event scheduling and processing defined per stage.
The application receives traffic as normal, with each
packet traversing the pipeline. Once the packet has
been processed by each of the pipeline stages, it is
transmitted again.

The app provides a framework to utilize cores for a single
role or multiple roles. Examples of roles are the RX core,
TX core, Scheduling core (in the case of the event/sw PMD),
and worker cores.

Various flags are available to configure numbers of stages,
cycles of work at each stage, type of scheduling, number of
worker cores, queue depths etc. For a full explaination,
please refer to the documentation.

Signed-off-by: Gage Eads 
Signed-off-by: Bruce Richardson 
Signed-off-by: Harry van Haaren 
Signed-off-by: David Hunt 
---
 examples/Makefile   |   2 +
 examples/eventdev_pipeline/Makefile |  49 ++
 examples/eventdev_pipeline/main.c   | 999 
 3 files changed, 1050 insertions(+)
 create mode 100644 examples/eventdev_pipeline/Makefile
 create mode 100644 examples/eventdev_pipeline/main.c

diff --git a/examples/Makefile b/examples/Makefile
index 6298626..a6dcc2b 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -100,4 +100,6 @@ $(info vm_power_manager requires libvirt >= 0.9.3)
 endif
 endif
 
+DIRS-y += eventdev_pipeline
+
 include $(RTE_SDK)/mk/rte.extsubdir.mk
diff --git a/examples/eventdev_pipeline/Makefile 
b/examples/eventdev_pipeline/Makefile
new file mode 100644
index 000..6e5350a
--- /dev/null
+++ b/examples/eventdev_pipeline/Makefile
@@ -0,0 +1,49 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 Intel Corporation. All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+ifeq ($(RTE_SDK),)
+$(error "Please define RTE_SDK environment variable")
+endif
+
+# Default target, can be overridden by command line or environment
+RTE_TARGET ?= x86_64-native-linuxapp-gcc
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# binary name
+APP = eventdev_pipeline
+
+# all source are stored in SRCS-y
+SRCS-y := main.c
+
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+
+include $(RTE_SDK)/mk/rte.extapp.mk
diff --git a/examples/eventdev_pipeline/main.c 
b/examples/eventdev_pipeline/main.c
new file mode 100644
index 000..f1386a4
--- /dev/null
+++ b/examples/eventdev_pipeline/main.c
@@ -0,0 +1,999 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2016-2017 Intel Corporation. All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HO

[dpdk-dev] [PATCH v3 3/3] doc: add eventdev library to programmers guide

[David Hunt]

From: Harry van Haaren 

This commit adds an entry in the programmers guide
explaining the eventdev library.

The rte_event struct, queues and ports are explained.
An API walktrough of a simple two stage atomic pipeline
provides the reader with a step by step overview of the
expected usage of the Eventdev API.

Signed-off-by: Harry van Haaren 
---
 doc/guides/prog_guide/eventdev.rst   | 365 ++
 doc/guides/prog_guide/img/eventdev_usage.svg | 994 +++
 doc/guides/prog_guide/index.rst  |   1 +
 3 files changed, 1360 insertions(+)
 create mode 100644 doc/guides/prog_guide/eventdev.rst
 create mode 100644 doc/guides/prog_guide/img/eventdev_usage.svg

diff --git a/doc/guides/prog_guide/eventdev.rst 
b/doc/guides/prog_guide/eventdev.rst
new file mode 100644
index 000..4f6088e
--- /dev/null
+++ b/doc/guides/prog_guide/eventdev.rst
@@ -0,0 +1,365 @@
+..  BSD LICENSE
+Copyright(c) 2017 Intel Corporation. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Event Device Library
+
+
+The DPDK Event device library is an abstraction that provides the application
+with features to schedule events. This is achieved using the PMD architecture
+similar to the ethdev or cryptodev APIs, which may already be familiar to the
+reader. The eventdev framework is provided as a DPDK library, allowing
+applications to use it if they wish, but not require its usage.
+
+The goal of this library is to enable applications to build processing
+pipelines where the load balancing and scheduling is handled by the eventdev.
+Step-by-step instructions of the eventdev design is available in the `API
+Walktrough`_ section later in this document.
+
+Event struct
+
+
+The eventdev API represents each event with a generic struct, which contains a
+payload and metadata required for scheduling by an eventdev.  The
+``rte_event`` struct is a 16 byte C structure, defined in
+``libs/librte_eventdev/rte_eventdev.h``.
+
+Event Metadata
+~~
+
+The rte_event structure contains the following metadata fields, which the
+application fills in to have the event scheduled as required:
+
+* ``flow_id`` - The targeted flow identifier for the enq/deq operation.
+* ``event_type`` - The source of this event, eg RTE_EVENT_TYPE_ETHDEV or CPU.
+* ``sub_event_type`` - Distinguishes events inside the application, that have
+  the same event_type (see above)
+* ``op`` - This field takes one of the RTE_EVENT_OP_* values, and tells the
+  eventdev about the status of the event - valid values are NEW, FORWARD or
+  RELEASE.
+* ``sched_type`` - Represents the type of scheduling that should be performed
+  on this event, valid values are the RTE_SCHED_TYPE_ORDERED, ATOMIC and
+  PARALLEL.
+* ``queue_id`` - The identifier for the event queue that the event is sent to.
+* ``priority`` - The priority of this event, see RTE_EVENT_DEV_PRIORITY.
+
+Event Payload
+~
+
+The rte_event struct contains a union for payload, allowing flexibility in what
+the actual event being scheduled is. The payload is a union of the following:
+
+* ``uint64_t u64``
+* ``void *event_ptr``
+* ``struct rte_mbuf *mbuf``
+
+These three items in a union occupy the same 64 bits at the end of the 
rte_event
+structure. The application can utilize the 64 bits directly by accessing the
+u64 variable, while the event_ptr and mbuf are provided as convenience
+variables.  For example the mbuf pointer in the union can used to

[dpdk-dev] [PATCH v3 2/3] doc: add eventdev pipeline to sample app ug

[David Hunt]

From: Harry van Haaren 

Add a new entry in the sample app user-guides,
which details the working of the eventdev_pipeline.

Signed-off-by: Harry van Haaren 
Signed-off-by: David Hunt 
---
 doc/guides/sample_app_ug/eventdev_pipeline.rst | 188 +
 doc/guides/sample_app_ug/index.rst |   1 +
 2 files changed, 189 insertions(+)
 create mode 100644 doc/guides/sample_app_ug/eventdev_pipeline.rst

diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst 
b/doc/guides/sample_app_ug/eventdev_pipeline.rst
new file mode 100644
index 000..bb09224
--- /dev/null
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -0,0 +1,188 @@
+
+..  BSD LICENSE
+Copyright(c) 2017 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Eventdev Pipeline Sample Application
+
+
+The eventdev pipeline sample application is a sample app that demonstrates
+the usage of the eventdev API. It shows how an application can configure
+a pipeline and assign a set of worker cores to perform the processing required.
+
+The application has a range of command line arguments allowing it to be
+configured for various numbers worker cores, stages,queue depths and cycles per
+stage of work. This is useful for performance testing as well as quickly 
testing
+a particular pipeline configuration.
+
+
+Compiling the Application
+-
+
+To compile the application:
+
+#.  Go to the sample application directory:
+
+.. code-block:: console
+
+export RTE_SDK=/path/to/rte_sdk cd 
${RTE_SDK}/examples/eventdev_pipeline
+
+#.  Set the target (a default target is used if not specified). For example:
+
+.. code-block:: console
+
+export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+See the *DPDK Getting Started Guide* for possible RTE_TARGET values.
+
+#.  Build the application:
+
+.. code-block:: console
+
+make
+
+Running the Application
+---
+
+The application has a lot of command line options. This allows specification of
+the eventdev PMD to use, and a number of attributes of the processing pipeline
+options.
+
+An example eventdev pipeline running with the software eventdev PMD using
+these settings is shown below:
+
+ * ``-r1``: core mask 0x1 for RX
+ * ``-t1``: core mask 0x1 for TX
+ * ``-e4``: core mask 0x4 for the software scheduler
+ * ``-w FF00``: core mask for worker cores, 8 cores from 8th to 16th
+ * ``-s4``: 4 atomic stages
+ * ``-n0``: process infinite packets (run forever)
+ * ``-c32``: worker dequeue depth of 32
+ * ``-W1000``: do 1000 cycles of work per packet in each stage
+ * ``-D``: dump statistics on exit
+
+.. code-block:: console
+
+./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -w FF00 -s4 -n0 
-c32 -W1000 -D
+
+The application has some sanity checking built-in, so if there is a function
+(eg; the RX core) which doesn't have a cpu core mask assigned, the application
+will print an error message:
+
+.. code-block:: console
+
+  Core part of pipeline was not assigned any cores. This will stall the
+  pipeline, please check core masks (use -h for details on setting core masks):
+  rx: 0
+  tx: 1
+
+Configuration of the eventdev is covered in detail in the programmers guide,
+see the Event Device Library section.
+
+
+Observing the Application
+-
+
+At runtime the eventdev pipeline application prints out a summar

Re: [dpdk-dev] [PATCH v5 09/12] vdev: use standard bus registration function

[Bruce Richardson]

On Mon, Jun 26, 2017 at 02:22:07AM +0200, Gaetan Rivet wrote:
> Signed-off-by: Gaetan Rivet 
> ---
>  lib/librte_eal/common/eal_common_vdev.c | 18 +-
>  1 file changed, 1 insertion(+), 17 deletions(-)
> 
Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH v8 2/2] config: enable vhost numa awareness by default

[Hemant Agrawal]

On 6/27/2017 6:15 PM, Jerin Jacob wrote:

-Original Message-

Date: Tue, 27 Jun 2017 17:47:44 +0530
From: Hemant Agrawal 
To: Jerin Jacob 
CC: Thomas Monjalon , Ilya Maximets
 , dev@dpdk.org, David Marchand
 , Sergio Gonzalez Monroy
 , Heetae Ahn ,
 Yuanhan Liu , Jianfeng Tan ,
 Neil Horman , Yulong Pei ,
 Bruce Richardson 
Subject: Re: [PATCH v8 2/2] config: enable vhost numa awareness by default
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0

On 6/27/2017 3:29 PM, Jerin Jacob wrote:

-Original Message-

Date: Tue, 27 Jun 2017 15:11:07 +0530
From: Hemant Agrawal 
To: Thomas Monjalon 
CC: Ilya Maximets , dev@dpdk.org, David Marchand
 , Sergio Gonzalez Monroy
 , Heetae Ahn ,
 Yuanhan Liu , Jianfeng Tan ,
 Neil Horman , Yulong Pei ,
 Bruce Richardson , Jerin Jacob
 
Subject: Re: [PATCH v8 2/2] config: enable vhost numa awareness by default
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0

On 6/27/2017 2:51 PM, Thomas Monjalon wrote:

27/06/2017 11:18, Hemant Agrawal:

On 6/27/2017 2:16 PM, Ilya Maximets wrote:

It is safe to enable LIBRTE_VHOST_NUMA by default for all
configurations where libnuma is already a default dependency.

Signed-off-by: Ilya Maximets 
---
 config/common_linuxapp| 1 +
 config/defconfig_arm-armv7a-linuxapp-gcc  | 1 +
 config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 +
 3 files changed, 3 insertions(+)

[...]

--- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -47,6 +47,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=256

 # Doesn't support NUMA
 CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=y
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n

 #
 # Compile Support Libraries for DPAA2



-1
It should also be disabled for generic ARM64. This patch is breaking
generic arm64 config tests on our platforms and creating a unnecessary
dependency.


What do you mean? Which ARM64 platform is it breaking?
We can specifically disable it on more platforms.


Unlike x86, ARM only represent a core architecture.
Different platforms can integrate these cores differently in their SoCs.
The stock ARM v8 cores do not provide support for NUMA in my knowledge.


A72 is just _an_ implementation of armv8. Not ARMv8 specification
itself. By specification it is NUMA capable and there are NUMA
implementation too.


Some vendors have modified ARM cores (e.g. Cavium) to support NUMA
architecture. However that is not a common phenomena.
NUMA config should not be default for generic ARM config. It should be
enabled only for architecture supporting it.


It just an build time dependency. Right? If you feed the libnuma package,
it will NON NUMA as well. Right? ARM64 libnuma package is already
available for major distributions.


yes, libnuma will work for non-NUMA.


My point is, I don't want to make arm64 generic config an exceptional case,
If DPDK common config creates libnuma dependency then there is no reason
for arm64 not have it. It is same for x86 and powerpc, non numa systems
too. Right?


x86 and powerpc configs are single vendor based.
Common should be common and generic.


Yes. What I understand by common is that it should work on functionality on 
_all_ the
armv8 targets. If you don't include NUMA then it will have functionality issue
with NUMA targets.

The ARM64 Linux kernel took the similar approach. The default config has all
options and NUMA is _enabled_ even it is not supported on A72.

http://elixir.free-electrons.com/linux/latest/source/arch/arm64/configs/defconfig#L77



Ok!  Not able to think of any other issue for now.





Why to create a unnecessary dependency, when we know that the support is not
uniform?  It adds difficulties e.g. For the ARM cross compilation, will also
have to cross compile libnuma-dev. Makefile will need a path for specifying
the lib and include paths for libnuma and numa.h.


Yes. I agree. Cross compilation needs additional step. On the other
hand, If we don't include NUMA in common config, We need to add new targets on
all new SoCs(like thunderx2). IMO, In order to reduce the config, I think,
this is the better way.(and it is not hard to disable NUMA for cross
compilation mode if not interested)








So, *arm64-armv8a-linuxapp-gcc* config is being used by several vendors
include NXP. e.g. We use this config on several of our low end systems
(non-dpaa). Also, we use it when running in VM with virtio interfaces on all
of our different platforms (non-dpaa, dpaa1, dpaa2 etc).


On the same note, arm64-armv8a-linuxapp-gcc used by other vendors for Server 
machines
with NUMA and if want to keep creating new targets there is no end to it.

How hard is to install libnuma on VM? There is already package for it.

Re: [dpdk-dev] [PATCH 1/3] examples/eventdev_pipeline: added sample app

[Hunt, David]

Hi Jerin:


On 27/6/2017 10:35 AM, Jerin Jacob wrote:

-Original Message-

Date: Mon, 26 Jun 2017 15:46:47 +0100
From: "Hunt, David" 
To: Jerin Jacob , Harry van Haaren
  
CC: dev@dpdk.org, Gage Eads , Bruce Richardson
  
Subject: Re: [dpdk-dev] [PATCH 1/3] examples/eventdev_pipeline: added
  sample app
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
  Thunderbird/45.8.0

Hi Jerin,

Hi David,

Looks like you have sent the old version. The below mentioned comments
are not addressed in v2.


Oops. Glitch in the Matrix. I've just pushed a V3 with the changes.


I'm assisting Harry on the sample app, and have just pushed up a V2 patch
based on your feedback. I've addressed most of your suggestions, comments
below. There may still a couple of outstanding questions that need further
discussion.

A few general comments:
1) Nikhil/Gage's proposal on ethdev rx to eventdev adapter will change the major
portion(eventdev setup and producer()) of this application
2) Producing one lcore worth of packets, really cant show as example
eventdev application as it will be pretty bad in low-end machine.
At least application infrastructure should not limit.

Considering above points, Should we wait for rx adapter to complete
first? I would like to show this as real world application to use eventdev.

Thoughts?

On the same note:
Can we finalize on rx adapter proposal? I can work on v1 of patch and
common code if Nikhil or Gage don't have bandwidth. Let me know?

last followup:
http://dpdk.org/ml/archives/dev/2017-June/068776.html


I had a quick chat with Harry, and wonder if we'd be as well to merge 
the app as it is now, and as the new frameworks become available, the 
app can be updated to make use of them? I feel it would be better to 
have something out there for people to play with than waiting for 17.11.


Also, if you have bandwidth to patch the app for your desired use cases, 
that would be a good contribution. I'd only be guessing for some of it :)




Regards,
Dave

On 10/5/2017 3:12 PM, Jerin Jacob wrote:

-Original Message-

Date: Fri, 21 Apr 2017 10:51:37 +0100
From: Harry van Haaren 
To: dev@dpdk.org
CC: jerin.ja...@caviumnetworks.com, Harry van Haaren
, Gage Eads , Bruce
  Richardson 
Subject: [PATCH 1/3] examples/eventdev_pipeline: added sample app
X-Mailer: git-send-email 2.7.4

This commit adds a sample app for the eventdev library.
The app has been tested with DPDK 17.05-rc2, hence this
release (or later) is recommended.

The sample app showcases a pipeline processing use-case,
with event scheduling and processing defined per stage.
The application recieves traffic as normal, with each
packet traversing the pipeline. Once the packet has
been processed by each of the pipeline stages, it is
transmitted again.

The app provides a framework to utilize cores for a single
role or multiple roles. Examples of roles are the RX core,
TX core, Scheduling core (in the case of the event/sw PMD),
and worker cores.

Various flags are available to configure numbers of stages,
cycles of work at each stage, type of scheduling, number of
worker cores, queue depths etc. For a full explaination,
please refer to the documentation.

Signed-off-by: Gage Eads 
Signed-off-by: Bruce Richardson 
Signed-off-by: Harry van Haaren 

Thanks for the example application to share the SW view.
I could make it run on HW after some tweaking(not optimized though)

[...]

+#define MAX_NUM_STAGES 8
+#define BATCH_SIZE 16
+#define MAX_NUM_CORE 64

How about RTE_MAX_LCORE?

Core usage in the sample app is held in a uint64_t. Adding arrays would be
possible, but I feel that the extra effort would not give that much benefit.
I've left as is for the moment, unless you see any strong requirement to go
beyond 64 cores?

I think, it is OK. Again with service core infrastructure this will change.


+
+static unsigned int active_cores;
+static unsigned int num_workers;
+static unsigned long num_packets = (1L << 25); /* do ~32M packets */
+static unsigned int num_fids = 512;
+static unsigned int num_priorities = 1;

looks like its not used.

Yes, Removed.


+static unsigned int num_stages = 1;
+static unsigned int worker_cq_depth = 16;
+static int queue_type = RTE_EVENT_QUEUE_CFG_ATOMIC_ONLY;
+static int16_t next_qid[MAX_NUM_STAGES+1] = {-1};
+static int16_t qid[MAX_NUM_STAGES] = {-1};

Moving all fastpath related variables under a structure with cache
aligned will help.

I tried a few different combinations of this, and saw no gains, some losses.
So will leave as is for the moment, if that's OK.

I think, the one are using in fastpath better to allocate from huge page
using rte_malloc()


+static int worker_cycles;
+static int enable_queue_priorities;
+
+struct prod_data {
+uint8_t dev_id;
+uint8_t port_id;
+int32_t qid;
+unsigned num_nic_ports;
+};

Yes, saw a percent or two gain when this plus following two data structs
cache aligned.

looks like it not fixed in v2. Looks like you have sent the old
ve

[dpdk-dev] [PATCH] ether: add support for vtune task tracing

[ilia . kurakin]

From: Ilia Kurakin 

The patch adds tracing of loop iterations that yielded no packets in a DPDK
application. It is using ITT task API:
https://software.intel.com/en-us/node/544206

We suppose the flow of using this tracing would assume the user has ITT lib
and header on machine and re-build DPDK with additional make parameters:

make EXTRA_CFLAGS=-I
 EXTRA_LDLIBS="-L -littnotify"

Signed-off-by: Ilia Kurakin 
---
 config/common_base |   1 +
 lib/librte_ether/Makefile  |   1 +
 lib/librte_ether/rte_eth_itt.h | 102 +
 lib/librte_ether/rte_ethdev.c  |   5 ++
 lib/librte_ether/rte_ethdev.h  |  23 ++
 5 files changed, 132 insertions(+)
 create mode 100644 lib/librte_ether/rte_eth_itt.h

diff --git a/config/common_base b/config/common_base
index f6aafd1..60d8b63 100644
--- a/config/common_base
+++ b/config/common_base
@@ -135,6 +135,7 @@ CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
 CONFIG_RTE_LIBRTE_IEEE1588=n
 CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
 CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
+CONFIG_RTE_ETHDEV_TRACE_WASTED_RX_ITERATIONS=n
 
 #
 # Turn off Tx preparation stage
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index 93fdde1..c10153a 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -56,5 +56,6 @@ SYMLINK-y-include += rte_eth_ctrl.h
 SYMLINK-y-include += rte_dev_info.h
 SYMLINK-y-include += rte_flow.h
 SYMLINK-y-include += rte_flow_driver.h
+SYMLINK-${CONFIG_RTE_ETHDEV_TRACE_WASTED_RX_ITERATIONS}-include += 
rte_eth_itt.h
 
 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ether/rte_eth_itt.h b/lib/librte_ether/rte_eth_itt.h
new file mode 100644
index 000..e661782
--- /dev/null
+++ b/lib/librte_ether/rte_eth_itt.h
@@ -0,0 +1,102 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_ETH_ITT_H_
+#define _RTE_ETH_ITT_H_
+
+#include 
+#include 
+
+#define ITT_MAX_NAME_LEN (100)
+
+/**
+ * Auxiliary ITT structure belonging to port and using to:
+ *   -  track queue state to determine whether it is wasting loop iterations
+ *   -  begin or end ITT task using task domain and name
+ */
+struct rte_eth_itt_aux_data {
+   /**
+* ITT domains for each queue.
+*/
+   __itt_domain *wasted_iter_domains[RTE_MAX_QUEUES_PER_PORT];
+   /**
+* ITT task names for each queue.
+*/
+   __itt_string_handle *wasted_iter_handles[RTE_MAX_QUEUES_PER_PORT];
+   /**
+* Flags indicating the queues state. Possible values:
+* 1 - queue is wasting iterations, 0 - otherwise.
+*/
+   uint8_t queue_is_wasting_iters[RTE_MAX_QUEUES_PER_PORT];
+};
+
+/**
+ * The pool of *rte_eth_itt_aux_data* structures.
+ */
+struct rte_eth_itt_aux_data itt_aux_data[RTE_MAX_ETHPORTS];
+
+/**
+ * Initialization of rte_eth_itt_aux_data for a given port.
+ * This function must be invoked when ethernet device is being configured.
+ * Result will be stored in the global array *itt_aux_data*.
+ *
+ * @param port_id
+ *  The port identifier of the Ethernet device.
+ * @param port_name
+ *  The name of the Ethernet device.
+ * @param queue_num
+ *  The number of queues on specified port.
+ */
+static inline void
+rte_eth_init_itt(uint8_t port_id, char *port_name, uint8_t queue_num) {
+   uint16_t q_id;
+   

Re: [dpdk-dev] [PATCH v6 0/2] ethdev: abstraction layer for QoS traffic management

[Dumitrescu, Cristian]

> This patch set introduces an ethdev-based abstraction layer for Quality of
> Service (QoS) Traffic Management, which includes: hierarchical scheduling,
> traffic shaping, congestion management, packet marking. The goal is to
> provide a simple generic API that is agnostic of the underlying HW, SW or
> mixed HW-SW implementation.
> 
> Patch 1 uses the approach introduced by rte_flow in DPDK to extend the
> ethdev functionality in a modular way for traffic management.
> 
> Patch 2 introduces the generic ethdev API for traffic management.
> 
> Cristian Dumitrescu (2):
>   ethdev: add traffic management ops get API
>   ethdev: add traffic management API

Series applied to dpdk-next-tm/master.

Many thanks to all the people involved in creating the DPDK Traffic Management 
API!

Re: [dpdk-dev] bug: virtio PMD sends malformed packets for 32-bit processes on 64-bit kernel

[Frederico Cadete]

On Mon, 2017-06-26 at 18:15 +0800, Tan, Jianfeng wrote:
> On 6/26/2017 4:14 PM, Frederico Cadete wrote:
> > 
> > On Fri, 2017-06-23 at 23:36 +0800, Tan, Jianfeng wrote:
> > > 
> > > Hi Cadete,
> > > 
> > > 
> > > On 6/22/2017 10:58 PM, Frederico Cadete wrote:
> > > > 
> > > > Hello,
> > > > 
> > > > I believe commit 260aae9a [1] has introduced a regression for
> > > > the
> > > > case
> > > > of 32-bit process running on a 64-bit kernel.
> > > > 
> > > > The commit is effectively casting mbuf->buf_physaddr to
> > > > uintptr_t
> > > > before dereferencing it. It truncates the physical address to
> > > > the
> > > > width
> > > > of the process's uint, and in the the aforementioned
> > > > combination
> > > > this
> > > > loses important bits.
> > > > 
> > > > I can confirm this under GDB. When virtqueue_enqueue_xmit is
> > > > filling in
> > > > start_dp, I get this result:
> > > > 
> > > > (gdb) p /x cookie->buf_physaddr
> > > > $5 = 0x12f94a000
> > > > (gdb) p /x start_dp[idx].addr
> > > > $6 = 0x2f94a080
> > > Now you are testing a virtio-pci device and app is compiled into
> > > a
> > > 32-bit executable on 64-bit VM system?
> > Exactly. Furthermore, this bug is only visible if you give the
> > virtual
> > machine enough memory for the mbuf's physiscal address to be above
> > the
> > 4GB mark.
> That's an important information.
> 
> > 
> > 
> > > 
> > > > 
> > > > 
> > > > On my system, I capture the packet that goes out to the host
> > > > and I
> > > > see
> > > > it has the correct size but the content is all-zeroes.
> > > > 
> > > > I would like to propose a patch that would work for all
> > > > supported
> > > > combinations of user/kernel bitwidth  *and* virtio-pci/virtio-
> > > > user.
> > > > But
> > > > I don't really see how that could work, given virtio-user tries
> > > > to
> > > > store a physical address in rte_mbuf's "void *buf_addr", and
> > > > this
> > > > is
> > > > not always big enough for a physical address.
> > > virtio-user does not store a physical address in rte_mbuf's "void
> > > *buf_addr", instead, it uses this field in rte_mbuf to fill
> > > desc's
> > > addr
> > > which is always 64bit long.
> > Oh, that's right. Sorry about that.
> > 
> > In that case I guess that the issue is that the conversion is
> > assuming
> > that on 32-bit apps only 4 bytes are necessary, even in the case of
> > virtio-pci and 64-bit physaddr.
> > 
> > Would you say that this is how vring_desc's addr should be filled?
> > 
> >  |   32-bit app  | 64-bit app |
> > +---+ ---+
> > virtio-pci  | buf_physaddr, 8 bytes | buf_physaddr, 8 bytes  |
> > virtio-user | buf_addr, 4 bytes | buf_addr, 8 bytes  |
> > 
> > I believe that the issue is that after commit 260aae9a, for virtio-
> > pci
> > and 32-bit app it is taking 4 bytes instead of 8.
> Aha, yes, that's the issue! Great analysis. After Bruce's commit 
> 586ec205bcbbb ("mbuf: fix 64-bit address alignment in 32-bit
> builds"), 
> we can fix this issue by fetching 8 bytes at all cases. But 
> unfortunately, that commit is not back-ported to v17.02.1.

I don't see how changing the alignment of buf_physaddr allows fetching
8 bytes in all cases, even in the case of 32-bit virtio-user where what
we need are 4 bytes from buf_addr. Am I missing something?

Besides, Bruce's patch changes the memory layout of rte_mbuf. A priori
that's not the kind I would like to find in an update of a stable
branch :)

> 
> I wonder if we can back-port Bruce's patch with a new patch to fix
> this 
> problem?
> 
> Any opinions from others?
> 
> Thanks,
> Jianfeng
> 
> > 
> > 
> > > 
> > > > 
> > > > Any suggestions on if and how this could be fixed?
> > > > 
> > > > Meanwhile, the bug affects dpdk 17.05, 17.02.1 and master.
> > > > Users
> > > > not
> > > > requiring virtio-user support can avoid it by setting
> > > > CONFIG_VIRTIO_USER=n during compilation.
> > > > 
> > > > Best regards,
> > > > Frederico Cadete

[dpdk-dev] [PATCH v3 00/17] net/i40e: base code update

[Jingjing Wu]

v3 chanes:
 - extra patch to update README
 - remove unnecessary code
 - fix checkpatch warnings

v2 changes:
 - fix compile issue
 - update from package from 2017.05.24 to 2017.06.23

i40e base code upate. The main changes are:
 - use virtchnl.h instead of i40e_virtchnl.h
 - add support for Adaptive Virtual Function
 - add new AQ commands for read/write PHY registers
 - add new phy types for 25G
 - extend processing of DDP

Jingjing Wu (17):
  net/i40e/base: use new virtchnl header file
  net/i40e/base: sync nvmupdate command and adminq subtask
  net/i40e/base: add AQ command for read/write PHY registers
  net/i40e/base: add support for Adaptive Virtual Function
  net/i40e/base: store the requested FEC information
  net/i40e/base: add new phy types for 25G AOC and ACC
  net/i40e/base: report supported link modes
  net/i40e/base: track id can be 0
  net/i40e/base: update FW AQ API version to 1.7
  net/i40e/base: add support for switch parameters
  net/i40e/base: use admin queue for setting LEDs behavior
  net/i40e/base: avoid potential null pointer dereference
  net/i40e/base: avoid reset timeout issue
  net/i40e/base: add EEPROM checksum verification
  net/i40e/base: extend processing of DDP
  net/i40e: use set switch aq instead of register setting
  net/i40e/base: update base code info

 drivers/net/i40e/base/README|   2 +-
 drivers/net/i40e/base/i40e_adminq.c |  12 +
 drivers/net/i40e/base/i40e_adminq_cmd.h |  71 ++-
 drivers/net/i40e/base/i40e_common.c | 549 +++
 drivers/net/i40e/base/i40e_devids.h |   1 +
 drivers/net/i40e/base/i40e_nvm.c|  20 +-
 drivers/net/i40e/base/i40e_prototype.h  |  33 +-
 drivers/net/i40e/base/i40e_register.h   |   2 +-
 drivers/net/i40e/base/i40e_type.h   |  49 +-
 drivers/net/i40e/base/i40e_virtchnl.h   | 445 --
 drivers/net/i40e/base/virtchnl.h| 772 
 drivers/net/i40e/i40e_ethdev.c  | 102 +++--
 drivers/net/i40e/i40e_ethdev.h  |   8 +-
 drivers/net/i40e/i40e_ethdev_vf.c   | 206 -
 drivers/net/i40e/i40e_pf.c  | 206 -
 drivers/net/i40e/i40e_pf.h  |  32 +-
 drivers/net/i40e/rte_pmd_i40e.h |   2 +-
 17 files changed, 1690 insertions(+), 822 deletions(-)
 delete mode 100644 drivers/net/i40e/base/i40e_virtchnl.h
 create mode 100644 drivers/net/i40e/base/virtchnl.h

-- 
2.4.11

[dpdk-dev] [PATCH v3 01/17] net/i40e/base: use new virtchnl header file

[Jingjing Wu]

Modify the necessary files to be compatible with the new virtchnl.h file
instead of relying on i40e_virtchnl.h variant. This mostly changes
references to VIRTCHNL_ variables by removing prefix of I40E_.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_common.c|  24 +-
 drivers/net/i40e/base/i40e_prototype.h |   6 +-
 drivers/net/i40e/base/i40e_type.h  |  12 +-
 drivers/net/i40e/base/i40e_virtchnl.h  | 445 ---
 drivers/net/i40e/base/virtchnl.h   | 772 +
 drivers/net/i40e/i40e_ethdev.h |   8 +-
 drivers/net/i40e/i40e_ethdev_vf.c  | 206 -
 drivers/net/i40e/i40e_pf.c | 206 -
 drivers/net/i40e/i40e_pf.h |  32 +-
 drivers/net/i40e/rte_pmd_i40e.h|   2 +-
 10 files changed, 1020 insertions(+), 693 deletions(-)
 delete mode 100644 drivers/net/i40e/base/i40e_virtchnl.h
 create mode 100644 drivers/net/i40e/base/virtchnl.h

diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 03e94bc..6c09c27 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -34,7 +34,7 @@ POSSIBILITY OF SUCH DAMAGE.
 #include "i40e_type.h"
 #include "i40e_adminq.h"
 #include "i40e_prototype.h"
-#include "i40e_virtchnl.h"
+#include "virtchnl.h"
 
 
 /**
@@ -5523,7 +5523,7 @@ enum i40e_status_code 
i40e_aq_add_rem_control_packet_filter(struct i40e_hw *hw,
}
 
if (mac_addr)
-   i40e_memcpy(cmd->mac, mac_addr, I40E_ETH_LENGTH_OF_ADDRESS,
+   i40e_memcpy(cmd->mac, mac_addr, ETH_ALEN,
I40E_NONDMA_TO_NONDMA);
 
cmd->etype = CPU_TO_LE16(ethtype);
@@ -6879,7 +6879,7 @@ void i40e_write_rx_ctl(struct i40e_hw *hw, u32 reg_addr, 
u32 reg_val)
  * completion before returning.
  **/
 enum i40e_status_code i40e_aq_send_msg_to_pf(struct i40e_hw *hw,
-   enum i40e_virtchnl_ops v_opcode,
+   enum virtchnl_ops v_opcode,
enum i40e_status_code v_retval,
u8 *msg, u16 msglen,
struct i40e_asq_cmd_details *cmd_details)
@@ -6918,9 +6918,9 @@ enum i40e_status_code i40e_aq_send_msg_to_pf(struct 
i40e_hw *hw,
  * with appropriate information.
  **/
 void i40e_vf_parse_hw_config(struct i40e_hw *hw,
-struct i40e_virtchnl_vf_resource *msg)
+struct virtchnl_vf_resource *msg)
 {
-   struct i40e_virtchnl_vsi_resource *vsi_res;
+   struct virtchnl_vsi_resource *vsi_res;
int i;
 
vsi_res = &msg->vsi_res[0];
@@ -6930,19 +6930,17 @@ void i40e_vf_parse_hw_config(struct i40e_hw *hw,
hw->dev_caps.num_tx_qp = msg->num_queue_pairs;
hw->dev_caps.num_msix_vectors_vf = msg->max_vectors;
hw->dev_caps.dcb = msg->vf_offload_flags &
-  I40E_VIRTCHNL_VF_OFFLOAD_L2;
-   hw->dev_caps.fcoe = (msg->vf_offload_flags &
-I40E_VIRTCHNL_VF_OFFLOAD_FCOE) ? 1 : 0;
+  VIRTCHNL_VF_OFFLOAD_L2;
hw->dev_caps.iwarp = (msg->vf_offload_flags &
- I40E_VIRTCHNL_VF_OFFLOAD_IWARP) ? 1 : 0;
+ VIRTCHNL_VF_OFFLOAD_IWARP) ? 1 : 0;
for (i = 0; i < msg->num_vsis; i++) {
-   if (vsi_res->vsi_type == I40E_VSI_SRIOV) {
+   if (vsi_res->vsi_type == VIRTCHNL_VSI_SRIOV) {
i40e_memcpy(hw->mac.perm_addr,
vsi_res->default_mac_addr,
-   I40E_ETH_LENGTH_OF_ADDRESS,
+   ETH_ALEN,
I40E_NONDMA_TO_NONDMA);
i40e_memcpy(hw->mac.addr, vsi_res->default_mac_addr,
-   I40E_ETH_LENGTH_OF_ADDRESS,
+   ETH_ALEN,
I40E_NONDMA_TO_NONDMA);
}
vsi_res++;
@@ -6959,7 +6957,7 @@ void i40e_vf_parse_hw_config(struct i40e_hw *hw,
  **/
 enum i40e_status_code i40e_vf_reset(struct i40e_hw *hw)
 {
-   return i40e_aq_send_msg_to_pf(hw, I40E_VIRTCHNL_OP_RESET_VF,
+   return i40e_aq_send_msg_to_pf(hw, VIRTCHNL_OP_RESET_VF,
  I40E_SUCCESS, NULL, 0, NULL);
 }
 #endif /* VF_DRIVER */
diff --git a/drivers/net/i40e/base/i40e_prototype.h 
b/drivers/net/i40e/base/i40e_prototype.h
index 4bd589e..6ec4304 100644
--- a/drivers/net/i40e/base/i40e_prototype.h
+++ b/drivers/net/i40e/base/i40e_prototype.h
@@ -36,7 +36,7 @@ POSSIBILITY OF SUCH DAMAGE.
 
 #include "i40e_type.h"
 #include "i40e_alloc.h"
-#include "i40e_virtchnl.h"
+#include "virtchnl.h"
 
 /* Prototypes for shared code functions that are not in
  * the standard function pointer structures.  These are
@@ -504,10 +504,10 @@ void i40e_destroy_spinlock(struct i40

[dpdk-dev] [PATCH v3 02/17] net/i40e/base: sync nvmupdate command and adminq subtask

[Jingjing Wu]

During NVMupdate, state machine gets into unrecoverable state because
i40e_clean_adminq_subtask can get scheduled after the admin queue
command but before other state variables are updated.

This patch adds locking around admin queue command and update of
state variables so that adminq_subtask will have accurate information
whenever it gets scheduled.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_nvm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_nvm.c b/drivers/net/i40e/base/i40e_nvm.c
index e896502..90521fa 100644
--- a/drivers/net/i40e/base/i40e_nvm.c
+++ b/drivers/net/i40e/base/i40e_nvm.c
@@ -899,6 +899,11 @@ enum i40e_status_code i40e_nvmupd_command(struct i40e_hw 
*hw,
hw->nvmupd_state = I40E_NVMUPD_STATE_INIT;
}
 
+   /* Acquire lock to prevent race condition where adminq_task
+* can execute after i40e_nvmupd_nvm_read/write but before state
+* variables (nvm_wait_opcode, nvm_release_on_done) are updated
+*/
+   i40e_acquire_spinlock(&hw->aq.arq_spinlock);
switch (hw->nvmupd_state) {
case I40E_NVMUPD_STATE_INIT:
status = i40e_nvmupd_state_init(hw, cmd, bytes, perrno);
@@ -934,6 +939,7 @@ enum i40e_status_code i40e_nvmupd_command(struct i40e_hw 
*hw,
*perrno = -ESRCH;
break;
}
+   i40e_release_spinlock(&hw->aq.arq_spinlock);
return status;
 }
 
-- 
2.4.11

[dpdk-dev] [PATCH v3 03/17] net/i40e/base: add AQ command for read/write PHY registers

[Jingjing Wu]

This patch adds new additional command for accessing to PHY registers.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_adminq_cmd.h | 18 +
 drivers/net/i40e/base/i40e_common.c | 70 +
 drivers/net/i40e/base/i40e_prototype.h  |  9 +
 3 files changed, 97 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h 
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index 09f5bf5..83b28f8 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -245,6 +245,8 @@ enum i40e_admin_queue_opc {
i40e_aqc_opc_set_phy_debug  = 0x0622,
i40e_aqc_opc_upload_ext_phy_fm  = 0x0625,
i40e_aqc_opc_run_phy_activity   = 0x0626,
+   i40e_aqc_opc_set_phy_register   = 0x0628,
+   i40e_aqc_opc_get_phy_register   = 0x0629,
 
/* NVM commands */
i40e_aqc_opc_nvm_read   = 0x0701,
@@ -2128,6 +2130,22 @@ struct i40e_aqc_run_phy_activity {
 
 I40E_CHECK_CMD_LENGTH(i40e_aqc_run_phy_activity);
 
+/* Set PHY Register command (0x0628) */
+/* Get PHY Register command (0x0629) */
+struct i40e_aqc_phy_register_access {
+   u8  phy_interface;
+#define I40E_AQ_PHY_REG_ACCESS_INTERNAL0
+#define I40E_AQ_PHY_REG_ACCESS_EXTERNAL1
+#define I40E_AQ_PHY_REG_ACCESS_EXTERNAL_MODULE 2
+   u8  dev_addres;
+   u8  reserved1[2];
+   u32 reg_address;
+   u32 reg_value;
+   u8  reserved2[4];
+};
+
+I40E_CHECK_CMD_LENGTH(i40e_aqc_phy_register_access);
+
 /* NVM Read command (indirect 0x0701)
  * NVM Erase commands (direct 0x0702)
  * NVM Update commands (indirect 0x0703)
diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 6c09c27..280d9da 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -6863,6 +6863,76 @@ void i40e_write_rx_ctl(struct i40e_hw *hw, u32 reg_addr, 
u32 reg_val)
if (status || use_register)
wr32(hw, reg_addr, reg_val);
 }
+
+/**
+ * i40e_aq_set_phy_register
+ * @hw: pointer to the hw struct
+ * @phy_select: select which phy should be accessed
+ * @dev_addr: PHY device address
+ * @reg_addr: PHY register address
+ * @reg_val: new register value
+ * @cmd_details: pointer to command details structure or NULL
+ *
+ * Write the external PHY register.
+ **/
+enum i40e_status_code i40e_aq_set_phy_register(struct i40e_hw *hw,
+   u8 phy_select, u8 dev_addr,
+   u32 reg_addr, u32 reg_val,
+   struct i40e_asq_cmd_details *cmd_details)
+{
+   struct i40e_aq_desc desc;
+   struct i40e_aqc_phy_register_access *cmd =
+   (struct i40e_aqc_phy_register_access *)&desc.params.raw;
+   enum i40e_status_code status;
+
+   i40e_fill_default_direct_cmd_desc(&desc,
+ i40e_aqc_opc_set_phy_register);
+
+   cmd->phy_interface = phy_select;
+   cmd->dev_addres = dev_addr;
+   cmd->reg_address = reg_addr;
+   cmd->reg_value = reg_val;
+
+   status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
+
+   return status;
+}
+
+/**
+ * i40e_aq_get_phy_register
+ * @hw: pointer to the hw struct
+ * @phy_select: select which phy should be accessed
+ * @dev_addr: PHY device address
+ * @reg_addr: PHY register address
+ * @reg_val: read register value
+ * @cmd_details: pointer to command details structure or NULL
+ *
+ * Read the external PHY register.
+ **/
+enum i40e_status_code i40e_aq_get_phy_register(struct i40e_hw *hw,
+   u8 phy_select, u8 dev_addr,
+   u32 reg_addr, u32 *reg_val,
+   struct i40e_asq_cmd_details *cmd_details)
+{
+   struct i40e_aq_desc desc;
+   struct i40e_aqc_phy_register_access *cmd =
+   (struct i40e_aqc_phy_register_access *)&desc.params.raw;
+   enum i40e_status_code status;
+
+   i40e_fill_default_direct_cmd_desc(&desc,
+ i40e_aqc_opc_get_phy_register);
+
+   cmd->phy_interface = phy_select;
+   cmd->dev_addres = dev_addr;
+   cmd->reg_address = reg_addr;
+
+   status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
+   if (!status)
+   *reg_val = cmd->reg_value;
+
+   return status;
+}
+
 #ifdef VF_DRIVER
 
 /**
diff --git a/drivers/net/i40e/base/i40e_prototype.h 
b/drivers/net/i40e/base/i40e_prototype.h
index 6ec4304..54b6750 100644
--- a/drivers/net/i40e/base/i40e_prototype.h
+++ b/drivers/net/i40e/base/i40e_prototype.h
@@ -533,6 +533,15 @@ enum i40e_status_code i40e_aq_rx_ctl_write_register(struct 
i40e_hw *hw,
u32 reg_addr, u32 reg_val,
struct i40e_asq_cmd_details *cmd_details);
 void i40e_write_rx_ctl(struct i40e_hw *hw, u32 reg_addr, u

[dpdk-dev] [PATCH v3 04/17] net/i40e/base: add support for Adaptive Virtual Function

[Jingjing Wu]

Add device id define and mac_type assignment needed for Adaptive
Virtual Function.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_common.c | 1 +
 drivers/net/i40e/base/i40e_devids.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 280d9da..5f6dd7b 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -93,6 +93,7 @@ STATIC enum i40e_status_code i40e_set_mac_type(struct i40e_hw 
*hw)
 #if defined(INTEGRATED_VF) || defined(VF_DRIVER)
case I40E_DEV_ID_VF:
case I40E_DEV_ID_VF_HV:
+   case I40E_DEV_ID_ADAPTIVE_VF:
hw->mac.type = I40E_MAC_VF;
break;
 #endif
diff --git a/drivers/net/i40e/base/i40e_devids.h 
b/drivers/net/i40e/base/i40e_devids.h
index 4546689..f4a8784 100644
--- a/drivers/net/i40e/base/i40e_devids.h
+++ b/drivers/net/i40e/base/i40e_devids.h
@@ -54,6 +54,7 @@ POSSIBILITY OF SUCH DAMAGE.
 #if defined(INTEGRATED_VF) || defined(VF_DRIVER) || defined(I40E_NDIS_SUPPORT)
 #define I40E_DEV_ID_VF 0x154C
 #define I40E_DEV_ID_VF_HV  0x1571
+#define I40E_DEV_ID_ADAPTIVE_VF0x1889
 #endif /* VF_DRIVER */
 #ifdef X722_A0_SUPPORT
 #define I40E_DEV_ID_X722_A00x374C
-- 
2.4.11

[dpdk-dev] [PATCH v3 05/17] net/i40e/base: store the requested FEC information

[Jingjing Wu]

Store information about FEC modes, that were requested. It will be used
in printing link status information function and this way there is no
need to call admin queue there.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_common.c | 4 
 drivers/net/i40e/base/i40e_type.h   | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 5f6dd7b..7d59b59 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -2826,6 +2826,10 @@ enum i40e_status_code i40e_update_link_info(struct 
i40e_hw *hw)
if (status)
return status;
 
+   hw->phy.link_info.req_fec_info =
+   abilities.fec_cfg_curr_mod_ext_info &
+   (I40E_AQ_REQUEST_FEC_KR | I40E_AQ_REQUEST_FEC_RS);
+
i40e_memcpy(hw->phy.link_info.module_type, 
&abilities.module_type,
sizeof(hw->phy.link_info.module_type), 
I40E_NONDMA_TO_NONDMA);
}
diff --git a/drivers/net/i40e/base/i40e_type.h 
b/drivers/net/i40e/base/i40e_type.h
index 52a114a..af5347b 100644
--- a/drivers/net/i40e/base/i40e_type.h
+++ b/drivers/net/i40e/base/i40e_type.h
@@ -271,6 +271,7 @@ struct i40e_link_status {
enum i40e_aq_link_speed link_speed;
u8 link_info;
u8 an_info;
+   u8 req_fec_info;
u8 fec_info;
u8 ext_info;
u8 loopback;
-- 
2.4.11

[dpdk-dev] [PATCH v3 06/17] net/i40e/base: add new phy types for 25G AOC and ACC

[Jingjing Wu]

This patch adds new phy types for 25G Active Optical Cables (AOC) and
Active Copper Cables (ACC) support.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_adminq_cmd.h | 4 
 drivers/net/i40e/base/i40e_common.c | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h 
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index 83b28f8..70079a0 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -1849,6 +1849,8 @@ enum i40e_aq_phy_type {
I40E_PHY_TYPE_25GBASE_CR= 0x20,
I40E_PHY_TYPE_25GBASE_SR= 0x21,
I40E_PHY_TYPE_25GBASE_LR= 0x22,
+   I40E_PHY_TYPE_25GBASE_AOC   = 0x23,
+   I40E_PHY_TYPE_25GBASE_ACC   = 0x24,
I40E_PHY_TYPE_MAX
 };
 
@@ -1906,6 +1908,8 @@ struct i40e_aq_get_phy_abilities_resp {
 #define I40E_AQ_PHY_TYPE_EXT_25G_CR0x02
 #define I40E_AQ_PHY_TYPE_EXT_25G_SR0x04
 #define I40E_AQ_PHY_TYPE_EXT_25G_LR0x08
+#define I40E_AQ_PHY_TYPE_EXT_25G_AOC   0x10
+#define I40E_AQ_PHY_TYPE_EXT_25G_ACC   0x20
u8  fec_cfg_curr_mod_ext_info;
 #define I40E_AQ_ENABLE_FEC_KR  0x01
 #define I40E_AQ_ENABLE_FEC_RS  0x02
diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 7d59b59..004c062 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -1296,6 +1296,8 @@ STATIC enum i40e_media_type i40e_get_media_type(struct 
i40e_hw *hw)
case I40E_PHY_TYPE_40GBASE_AOC:
case I40E_PHY_TYPE_10GBASE_AOC:
case I40E_PHY_TYPE_25GBASE_CR:
+   case I40E_PHY_TYPE_25GBASE_AOC:
+   case I40E_PHY_TYPE_25GBASE_ACC:
media = I40E_MEDIA_TYPE_DA;
break;
case I40E_PHY_TYPE_1000BASE_KX:
-- 
2.4.11

[dpdk-dev] [PATCH v3 09/17] net/i40e/base: update FW AQ API version to 1.7

[Jingjing Wu]

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_adminq_cmd.h | 10 +-
 drivers/net/i40e/base/i40e_common.c |  5 +++--
 drivers/net/i40e/base/i40e_type.h   |  4 
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h 
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index c1ca290..dd9fb55 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -41,7 +41,15 @@ POSSIBILITY OF SUCH DAMAGE.
  */
 
 #define I40E_FW_API_VERSION_MAJOR  0x0001
-#define I40E_FW_API_VERSION_MINOR  0x0005
+#define I40E_FW_API_VERSION_MINOR_X722 0x0005
+#define I40E_FW_API_VERSION_MINOR_X710 0x0007
+
+#define I40E_FW_MINOR_VERSION(_h) ((_h)->mac.type == I40E_MAC_XL710 ? \
+   I40E_FW_API_VERSION_MINOR_X710 : \
+   I40E_FW_API_VERSION_MINOR_X722)
+
+/* API version 1.7 implements additional link and PHY-specific APIs  */
+#define I40E_MINOR_VER_GET_LINK_INFO_XL710 0x0007
 
 struct i40e_aq_desc {
__le16 flags;
diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 38c30a1..9895a77 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -1692,8 +1692,9 @@ enum i40e_status_code i40e_aq_get_phy_capabilities(struct 
i40e_hw *hw,
status = I40E_ERR_UNKNOWN_PHY;
 
if (report_init) {
-   if (hw->aq.api_maj_ver == I40E_FW_API_VERSION_MAJOR &&
-   hw->aq.api_min_ver >= 7) {
+   if (hw->mac.type ==  I40E_MAC_XL710 &&
+   hw->aq.api_maj_ver == I40E_FW_API_VERSION_MAJOR &&
+   hw->aq.api_min_ver >= I40E_MINOR_VER_GET_LINK_INFO_XL710) {
status = i40e_aq_get_link_info(hw, true, NULL, NULL);
} else {
hw->phy.phy_types = LE32_TO_CPU(abilities->phy_type);
diff --git a/drivers/net/i40e/base/i40e_type.h 
b/drivers/net/i40e/base/i40e_type.h
index af5347b..6ca1a0f 100644
--- a/drivers/net/i40e/base/i40e_type.h
+++ b/drivers/net/i40e/base/i40e_type.h
@@ -199,10 +199,6 @@ enum i40e_memcpy_type {
I40E_DMA_TO_NONDMA
 };
 
-#define I40E_FW_API_VERSION_MINOR_X722 0x0005
-#define I40E_FW_API_VERSION_MINOR_X710 0x0005
-
-
 /* These are structs for managing the hardware information and the operations.
  * The structures of function pointers are filled out at init time when we
  * know for sure exactly which hardware we're working with.  This gives us the
-- 
2.4.11

[dpdk-dev] [PATCH v3 07/17] net/i40e/base: report supported link modes

[Jingjing Wu]

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_adminq_cmd.h | 22 +++---
 drivers/net/i40e/base/i40e_common.c | 18 +++---
 2 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h 
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index 70079a0..c1ca290 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -1831,6 +1831,8 @@ enum i40e_aq_phy_type {
I40E_PHY_TYPE_10GBASE_CR1_CU= 0xB,
I40E_PHY_TYPE_10GBASE_AOC   = 0xC,
I40E_PHY_TYPE_40GBASE_AOC   = 0xD,
+   I40E_PHY_TYPE_UNRECOGNIZED  = 0xE,
+   I40E_PHY_TYPE_UNSUPPORTED   = 0xF,
I40E_PHY_TYPE_100BASE_TX= 0x11,
I40E_PHY_TYPE_1000BASE_T= 0x12,
I40E_PHY_TYPE_10GBASE_T = 0x13,
@@ -1851,7 +1853,9 @@ enum i40e_aq_phy_type {
I40E_PHY_TYPE_25GBASE_LR= 0x22,
I40E_PHY_TYPE_25GBASE_AOC   = 0x23,
I40E_PHY_TYPE_25GBASE_ACC   = 0x24,
-   I40E_PHY_TYPE_MAX
+   I40E_PHY_TYPE_MAX,
+   I40E_PHY_TYPE_EMPTY = 0xFE,
+   I40E_PHY_TYPE_DEFAULT   = 0xFF,
 };
 
 #define I40E_LINK_SPEED_100MB_SHIFT0x1
@@ -2039,19 +2043,31 @@ struct i40e_aqc_get_link_status {
 #define I40E_AQ_25G_SERDES_UCODE_ERR   0X04
 #define I40E_AQ_25G_NIMB_UCODE_ERR 0X05
u8  loopback; /* use defines from i40e_aqc_set_lb_mode */
+/* Since firmware API 1.7 loopback field keeps power class info as well */
+#define I40E_AQ_LOOPBACK_MASK  0x07
+#define I40E_AQ_PWR_CLASS_SHIFT_LB 6
+#define I40E_AQ_PWR_CLASS_MASK_LB  (0x03 << I40E_AQ_PWR_CLASS_SHIFT_LB)
__le16  max_frame_size;
u8  config;
 #define I40E_AQ_CONFIG_FEC_KR_ENA  0x01
 #define I40E_AQ_CONFIG_FEC_RS_ENA  0x02
 #define I40E_AQ_CONFIG_CRC_ENA 0x04
 #define I40E_AQ_CONFIG_PACING_MASK 0x78
-   u8  power_desc;
+   union {
+   struct {
+   u8  power_desc;
 #define I40E_AQ_LINK_POWER_CLASS_1 0x00
 #define I40E_AQ_LINK_POWER_CLASS_2 0x01
 #define I40E_AQ_LINK_POWER_CLASS_3 0x02
 #define I40E_AQ_LINK_POWER_CLASS_4 0x03
 #define I40E_AQ_PWR_CLASS_MASK 0x03
-   u8  reserved[4];
+   u8  reserved[4];
+   };
+   struct {
+   u8  link_type[4];
+   u8  link_type_ext;
+   };
+   };
 };
 
 I40E_CHECK_CMD_LENGTH(i40e_aqc_get_link_status);
diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 004c062..bb4b7eb 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -1692,8 +1692,14 @@ enum i40e_status_code 
i40e_aq_get_phy_capabilities(struct i40e_hw *hw,
status = I40E_ERR_UNKNOWN_PHY;
 
if (report_init) {
-   hw->phy.phy_types = LE32_TO_CPU(abilities->phy_type);
-   hw->phy.phy_types |= ((u64)abilities->phy_type_ext << 32);
+   if (hw->aq.api_maj_ver == I40E_FW_API_VERSION_MAJOR &&
+   hw->aq.api_min_ver >= 7) {
+   status = i40e_aq_get_link_info(hw, true, NULL, NULL);
+   } else {
+   hw->phy.phy_types = LE32_TO_CPU(abilities->phy_type);
+   hw->phy.phy_types |=
+   ((u64)abilities->phy_type_ext << 32);
+   }
}
 
return status;
@@ -1955,7 +1961,7 @@ enum i40e_status_code i40e_aq_get_link_info(struct 
i40e_hw *hw,
hw_link_info->fec_info = resp->config & (I40E_AQ_CONFIG_FEC_KR_ENA |
 I40E_AQ_CONFIG_FEC_RS_ENA);
hw_link_info->ext_info = resp->ext_info;
-   hw_link_info->loopback = resp->loopback;
+   hw_link_info->loopback = resp->loopback & I40E_AQ_LOOPBACK_MASK;
hw_link_info->max_frame_size = LE16_TO_CPU(resp->max_frame_size);
hw_link_info->pacing = resp->config & I40E_AQ_CONFIG_PACING_MASK;
 
@@ -1986,6 +1992,12 @@ enum i40e_status_code i40e_aq_get_link_info(struct 
i40e_hw *hw,
 hw->aq.fw_min_ver < 40)) && hw_link_info->phy_type == 0xE)
hw_link_info->phy_type = I40E_PHY_TYPE_10GBASE_SFPP_CU;
 
+   if (hw->aq.api_maj_ver == I40E_FW_API_VERSION_MAJOR &&
+   hw->aq.api_min_ver >= 7) {
+   hw->phy.phy_types = LE32_TO_CPU(*(__le32 *)resp->link_type);
+   hw->phy.phy_types |= ((u64)resp->link_type_ext << 32);
+   }
+
/* save link status information */
if (link)
i40e_memcpy(link, hw_link_info, sizeof(*hw_link_info),
-- 
2.4.11

[dpdk-dev] [PATCH v3 08/17] net/i40e/base: track id can be 0

[Jingjing Wu]

track_id == 0 is valid for “read only” profiles when
profile does not have any “write” commands.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_common.c|  7 +--
 drivers/net/i40e/base/i40e_prototype.h | 12 +++-
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index bb4b7eb..38c30a1 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -7370,11 +7370,6 @@ i40e_write_profile(struct i40e_hw *hw, struct 
i40e_profile_segment *profile,
u32 offset = 0, info = 0;
u32 i;
 
-   if (!track_id) {
-   i40e_debug(hw, I40E_DEBUG_PACKAGE, "Track_id can't be 0.");
-   return I40E_NOT_SUPPORTED;
-   }
-
dev_cnt = profile->device_table_count;
 
for (i = 0; i < dev_cnt; i++) {
@@ -7449,6 +7444,6 @@ i40e_add_pinfo_to_list(struct i40e_hw *hw,
memcpy(pinfo->name, profile->name, I40E_DDP_NAME_SIZE);
 
status = i40e_aq_write_ddp(hw, (void *)sec, sec->data_end,
-   track_id, &offset, &info, NULL);
+  track_id, &offset, &info, NULL);
return status;
 }
diff --git a/drivers/net/i40e/base/i40e_prototype.h 
b/drivers/net/i40e/base/i40e_prototype.h
index 54b6750..9171e97 100644
--- a/drivers/net/i40e/base/i40e_prototype.h
+++ b/drivers/net/i40e/base/i40e_prototype.h
@@ -575,12 +575,14 @@ u8 i40e_get_phy_address(struct i40e_hw *hw, u8 dev_num);
 enum i40e_status_code i40e_blink_phy_link_led(struct i40e_hw *hw,
  u32 time, u32 interval);
 enum i40e_status_code i40e_aq_write_ddp(struct i40e_hw *hw, void *buff,
-   u16 buff_size, u32 track_id,
-   u32 *error_offset, u32 *error_info,
-   struct i40e_asq_cmd_details *cmd_details);
+   u16 buff_size, u32 track_id,
+   u32 *error_offset, u32 *error_info,
+   struct i40e_asq_cmd_details *
+   cmd_details);
 enum i40e_status_code i40e_aq_get_ddp_list(struct i40e_hw *hw, void *buff,
-  u16 buff_size, u8 flags,
-  struct i40e_asq_cmd_details *cmd_details);
+  u16 buff_size, u8 flags,
+  struct i40e_asq_cmd_details *
+  cmd_details);
 struct i40e_generic_seg_header *
 i40e_find_segment_in_package(u32 segment_type,
 struct i40e_package_header *pkg_header);
-- 
2.4.11

[dpdk-dev] [PATCH v3 10/17] net/i40e/base: add support for switch parameters

[Jingjing Wu]

Adds double VLAN tagging ethertype fields to Set Switch Parameters AQ
command.  These were added in firmware API 1.7.

Callers of i40e_aq_set_switch_config() can specify the ethertypes to
use by filling out the corresponding fields in struct i40e_hw.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_adminq.c |  6 ++
 drivers/net/i40e/base/i40e_adminq_cmd.h | 17 -
 drivers/net/i40e/base/i40e_common.c |  6 +-
 drivers/net/i40e/base/i40e_type.h   |  6 ++
 4 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/net/i40e/base/i40e_adminq.c 
b/drivers/net/i40e/base/i40e_adminq.c
index a60292a..19871c7 100644
--- a/drivers/net/i40e/base/i40e_adminq.c
+++ b/drivers/net/i40e/base/i40e_adminq.c
@@ -682,6 +682,12 @@ enum i40e_status_code i40e_init_adminq(struct i40e_hw *hw)
   &oem_lo);
hw->nvm.oem_ver = ((u32)oem_hi << 16) | oem_lo;
 
+   /* The ability to RX (not drop) 802.1ad frames was added in API 1.7 */
+   if ((hw->aq.api_maj_ver > 1) ||
+   ((hw->aq.api_maj_ver == 1) &&
+(hw->aq.api_min_ver >= 7)))
+   hw->flags |= I40E_HW_FLAG_802_1AD_CAPABLE;
+
if (hw->aq.api_maj_ver > I40E_FW_API_VERSION_MAJOR) {
ret_code = I40E_ERR_FIRMWARE_API_VERSION;
goto init_adminq_free_arq;
diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h 
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index dd9fb55..c36da2a 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -787,7 +787,22 @@ struct i40e_aqc_set_switch_config {
 #define I40E_AQ_SET_SWITCH_CFG_L2_FILTER   0x0002
 #define I40E_AQ_SET_SWITCH_CFG_HW_ATR_EVICT0x0004
__le16  valid_flags;
-   u8  reserved[12];
+   /* The ethertype in switch_tag is dropped on ingress and used
+* internally by the switch. Set this to zero for the default
+* of 0x88a8 (802.1ad). Should be zero for firmware API
+* versions lower than 1.7.
+*/
+   __le16  switch_tag;
+   /* The ethertypes in first_tag and second_tag are used to
+* match the outer and inner VLAN tags (respectively) when HW
+* double VLAN tagging is enabled via the set port parameters
+* AQ command. Otherwise these are both ignored. Set them to
+* zero for their defaults of 0x8100 (802.1Q). Should be zero
+* for firmware API versions lower than 1.7.
+*/
+   __le16  first_tag;
+   __le16  second_tag;
+   u8  reserved[6];
 };
 
 I40E_CHECK_CMD_LENGTH(i40e_aqc_set_switch_config);
diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 9895a77..b4901ef 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -2695,7 +2695,11 @@ enum i40e_status_code i40e_aq_set_switch_config(struct 
i40e_hw *hw,
  i40e_aqc_opc_set_switch_config);
scfg->flags = CPU_TO_LE16(flags);
scfg->valid_flags = CPU_TO_LE16(valid_flags);
-
+   if (hw->flags & I40E_HW_FLAG_802_1AD_CAPABLE) {
+   scfg->switch_tag = CPU_TO_LE16(hw->switch_tag);
+   scfg->first_tag = CPU_TO_LE16(hw->first_tag);
+   scfg->second_tag = CPU_TO_LE16(hw->second_tag);
+   }
status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
 
return status;
diff --git a/drivers/net/i40e/base/i40e_type.h 
b/drivers/net/i40e/base/i40e_type.h
index 6ca1a0f..152b4a7 100644
--- a/drivers/net/i40e/base/i40e_type.h
+++ b/drivers/net/i40e/base/i40e_type.h
@@ -700,8 +700,14 @@ struct i40e_hw {
u16 wol_proxy_vsi_seid;
 
 #define I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE BIT_ULL(0)
+#define I40E_HW_FLAG_802_1AD_CAPABLEBIT_ULL(1)
u64 flags;
 
+   /* Used in set switch config AQ command */
+   u16 switch_tag;
+   u16 first_tag;
+   u16 second_tag;
+
/* debug mask */
u32 debug_mask;
char err_str[16];
-- 
2.4.11

[dpdk-dev] [PATCH v3 13/17] net/i40e/base: avoid reset timeout issue

[Jingjing Wu]

This patch allows detection of upcoming core reset in case NIC gets
stuck while performing FLR reset. The i40e_pf_reset() function returns
I40E_ERR_NOT_READY when global reset was detected.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_common.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 78ed2a8..ed2e01a 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -1382,6 +1382,8 @@ enum i40e_status_code i40e_pf_reset(struct i40e_hw *hw)
 * we don't need to do the PF Reset
 */
if (!cnt) {
+   u32 reg2 = 0;
+
reg = rd32(hw, I40E_PFGEN_CTRL);
wr32(hw, I40E_PFGEN_CTRL,
 (reg | I40E_PFGEN_CTRL_PFSWR_MASK));
@@ -1389,6 +1391,12 @@ enum i40e_status_code i40e_pf_reset(struct i40e_hw *hw)
reg = rd32(hw, I40E_PFGEN_CTRL);
if (!(reg & I40E_PFGEN_CTRL_PFSWR_MASK))
break;
+   reg2 = rd32(hw, I40E_GLGEN_RSTAT);
+   if (reg2 & I40E_GLGEN_RSTAT_DEVSTATE_MASK) {
+   DEBUGOUT("Core reset upcoming.\n");
+   DEBUGOUT1("I40E_GLGEN_RSTAT = 0x%x\n", reg2);
+   return I40E_ERR_NOT_READY;
+   }
i40e_msec_delay(1);
}
if (reg & I40E_PFGEN_CTRL_PFSWR_MASK) {
-- 
2.4.11

[dpdk-dev] [PATCH v3 12/17] net/i40e/base: avoid potential null pointer dereference

[Jingjing Wu]

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 3f3b275..78ed2a8 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -330,13 +330,15 @@ void i40e_debug_aq(struct i40e_hw *hw, enum 
i40e_debug_mask mask, void *desc,
   void *buffer, u16 buf_len)
 {
struct i40e_aq_desc *aq_desc = (struct i40e_aq_desc *)desc;
-   u16 len = LE16_TO_CPU(aq_desc->datalen);
u8 *buf = (u8 *)buffer;
+   u16 len;
u16 i = 0;
 
if ((!(mask & hw->debug_mask)) || (desc == NULL))
return;
 
+   len = LE16_TO_CPU(aq_desc->datalen);
+
i40e_debug(hw, mask,
   "AQ CMD: opcode 0x%04X, flags 0x%04X, datalen 0x%04X, retval 
0x%04X\n",
   LE16_TO_CPU(aq_desc->opcode),
-- 
2.4.11

[dpdk-dev] [PATCH v3 11/17] net/i40e/base: use admin queue for setting LEDs behavior

[Jingjing Wu]

Instead of accessing register directly, use newly added AQC in
order to blink LEDs. Introduce and utilize a new flag to prevent
excessive API version checking.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_adminq.c   |   6 ++
 drivers/net/i40e/base/i40e_common.c   | 148 ++
 drivers/net/i40e/base/i40e_register.h |   2 +-
 drivers/net/i40e/base/i40e_type.h |   1 +
 4 files changed, 121 insertions(+), 36 deletions(-)

diff --git a/drivers/net/i40e/base/i40e_adminq.c 
b/drivers/net/i40e/base/i40e_adminq.c
index 19871c7..8cc8c5e 100644
--- a/drivers/net/i40e/base/i40e_adminq.c
+++ b/drivers/net/i40e/base/i40e_adminq.c
@@ -688,6 +688,12 @@ enum i40e_status_code i40e_init_adminq(struct i40e_hw *hw)
 (hw->aq.api_min_ver >= 7)))
hw->flags |= I40E_HW_FLAG_802_1AD_CAPABLE;
 
+   if (hw->mac.type ==  I40E_MAC_XL710 &&
+   hw->aq.api_maj_ver == I40E_FW_API_VERSION_MAJOR &&
+   hw->aq.api_min_ver >= I40E_MINOR_VER_GET_LINK_INFO_XL710) {
+   hw->flags |= I40E_HW_FLAG_AQ_PHY_ACCESS_CAPABLE;
+   }
+
if (hw->aq.api_maj_ver > I40E_FW_API_VERSION_MAJOR) {
ret_code = I40E_ERR_FIRMWARE_API_VERSION;
goto init_adminq_free_arq;
diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index b4901ef..3f3b275 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -6678,24 +6678,38 @@ enum i40e_status_code i40e_led_get_phy(struct i40e_hw 
*hw, u16 *led_addr,
u16 temp_addr;
u8 port_num;
u32 i;
-
-   temp_addr = I40E_PHY_LED_PROV_REG_1;
-   i = rd32(hw, I40E_PFGEN_PORTNUM);
-   port_num = (u8)(i & I40E_PFGEN_PORTNUM_PORT_NUM_MASK);
-   phy_addr = i40e_get_phy_address(hw, port_num);
-
-   for (gpio_led_port = 0; gpio_led_port < 3; gpio_led_port++,
-temp_addr++) {
-   status = i40e_read_phy_register_clause45(hw,
+   u32 reg_val_aq;
+
+   if (hw->flags & I40E_HW_FLAG_AQ_PHY_ACCESS_CAPABLE) {
+   status =
+ i40e_aq_get_phy_register(hw,
+  I40E_AQ_PHY_REG_ACCESS_EXTERNAL,
+  I40E_PHY_COM_REG_PAGE,
+  I40E_PHY_LED_PROV_REG_1,
+  ®_val_aq, NULL);
+   if (status)
+   return status;
+   *val = (u16)reg_val_aq;
+   } else {
+   temp_addr = I40E_PHY_LED_PROV_REG_1;
+   i = rd32(hw, I40E_PFGEN_PORTNUM);
+   port_num = (u8)(i & I40E_PFGEN_PORTNUM_PORT_NUM_MASK);
+   phy_addr = i40e_get_phy_address(hw, port_num);
+
+   for (gpio_led_port = 0; gpio_led_port < 3; gpio_led_port++,
+temp_addr++) {
+   status =
+i40e_read_phy_register_clause45(hw,
 I40E_PHY_COM_REG_PAGE,
 temp_addr, phy_addr,
 ®_val);
-   if (status)
-   return status;
-   *val = reg_val;
-   if (reg_val & I40E_PHY_LED_LINK_MODE_MASK) {
-   *led_addr = temp_addr;
-   break;
+   if (status)
+   return status;
+   *val = reg_val;
+   if (reg_val & I40E_PHY_LED_LINK_MODE_MASK) {
+   *led_addr = temp_addr;
+   break;
+   }
}
}
return status;
@@ -6713,51 +6727,115 @@ enum i40e_status_code i40e_led_set_phy(struct i40e_hw 
*hw, bool on,
   u16 led_addr, u32 mode)
 {
enum i40e_status_code status = I40E_SUCCESS;
-   u16 led_ctl = 0;
-   u16 led_reg = 0;
+   u32 led_ctl = 0;
+   u32 led_reg = 0;
u8 phy_addr = 0;
u8 port_num;
u32 i;
 
-   i = rd32(hw, I40E_PFGEN_PORTNUM);
-   port_num = (u8)(i & I40E_PFGEN_PORTNUM_PORT_NUM_MASK);
-   phy_addr = i40e_get_phy_address(hw, port_num);
-   status = i40e_read_phy_register_clause45(hw, I40E_PHY_COM_REG_PAGE,
-led_addr, phy_addr, &led_reg);
+   if (hw->flags & I40E_HW_FLAG_AQ_PHY_ACCESS_CAPABLE) {
+   status =
+ i40e_aq_get_phy_register(hw,
+  I40E_AQ_PHY_REG_ACCESS_EXTERNAL,
+  I40E_PHY_COM_REG_PAGE,
+  I40E_PHY_LED_PROV_REG_1,
+  &led_reg, NULL);
+   } else {
+   i = r

[dpdk-dev] [PATCH v3 15/17] net/i40e/base: extend processing of DDP

[Jingjing Wu]

This patch adds extended processing of DDP packages:
 - Execution of adminq command sections to support AQ-depended profiles,
   for example, for programming cloud filters types.
 - Ability to write a profile without registering it in the list of
   applied profiles, to be used for AQ-depended profiles.
 - Profile rollback is implemented to support restoration of original
   parser/analyzer configuration without the need of core reset,
   for example, for deploying new profile without resetting device.
 - Search for a specific section in a profile, to be used by driver
   to access metadata sections with description of PCTYPE/PTYPEs
   defined in the profile.

Signed-off-by: Andrey Chilikin 
Signed-off-by: Beilei Xing 
Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_common.c| 258 ++---
 drivers/net/i40e/base/i40e_prototype.h |   6 +
 drivers/net/i40e/base/i40e_type.h  |  25 +++-
 3 files changed, 265 insertions(+), 24 deletions(-)

diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index ed2e01a..900d379 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -7441,6 +7441,165 @@ i40e_find_segment_in_package(u32 segment_type,
return NULL;
 }
 
+/* Get section table in profile */
+#define I40E_SECTION_TABLE(profile, sec_tbl)   \
+   do {\
+   struct i40e_profile_segment *p = (profile); \
+   u32 count;  \
+   u32 *nvm;   \
+   count = p->device_table_count;  \
+   nvm = (u32 *)&p->device_table[count];   \
+   sec_tbl = (struct i40e_section_table *)&nvm[nvm[0] + 1]; \
+   } while (0)
+
+/* Get section header in profile */
+#define I40E_SECTION_HEADER(profile, offset)   \
+   (struct i40e_profile_section_header *)((u8 *)(profile) + (offset))
+
+/**
+ * i40e_find_section_in_profile
+ * @section_type: the section type to search for (i.e., SECTION_TYPE_NOTE)
+ * @profile: pointer to the i40e segment header to be searched
+ *
+ * This function searches i40e segment for a particular section type. On
+ * success it returns a pointer to the section header, otherwise it will
+ * return NULL.
+ **/
+struct i40e_profile_section_header *
+i40e_find_section_in_profile(u32 section_type,
+struct i40e_profile_segment *profile)
+{
+   struct i40e_profile_section_header *sec;
+   struct i40e_section_table *sec_tbl;
+   u32 sec_off;
+   u32 i;
+
+   if (profile->header.type != SEGMENT_TYPE_I40E)
+   return NULL;
+
+   I40E_SECTION_TABLE(profile, sec_tbl);
+
+   for (i = 0; i < sec_tbl->section_count; i++) {
+   sec_off = sec_tbl->section_offset[i];
+   sec = I40E_SECTION_HEADER(profile, sec_off);
+   if (sec->section.type == section_type)
+   return sec;
+   }
+
+   return NULL;
+}
+
+/**
+ * i40e_ddp_exec_aq_section - Execute generic AQ for DDP
+ * @hw: pointer to the hw struct
+ * @aq: command buffer containing all data to execute AQ
+ **/
+STATIC enum
+i40e_status_code i40e_ddp_exec_aq_section(struct i40e_hw *hw,
+ struct i40e_profile_aq_section *aq)
+{
+   enum i40e_status_code status;
+   struct i40e_aq_desc desc;
+   u8 *msg = NULL;
+   u16 msglen;
+
+   i40e_fill_default_direct_cmd_desc(&desc, aq->opcode);
+   desc.flags |= CPU_TO_LE16(aq->flags);
+   i40e_memcpy(desc.params.raw, aq->param, sizeof(desc.params.raw),
+   I40E_NONDMA_TO_NONDMA);
+
+   msglen = aq->datalen;
+   if (msglen) {
+   desc.flags |= CPU_TO_LE16((u16)(I40E_AQ_FLAG_BUF |
+   I40E_AQ_FLAG_RD));
+   if (msglen > I40E_AQ_LARGE_BUF)
+   desc.flags |= CPU_TO_LE16((u16)I40E_AQ_FLAG_LB);
+   desc.datalen = CPU_TO_LE16(msglen);
+   msg = &aq->data[0];
+   }
+
+   status = i40e_asq_send_command(hw, &desc, msg, msglen, NULL);
+
+   if (status != I40E_SUCCESS) {
+   i40e_debug(hw, I40E_DEBUG_PACKAGE,
+  "unable to exec DDP AQ opcode %u, error %d\n",
+  aq->opcode, status);
+   return status;
+   }
+
+   /* copy returned desc to aq_buf */
+   i40e_memcpy(aq->param, desc.params.raw, sizeof(desc.params.raw),
+   I40E_NONDMA_TO_NONDMA);
+
+   return I40E_SUCCESS;
+}
+
+/**
+ * i40e_validate_profile
+ * @hw: pointer to the hardware structure
+ * @profile: pointer to the profile segment of the package to be validated
+ * @track_id: package tracking id
+ * @rollback: fl

[dpdk-dev] [PATCH v3 14/17] net/i40e/base: add EEPROM checksum verification

[Jingjing Wu]

This patch ensures PFs mutually exclusive access to NVM.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_nvm.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/i40e/base/i40e_nvm.c b/drivers/net/i40e/base/i40e_nvm.c
index 90521fa..a1e7830 100644
--- a/drivers/net/i40e/base/i40e_nvm.c
+++ b/drivers/net/i40e/base/i40e_nvm.c
@@ -749,12 +749,18 @@ enum i40e_status_code i40e_validate_nvm_checksum(struct 
i40e_hw *hw,
 
DEBUGFUNC("i40e_validate_nvm_checksum");
 
-   if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE)
-   ret_code = i40e_acquire_nvm(hw, I40E_RESOURCE_READ);
+   /* acquire_nvm provides exclusive NVM lock to synchronize access across
+* PFs. X710 uses i40e_read_nvm_word_srctl which polls for done bit
+* twice (first time to be able to write address to I40E_GLNVM_SRCTL
+* register, second to read data from I40E_GLNVM_SRDATA. One PF can see
+* done bit and try to write address, while another one will interpret
+* it as a good time to read data. It will cause invalid data to be
+* read.
+*/
+   ret_code = i40e_acquire_nvm(hw, I40E_RESOURCE_READ);
if (!ret_code) {
ret_code = i40e_calc_nvm_checksum(hw, &checksum_local);
-   if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE)
-   i40e_release_nvm(hw);
+   i40e_release_nvm(hw);
if (ret_code != I40E_SUCCESS)
goto i40e_validate_nvm_checksum_exit;
} else {
-- 
2.4.11

[dpdk-dev] [PATCH v3 16/17] net/i40e: use set switch aq instead of register setting

[Jingjing Wu]

TPID can be set by set_switch_config aq, change the TPID setting
by set_switch_config on new FW release.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/i40e_ethdev.c | 102 +
 1 file changed, 62 insertions(+), 40 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 4ee1113..b1706a0 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2973,71 +2973,93 @@ i40e_vlan_filter_set(struct rte_eth_dev *dev, uint16_t 
vlan_id, int on)
 }
 
 static int
-i40e_vlan_tpid_set(struct rte_eth_dev *dev,
-  enum rte_vlan_type vlan_type,
-  uint16_t tpid)
+i40e_vlan_tpid_set_by_registers(struct rte_eth_dev *dev,
+   enum rte_vlan_type vlan_type,
+   uint16_t tpid, int qinq)
 {
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-   uint64_t reg_r = 0, reg_w = 0;
-   uint16_t reg_id = 0;
-   int ret = 0;
-   int qinq = dev->data->dev_conf.rxmode.hw_vlan_extend;
+   uint64_t reg_r = 0;
+   uint64_t reg_w = 0;
+   uint16_t reg_id = 3;
+   int ret;
 
-   switch (vlan_type) {
-   case ETH_VLAN_TYPE_OUTER:
-   if (qinq)
+   if (qinq) {
+   if (vlan_type == ETH_VLAN_TYPE_OUTER)
reg_id = 2;
-   else
-   reg_id = 3;
-   break;
-   case ETH_VLAN_TYPE_INNER:
-   if (qinq)
-   reg_id = 3;
-   else {
-   ret = -EINVAL;
-   PMD_DRV_LOG(ERR,
-   "Unsupported vlan type in single vlan.");
-   return ret;
-   }
-   break;
-   default:
-   ret = -EINVAL;
-   PMD_DRV_LOG(ERR, "Unsupported vlan type %d", vlan_type);
-   return ret;
}
+
ret = i40e_aq_debug_read_register(hw, I40E_GL_SWT_L2TAGCTRL(reg_id),
  ®_r, NULL);
if (ret != I40E_SUCCESS) {
PMD_DRV_LOG(ERR,
   "Fail to debug read from I40E_GL_SWT_L2TAGCTRL[%d]",
   reg_id);
-   ret = -EIO;
-   return ret;
+   return -EIO;
}
PMD_DRV_LOG(DEBUG,
-   "Debug read from I40E_GL_SWT_L2TAGCTRL[%d]: 0x%08"PRIx64,
-   reg_id, reg_r);
+   "Debug read from I40E_GL_SWT_L2TAGCTRL[%d]: 0x%08"PRIx64,
+   reg_id, reg_r);
 
reg_w = reg_r & (~(I40E_GL_SWT_L2TAGCTRL_ETHERTYPE_MASK));
reg_w |= ((uint64_t)tpid << I40E_GL_SWT_L2TAGCTRL_ETHERTYPE_SHIFT);
if (reg_r == reg_w) {
-   ret = 0;
PMD_DRV_LOG(DEBUG, "No need to write");
-   return ret;
+   return 0;
}
 
ret = i40e_aq_debug_write_register(hw, I40E_GL_SWT_L2TAGCTRL(reg_id),
   reg_w, NULL);
if (ret != I40E_SUCCESS) {
-   ret = -EIO;
PMD_DRV_LOG(ERR,
-   "Fail to debug write to I40E_GL_SWT_L2TAGCTRL[%d]",
-   reg_id);
-   return ret;
+   "Fail to debug write to I40E_GL_SWT_L2TAGCTRL[%d]",
+   reg_id);
+   return -EIO;
}
PMD_DRV_LOG(DEBUG,
-   "Debug write 0x%08"PRIx64" to I40E_GL_SWT_L2TAGCTRL[%d]",
-   reg_w, reg_id);
+   "Debug write 0x%08"PRIx64" to I40E_GL_SWT_L2TAGCTRL[%d]",
+   reg_w, reg_id);
+
+   return 0;
+}
+
+static int
+i40e_vlan_tpid_set(struct rte_eth_dev *dev,
+  enum rte_vlan_type vlan_type,
+  uint16_t tpid)
+{
+   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   int qinq = dev->data->dev_conf.rxmode.hw_vlan_extend;
+   int ret = 0;
+
+   if ((vlan_type != ETH_VLAN_TYPE_INNER &&
+vlan_type != ETH_VLAN_TYPE_OUTER) ||
+   (!qinq && vlan_type == ETH_VLAN_TYPE_INNER)) {
+   PMD_DRV_LOG(ERR,
+   "Unsupported vlan type.");
+   return -EINVAL;
+   }
+   /* 802.1ad frames ability is added in NVM API 1.7*/
+   if (hw->flags & I40E_HW_FLAG_802_1AD_CAPABLE) {
+   if (qinq) {
+   if (vlan_type == ETH_VLAN_TYPE_OUTER)
+   hw->first_tag = rte_cpu_to_le_16(tpid);
+   else if (vlan_type == ETH_VLAN_TYPE_INNER)
+   hw->second_tag = rte_cpu_to_le_16(tpid);
+   } else {
+   if (vlan_type == ETH_VLAN_TYPE_OUTER)
+   hw->second_tag = rte_cpu_to_le_16(tpid);
+   }
+   ret = i40e_aq_set_switch

[dpdk-dev] [PATCH v3 17/17] net/i40e/base: update base code info

[Jingjing Wu]

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/i40e/base/README b/drivers/net/i40e/base/README
index 0da9f67..59e76c2 100644
--- a/drivers/net/i40e/base/README
+++ b/drivers/net/i40e/base/README
@@ -34,7 +34,7 @@ Intel® I40E driver
 ==
 
 This directory contains source code of FreeBSD i40e driver of version
-cid-i40e.2017.03.21.tar.gz released by the team which develops
+cid-i40e.2017.06.23.tar.gz released by the team which develops
 basic drivers for any i40e NIC. The directory of base/ contains the
 original source package.
 This driver is valid for the product(s) listed below
-- 
2.4.11

[dpdk-dev] [PATCH v3 1/2] net/i40e: extended list of operations for ddp processing

[Andrey Chilikin]

This patch adds ability to remove already loaded profile
or write profile without registering it

Signed-off-by: Andrey Chilikin 
---
 drivers/net/i40e/rte_pmd_i40e.c | 87 +
 drivers/net/i40e/rte_pmd_i40e.h |  6 ++-
 2 files changed, 66 insertions(+), 27 deletions(-)

diff --git a/drivers/net/i40e/rte_pmd_i40e.c b/drivers/net/i40e/rte_pmd_i40e.c
index 45cdcfaa3..ca2515d96 100644
--- a/drivers/net/i40e/rte_pmd_i40e.c
+++ b/drivers/net/i40e/rte_pmd_i40e.c
@@ -1554,11 +1554,7 @@ i40e_check_profile_info(uint8_t port, uint8_t 
*profile_info_sec)
 sizeof(struct i40e_profile_section_header));
for (i = 0; i < p_list->p_count; i++) {
p = &p_list->p_info[i];
-   if ((pinfo->track_id == p->track_id) &&
-   !memcmp(&pinfo->version, &p->version,
-   sizeof(struct i40e_ddp_version)) &&
-   !memcmp(&pinfo->name, &p->name,
-   I40E_DDP_NAME_SIZE)) {
+   if (pinfo->track_id == p->track_id) {
PMD_DRV_LOG(INFO, "Profile exists.");
rte_free(buff);
return 1;
@@ -1584,6 +1580,13 @@ rte_pmd_i40e_process_ddp_package(uint8_t port, uint8_t 
*buff,
int is_exist;
enum i40e_status_code status = I40E_SUCCESS;
 
+   if (op != RTE_PMD_I40E_PKG_OP_WR_ADD &&
+   op != RTE_PMD_I40E_PKG_OP_WR_ONLY &&
+   op != RTE_PMD_I40E_PKG_OP_WR_DEL) {
+   PMD_DRV_LOG(ERR, "Operation not supported.");
+   return -ENOTSUP;
+   }
+
RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
 
dev = &rte_eth_devices[port];
@@ -1620,6 +1623,10 @@ rte_pmd_i40e_process_ddp_package(uint8_t port, uint8_t 
*buff,
return -EINVAL;
}
track_id = ((struct i40e_metadata_segment *)metadata_seg_hdr)->track_id;
+   if (track_id == I40E_DDP_TRACKID_INVALID) {
+   PMD_DRV_LOG(ERR, "Invalid track_id");
+   return -EINVAL;
+   }
 
/* Find profile segment */
profile_seg_hdr = i40e_find_segment_in_package(SEGMENT_TYPE_I40E,
@@ -1639,40 +1646,68 @@ rte_pmd_i40e_process_ddp_package(uint8_t port, uint8_t 
*buff,
return -EINVAL;
}
 
+   /* Check if the profile already loaded */
+   i40e_generate_profile_info_sec(
+   ((struct i40e_profile_segment *)profile_seg_hdr)->name,
+   &((struct i40e_profile_segment *)profile_seg_hdr)->version,
+   track_id, profile_info_sec,
+   op == RTE_PMD_I40E_PKG_OP_WR_ADD);
+   is_exist = i40e_check_profile_info(port, profile_info_sec);
+   if (is_exist < 0) {
+   PMD_DRV_LOG(ERR, "Failed to check profile.");
+   rte_free(profile_info_sec);
+   return -EINVAL;
+   }
+
if (op == RTE_PMD_I40E_PKG_OP_WR_ADD) {
-   /* Check if the profile exists */
-   i40e_generate_profile_info_sec(
-((struct i40e_profile_segment *)profile_seg_hdr)->name,
-&((struct i40e_profile_segment *)profile_seg_hdr)->version,
-track_id, profile_info_sec, 1);
-   is_exist = i40e_check_profile_info(port, profile_info_sec);
-   if (is_exist > 0) {
+   if (is_exist) {
PMD_DRV_LOG(ERR, "Profile already exists.");
rte_free(profile_info_sec);
-   return 1;
-   } else if (is_exist < 0) {
-   PMD_DRV_LOG(ERR, "Failed to check profile.");
+   return -EEXIST;
+   }
+   } else if (op == RTE_PMD_I40E_PKG_OP_WR_DEL) {
+   if (!is_exist) {
+   PMD_DRV_LOG(ERR, "Profile does not exist.");
rte_free(profile_info_sec);
-   return -EINVAL;
+   return -EACCES;
}
+   }
 
-   /* Write profile to HW */
+   if (op == RTE_PMD_I40E_PKG_OP_WR_DEL) {
+   status = i40e_rollback_profile(
+   hw,
+   (struct i40e_profile_segment *)profile_seg_hdr,
+   track_id);
+   if (status) {
+   PMD_DRV_LOG(ERR, "Failed to write profile for delete.");
+   rte_free(profile_info_sec);
+   return status;
+   }
+   }
+   else {
status = i40e_write_profile(
-   hw,
-   (struct i40e_profile_segment *)profile_seg_hdr,
-   track_id);
+   hw,
+   (struct i40e_profile_segment *)profile_seg_hdr,
+   track_id);
if (status) {
-   PMD_DRV_LOG(ERR, "Failed 

[dpdk-dev] [PATCH v3 0/2] net/i40e: extended list of operations for ddp processing

[Andrey Chilikin]

This patch adds two new operations for dynamic device personalisation:
* remove already loaded profile and delete it from the list
* write profile without registering it

This patchset depends on:
[PATCH v2 00/16] net/i40e: base code update
http://dpdk.org/ml/archives/dev/2017-June/068732.html
http://dpdk.org/dev/patchwork/patch/25705/

v3:
- move testpmd updates to 'ddp add' command to a separate
  patch http://dpdk.org/dev/patchwork/patch/25779/

v2:
- Local static functions replaced by corresponding new
  functions in i40e base code
- Test-pmd command added


Andrey Chilikin (2):
  net/i40e: extended list of operations for ddp processing
  app/testpmd: enable ddp remove profile feature

 app/test-pmd/cmdline.c  | 74 
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  7 +++
 drivers/net/i40e/rte_pmd_i40e.c | 87 -
 drivers/net/i40e/rte_pmd_i40e.h |  6 +-
 4 files changed, 147 insertions(+), 27 deletions(-)

-- 
2.13.0

[dpdk-dev] [PATCH v3 2/2] app/testpmd: enable ddp remove profile feature

[Andrey Chilikin]

New command 'ddp del (port) (profile_path)' removes previously
loaded profile and deletes it from the list of the loaded profiles.

Signed-off-by: Andrey Chilikin 
---
 app/test-pmd/cmdline.c  | 74 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  7 +++
 2 files changed, 81 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 632d6f03f..425ffccb9 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -606,6 +606,9 @@ static void cmd_help_long_parsed(void *parsed_result,
"ddp add (port_id) (profile_path)\n"
"Load a profile package on a port\n\n"
 
+   "ddp del (port_id) (profile_path)\n"
+   "Delete a profile package from a port\n\n"
+
"ptype mapping get (port_id) (valid_only)\n"
"Get ptype mapping on a port\n\n"
 
@@ -12999,6 +13002,76 @@ cmdline_parse_inst_t cmd_ddp_add = {
},
 };
 
+/* Delete dynamic device personalization*/
+struct cmd_ddp_del_result {
+   cmdline_fixed_string_t ddp;
+   cmdline_fixed_string_t del;
+   uint8_t port_id;
+   char filepath[];
+};
+
+cmdline_parse_token_string_t cmd_ddp_del_ddp =
+   TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, ddp, "ddp");
+cmdline_parse_token_string_t cmd_ddp_del_del =
+   TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, del, "del");
+cmdline_parse_token_num_t cmd_ddp_del_port_id =
+   TOKEN_NUM_INITIALIZER(struct cmd_ddp_del_result, port_id, UINT8);
+cmdline_parse_token_string_t cmd_ddp_del_filepath =
+   TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, filepath, NULL);
+
+static void
+cmd_ddp_del_parsed(
+   void *parsed_result,
+   __attribute__((unused)) struct cmdline *cl,
+   __attribute__((unused)) void *data)
+{
+   struct cmd_ddp_del_result *res = parsed_result;
+   uint8_t *buff;
+   uint32_t size;
+   int ret = -ENOTSUP;
+
+   if (res->port_id > nb_ports) {
+   printf("Invalid port, range is [0, %d]\n", nb_ports - 1);
+   return;
+   }
+
+   if (!all_ports_stopped()) {
+   printf("Please stop all ports first\n");
+   return;
+   }
+
+   buff = open_ddp_package_file(res->filepath, &size);
+   if (!buff)
+   return;
+
+#ifdef RTE_LIBRTE_I40E_PMD
+   if (ret == -ENOTSUP)
+   ret = rte_pmd_i40e_process_ddp_package(res->port_id,
+  buff, size,
+  RTE_PMD_I40E_PKG_OP_WR_DEL);
+#endif
+
+   if (ret == -EACCES)
+   printf("Profile does not exist.\n");
+   else if (ret < 0)
+   printf("Failed to delete profile.\n");
+
+   close_ddp_package_file(buff);
+}
+
+cmdline_parse_inst_t cmd_ddp_del = {
+   .f = cmd_ddp_del_parsed,
+   .data = NULL,
+   .help_str = "ddp del  ",
+   .tokens = {
+   (void *)&cmd_ddp_del_ddp,
+   (void *)&cmd_ddp_del_del,
+   (void *)&cmd_ddp_del_port_id,
+   (void *)&cmd_ddp_del_filepath,
+   NULL,
+   },
+};
+
 /* Get dynamic device personalization profile info */
 struct cmd_ddp_info_result {
cmdline_fixed_string_t ddp;
@@ -13978,6 +14051,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_strict_link_prio,
(cmdline_parse_inst_t *)&cmd_tc_min_bw,
(cmdline_parse_inst_t *)&cmd_ddp_add,
+   (cmdline_parse_inst_t *)&cmd_ddp_del,
(cmdline_parse_inst_t *)&cmd_ddp_get_list,
(cmdline_parse_inst_t *)&cmd_ddp_get_info,
(cmdline_parse_inst_t *)&cmd_show_vf_stats,
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 18ee8a3fe..76809b859 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1232,6 +1232,13 @@ Load a dynamic device personalization (DDP) package::
 
testpmd> ddp add (port_id) (package_path)
 
+ddp del
+~~~
+
+Delete a dynamic device personalization package::
+
+   testpmd> ddp del (port_id) (package_path)
+
 ptype mapping
 ~
 
-- 
2.13.0

Re: [dpdk-dev] [PATCH v5 10/12] pci: implement find_device bus operation

[Bruce Richardson]

On Mon, Jun 26, 2017 at 02:22:08AM +0200, Gaetan Rivet wrote:
> Signed-off-by: Gaetan Rivet 
> ---
>  lib/librte_eal/common/eal_common_pci.c | 13 +
>  1 file changed, 13 insertions(+)
> 
Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH v5 11/12] pci: implement hotplug bus operation

[Bruce Richardson]

On Mon, Jun 26, 2017 at 02:22:09AM +0200, Gaetan Rivet wrote:
> Signed-off-by: Gaetan Rivet 
> ---
>  lib/librte_eal/common/eal_common_pci.c | 44 
> ++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/lib/librte_eal/common/eal_common_pci.c 
> b/lib/librte_eal/common/eal_common_pci.c
> index 00d48d9..286357d 100644
> --- a/lib/librte_eal/common/eal_common_pci.c
> +++ b/lib/librte_eal/common/eal_common_pci.c
> @@ -47,6 +47,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -500,11 +501,54 @@ pci_find_device(rte_dev_cmp_t cmp, const void *data)
>   return NULL;
>  }
>  
> +static struct rte_device *
> +pci_plug(struct rte_devargs *da)
> +{
> + struct rte_pci_device *pdev;
> + struct rte_pci_addr *addr;
> +
> + addr = &da->pci.addr;
> + /*
> +  * Update eventual pci device in global list.
> +  * Insert it if none was found.
> +  */
> + if (pci_update_device(addr) < 0) {
> + rte_errno = EIO;
> + return NULL;
> + }
> + /* Find the current device holding this address in the bus. */
> + FOREACH_DEVICE_ON_PCIBUS(pdev) {
> + if (rte_eal_compare_pci_addr(&pdev->addr, addr) == 0) {
> + if (rte_pci_probe_one(addr)) {

Please put the != 0, or == -1 in the condition, to make it clear it's an
error leg.

> + rte_errno = ENODEV;
> + return NULL;
> + }
> + break;
> + }
> + }
> + return pdev ? &pdev->device : NULL;
> +}

Please put in explicit != NULL, as per coding standards here.

> +
> +static int
> +pci_unplug(struct rte_device *dev)
> +{
> + struct rte_pci_device *pdev;
> +
> + pdev = RTE_DEV_TO_PCI(dev);
> + if (rte_pci_detach(&pdev->addr)) {

As above, please check for == or != some value.

> + rte_errno = ENODEV;
> + return -1;
> + }
> + return 0;
> +}
> +
>  struct rte_pci_bus rte_pci_bus = {
>   .bus = {
>   .scan = rte_pci_scan,
>   .probe = rte_pci_probe,
>   .find_device = pci_find_device,
> + .plug = pci_plug,
> + .unplug = pci_unplug,
>   },
>   .device_list = TAILQ_HEAD_INITIALIZER(rte_pci_bus.device_list),
>   .driver_list = TAILQ_HEAD_INITIALIZER(rte_pci_bus.driver_list),
> -- 
> 2.1.4
> 
With above fixes,

Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH v2 3/6] net/vmxnet3: Generate link-state change notifications

[Ferruh Yigit]

On 6/15/2017 1:16 PM, Charles (Chas) Williams wrote:
> From: Robert Shearman 
> 
> Generate link-state change notifications by listening to interrupts
> generated by the device. Make use of the existing
> vmxnet3_process_events function that was compiled out, but change it
> to call vmxnet3_dev_link_update on a VMXNET3_ECR_LINK event and to not
> be so noisy in its log messages.
> 
> Enable interrupts on starting the device, using a new helper function,
> vmxnet3_enable_intr, based on vmxnet3_disable_intr and validated
> against the FreeBSD driver.
> 
> Keep track of the number of interrupts registered for to avoid
> hardcoding these in vmxnet3_enable/disable_intr and to provision for
> any future rxq intr support.
> 
> Factor out the guts of vmxnet3_dev_link_update minus the started check
> to allow the new function to be called from vmxnet3_dev_start in the
> lsc-enabled case to ensure that the link state is correctly set from
> the actual state at that point.
> 
> Signed-off-by: Robert Shearman 

It is close to the integration deadline, and all patches in the set
acked except this one, I am for getting the set and if any issue found
related LSC, fix it after integration deadline.

If there is an objection to get the patchset, please comment soon.

Thanks,
ferruh

Re: [dpdk-dev] [PATCH v3 7/8] mk: sort object files when building deps lists

[Thomas Monjalon]

27/06/2017 12:43, Luca Boccassi:
> On Tue, 2017-06-27 at 01:20 +0200, Thomas Monjalon wrote:
> > 23/06/2017 20:41, lbocc...@brocade.com:
> > > From: Luca Boccassi 
> > > 
> > > In order to achieve reproducible builds, always use the same
> > > order when listing object files to build dependencies lists.
> > > 
> > > Signed-off-by: Luca Boccassi 
> > > ---
> > >  mk/rte.app.mk | 4 ++--
> > >  mk/rte.hostapp.mk | 4 ++--
> > >  mk/rte.shared.mk  | 4 ++--
> > >  3 files changed, 6 insertions(+), 6 deletions(-)
> > > 
> > > --- a/mk/rte.app.mk
> > > +++ b/mk/rte.app.mk
> > > @@ -263,8 +263,8 @@ LDLIBS_NAMES += $(patsubst -Wl$(comma)-
> > > l%,lib%.a,$(filter -Wl$(comma)-l%,$(LDLIB
> > >  
> > >  # list of found libraries files (useful for deps). If not found,
> > > the
> > >  # library is silently ignored and dep won't be checked
> > > -LDLIBS_FILES := $(wildcard $(foreach dir,$(LDLIBS_PATH),\
> > > - $(addprefix $(dir)/,$(LDLIBS_NAMES
> > > +LDLIBS_FILES := $(sort $(wildcard $(foreach dir,$(LDLIBS_PATH),\
> > > + $(addprefix $(dir)/,$(LDLIBS_NAMES)
> > 
> > You cannot sort libraries.
> > Check - for instance - this comment above in this file:
> > # Eliminate duplicates without sorting, only keep the last
> > occurrence
> > filter-libs = \
> 
> Not sure I follow - what's the reason for avoiding to sort the list of
> libs to link against?

Sorry, the ordering issue is with LDLIBS not LDLIBS_FILES.

> > Why sorting them?
> > What is random in libraries list?
> 
> The issue is that the output of wildcard is not fully deterministic. It
> can depend on the filesystem, and even on the locale settings [1].
> Before GNU Make 3.82 (2009) it used to automatically sort the output,
> but that was removed (to make it faster... sigh). [2]

It is not a true wildcard here. It is just filtering files which
do not exist.
I think you do not need this patch for deterministic build.

Re: [dpdk-dev] [PATCH v5 04/12] bus: add bus iterator to find a device

[Bruce Richardson]

On Mon, Jun 26, 2017 at 02:22:02AM +0200, Gaetan Rivet wrote:
> From: Jan Blunck 
> 
> Signed-off-by: Jan Blunck 
> Signed-off-by: Gaetan Rivet 
> ---
>  lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  1 +
>  lib/librte_eal/common/eal_common_bus.c  | 24 +++
>  lib/librte_eal/common/include/rte_bus.h | 26 
> +
>  lib/librte_eal/linuxapp/eal/rte_eal_version.map |  1 +
>  4 files changed, 52 insertions(+)
> 
> diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map 
> b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> index f1a0765..21640d6 100644
> --- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> +++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> @@ -164,6 +164,7 @@ DPDK_17.05 {
>  
>   rte_bus_find;
>   rte_bus_find_by_device;
> + rte_bus_find_device;
>   rte_cpu_is_supported;
>   rte_log_dump;
>   rte_log_register;
> diff --git a/lib/librte_eal/common/eal_common_bus.c 
> b/lib/librte_eal/common/eal_common_bus.c
> index d208214..63fd9f1 100644
> --- a/lib/librte_eal/common/eal_common_bus.c
> +++ b/lib/librte_eal/common/eal_common_bus.c
> @@ -190,3 +190,27 @@ rte_bus_find_by_device(const struct rte_device *dev)
>  {
>   return rte_bus_find(bus_find_device, (const void *)dev, NULL);
>  }
> +
> +struct rte_device *
> +rte_bus_find_device(rte_dev_cmp_t cmp, const void *data,
> + const struct rte_device *start)

One additional suggestion: might it be worthwhile also returning the bus
for the device here, in an optional 4th parameter. This is, after all,
a bus API. :-)

/Bruce

Re: [dpdk-dev] [PATCH v5 12/12] eal: make virtual driver probe and remove take rte_vdev_device

[Bruce Richardson]

On Mon, Jun 26, 2017 at 02:22:10AM +0200, Gaetan Rivet wrote:
> From: Jan Blunck 
> 
> This is a preparation to embed the generic rte_device into the rte_eth_dev
> also for virtual devices.
> 
> Signed-off-by: Jan Blunck 
> Signed-off-by: Gaetan Rivet 
> ---
>  lib/librte_eal/common/eal_common_dev.c | 93 
> ++
>  1 file changed, 71 insertions(+), 22 deletions(-)
> 
> diff --git a/lib/librte_eal/common/eal_common_dev.c 
> b/lib/librte_eal/common/eal_common_dev.c
> index a400ddd..d83ae41 100644
> --- a/lib/librte_eal/common/eal_common_dev.c
> +++ b/lib/librte_eal/common/eal_common_dev.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -45,50 +46,98 @@
>  
>  #include "eal_private.h"
>  
> +static int cmp_detached_dev_name(const struct rte_device *dev,
> + const void *_name)
> +{
> + const char *name = _name;
> +
> + /* skip attached devices */
> + if (dev->driver)
> + return 0;
> +

Does returning 0 from this function not mean that all already-attached
devices with match? Is that really what we want, as it doesn't seem to
match the logic in the function below. Please explain if I'm wrong here.

> + return strcmp(dev->name, name);
> +}
> +
>  int rte_eal_dev_attach(const char *name, const char *devargs)
>  {
> - struct rte_pci_addr addr;
> + struct rte_device *dev;
> + int ret;
>  
>   if (name == NULL || devargs == NULL) {
>   RTE_LOG(ERR, EAL, "Invalid device or arguments provided\n");
>   return -EINVAL;
>   }
>  
> - if (eal_parse_pci_DomBDF(name, &addr) == 0) {
> - if (rte_pci_probe_one(&addr) < 0)
> - goto err;
> + dev = rte_bus_find_device(cmp_detached_dev_name, name, NULL);
> + if (dev) {
> + struct rte_bus *bus;
> +
> + bus = rte_bus_find_by_device(dev);
> + if (!bus) {
> + RTE_LOG(ERR, EAL, "Cannot find bus for device (%s)\n",
> + name);
> + return -EINVAL;
> + }
>  
> - } else {
> - if (rte_vdev_init(name, devargs))
> - goto err;
> + if (!bus->plug) {
> + RTE_LOG(ERR, EAL, "Bus function not supported\n");
> + return -ENOTSUP;
> + }
> +
> + ret = (bus->plug(dev->devargs) == NULL);
> + goto out;
>   }
>  
> - return 0;
> + /*
> +  * If we haven't found a bus device the user meant to "hotplug" a
> +  * virtual device instead.
> +  */
> + ret = rte_vdev_init(name, devargs);
> +out:
> + if (ret)
> + RTE_LOG(ERR, EAL, "Driver cannot attach the device (%s)\n",
> + name);
> + return ret;
> +}
> +


Regards,
/Bruce

Re: [dpdk-dev] [PATCH v5 12/12] eal: make virtual driver probe and remove take rte_vdev_device

[Bruce Richardson]

I'm also not sure about the commit title of this patch. It doesn't match
my understanding of what the patch does.

/Bruce

On Mon, Jun 26, 2017 at 02:22:10AM +0200, Gaetan Rivet wrote:
> From: Jan Blunck 
> 
> This is a preparation to embed the generic rte_device into the rte_eth_dev
> also for virtual devices.
> 
> Signed-off-by: Jan Blunck 
> Signed-off-by: Gaetan Rivet 
> ---

[dpdk-dev] [PATCH v4 00/17] net/i40e: base code update

[Jingjing Wu]

v4 changes:
 - fix more checkpatch warnings

v3 changes:
 - extra patch to update README
 - remove unnecessary code
 - fix checkpatch warning

v2 changes:
 - fix compile issue
 - update from package from 2017.05.24 to 2017.06.23

i40e base code upate. The main changes are:
 - use virtchnl.h instead of i40e_virtchnl.h
 - add support for Adaptive Virtual Function
 - add new AQ commands for read/write PHY registers
 - add new phy types for 25G
 - extend processing of DDP

Jingjing Wu (17):
  net/i40e/base: use new virtchnl header file
  net/i40e/base: sync nvmupdate command and adminq subtask
  net/i40e/base: add AQ command for read/write PHY registers
  net/i40e/base: add support for Adaptive Virtual Function
  net/i40e/base: store the requested FEC information
  net/i40e/base: add new phy types for 25G AOC and ACC
  net/i40e/base: report supported link modes
  net/i40e/base: track id can be 0
  net/i40e/base: update FW AQ API version to 1.7
  net/i40e/base: add support for switch parameters
  net/i40e/base: use admin queue for setting LEDs behavior
  net/i40e/base: avoid potential null pointer dereference
  net/i40e/base: avoid reset timeout issue
  net/i40e/base: add EEPROM checksum verification
  net/i40e/base: extend processing of DDP
  net/i40e: use set switch aq instead of register setting
  net/i40e/base: update base code info

 drivers/net/i40e/base/README|   2 +-
 drivers/net/i40e/base/i40e_adminq.c |  12 +
 drivers/net/i40e/base/i40e_adminq_cmd.h |  71 ++-
 drivers/net/i40e/base/i40e_common.c | 549 +++
 drivers/net/i40e/base/i40e_devids.h |   1 +
 drivers/net/i40e/base/i40e_nvm.c|  20 +-
 drivers/net/i40e/base/i40e_prototype.h  |  33 +-
 drivers/net/i40e/base/i40e_register.h   |   2 +-
 drivers/net/i40e/base/i40e_type.h   |  49 +-
 drivers/net/i40e/base/i40e_virtchnl.h   | 445 --
 drivers/net/i40e/base/virtchnl.h| 772 
 drivers/net/i40e/i40e_ethdev.c  | 102 +++--
 drivers/net/i40e/i40e_ethdev.h  |   8 +-
 drivers/net/i40e/i40e_ethdev_vf.c   | 209 +
 drivers/net/i40e/i40e_pf.c  | 235 +-
 drivers/net/i40e/i40e_pf.h  |  32 +-
 drivers/net/i40e/rte_pmd_i40e.h |   2 +-
 17 files changed, 1709 insertions(+), 835 deletions(-)
 delete mode 100644 drivers/net/i40e/base/i40e_virtchnl.h
 create mode 100644 drivers/net/i40e/base/virtchnl.h

-- 
2.4.11

[dpdk-dev] [PATCH v4 01/17] net/i40e/base: use new virtchnl header file

[Jingjing Wu]

Modify the necessary files to be compatible with the new virtchnl.h file
instead of relying on i40e_virtchnl.h variant. This mostly changes
references to VIRTCHNL_ variables by removing prefix of I40E_.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_common.c|  24 +-
 drivers/net/i40e/base/i40e_prototype.h |   6 +-
 drivers/net/i40e/base/i40e_type.h  |  12 +-
 drivers/net/i40e/base/i40e_virtchnl.h  | 445 ---
 drivers/net/i40e/base/virtchnl.h   | 772 +
 drivers/net/i40e/i40e_ethdev.h |   8 +-
 drivers/net/i40e/i40e_ethdev_vf.c  | 209 +
 drivers/net/i40e/i40e_pf.c | 235 +-
 drivers/net/i40e/i40e_pf.h |  32 +-
 drivers/net/i40e/rte_pmd_i40e.h|   2 +-
 10 files changed, 1039 insertions(+), 706 deletions(-)
 delete mode 100644 drivers/net/i40e/base/i40e_virtchnl.h
 create mode 100644 drivers/net/i40e/base/virtchnl.h

diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 03e94bc..6c09c27 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -34,7 +34,7 @@ POSSIBILITY OF SUCH DAMAGE.
 #include "i40e_type.h"
 #include "i40e_adminq.h"
 #include "i40e_prototype.h"
-#include "i40e_virtchnl.h"
+#include "virtchnl.h"
 
 
 /**
@@ -5523,7 +5523,7 @@ enum i40e_status_code 
i40e_aq_add_rem_control_packet_filter(struct i40e_hw *hw,
}
 
if (mac_addr)
-   i40e_memcpy(cmd->mac, mac_addr, I40E_ETH_LENGTH_OF_ADDRESS,
+   i40e_memcpy(cmd->mac, mac_addr, ETH_ALEN,
I40E_NONDMA_TO_NONDMA);
 
cmd->etype = CPU_TO_LE16(ethtype);
@@ -6879,7 +6879,7 @@ void i40e_write_rx_ctl(struct i40e_hw *hw, u32 reg_addr, 
u32 reg_val)
  * completion before returning.
  **/
 enum i40e_status_code i40e_aq_send_msg_to_pf(struct i40e_hw *hw,
-   enum i40e_virtchnl_ops v_opcode,
+   enum virtchnl_ops v_opcode,
enum i40e_status_code v_retval,
u8 *msg, u16 msglen,
struct i40e_asq_cmd_details *cmd_details)
@@ -6918,9 +6918,9 @@ enum i40e_status_code i40e_aq_send_msg_to_pf(struct 
i40e_hw *hw,
  * with appropriate information.
  **/
 void i40e_vf_parse_hw_config(struct i40e_hw *hw,
-struct i40e_virtchnl_vf_resource *msg)
+struct virtchnl_vf_resource *msg)
 {
-   struct i40e_virtchnl_vsi_resource *vsi_res;
+   struct virtchnl_vsi_resource *vsi_res;
int i;
 
vsi_res = &msg->vsi_res[0];
@@ -6930,19 +6930,17 @@ void i40e_vf_parse_hw_config(struct i40e_hw *hw,
hw->dev_caps.num_tx_qp = msg->num_queue_pairs;
hw->dev_caps.num_msix_vectors_vf = msg->max_vectors;
hw->dev_caps.dcb = msg->vf_offload_flags &
-  I40E_VIRTCHNL_VF_OFFLOAD_L2;
-   hw->dev_caps.fcoe = (msg->vf_offload_flags &
-I40E_VIRTCHNL_VF_OFFLOAD_FCOE) ? 1 : 0;
+  VIRTCHNL_VF_OFFLOAD_L2;
hw->dev_caps.iwarp = (msg->vf_offload_flags &
- I40E_VIRTCHNL_VF_OFFLOAD_IWARP) ? 1 : 0;
+ VIRTCHNL_VF_OFFLOAD_IWARP) ? 1 : 0;
for (i = 0; i < msg->num_vsis; i++) {
-   if (vsi_res->vsi_type == I40E_VSI_SRIOV) {
+   if (vsi_res->vsi_type == VIRTCHNL_VSI_SRIOV) {
i40e_memcpy(hw->mac.perm_addr,
vsi_res->default_mac_addr,
-   I40E_ETH_LENGTH_OF_ADDRESS,
+   ETH_ALEN,
I40E_NONDMA_TO_NONDMA);
i40e_memcpy(hw->mac.addr, vsi_res->default_mac_addr,
-   I40E_ETH_LENGTH_OF_ADDRESS,
+   ETH_ALEN,
I40E_NONDMA_TO_NONDMA);
}
vsi_res++;
@@ -6959,7 +6957,7 @@ void i40e_vf_parse_hw_config(struct i40e_hw *hw,
  **/
 enum i40e_status_code i40e_vf_reset(struct i40e_hw *hw)
 {
-   return i40e_aq_send_msg_to_pf(hw, I40E_VIRTCHNL_OP_RESET_VF,
+   return i40e_aq_send_msg_to_pf(hw, VIRTCHNL_OP_RESET_VF,
  I40E_SUCCESS, NULL, 0, NULL);
 }
 #endif /* VF_DRIVER */
diff --git a/drivers/net/i40e/base/i40e_prototype.h 
b/drivers/net/i40e/base/i40e_prototype.h
index 4bd589e..6ec4304 100644
--- a/drivers/net/i40e/base/i40e_prototype.h
+++ b/drivers/net/i40e/base/i40e_prototype.h
@@ -36,7 +36,7 @@ POSSIBILITY OF SUCH DAMAGE.
 
 #include "i40e_type.h"
 #include "i40e_alloc.h"
-#include "i40e_virtchnl.h"
+#include "virtchnl.h"
 
 /* Prototypes for shared code functions that are not in
  * the standard function pointer structures.  These are
@@ -504,10 +504,10 @@ void i40e_destroy_spinlock(struct i4

[dpdk-dev] [PATCH v4 02/17] net/i40e/base: sync nvmupdate command and adminq subtask

[Jingjing Wu]

During NVMupdate, state machine gets into unrecoverable state because
i40e_clean_adminq_subtask can get scheduled after the admin queue
command but before other state variables are updated.

This patch adds locking around admin queue command and update of
state variables so that adminq_subtask will have accurate information
whenever it gets scheduled.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_nvm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_nvm.c b/drivers/net/i40e/base/i40e_nvm.c
index e896502..90521fa 100644
--- a/drivers/net/i40e/base/i40e_nvm.c
+++ b/drivers/net/i40e/base/i40e_nvm.c
@@ -899,6 +899,11 @@ enum i40e_status_code i40e_nvmupd_command(struct i40e_hw 
*hw,
hw->nvmupd_state = I40E_NVMUPD_STATE_INIT;
}
 
+   /* Acquire lock to prevent race condition where adminq_task
+* can execute after i40e_nvmupd_nvm_read/write but before state
+* variables (nvm_wait_opcode, nvm_release_on_done) are updated
+*/
+   i40e_acquire_spinlock(&hw->aq.arq_spinlock);
switch (hw->nvmupd_state) {
case I40E_NVMUPD_STATE_INIT:
status = i40e_nvmupd_state_init(hw, cmd, bytes, perrno);
@@ -934,6 +939,7 @@ enum i40e_status_code i40e_nvmupd_command(struct i40e_hw 
*hw,
*perrno = -ESRCH;
break;
}
+   i40e_release_spinlock(&hw->aq.arq_spinlock);
return status;
 }
 
-- 
2.4.11

[dpdk-dev] [PATCH v4 03/17] net/i40e/base: add AQ command for read/write PHY registers

[Jingjing Wu]

This patch adds new additional command for accessing to PHY registers.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_adminq_cmd.h | 18 +
 drivers/net/i40e/base/i40e_common.c | 70 +
 drivers/net/i40e/base/i40e_prototype.h  |  9 +
 3 files changed, 97 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h 
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index 09f5bf5..83b28f8 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -245,6 +245,8 @@ enum i40e_admin_queue_opc {
i40e_aqc_opc_set_phy_debug  = 0x0622,
i40e_aqc_opc_upload_ext_phy_fm  = 0x0625,
i40e_aqc_opc_run_phy_activity   = 0x0626,
+   i40e_aqc_opc_set_phy_register   = 0x0628,
+   i40e_aqc_opc_get_phy_register   = 0x0629,
 
/* NVM commands */
i40e_aqc_opc_nvm_read   = 0x0701,
@@ -2128,6 +2130,22 @@ struct i40e_aqc_run_phy_activity {
 
 I40E_CHECK_CMD_LENGTH(i40e_aqc_run_phy_activity);
 
+/* Set PHY Register command (0x0628) */
+/* Get PHY Register command (0x0629) */
+struct i40e_aqc_phy_register_access {
+   u8  phy_interface;
+#define I40E_AQ_PHY_REG_ACCESS_INTERNAL0
+#define I40E_AQ_PHY_REG_ACCESS_EXTERNAL1
+#define I40E_AQ_PHY_REG_ACCESS_EXTERNAL_MODULE 2
+   u8  dev_addres;
+   u8  reserved1[2];
+   u32 reg_address;
+   u32 reg_value;
+   u8  reserved2[4];
+};
+
+I40E_CHECK_CMD_LENGTH(i40e_aqc_phy_register_access);
+
 /* NVM Read command (indirect 0x0701)
  * NVM Erase commands (direct 0x0702)
  * NVM Update commands (indirect 0x0703)
diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 6c09c27..280d9da 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -6863,6 +6863,76 @@ void i40e_write_rx_ctl(struct i40e_hw *hw, u32 reg_addr, 
u32 reg_val)
if (status || use_register)
wr32(hw, reg_addr, reg_val);
 }
+
+/**
+ * i40e_aq_set_phy_register
+ * @hw: pointer to the hw struct
+ * @phy_select: select which phy should be accessed
+ * @dev_addr: PHY device address
+ * @reg_addr: PHY register address
+ * @reg_val: new register value
+ * @cmd_details: pointer to command details structure or NULL
+ *
+ * Write the external PHY register.
+ **/
+enum i40e_status_code i40e_aq_set_phy_register(struct i40e_hw *hw,
+   u8 phy_select, u8 dev_addr,
+   u32 reg_addr, u32 reg_val,
+   struct i40e_asq_cmd_details *cmd_details)
+{
+   struct i40e_aq_desc desc;
+   struct i40e_aqc_phy_register_access *cmd =
+   (struct i40e_aqc_phy_register_access *)&desc.params.raw;
+   enum i40e_status_code status;
+
+   i40e_fill_default_direct_cmd_desc(&desc,
+ i40e_aqc_opc_set_phy_register);
+
+   cmd->phy_interface = phy_select;
+   cmd->dev_addres = dev_addr;
+   cmd->reg_address = reg_addr;
+   cmd->reg_value = reg_val;
+
+   status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
+
+   return status;
+}
+
+/**
+ * i40e_aq_get_phy_register
+ * @hw: pointer to the hw struct
+ * @phy_select: select which phy should be accessed
+ * @dev_addr: PHY device address
+ * @reg_addr: PHY register address
+ * @reg_val: read register value
+ * @cmd_details: pointer to command details structure or NULL
+ *
+ * Read the external PHY register.
+ **/
+enum i40e_status_code i40e_aq_get_phy_register(struct i40e_hw *hw,
+   u8 phy_select, u8 dev_addr,
+   u32 reg_addr, u32 *reg_val,
+   struct i40e_asq_cmd_details *cmd_details)
+{
+   struct i40e_aq_desc desc;
+   struct i40e_aqc_phy_register_access *cmd =
+   (struct i40e_aqc_phy_register_access *)&desc.params.raw;
+   enum i40e_status_code status;
+
+   i40e_fill_default_direct_cmd_desc(&desc,
+ i40e_aqc_opc_get_phy_register);
+
+   cmd->phy_interface = phy_select;
+   cmd->dev_addres = dev_addr;
+   cmd->reg_address = reg_addr;
+
+   status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
+   if (!status)
+   *reg_val = cmd->reg_value;
+
+   return status;
+}
+
 #ifdef VF_DRIVER
 
 /**
diff --git a/drivers/net/i40e/base/i40e_prototype.h 
b/drivers/net/i40e/base/i40e_prototype.h
index 6ec4304..54b6750 100644
--- a/drivers/net/i40e/base/i40e_prototype.h
+++ b/drivers/net/i40e/base/i40e_prototype.h
@@ -533,6 +533,15 @@ enum i40e_status_code i40e_aq_rx_ctl_write_register(struct 
i40e_hw *hw,
u32 reg_addr, u32 reg_val,
struct i40e_asq_cmd_details *cmd_details);
 void i40e_write_rx_ctl(struct i40e_hw *hw, u32 reg_addr, u

[dpdk-dev] [PATCH v4 04/17] net/i40e/base: add support for Adaptive Virtual Function

[Jingjing Wu]

Add device id define and mac_type assignment needed for Adaptive
Virtual Function.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_common.c | 1 +
 drivers/net/i40e/base/i40e_devids.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 280d9da..5f6dd7b 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -93,6 +93,7 @@ STATIC enum i40e_status_code i40e_set_mac_type(struct i40e_hw 
*hw)
 #if defined(INTEGRATED_VF) || defined(VF_DRIVER)
case I40E_DEV_ID_VF:
case I40E_DEV_ID_VF_HV:
+   case I40E_DEV_ID_ADAPTIVE_VF:
hw->mac.type = I40E_MAC_VF;
break;
 #endif
diff --git a/drivers/net/i40e/base/i40e_devids.h 
b/drivers/net/i40e/base/i40e_devids.h
index 4546689..f4a8784 100644
--- a/drivers/net/i40e/base/i40e_devids.h
+++ b/drivers/net/i40e/base/i40e_devids.h
@@ -54,6 +54,7 @@ POSSIBILITY OF SUCH DAMAGE.
 #if defined(INTEGRATED_VF) || defined(VF_DRIVER) || defined(I40E_NDIS_SUPPORT)
 #define I40E_DEV_ID_VF 0x154C
 #define I40E_DEV_ID_VF_HV  0x1571
+#define I40E_DEV_ID_ADAPTIVE_VF0x1889
 #endif /* VF_DRIVER */
 #ifdef X722_A0_SUPPORT
 #define I40E_DEV_ID_X722_A00x374C
-- 
2.4.11

[dpdk-dev] [PATCH v4 05/17] net/i40e/base: store the requested FEC information

[Jingjing Wu]

Store information about FEC modes, that were requested. It will be used
in printing link status information function and this way there is no
need to call admin queue there.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/base/i40e_common.c | 4 
 drivers/net/i40e/base/i40e_type.h   | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 5f6dd7b..7d59b59 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -2826,6 +2826,10 @@ enum i40e_status_code i40e_update_link_info(struct 
i40e_hw *hw)
if (status)
return status;
 
+   hw->phy.link_info.req_fec_info =
+   abilities.fec_cfg_curr_mod_ext_info &
+   (I40E_AQ_REQUEST_FEC_KR | I40E_AQ_REQUEST_FEC_RS);
+
i40e_memcpy(hw->phy.link_info.module_type, 
&abilities.module_type,
sizeof(hw->phy.link_info.module_type), 
I40E_NONDMA_TO_NONDMA);
}
diff --git a/drivers/net/i40e/base/i40e_type.h 
b/drivers/net/i40e/base/i40e_type.h
index 52a114a..af5347b 100644
--- a/drivers/net/i40e/base/i40e_type.h
+++ b/drivers/net/i40e/base/i40e_type.h
@@ -271,6 +271,7 @@ struct i40e_link_status {
enum i40e_aq_link_speed link_speed;
u8 link_info;
u8 an_info;
+   u8 req_fec_info;
u8 fec_info;
u8 ext_info;
u8 loopback;
-- 
2.4.11