[dpdk-dev] [PATCH] lpm: remove redundant check when adding lpm rule

2016-08-01 Thread Wei Dai
When a rule with depth > 24 is added into an existing
rule with depth <=24, a new tbl8 is allocated, the existing
rule first fulfill whole new tbl8, so the filed vaild of
each entry in this tbl8 is always true and depth of each
entry is always < 24 before adding new rule with depth > 24.

Signed-off-by: Wei Dai 
---
 lib/librte_lpm/rte_lpm.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index 24fec4b..5bdc23f 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -1071,14 +1071,9 @@ add_depth_big_v1604(struct rte_lpm *lpm, uint32_t 
ip_masked, uint8_t depth,

/* Insert new rule into the tbl8 entry. */
for (i = tbl8_index; i < tbl8_index + tbl8_range; i++) {
-   if (!lpm->tbl8[i].valid ||
-   lpm->tbl8[i].depth <= depth) {
-   lpm->tbl8[i].valid = VALID;
-   lpm->tbl8[i].depth = depth;
-   lpm->tbl8[i].next_hop = next_hop;
-
-   continue;
-   }
+   lpm->tbl8[i].valid = VALID;
+   lpm->tbl8[i].depth = depth;
+   lpm->tbl8[i].next_hop = next_hop;
}

/*
-- 
2.5.5



[dpdk-dev] DPDK Community Survey

2016-08-01 Thread Glynn, Michael J


-Original Message-
From: users [mailto:users-boun...@dpdk.org] On Behalf Of Glynn, Michael J
Sent: Thursday, July 28, 2016 5:46 PM

Hi all

As part of our ongoing efforts to improve DPDK, we'd like to hear your feedback!

We have created a number of DPDK-related questions here 
https://www.surveymonkey.com/r/DPDK_Community_Survey and want to hear your 
views!!

The survey will close at midnight GMT on Thursday August 4th

> Hi all
> Just a reminder to submit your feedback by midnight GMT this Thursday, August 
> 4th 
> This is your opportunity to voice your feedback - the more we get the better 
> so appreciate if you can take a few minutes to respond using the link 
> provided.
> Thanks to those who have already responded!!
> Regards
> Mike




[dpdk-dev] [PATCH] net/mlx5: Fix possible NULL deref in RX path

2016-08-01 Thread Adrien Mazarguil
Hi Sagi,

On Mon, Aug 01, 2016 at 11:44:21AM +0300, Sagi Grimberg wrote:
> The user is allowed to call ->rx_pkt_burst() even without free
> mbufs in the pool. In this scenario we'll fail allocating a rep mbuf
> on the first iteration (where pkt is still NULL). This would cause us
> to deref a NULL pkt (reset refcount and free).
> 
> Fix this by checking the pkt before freeing it.

Just to be sure, did you get an actual NULL deref crash here or is that an
assumed possibility?

I'm asking because this problem was supposed to be addressed by:

 a1bdb71a32da ("net/mlx5: fix crash in Rx")

> Signed-off-by: Sagi Grimberg 
> ---
>  drivers/net/mlx5/mlx5_rxtx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
> index fce3381ae87a..a07cc4794023 100644
> --- a/drivers/net/mlx5/mlx5_rxtx.c
> +++ b/drivers/net/mlx5/mlx5_rxtx.c
> @@ -1572,7 +1572,7 @@ mlx5_rx_burst(void *dpdk_rxq, struct rte_mbuf **pkts, 
> uint16_t pkts_n)
>   rte_prefetch0(wqe);
>   rep = rte_mbuf_raw_alloc(rxq->mp);
>   if (unlikely(rep == NULL)) {
> - while (pkt != seg) {
> + while (pkt && pkt != seg) {
>   assert(pkt != (*rxq->elts)[idx]);
>   seg = NEXT(pkt);
>   rte_mbuf_refcnt_set(pkt, 0);
> -- 
> 1.9.1

I've reviewed your patch and it indeed seems to address an issue, please
confirm my analysis below.

When rep cannot be allocated and is thus NULL, either pkt is still NULL
because the first packet segment has not been seen yet or points to the
first segment.

Either way at this point, seg points to current segment to process in the
queue and is never NULL.

Thus when pkt is still NULL (first segment) and rep cannot be allocated, the
comparison (pkt != seg) between a valid pointer (seg) and NULL (pkt)
succeeds. This case is not handled by the assert() statement and a crash
occurs.

We really want to avoid useless code in the data path, particularly inside
loops. The extra check you added is performed for each iteration, so what
about modifying your patch by adding the following if statement instead?

 if (!pkt)
 pkt = seg;
 while (pkt != seg) {
  ...
 }

I guess you could add "Fixes: a1bdb71a32da ("net/mlx5: fix crash in Rx")"
line to your commit log as well because the original patch only solved half
of the issue.

Thanks.

-- 
Adrien Mazarguil
6WIND


[dpdk-dev] [PATCH v7 00/17] Prepare for rte_device / rte_driver

2016-08-01 Thread Jan Viktorin
Thank you. Hope to find some time this week to do my part.

Jan

On Mon, 1 Aug 2016 16:15:15 +0530
Shreyansh Jain  wrote:

> * Original patch series is from David Marchand [1], [2].
> * Link with patch series [4] from Jan Viktorin for a more complete picture
>   of proposed EAL device heirarchy changes.
> * This might not be in-sync with pmdinfogen as PMD_REGISTER_DRIVER is
>   removed [7].
> 
> David created the original patchset based on the discussions on list [3].
> Being a large piece of work, this patchset introduces first level of changes
> for generalizing the driver-device relationship for supporting hotplug.
> 
> Overview of this work as per David [3], as well as notes from Thomas [9] &
> Jan:
> - pdev -> PCI registeration using helpers (introduced in this series)
> - removal of eth/crypto driver registeration callbacks. These are now handled
>   by PCI registeration helpers (this patch)
> - rte_device=>pci/vdev device heirarchy (by this [4] series)  
> - removal of PMD_PDEV type (this patch) and PMD_VDEV (by this [4] series)
> - Support for hotplugging
> 
> This patchset is based on master (b0a1419)
> 
> [1] http://dpdk.org/ml/archives/dev/2016-January/032387.html
> [2] http://dpdk.org/ml/archives/dev/2016-April/037686.html
> [3] http://dpdk.org/ml/archives/dev/2016-January/031390.html
> [4] http://dpdk.org/ml/archives/dev/2016-July/043645.html
> [5] http://dpdk.org/ml/archives/dev/2016-June/042439.html
> [6] http://dpdk.org/ml/archives/dev/2016-June/042444.html
> [7] http://dpdk.org/ml/archives/dev/2016-July/043172.html
> [8] http://dpdk.org/ml/archives/dev/2016-July/044004.html
> [9] http://dpdk.org/ml/archives/dev/2016-July/044086.html
> 
> Changes since v6:
> - rebase over 16.07 (b0a1419)
> - DRIVER_REGISTER_PCI macro is now passed pci_drv rather than drv
> - review comments regarding missing information in log messages
> - new API additions to 16.11 map objects
> - review comment in [5] and [7] are not included in this series.
> 
> Changes since v5:
> - Rebase over master (11c5e45d8)
> - Rename RTE_EAL_PCI_REGISTER helper macro to DRIVER_REGISTER_PCI to be in 
> sync
>   with DRIVER_REGISTER_PCI_TABLE. [Probably, in future, both can be merged]
> - Modifications to bnxt and thunderx driver PMD registeration files for
>   using the simplified PCI device registeration helper macro
> 
> Changes since v4:
> - Fix compilation issue after rebase on HEAD (913154e) in previous series
> - Retain rte_eth_dev_get_port_by_name and rte_eth_dev_get_name_by_port which
>   were removed by previous patchset. These are being used by pdump library
> 
> Changes since v3:
> - rebase over HEAD (913154e)
> - Update arguments to RTE_EAL_PCI_REGISTER macro as per Jan's suggestion
> - modify qede driver to use RTE_EAL_PCI_REGISTER
> - Argument check in hotplug functions
> 
> Changes since v2:
> - rebase over HEAD (d76c193)
> - Move SYSFS_PCI_DRIVERS macro to rte_pci.h to avoid compilation issue
> 
> Changes since v1:
> - rebased on HEAD, new drivers should be okay
> - patches have been split into smaller pieces
> - RTE_INIT macro has been added, but in the end, I am not sure it is useful
> - device type has been removed from ethdev, as it was used only by hotplug
> - getting rid of pmd type in eal patch (patch 5 of initial series) has been
>   dropped for now, we can do this once vdev drivers have been converted
> 
> David Marchand, Shreyansh Jain (17):
>   pci: no need for dynamic tailq init
>   crypto: no need for a crypto pmd type
>   drivers: align pci driver definitions
>   eal: remove duplicate function declaration
>   eal: introduce init macros
>   crypto: export init/uninit common wrappers for pci drivers
>   ethdev: export init/uninit common wrappers for pci drivers
>   drivers: convert all pdev drivers as pci drivers
>   crypto: get rid of crypto driver register callback
>   ethdev: get rid of eth driver register callback
>   eal/linux: move back interrupt thread init before setting affinity
>   pci: add a helper for device name
>   pci: add a helper to update a device
>   ethdev: do not scan all pci devices on attach
>   eal: add hotplug operations for pci and vdev
>   ethdev: convert to eal hotplug
>   ethdev: get rid of device type
> 
>  app/test/virtual_pmd.c  |   2 +-
>  drivers/crypto/qat/rte_qat_cryptodev.c  |  18 +-
>  drivers/net/af_packet/rte_eth_af_packet.c   |   2 +-
>  drivers/net/bnx2x/bnx2x_ethdev.c|  34 +--
>  drivers/net/bnxt/bnxt_ethdev.c  |  16 +-
>  drivers/net/bonding/rte_eth_bond_api.c  |   2 +-
>  drivers/net/cxgbe/cxgbe_ethdev.c|  24 +--
>  drivers/net/cxgbe/cxgbe_main.c  |   2 +-
>  drivers/net/e1000/em_ethdev.c   |  16 +-
>  drivers/net/e1000/igb_ethdev.c  |  39 +---
>  drivers/net/ena/ena_ethdev.c|  19 +-
>  drivers/net/enic/enic_ethdev.c  |  23 +-
>  drivers/net/fm10k/fm10k_ethdev.c|  23 +-

[dpdk-dev] [PATCH 4/4] net/bonding: fix configuration of LACP slaves

2016-08-01 Thread Robert Sanford
Problem: When adding a slave or starting a bond device, the bond
device configures slave devices via function slave_configure().
However, settings configured in the bond device's rte_eth_conf are
not propagated to the slaves. For example, VLAN and CRC stripping
are not working as expected.

The problem is that we pass the wrong argument when we invoke
rte_eth_dev_configure(). We pass the slave's currently configured
rte_eth_conf (as a source arg!), when we should pass a copy of the
(master) bond device's rte_eth_conf.

Solution: Make a local copy of the bond device's rte_eth_conf, adjust
the LSC flag based on the slave, and then pass that rte_eth_conf to
rte_eth_dev_configure().

Also, remove code that directly pokes RSS data into the slave's
rte_eth_conf, as that is also contained in the proper rte_eth_conf
that we will pass to rte_eth_dev_configure().

Signed-off-by: Robert Sanford 
---
 drivers/net/bonding/rte_eth_bond_pmd.c |   28 +++-
 1 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c 
b/drivers/net/bonding/rte_eth_bond_pmd.c
index b20a272..486582f 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -1302,6 +1302,7 @@ int
 slave_configure(struct rte_eth_dev *bonded_eth_dev,
struct rte_eth_dev *slave_eth_dev)
 {
+   struct rte_eth_conf slave_eth_conf;
struct bond_rx_queue *bd_rx_q;
struct bond_tx_queue *bd_tx_q;

@@ -1313,33 +1314,18 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
/* Stop slave */
rte_eth_dev_stop(slave_eth_dev->data->port_id);

-   /* Enable interrupts on slave device if supported */
-   if (slave_eth_dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC)
-   slave_eth_dev->data->dev_conf.intr_conf.lsc = 1;
-
-   /* If RSS is enabled for bonding, try to enable it for slaves  */
-   if (bonded_eth_dev->data->dev_conf.rxmode.mq_mode & ETH_MQ_RX_RSS_FLAG) 
{
-   if 
(bonded_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_key_len
-   != 0) {
-   
slave_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_key_len =
-   
bonded_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_key_len;
-   
slave_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_key =
-   
bonded_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_key;
-   } else {
-   
slave_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_key = NULL;
-   }
+   /* Build slave rte_eth_conf, starting from bonded's conf */
+   slave_eth_conf = bonded_eth_dev->data->dev_conf;

-   slave_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf =
-   
bonded_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf;
-   slave_eth_dev->data->dev_conf.rxmode.mq_mode =
-   bonded_eth_dev->data->dev_conf.rxmode.mq_mode;
-   }
+   /* Enable interrupts on slave device if supported */
+   slave_eth_conf.intr_conf.lsc =
+   !!(slave_eth_dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC);

/* Configure device */
errval = rte_eth_dev_configure(slave_eth_dev->data->port_id,
bonded_eth_dev->data->nb_rx_queues,
bonded_eth_dev->data->nb_tx_queues,
-   &(slave_eth_dev->data->dev_conf));
+   _eth_conf);
if (errval != 0) {
RTE_BOND_LOG(ERR, "Cannot configure slave device: port %u , err 
(%d)",
slave_eth_dev->data->port_id, errval);
-- 
1.7.1



[dpdk-dev] [PATCH 3/4] net/bonding: another fix to LACP mempool size

2016-08-01 Thread Robert Sanford
The following log message may appear after a slave is idle (or nearly
idle) for a few minutes: "PMD: Failed to allocate LACP packet from
pool".

Problem: All mbufs from a slave's private pool (used exclusively for
transmitting LACPDUs) have been allocated and are still sitting in
the device's tx descriptor ring and other cores' mempool caches.

Solution: Ensure that each slaves' tx (LACPDU) mempool owns more than
n-tx-queues * (n-tx-descriptors + per-core-mempool-flush-threshold)
mbufs.

Note that the LACP tx machine function is the only code that allocates
from a slave's private pool. It runs in the context of the interrupt
thread, and thus it has no mempool cache of its own.

Signed-off-by: Robert Sanford 
---
 drivers/net/bonding/rte_eth_bond_8023ad.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c 
b/drivers/net/bonding/rte_eth_bond_8023ad.c
index 2f7ae70..1207896 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.c
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
@@ -854,6 +854,8 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev 
*bond_dev, uint8_t slave_id)
char mem_name[RTE_ETH_NAME_MAX_LEN];
int socket_id;
unsigned element_size;
+   unsigned cache_size;
+   unsigned cache_flushthresh;
uint32_t total_tx_desc;
struct bond_tx_queue *bd_tx_q;
uint16_t q_id;
@@ -890,19 +892,21 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev 
*bond_dev, uint8_t slave_id)

element_size = sizeof(struct slow_protocol_frame) + sizeof(struct 
rte_mbuf)
+ RTE_PKTMBUF_HEADROOM;
+   cache_size = RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ?
+   32 : RTE_MEMPOOL_CACHE_MAX_SIZE;
+   cache_flushthresh = RTE_MEMPOOL_CALC_CACHE_FLUSHTHRESH(cache_size);

/* The size of the mempool should be at least:
 * the sum of the TX descriptors + BOND_MODE_8023AX_SLAVE_TX_PKTS */
total_tx_desc = BOND_MODE_8023AX_SLAVE_TX_PKTS;
for (q_id = 0; q_id < bond_dev->data->nb_tx_queues; q_id++) {
bd_tx_q = (struct 
bond_tx_queue*)bond_dev->data->tx_queues[q_id];
-   total_tx_desc += bd_tx_q->nb_tx_desc;
+   total_tx_desc += bd_tx_q->nb_tx_desc + cache_flushthresh;
}

snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", slave_id);
port->mbuf_pool = rte_mempool_create(mem_name,
-   total_tx_desc, element_size,
-   RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? 32 : 
RTE_MEMPOOL_CACHE_MAX_SIZE,
+   total_tx_desc, element_size, cache_size,
sizeof(struct rte_pktmbuf_pool_private), rte_pktmbuf_pool_init,
NULL, rte_pktmbuf_init, NULL, socket_id, MEMPOOL_F_NO_SPREAD);

-- 
1.7.1



[dpdk-dev] [PATCH 2/4] mempool: make cache flush threshold macro public

2016-08-01 Thread Robert Sanford
Rename macros that calculate a mempool cache flush threshold, and
move them from rte_mempool.c to rte_mempool.h, so that the bonding
driver can accurately calculate its mbuf requirements.

Signed-off-by: Robert Sanford 
---
 lib/librte_mempool/rte_mempool.c |8 ++--
 lib/librte_mempool/rte_mempool.h |7 +++
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 2e28e2e..cca4843 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -69,10 +69,6 @@ static struct rte_tailq_elem rte_mempool_tailq = {
 };
 EAL_REGISTER_TAILQ(rte_mempool_tailq)

-#define CACHE_FLUSHTHRESH_MULTIPLIER 1.5
-#define CALC_CACHE_FLUSHTHRESH(c)  \
-   ((typeof(c))((c) * CACHE_FLUSHTHRESH_MULTIPLIER))
-
 /*
  * return the greatest common divisor between a and b (fast algorithm)
  *
@@ -686,7 +682,7 @@ static void
 mempool_cache_init(struct rte_mempool_cache *cache, uint32_t size)
 {
cache->size = size;
-   cache->flushthresh = CALC_CACHE_FLUSHTHRESH(size);
+   cache->flushthresh = RTE_MEMPOOL_CALC_CACHE_FLUSHTHRESH(size);
cache->len = 0;
 }

@@ -762,7 +758,7 @@ rte_mempool_create_empty(const char *name, unsigned n, 
unsigned elt_size,

/* asked cache too big */
if (cache_size > RTE_MEMPOOL_CACHE_MAX_SIZE ||
-   CALC_CACHE_FLUSHTHRESH(cache_size) > n) {
+   RTE_MEMPOOL_CALC_CACHE_FLUSHTHRESH(cache_size) > n) {
rte_errno = EINVAL;
return NULL;
}
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 059ad9e..4323c1b 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -263,6 +263,13 @@ struct rte_mempool {
 #define MEMPOOL_F_NO_PHYS_CONTIG 0x0020 /**< Don't need physically contiguous 
objs. */

 /**
+ * Calculate the threshold before we flush excess elements.
+ */
+#define RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER 1.5
+#define RTE_MEMPOOL_CALC_CACHE_FLUSHTHRESH(c)  \
+   ((typeof(c))((c) * RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER))
+
+/**
  * @internal When debug is enabled, store some statistics.
  *
  * @param mp
-- 
1.7.1



[dpdk-dev] [PATCH 1/4] testpmd: fix LACP ports to work with idle links

2016-08-01 Thread Robert Sanford
Problem: When there is little or no TX traffic on an LACP port
(bonding mode 4), we don't call its tx burst function in a timely
manner, and thus we don't transmit LACPDUs when we should.

Solution: Add and maintain an "lacp_master" flag in rte_port struct.
In the main packet forwarding loop, if port is an LACP master, in 1
out of N loops force an empty call to the tx burst API.

Signed-off-by: Robert Sanford 
---
 app/test-pmd/cmdline.c |9 +
 app/test-pmd/testpmd.c |   37 +
 app/test-pmd/testpmd.h |4 
 3 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index f90befc..2a629ee 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -3975,6 +3975,10 @@ static void cmd_set_bonding_mode_parsed(void 
*parsed_result,
/* Set the bonding mode for the relevant port. */
if (0 != rte_eth_bond_mode_set(port_id, res->value))
printf("\t Failed to set bonding mode for port = %d.\n", 
port_id);
+   else if (res->value == BONDING_MODE_8023AD)
+   set_port_lacp_master(port_id);
+   else
+   clear_port_lacp_master(port_id);
 }

 cmdline_parse_token_string_t cmd_setbonding_mode_set =
@@ -4408,6 +4412,11 @@ static void cmd_create_bonded_device_parsed(void 
*parsed_result,
reconfig(port_id, res->socket);
rte_eth_promiscuous_enable(port_id);
ports[port_id].enabled = 1;
+
+   if (res->mode == BONDING_MODE_8023AD)
+   set_port_lacp_master(port_id);
+   else
+   clear_port_lacp_master(port_id);
}

 }
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 1428974..806667e 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -920,12 +920,28 @@ run_pkt_fwd_on_lcore(struct fwd_lcore *fc, packet_fwd_t 
pkt_fwd)
struct fwd_stream **fsm;
streamid_t nb_fs;
streamid_t sm_id;
+   unsigned int loop_count = 0;

fsm = _streams[fc->stream_idx];
nb_fs = fc->stream_nb;
do {
for (sm_id = 0; sm_id < nb_fs; sm_id++)
(*pkt_fwd)(fsm[sm_id]);
+
+   /*
+* Per rte_eth_bond.h, we must invoke LACP master's tx
+* burst function at least once every 100 ms.
+*/
+   loop_count++;
+   if (likely(loop_count % 1024 != 0))
+   continue;
+   for (sm_id = 0; sm_id < nb_fs; sm_id++) {
+   struct fwd_stream *fs = fsm[sm_id];
+
+   if (port_is_lacp_master(fs->tx_port))
+   rte_eth_tx_burst(fs->tx_port, fs->tx_queue,
+NULL, 0);
+   }
} while (! fc->stopped);
 }

@@ -1881,6 +1897,27 @@ uint8_t port_is_bonding_slave(portid_t slave_pid)
return port->slave_flag;
 }

+void set_port_lacp_master(portid_t pid)
+{
+   struct rte_port *port = [pid];
+
+   port->lacp_master = 1;
+}
+
+void clear_port_lacp_master(portid_t pid)
+{
+   struct rte_port *port = [pid];
+
+   port->lacp_master = 0;
+}
+
+uint8_t port_is_lacp_master(portid_t pid)
+{
+   struct rte_port *port = [pid];
+
+   return port->lacp_master;
+}
+
 const uint16_t vlan_tags[] = {
0,  1,  2,  3,  4,  5,  6,  7,
8,  9, 10, 11,  12, 13, 14, 15,
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 2b281cc..0898194 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -170,6 +170,7 @@ struct rte_port {
struct ether_addr   *mc_addr_pool; /**< pool of multicast addrs */
uint32_tmc_addr_nb; /**< nb. of addr. in mc_addr_pool */
uint8_t slave_flag; /**< bonding slave port */
+   uint8_t lacp_master;/**< bonding LACP master */
 };

 extern portid_t __rte_unused
@@ -542,6 +543,9 @@ void init_port_config(void);
 void set_port_slave_flag(portid_t slave_pid);
 void clear_port_slave_flag(portid_t slave_pid);
 uint8_t port_is_bonding_slave(portid_t slave_pid);
+void set_port_lacp_master(portid_t pid);
+void clear_port_lacp_master(portid_t pid);
+uint8_t port_is_lacp_master(portid_t pid);

 int init_port_dcb_config(portid_t pid, enum dcb_mode_enable dcb_mode,
 enum rte_eth_nb_tcs num_tcs,
-- 
1.7.1



[dpdk-dev] [PATCH 0/4] net/bonding: bonding and LACP fixes

2016-08-01 Thread Robert Sanford
In this patch series, we fix two bonding driver bugs and
enhance testpmd so that bonding mode 4 (LACP) ports remain
operational even when idle.

1. Problem: testpmd does not call bonding mode 4 (LACP) ports' tx
   burst function at least every 100 ms, as mandated.
   Solution: Enhance testpmd's packet forwarding loop to infrequently
   invoke the tx burst API for bonding ports in mode 4, to transmit
   LACPDUs to the partner in a timely manner.
2. Problem: Bonding driver (item 3 below) needs to know how many
   objects may become cached in a memory pool. Solution: Rename
   macros that calculate a mempool cache flush threshold, and move
   them from rte_mempool.c to rte_mempool.h.
3. Problem: With little or no tx traffic, LACP tx machine may run out
   of mbufs. Solution: When calculating the minimum number of mbufs
   required in a bonding mode 4 slave's private (tx LACPDU) pool,
   include the maximum number of mbufs that may be cached in the
   pool's per-core caches.
4. Problem: When configuring a bonding device, we don't properly
   propagate most of the settings from the master to the slaves.
   Solution: Fix slave_configure() to correctly pass configuration
   data to rte_eth_dev_configure() on behalf of the slaves.

Notes for configuring and running testpmd: We specify four ethernet
devices in the arguments, because testpmd expects an even number.
We configure two devices to be slaves under one bonded device, one
device to be the other side of the forwarding bridge, and we ignore
the fourth eth dev.

 +-++---+ ++
 |client A |<==>|DPDK   | ||
 |bonded device||testpmd|<===>|client B|
 |with 2 slaves|<==>|   | ||
 +-++---+ ++

To reproduce the out of buffers problem (#3), apply patch 1/4, run
testpmd (with example args and commands shown below), and run ping
from client A, like this: "ping -i18 -c10 clientB". After about five
minutes, one of the slaves will run out of LACPDU mbufs.

Example testpmd args:

  ./testpmd -c 0x0555 -n 2 \
--log-level 7 \
--pci-whitelist "01:00.0" \
--pci-whitelist "01:00.1" \
--pci-whitelist "05:00.0" \
--pci-whitelist "84:00.0" \
--master-lcore 0 -- \
--interactive --portmask=0xf --numa --socket-num=0 --auto-start \
--coremask=0x0554 --rxd=512 --txd=256 \
--burst=32 --mbcache=64 \
--nb-cores=2 --rxq=1 --txq=1

Example testpmd commands to reconfigure into bonding mode 4:

  stop
  port stop all
  create bonded device 4 0
  add bonding slave 2 4
  add bonding slave 3 4
  port start 0
  port start 1
  port start 4
  set portlist 4,0
  start

Robert Sanford (4):
  testpmd: fix LACP ports to work with idle links
  mempool: make cache flush threshold macro public
  net/bonding: another fix to LACP mempool size
  net/bonding: fix configuration of LACP slaves

 app/test-pmd/cmdline.c|9 +++
 app/test-pmd/testpmd.c|   37 +
 app/test-pmd/testpmd.h|4 +++
 drivers/net/bonding/rte_eth_bond_8023ad.c |   10 +--
 drivers/net/bonding/rte_eth_bond_pmd.c|   28 +
 lib/librte_mempool/rte_mempool.c  |8 +
 lib/librte_mempool/rte_mempool.h  |7 +
 7 files changed, 73 insertions(+), 30 deletions(-)



[dpdk-dev] [PATCH v6 05/17] eal: introduce init macros

2016-08-01 Thread Shreyansh Jain
Hi Jan,

On Saturday 30 July 2016 01:44 PM, Jan Viktorin wrote:
> On Thu, 28 Jul 2016 15:06:10 +0530
> Shreyansh Jain  wrote:
> 
>> Hi Jan,
>>
>> On Friday 15 July 2016 04:18 PM, Shreyansh jain wrote:
>>> On Thursday 14 July 2016 09:27 PM, Jan Viktorin wrote:  
> 
> [...]
> 
>>> (drv).name = RTE_STR(nm);
>
> That is a miss from my side.
> I will publish v7 with this. You want this right away or should I wait a 
> little while (more reviews, or any pending additions as per Thomas's 
> notes) before publishing?  

 Please. The time is almost gone. 18/7/2016 is the release (according
 to the roadmap)... I have to fix it in my patchset, otherwise it
 does not build (after moving the .name from rte_pci_driver to
 rte_driver).
  
>>>
>>> I didn't consider 18/Jul.
>>> Please go ahead. I will continue to send v7 _without_ the above change so 
>>> that your patchset doesn't break. This way you will not get blocked because 
>>> of me.
>>>   
>>
>> Now that we have already skipped the 16.07, I will fix this in my code and 
>> release an updated version as soon as 16.07 is officially available. Is that 
>> OK?
> 
> Sure :). The thing is that during August-September, I've got significantly
> less time for this then in June-July :/. That's why I was trying to fit in
> the 16.07.

Well, then lets try and get things out for review as soon as we can.
I have sent across v7 of rte_driver set.
Unfortunately, I forgot to add your sign-off. If the set works for you, can you 
bulk ack?

> 
>>
>> Also, I have fixed most review comments except [1]. I am still not sure of 
>> the impact of this change. So, I will publish the v7 without this and then 
>> probably a v8 in case this change has any impact.
> 
> I have no idea about this. Hopefully, it's not a very serious thing.
> 
>> That way we can have your patchset not blocked because of this series.
> 
> Thank you!
> 
>>
>> [1] http://dpdk.org/ml/archives/dev/2016-July/044004.html
> 
>>
>> [...]
>>
>>
>> -
>> Shreyansh
> 
> 
> 



[dpdk-dev] [PATCH] validate_abi: build faster by augmenting make with job count

2016-08-01 Thread Wiles, Keith

>> Neil
>> 
> Sorry for the delayed response, I've been on vacation.
> 
>> Your modified copy of make has no bearing on the topic we are taking about 
>> customers using dpdk in standard distros right?
>> 
> !?  I really don't know what you're saying here.  My only reason for 
> commenting
> on my copy of make was to consider an explination for why make -j 0 might be
> working for me, and not for you.  I've since uninstalled and resinalled make 
> on
> my system, and my copy now behaves as yours does
> 
> But thats all really irrelevant.  I don't know what you mean by this not 
> having
> any bearing on the conversation since we're talking about customers using dpdk
> in a distro.  We're not really talking about that at all (if we were using 
> make
> would be a moot point, since distro users tend to only use pre-compiled
> binaries).  Were talking about accelerating the build process when comparing
> ABIs on two different dpdk versions, thats all.

Neil, (I am trying to not read your style of text as condescending and I will 
try to not do that as well)

Not everyone uses DPDK from prebuilt libraries and we need to support them as 
well, correct?

> 
>> Seems odd to me to send this out with 0 or lspci as it may fail because of 
>> no lspci and will fail on all Ubuntu systems. 
>> 
> Again, don't really understand what your saying.  If you look at the patch,
> neither of your assertions are true.  With this patch and no other change, the
> validate_abi script behaves exactly as it does now.  The only thing I've done 
> is
> add a check for the DPDK_MAKE_JOBS environment variable, and if its not set,
> either:
> 
> a) Set DPDK_MAKE_JOBS to 1 if lscpu doesn't exist on the system
> b) Set DPDK_MAKE_JOBS to the number of online cpus if lscpu does exist
> 
> All of that gets overridden if you manually set DPDK_MAKE_JOBS to something
> else.
> 
> seems pretty straightforward to me.

At this point do we need to add yet another environment variable to get the 
correct behavior with DPDK. DPDK is very simple to build today and I worry we 
keep adding special variables to build DPDK. Can we just use a cleaner default, 
then adding more and more special build requirements? Adding this one is fine, 
but it also means the customer must read the docs to find this new variable.

DPDK should be build able with the least amount of docs to read, then they can 
read the docs more later. Just looking at how the developer can get started 
building DPDK without RTFM problem. At some point they need to read the docs to 
possibly runs the examples, but to build DPDK should very simple IMO.

> 
>> If we ship with 1 then why even bother the adding code and if I have to edit 
>> the file or some other method to get better compile performance then why 
>> bother as well.
>> 
> Please stop and think for a minute.  Why would you need to edit a file to 
> change
> anything?  If lscpu exists, then everything happens automatically.  If it
> doesn't you can still just run:
> export DPDK_MAKE_JOBS=$BIGNUMBER; validate_abi.sh 

Please do not add extra environment variable we would start to get to the point 
of having so many pre-build requirements it becomes the private knowledge to 
just build DPDK or a huge setup/RTFM problem.

> 
> and it works fine.  If ubuntu has some other utiilty besides lscpu to parse 
> cpu
> counts, fine, we can add that in as a feature, but I don't see why that should
> stop other, non-ubuntu systems from taking advantage of this.
> 
>> Setting the value to some large number does not make any sense to me and if 
>> I have to edit file every time or maintain a patch just seems silly. 
>> 
> Goodness Keith, stop for just a minute with the editing the file train your 
> on.
> Its an environment variable, you don't have to edit a file to change it.

Yes Neil, you also need to stop an think about what you are placing on the 
developer to build DPDK. This one little problem is not the real issue to me, 
but a symptom of a growing problem in DPDK around how DPDK is build and the 
amount of knowledge or setup it requires to do this one simple task.

> 
>> It just seems easier to set it to -j and not use lspci at all. This way we 
>> all win as I am not following your logic at all.
>> 
> This doesn't even make any sense.  If you set it to -j then you get make 
> issuing
> jobs at the max rate make can issue them, which is potentially fine, but may 
> not
> be what developers want in the event they don't want this script to monopolize
> their system.  The way its written now lets people get reasonable behavior in
> most cases, and opt-in to the extreeme case should they desire.  That makes 
> far
> more sense to me, then just chewing up as much cpu as possible all the time.

I only suggest -j as this would give the developer the best build performance 
without having to require lscpu or setting up yet another build environment 
variable. The lscpu command does not exist on all systems today and other 
non-Linux based 

[dpdk-dev] [PATCH v7 17/17] ethdev: get rid of device type

2016-08-01 Thread Shreyansh Jain
Now that hotplug has been moved to eal, there is no reason to keep the device
type in this layer.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 app/test/virtual_pmd.c|  2 +-
 drivers/net/af_packet/rte_eth_af_packet.c |  2 +-
 drivers/net/bonding/rte_eth_bond_api.c|  2 +-
 drivers/net/cxgbe/cxgbe_main.c|  2 +-
 drivers/net/mlx4/mlx4.c   |  2 +-
 drivers/net/mlx5/mlx5.c   |  2 +-
 drivers/net/mpipe/mpipe_tilegx.c  |  2 +-
 drivers/net/null/rte_eth_null.c   |  2 +-
 drivers/net/pcap/rte_eth_pcap.c   |  2 +-
 drivers/net/ring/rte_eth_ring.c   |  2 +-
 drivers/net/vhost/rte_eth_vhost.c |  2 +-
 drivers/net/virtio/virtio_user_ethdev.c   |  2 +-
 drivers/net/xenvirt/rte_eth_xenvirt.c |  2 +-
 examples/ip_pipeline/init.c   | 22 --
 lib/librte_ether/rte_ethdev.c |  5 ++---
 lib/librte_ether/rte_ethdev.h | 15 +--
 16 files changed, 16 insertions(+), 52 deletions(-)

diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index b4bd2f2..8a1f0d0 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -581,7 +581,7 @@ virtual_ethdev_create(const char *name, struct ether_addr 
*mac_addr,
goto err;

/* reserve an ethdev entry */
-   eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+   eth_dev = rte_eth_dev_allocate(name);
if (eth_dev == NULL)
goto err;

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
b/drivers/net/af_packet/rte_eth_af_packet.c
index f795566..d629ee3 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -666,7 +666,7 @@ rte_pmd_init_internals(const char *name,
}

/* reserve an ethdev entry */
-   *eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_VIRTUAL);
+   *eth_dev = rte_eth_dev_allocate(name);
if (*eth_dev == NULL)
goto error;

diff --git a/drivers/net/bonding/rte_eth_bond_api.c 
b/drivers/net/bonding/rte_eth_bond_api.c
index 203ebe9..8514652 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -189,7 +189,7 @@ rte_eth_bond_create(const char *name, uint8_t mode, uint8_t 
socket_id)
}

/* reserve an ethdev entry */
-   eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_VIRTUAL);
+   eth_dev = rte_eth_dev_allocate(name);
if (eth_dev == NULL) {
RTE_BOND_LOG(ERR, "Unable to allocate rte_eth_dev");
goto err;
diff --git a/drivers/net/cxgbe/cxgbe_main.c b/drivers/net/cxgbe/cxgbe_main.c
index ceaf5ab..922155b 100644
--- a/drivers/net/cxgbe/cxgbe_main.c
+++ b/drivers/net/cxgbe/cxgbe_main.c
@@ -1150,7 +1150,7 @@ int cxgbe_probe(struct adapter *adapter)
 */

/* reserve an ethdev entry */
-   pi->eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+   pi->eth_dev = rte_eth_dev_allocate(name);
if (!pi->eth_dev)
goto out_free;

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 2bed4de..b333ad6 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -5803,7 +5803,7 @@ mlx4_pci_devinit(struct rte_pci_driver *pci_drv, struct 
rte_pci_device *pci_dev)

snprintf(name, sizeof(name), "%s port %u",
 ibv_get_device_name(ibv_dev), port);
-   eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+   eth_dev = rte_eth_dev_allocate(name);
}
if (eth_dev == NULL) {
ERROR("can not allocate rte ethdev");
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 3658769..ebad7cb 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -617,7 +617,7 @@ mlx5_pci_devinit(struct rte_pci_driver *pci_drv, struct 
rte_pci_device *pci_dev)

snprintf(name, sizeof(name), "%s port %u",
 ibv_get_device_name(ibv_dev), port);
-   eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+   eth_dev = rte_eth_dev_allocate(name);
}
if (eth_dev == NULL) {
ERROR("can not allocate rte ethdev");
diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index 93f8730..c0d0e3b 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -1587,7 +1587,7 @@ rte_pmd_mpipe_devinit(const char *ifname,
return -ENODEV;
}

-   eth_dev = rte_eth_dev_allocate(ifname, RTE_ETH_DEV_VIRTUAL);
+   eth_dev = rte_eth_dev_allocate(ifname);
if (!eth_dev) {
RTE_LOG(ERR, PMD, "%s: Failed to allocate device.\n", ifname);
 

[dpdk-dev] [PATCH v7 16/17] ethdev: convert to eal hotplug

2016-08-01 Thread Shreyansh Jain
Remove bus logic from ethdev hotplug by using eal for this.

Current api is preserved:
- the last port that has been created is tracked to return it to the
  application when attaching,
- the internal device name is reused when detaching.

We can not get rid of ethdev hotplug yet since we still need some mechanism
to inform applications of port creation/removal to substitute for ethdev
hotplug api.

dev_type field in struct rte_eth_dev and rte_eth_dev_allocate are kept as
is, but this information is not needed anymore and is removed in the following
commit.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_ether/rte_ethdev.c | 208 +++---
 1 file changed, 34 insertions(+), 174 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index fdeac86..86c9d1a 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -72,6 +72,7 @@
 static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
 struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
 static struct rte_eth_dev_data *rte_eth_dev_data;
+static uint8_t eth_dev_last_created_port;
 static uint8_t nb_ports;

 /* spinlock for eth device callbacks */
@@ -216,6 +217,7 @@ rte_eth_dev_allocate(const char *name, enum 
rte_eth_dev_type type)
eth_dev->data->port_id = port_id;
eth_dev->attached = DEV_ATTACHED;
eth_dev->dev_type = type;
+   eth_dev_last_created_port = port_id;
nb_ports++;
return eth_dev;
 }
@@ -347,27 +349,6 @@ rte_eth_dev_count(void)
return nb_ports;
 }

-static enum rte_eth_dev_type
-rte_eth_dev_get_device_type(uint8_t port_id)
-{
-   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, RTE_ETH_DEV_UNKNOWN);
-   return rte_eth_devices[port_id].dev_type;
-}
-
-static int
-rte_eth_dev_get_addr_by_port(uint8_t port_id, struct rte_pci_addr *addr)
-{
-   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
-
-   if (addr == NULL) {
-   RTE_PMD_DEBUG_TRACE("Null pointer is specified\n");
-   return -EINVAL;
-   }
-
-   *addr = rte_eth_devices[port_id].pci_dev->addr;
-   return 0;
-}
-
 int
 rte_eth_dev_get_name_by_port(uint8_t port_id, char *name)
 {
@@ -413,34 +394,6 @@ rte_eth_dev_get_port_by_name(const char *name, uint8_t 
*port_id)
 }

 static int
-rte_eth_dev_get_port_by_addr(const struct rte_pci_addr *addr, uint8_t *port_id)
-{
-   int i;
-   struct rte_pci_device *pci_dev = NULL;
-
-   if (addr == NULL) {
-   RTE_PMD_DEBUG_TRACE("Null pointer is specified\n");
-   return -EINVAL;
-   }
-
-   *port_id = RTE_MAX_ETHPORTS;
-
-   for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
-
-   pci_dev = rte_eth_devices[i].pci_dev;
-
-   if (pci_dev &&
-   !rte_eal_compare_pci_addr(_dev->addr, addr)) {
-
-   *port_id = i;
-
-   return 0;
-   }
-   }
-   return -ENODEV;
-}
-
-static int
 rte_eth_dev_is_detachable(uint8_t port_id)
 {
uint32_t dev_flags;
@@ -465,124 +418,46 @@ rte_eth_dev_is_detachable(uint8_t port_id)
return 1;
 }

-/* attach the new physical device, then store port_id of the device */
-static int
-rte_eth_dev_attach_pdev(struct rte_pci_addr *addr, uint8_t *port_id)
-{
-   /* Invoke probe func of the driver can handle the new device. */
-   if (rte_eal_pci_probe_one(addr))
-   goto err;
-
-   if (rte_eth_dev_get_port_by_addr(addr, port_id))
-   goto err;
-
-   return 0;
-err:
-   return -1;
-}
-
-/* detach the new physical device, then store pci_addr of the device */
-static int
-rte_eth_dev_detach_pdev(uint8_t port_id, struct rte_pci_addr *addr)
-{
-   struct rte_pci_addr freed_addr;
-   struct rte_pci_addr vp;
-
-   /* get pci address by port id */
-   if (rte_eth_dev_get_addr_by_port(port_id, _addr))
-   goto err;
-
-   /* Zeroed pci addr means the port comes from virtual device */
-   vp.domain = vp.bus = vp.devid = vp.function = 0;
-   if (rte_eal_compare_pci_addr(, _addr) == 0)
-   goto err;
-
-   /* invoke devuninit func of the pci driver,
-* also remove the device from pci_device_list */
-   if (rte_eal_pci_detach(_addr))
-   goto err;
-
-   *addr = freed_addr;
-   return 0;
-err:
-   return -1;
-}
-
-/* attach the new virtual device, then store port_id of the device */
-static int
-rte_eth_dev_attach_vdev(const char *vdevargs, uint8_t *port_id)
-{
-   char *name = NULL, *args = NULL;
-   int ret = -1;
-
-   /* parse vdevargs, then retrieve device name and args */
-   if (rte_eal_parse_devargs_str(vdevargs, , ))
-   goto end;
-
-   /* walk around dev_driver_list to find the driver of the device,
-* then invoke probe function of the driver.
-* rte_eal_vdev_init() updates port_id 

[dpdk-dev] [PATCH v7 15/17] eal: add hotplug operations for pci and vdev

2016-08-01 Thread Shreyansh Jain
Hotplug invocations, which deals with devices, should come from the layer that
already handles them, i.e. EAL.

For both attach and detach operations, 'name' is used to select the bus
that will handle the request.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  7 
 lib/librte_eal/common/eal_common_dev.c  | 48 +
 lib/librte_eal/common/include/rte_dev.h | 26 ++
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |  7 
 4 files changed, 88 insertions(+)

diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map 
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index a335e04..7b3d409 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -162,3 +162,10 @@ DPDK_16.07 {
rte_thread_setname;

 } DPDK_16.04;
+
+DPDK_16.11 {
+   global:
+
+   rte_eal_dev_attach;
+   rte_eal_dev_detach;
+} DPDK_16.07;
diff --git a/lib/librte_eal/common/eal_common_dev.c 
b/lib/librte_eal/common/eal_common_dev.c
index a8a4146..88f9d3f 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -150,3 +150,51 @@ rte_eal_vdev_uninit(const char *name)
RTE_LOG(ERR, EAL, "no driver found for %s\n", name);
return -EINVAL;
 }
+
+int rte_eal_dev_attach(const char *name, const char *devargs)
+{
+   struct rte_pci_addr addr;
+
+   if (name == NULL || devargs == NULL) {
+   RTE_LOG(ERR, EAL, "Invalid device or arguments provided\n");
+   return -EINVAL;
+   }
+
+   if (eal_parse_pci_DomBDF(name, ) == 0) {
+   if (rte_eal_pci_probe_one() < 0)
+   goto err;
+
+   } else {
+   if (rte_eal_vdev_init(name, devargs))
+   goto err;
+   }
+
+   return 0;
+
+err:
+   RTE_LOG(ERR, EAL, "Driver cannot attach the device (%s)\n", name);
+   return -EINVAL;
+}
+
+int rte_eal_dev_detach(const char *name)
+{
+   struct rte_pci_addr addr;
+
+   if (name == NULL) {
+   RTE_LOG(ERR, EAL, "Invalid device provided.\n");
+   return -EINVAL;
+   }
+
+   if (eal_parse_pci_DomBDF(name, ) == 0) {
+   if (rte_eal_pci_detach() < 0)
+   goto err;
+   } else {
+   if (rte_eal_vdev_uninit(name))
+   goto err;
+   }
+   return 0;
+
+err:
+   RTE_LOG(ERR, EAL, "Driver cannot detach the device (%s)\n", name);
+   return -EINVAL;
+}
diff --git a/lib/librte_eal/common/include/rte_dev.h 
b/lib/librte_eal/common/include/rte_dev.h
index 994650b..a4f08b5 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -178,6 +178,32 @@ int rte_eal_vdev_init(const char *name, const char *args);
  */
 int rte_eal_vdev_uninit(const char *name);

+/**
+ * Attach a device to a registered driver.
+ *
+ * @param name
+ *   The device name, that refers to a pci device (or some private
+ *   way of designating a vdev device). Based on this device name, eal
+ *   will identify a driver capable of handling it and pass it to the
+ *   driver probing function.
+ * @param devargs
+ *   Device arguments to be passed to the driver.
+ * @return
+ *   0 on success, negative on error.
+ */
+int rte_eal_dev_attach(const char *name, const char *devargs);
+
+/**
+ * Detach a device from its driver.
+ *
+ * @param name
+ *   Same description as for rte_eal_dev_attach().
+ *   Here, eal will call the driver detaching function.
+ * @return
+ *   0 on success, negative on error.
+ */
+int rte_eal_dev_detach(const char *name);
+
 #define DRIVER_EXPORT_NAME_ARRAY(n, idx) n##idx[]

 #define DRIVER_EXPORT_NAME(name, idx) \
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map 
b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index db8c984..c0bd391 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -166,3 +166,10 @@ DPDK_16.07 {
rte_thread_setname;

 } DPDK_16.04;
+
+DPDK_16.11 {
+   global:
+
+   rte_eal_dev_attach;
+   rte_eal_dev_detach;
+} DPDK_16.07;
-- 
2.7.4



[dpdk-dev] [PATCH v7 14/17] ethdev: do not scan all pci devices on attach

2016-08-01 Thread Shreyansh Jain
No need to scan all devices, we only need to update the device being
attached.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/common/eal_common_pci.c | 11 ---
 lib/librte_ether/rte_ethdev.c  |  3 ---
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_pci.c 
b/lib/librte_eal/common/eal_common_pci.c
index 6a0f6ac..da0038f 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -341,6 +341,11 @@ rte_eal_pci_probe_one(const struct rte_pci_addr *addr)
if (addr == NULL)
return -1;

+   /* update current pci device in global list, kernel bindings might have
+* changed since last time we looked at it */
+   if (pci_update_device(addr) < 0)
+   goto err_return;
+
TAILQ_FOREACH(dev, _device_list, next) {
if (rte_eal_compare_pci_addr(>addr, addr))
continue;
@@ -353,9 +358,9 @@ rte_eal_pci_probe_one(const struct rte_pci_addr *addr)
return -1;

 err_return:
-   RTE_LOG(WARNING, EAL, "Requested device " PCI_PRI_FMT
-   " cannot be used\n", dev->addr.domain, dev->addr.bus,
-   dev->addr.devid, dev->addr.function);
+   RTE_LOG(WARNING, EAL,
+   "Requested device " PCI_PRI_FMT " cannot be used\n",
+   addr->domain, addr->bus, addr->devid, addr->function);
return -1;
 }

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a1bb043..fdeac86 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -469,9 +469,6 @@ rte_eth_dev_is_detachable(uint8_t port_id)
 static int
 rte_eth_dev_attach_pdev(struct rte_pci_addr *addr, uint8_t *port_id)
 {
-   /* re-construct pci_device_list */
-   if (rte_eal_pci_scan())
-   goto err;
/* Invoke probe func of the driver can handle the new device. */
if (rte_eal_pci_probe_one(addr))
goto err;
-- 
2.7.4



[dpdk-dev] [PATCH v7 13/17] pci: add a helper to update a device

2016-08-01 Thread Shreyansh Jain
This helper updates a pci device object with latest information it can
find.
It will be used mainly for hotplug code.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/bsdapp/eal/eal_pci.c   | 49 +++
 lib/librte_eal/common/eal_private.h   | 13 ++
 lib/librte_eal/linuxapp/eal/eal_pci.c | 13 ++
 3 files changed, 75 insertions(+)

diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c 
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index a73cbb0..1d91c78 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -406,6 +406,55 @@ error:
return -1;
 }

+int
+pci_update_device(const struct rte_pci_addr *addr)
+{
+   int fd;
+   struct pci_conf matches[2];
+   struct pci_match_conf match = {
+   .pc_sel = {
+   .pc_domain = addr->domain,
+   .pc_bus = addr->bus,
+   .pc_dev = addr->devid,
+   .pc_func = addr->function,
+   },
+   };
+   struct pci_conf_io conf_io = {
+   .pat_buf_len = 0,
+   .num_patterns = 1,
+   .patterns = ,
+   .match_buf_len = sizeof(matches),
+   .matches = [0],
+   };
+
+   fd = open("/dev/pci", O_RDONLY);
+   if (fd < 0) {
+   RTE_LOG(ERR, EAL, "%s(): error opening /dev/pci\n", __func__);
+   goto error;
+   }
+
+   if (ioctl(fd, PCIOCGETCONF, _io) < 0) {
+   RTE_LOG(ERR, EAL, "%s(): error with ioctl on /dev/pci: %s\n",
+   __func__, strerror(errno));
+   goto error;
+   }
+
+   if (conf_io.num_matches != 1)
+   goto error;
+
+   if (pci_scan_one(fd, [0]) < 0)
+   goto error;
+
+   close(fd);
+
+   return 0;
+
+error:
+   if (fd >= 0)
+   close(fd);
+   return -1;
+}
+
 /* Read PCI config space. */
 int rte_eal_pci_read_config(const struct rte_pci_device *dev,
void *buf, size_t len, off_t offset)
diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index 06a68f6..b8ff9c5 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -152,6 +152,19 @@ struct rte_pci_driver;
 struct rte_pci_device;

 /**
+ * Update a pci device object by asking the kernel for the latest information.
+ *
+ * This function is private to EAL.
+ *
+ * @param addr
+ * The PCI Bus-Device-Function address to look for
+ * @return
+ *   - 0 on success.
+ *   - negative on error.
+ */
+int pci_update_device(const struct rte_pci_addr *addr);
+
+/**
  * Unbind kernel driver for this device
  *
  * This function is private to EAL.
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index f0215ee..62da4d4 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -417,6 +417,19 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t 
bus,
return 0;
 }

+int
+pci_update_device(const struct rte_pci_addr *addr)
+{
+   char filename[PATH_MAX];
+
+   snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT,
+pci_get_sysfs_path(), addr->domain, addr->bus, addr->devid,
+addr->function);
+
+   return pci_scan_one(filename, addr->domain, addr->bus, addr->devid,
+   addr->function);
+}
+
 /*
  * split up a pci address into its constituent parts.
  */
-- 
2.7.4



[dpdk-dev] [PATCH v7 12/17] pci: add a helper for device name

2016-08-01 Thread Shreyansh Jain
Eal is a better place than crypto / ethdev to name devices.
Add a helper in eal and make use of it in crypto / ethdev.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_cryptodev/rte_cryptodev.c| 27 ---
 lib/librte_eal/common/include/rte_pci.h | 26 ++
 lib/librte_ether/rte_ethdev.c   | 24 
 3 files changed, 34 insertions(+), 43 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index 2a3b649..c81e366 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -365,23 +365,6 @@ rte_cryptodev_pmd_allocate(const char *name, int socket_id)
return cryptodev;
 }

-static inline int
-rte_cryptodev_create_unique_device_name(char *name, size_t size,
-   struct rte_pci_device *pci_dev)
-{
-   int ret;
-
-   if ((name == NULL) || (pci_dev == NULL))
-   return -EINVAL;
-
-   ret = snprintf(name, size, "%d:%d.%d",
-   pci_dev->addr.bus, pci_dev->addr.devid,
-   pci_dev->addr.function);
-   if (ret < 0)
-   return ret;
-   return 0;
-}
-
 int
 rte_cryptodev_pmd_release_device(struct rte_cryptodev *cryptodev)
 {
@@ -444,9 +427,8 @@ rte_cryptodev_pci_probe(struct rte_pci_driver *pci_drv,
if (cryptodrv == NULL)
return -ENODEV;

-   /* Create unique Crypto device name using PCI address */
-   rte_cryptodev_create_unique_device_name(cryptodev_name,
-   sizeof(cryptodev_name), pci_dev);
+   rte_eal_pci_device_name(_dev->addr, cryptodev_name,
+   sizeof(cryptodev_name));

cryptodev = rte_cryptodev_pmd_allocate(cryptodev_name, rte_socket_id());
if (cryptodev == NULL)
@@ -501,9 +483,8 @@ rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
if (pci_dev == NULL)
return -EINVAL;

-   /* Create unique device name using PCI address */
-   rte_cryptodev_create_unique_device_name(cryptodev_name,
-   sizeof(cryptodev_name), pci_dev);
+   rte_eal_pci_device_name(_dev->addr, cryptodev_name,
+   sizeof(cryptodev_name));

cryptodev = rte_cryptodev_pmd_get_named_dev(cryptodev_name);
if (cryptodev == NULL)
diff --git a/lib/librte_eal/common/include/rte_pci.h 
b/lib/librte_eal/common/include/rte_pci.h
index ffeb94c..9eea092 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -82,6 +82,7 @@ extern "C" {
 #include 
 #include 

+#include 
 #include 

 TAILQ_HEAD(pci_device_list, rte_pci_device); /**< PCI devices in D-linked Q. */
@@ -95,6 +96,7 @@ const char *pci_get_sysfs_path(void);

 /** Formatting string for PCI device identifier: Ex: :00:01.0 */
 #define PCI_PRI_FMT "%.4" PRIx16 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
+#define PCI_PRI_STR_SIZE sizeof(":XX:XX.X")

 /** Short formatting string, without domain, for PCI device: Ex: 00:01.0 */
 #define PCI_SHORT_PRI_FMT "%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
@@ -308,6 +310,30 @@ eal_parse_pci_DomBDF(const char *input, struct 
rte_pci_addr *dev_addr)
 }
 #undef GET_PCIADDR_FIELD

+/**
+ * Utility function to write a pci device name, this device name can later be
+ * used to retrieve the corresponding rte_pci_addr using eal_parse_pci_*
+ * BDF helpers.
+ *
+ * @param addr
+ * The PCI Bus-Device-Function address
+ * @param output
+ * The output buffer string
+ * @param size
+ * The output buffer size
+ * @return
+ *  0 on success, negative on error.
+ */
+static inline void
+rte_eal_pci_device_name(const struct rte_pci_addr *addr,
+   char *output, size_t size)
+{
+   RTE_VERIFY(size >= PCI_PRI_STR_SIZE);
+   RTE_VERIFY(snprintf(output, size, PCI_PRI_FMT,
+   addr->domain, addr->bus,
+   addr->devid, addr->function) >= 0);
+}
+
 /* Compare two PCI device addresses. */
 /**
  * Utility function to compare two PCI device addresses.
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 3bccf20..a1bb043 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -220,20 +220,6 @@ rte_eth_dev_allocate(const char *name, enum 
rte_eth_dev_type type)
return eth_dev;
 }

-static int
-rte_eth_dev_create_unique_device_name(char *name, size_t size,
-   struct rte_pci_device *pci_dev)
-{
-   int ret;
-
-   ret = snprintf(name, size, "%d:%d.%d",
-   pci_dev->addr.bus, pci_dev->addr.devid,
-   pci_dev->addr.function);
-   if (ret < 0)
-   return ret;
-   return 0;
-}
-
 int
 rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
 {
@@ -257,9 +243,8 @@ rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,

eth_drv = (struct eth_driver *)pci_drv;

-   

[dpdk-dev] [PATCH v7 11/17] eal/linux: move back interrupt thread init before setting affinity

2016-08-01 Thread Shreyansh Jain
Now that virtio pci driver is initialized in a constructor, iopl() stuff
happens early enough so that interrupt thread can be created right after
plugin loading.
This way, chelsio driver should be happy again [1].

[1] http://dpdk.org/ml/archives/dev/2015-November/028289.html

Signed-off-by: David Marchand 
Tested-by: Rahul Lakkireddy 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/linuxapp/eal/eal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index fe9c704..259a7e4 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -834,6 +834,9 @@ rte_eal_init(int argc, char **argv)
if (eal_plugins_init() < 0)
rte_panic("Cannot init plugins\n");

+   if (rte_eal_intr_init() < 0)
+   rte_panic("Cannot init interrupt-handling thread\n");
+
eal_thread_init_master(rte_config.master_lcore);

ret = eal_thread_dump_affinity(cpuset, RTE_CPU_AFFINITY_STR_LEN);
@@ -845,9 +848,6 @@ rte_eal_init(int argc, char **argv)
if (rte_eal_dev_init() < 0)
rte_panic("Cannot init pmd devices\n");

-   if (rte_eal_intr_init() < 0)
-   rte_panic("Cannot init interrupt-handling thread\n");
-
RTE_LCORE_FOREACH_SLAVE(i) {

/*
-- 
2.7.4



[dpdk-dev] [PATCH v7 10/17] ethdev: get rid of eth driver register callback

2016-08-01 Thread Shreyansh Jain
Now that all pdev are pci drivers, we don't need to register ethdev drivers
through a dedicated channel.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_ether/rte_ethdev.c | 22 --
 lib/librte_ether/rte_ethdev.h | 12 
 2 files changed, 34 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 8825219..3bccf20 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -340,28 +340,6 @@ rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev)
return 0;
 }

-/**
- * Register an Ethernet [Poll Mode] driver.
- *
- * Function invoked by the initialization function of an Ethernet driver
- * to simultaneously register itself as a PCI driver and as an Ethernet
- * Poll Mode Driver.
- * Invokes the rte_eal_pci_register() function to register the *pci_drv*
- * structure embedded in the *eth_drv* structure, after having stored the
- * address of the rte_eth_dev_init() function in the *devinit* field of
- * the *pci_drv* structure.
- * During the PCI probing phase, the rte_eth_dev_init() function is
- * invoked for each PCI [Ethernet device] matching the embedded PCI
- * identifiers provided by the driver.
- */
-void
-rte_eth_driver_register(struct eth_driver *eth_drv)
-{
-   eth_drv->pci_drv.devinit = rte_eth_dev_pci_probe;
-   eth_drv->pci_drv.devuninit = rte_eth_dev_pci_remove;
-   rte_eal_pci_register(_drv->pci_drv);
-}
-
 int
 rte_eth_dev_is_valid_port(uint8_t port_id)
 {
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 37d78bf..b005c1b 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1871,18 +1871,6 @@ struct eth_driver {
 };

 /**
- * @internal
- * A function invoked by the initialization function of an Ethernet driver
- * to simultaneously register itself as a PCI driver and as an Ethernet
- * Poll Mode Driver (PMD).
- *
- * @param eth_drv
- *   The pointer to the *eth_driver* structure associated with
- *   the Ethernet driver.
- */
-void rte_eth_driver_register(struct eth_driver *eth_drv);
-
-/**
  * Convert a numerical speed in Mbps to a bitmap flag that can be used in
  * the bitmap link_speeds of the struct rte_eth_conf
  *
-- 
2.7.4



[dpdk-dev] [PATCH v7 09/17] crypto: get rid of crypto driver register callback

2016-08-01 Thread Shreyansh Jain
Now that all pdev are pci drivers, we don't need to register crypto drivers
through a dedicated channel.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_cryptodev/rte_cryptodev.c   | 22 ---
 lib/librte_cryptodev/rte_cryptodev_pmd.h   | 30 --
 lib/librte_cryptodev/rte_cryptodev_version.map |  1 -
 3 files changed, 53 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index b1e82b6..2a3b649 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -533,28 +533,6 @@ rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
return 0;
 }

-int
-rte_cryptodev_pmd_driver_register(struct rte_cryptodev_driver *cryptodrv,
-   enum pmd_type type)
-{
-   /* Call crypto device initialization directly if device is virtual */
-   if (type == PMD_VDEV)
-   return rte_cryptodev_pci_probe((struct rte_pci_driver 
*)cryptodrv,
-   NULL);
-
-   /*
-* Register PCI driver for physical device intialisation during
-* PCI probing
-*/
-   cryptodrv->pci_drv.devinit = rte_cryptodev_pci_probe;
-   cryptodrv->pci_drv.devuninit = rte_cryptodev_pci_remove;
-
-   rte_eal_pci_register(>pci_drv);
-
-   return 0;
-}
-
-
 uint16_t
 rte_cryptodev_queue_pair_count(uint8_t dev_id)
 {
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 3fb7c7c..99fd69e 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -491,36 +491,6 @@ rte_cryptodev_pmd_virtual_dev_init(const char *name, 
size_t dev_private_size,
 extern int
 rte_cryptodev_pmd_release_device(struct rte_cryptodev *cryptodev);

-
-/**
- * Register a Crypto [Poll Mode] driver.
- *
- * Function invoked by the initialization function of a Crypto driver
- * to simultaneously register itself as Crypto Poll Mode Driver and to either:
- *
- * a - register itself as PCI driver if the crypto device is a physical
- * device, by invoking the rte_eal_pci_register() function to
- * register the *pci_drv* structure embedded in the *crypto_drv*
- * structure, after having stored the address of the
- * rte_cryptodev_init() function in the *devinit* field of the
- * *pci_drv* structure.
- *
- * During the PCI probing phase, the rte_cryptodev_init()
- * function is invoked for each PCI [device] matching the
- * embedded PCI identifiers provided by the driver.
- *
- * b, complete the initialization sequence if the device is a virtual
- * device by calling the rte_cryptodev_init() directly passing a
- * NULL parameter for the rte_pci_device structure.
- *
- *   @param crypto_drv crypto_driver structure associated with the crypto
- * driver.
- *   @param type   pmd type
- */
-extern int
-rte_cryptodev_pmd_driver_register(struct rte_cryptodev_driver *crypto_drv,
-   enum pmd_type type);
-
 /**
  * Executes all the user application registered callbacks for the specific
  * device.
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map 
b/lib/librte_cryptodev/rte_cryptodev_version.map
index 1fc0d57..9627ac4 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -14,7 +14,6 @@ DPDK_16.04 {
rte_cryptodev_info_get;
rte_cryptodev_pmd_allocate;
rte_cryptodev_pmd_callback_process;
-   rte_cryptodev_pmd_driver_register;
rte_cryptodev_pmd_release_device;
rte_cryptodev_pmd_virtual_dev_init;
rte_cryptodev_sym_session_create;
-- 
2.7.4



[dpdk-dev] [PATCH v7 08/17] drivers: convert all pdev drivers as pci drivers

2016-08-01 Thread Shreyansh Jain
Simplify crypto and ethdev pci drivers init by using newly introduced
init macros and helpers.
Those drivers then don't need to register as "rte_driver"s anymore.

Exceptions:
- virtio and mlx* use RTE_INIT directly as they have custom initialization
  steps.
- VDEV devices are not modified - they continue to use PMD_REGISTER_DRIVER.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 drivers/crypto/qat/rte_qat_cryptodev.c  | 16 +++-
 drivers/net/bnx2x/bnx2x_ethdev.c| 34 +---
 drivers/net/bnxt/bnxt_ethdev.c  | 16 +++-
 drivers/net/cxgbe/cxgbe_ethdev.c| 24 +++--
 drivers/net/e1000/em_ethdev.c   | 16 +++-
 drivers/net/e1000/igb_ethdev.c  | 39 +---
 drivers/net/ena/ena_ethdev.c| 17 +++-
 drivers/net/enic/enic_ethdev.c  | 23 +++--
 drivers/net/fm10k/fm10k_ethdev.c| 23 +++--
 drivers/net/i40e/i40e_ethdev.c  | 24 +++--
 drivers/net/i40e/i40e_ethdev_vf.c   | 25 +++---
 drivers/net/ixgbe/ixgbe_ethdev.c| 46 +
 drivers/net/mlx4/mlx4.c | 15 +++
 drivers/net/mlx5/mlx5.c | 14 +++---
 drivers/net/nfp/nfp_net.c   | 21 +++
 drivers/net/qede/qede_ethdev.c  | 40 ++--
 drivers/net/szedata2/rte_eth_szedata2.c | 24 +++--
 drivers/net/thunderx/nicvf_ethdev.c | 20 +++---
 drivers/net/virtio/virtio_ethdev.c  | 25 +-
 drivers/net/vmxnet3/vmxnet3_ethdev.c| 23 +++--
 20 files changed, 78 insertions(+), 407 deletions(-)

diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c 
b/drivers/crypto/qat/rte_qat_cryptodev.c
index 1e9e0ba..b94af59 100644
--- a/drivers/crypto/qat/rte_qat_cryptodev.c
+++ b/drivers/crypto/qat/rte_qat_cryptodev.c
@@ -116,23 +116,13 @@ static struct rte_cryptodev_driver rte_qat_pmd = {
.pci_drv = {
.id_table = pci_id_qat_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
+   .devinit = rte_cryptodev_pci_probe,
+   .devuninit = rte_cryptodev_pci_remove,
},
.cryptodev_init = crypto_qat_dev_init,
.dev_private_size = sizeof(struct qat_pmd_private),
 };

-static int
-rte_qat_pmd_init(const char *name __rte_unused, const char *params 
__rte_unused)
-{
-   PMD_INIT_FUNC_TRACE();
-   return rte_cryptodev_pmd_driver_register(_qat_pmd, PMD_PDEV);
-}
-
-static struct rte_driver pmd_qat_drv = {
-   .type = PMD_PDEV,
-   .init = rte_qat_pmd_init,
-};
-
-PMD_REGISTER_DRIVER(pmd_qat_drv, CRYPTODEV_NAME_QAT_SYM_PMD);
+DRIVER_REGISTER_PCI(CRYPTODEV_NAME_QAT_SYM_PMD, rte_qat_pmd.pci_drv);
 DRIVER_REGISTER_PCI_TABLE(CRYPTODEV_NAME_QAT_SYM_PMD, pci_id_qat_map);

diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index f3ab355..214b655 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -621,6 +621,8 @@ static struct eth_driver rte_bnx2x_pmd = {
.name = "rte_bnx2x_pmd",
.id_table = pci_id_bnx2x_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC,
+   .devinit = rte_eth_dev_pci_probe,
+   .devuninit = rte_eth_dev_pci_remove,
},
.eth_dev_init = eth_bnx2x_dev_init,
.dev_private_size = sizeof(struct bnx2x_softc),
@@ -634,38 +636,14 @@ static struct eth_driver rte_bnx2xvf_pmd = {
.name = "rte_bnx2xvf_pmd",
.id_table = pci_id_bnx2xvf_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
+   .devinit = rte_eth_dev_pci_probe,
+   .devuninit = rte_eth_dev_pci_remove,
},
.eth_dev_init = eth_bnx2xvf_dev_init,
.dev_private_size = sizeof(struct bnx2x_softc),
 };

-static int rte_bnx2x_pmd_init(const char *name __rte_unused, const char 
*params __rte_unused)
-{
-   PMD_INIT_FUNC_TRACE();
-   rte_eth_driver_register(_bnx2x_pmd);
-
-   return 0;
-}
-
-static int rte_bnx2xvf_pmd_init(const char *name __rte_unused, const char 
*params __rte_unused)
-{
-   PMD_INIT_FUNC_TRACE();
-   rte_eth_driver_register(_bnx2xvf_pmd);
-
-   return 0;
-}
-
-static struct rte_driver rte_bnx2x_driver = {
-   .type = PMD_PDEV,
-   .init = rte_bnx2x_pmd_init,
-};
-
-static struct rte_driver rte_bnx2xvf_driver = {
-   .type = PMD_PDEV,
-   .init = rte_bnx2xvf_pmd_init,
-};
-
-PMD_REGISTER_DRIVER(rte_bnx2x_driver, bnx2x);
+DRIVER_REGISTER_PCI(bnx2x, rte_bnx2x_pmd.pci_drv);
 DRIVER_REGISTER_PCI_TABLE(bnx2x, pci_id_bnx2x_map);
-PMD_REGISTER_DRIVER(rte_bnx2xvf_driver, bnx2xvf);
+DRIVER_REGISTER_PCI(bnx2xvf, rte_bnx2xvf_pmd.pci_drv);
 DRIVER_REGISTER_PCI_TABLE(bnx2xvf, pci_id_bnx2xvf_map);
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c

[dpdk-dev] [PATCH v7 07/17] ethdev: export init/uninit common wrappers for pci drivers

2016-08-01 Thread Shreyansh Jain
Preparing for getting rid of eth_drv, here are two wrappers that can be
used by pci drivers that assume a 1 to 1 association between pci resource and
upper interface.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_ether/rte_ethdev.c  | 14 +++---
 lib/librte_ether/rte_ethdev.h  | 13 +
 lib/librte_ether/rte_ether_version.map |  9 +
 3 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index f62a9ec..8825219 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -245,9 +245,9 @@ rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
return 0;
 }

-static int
-rte_eth_dev_init(struct rte_pci_driver *pci_drv,
-struct rte_pci_device *pci_dev)
+int
+rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,
+ struct rte_pci_device *pci_dev)
 {
struct eth_driver*eth_drv;
struct rte_eth_dev *eth_dev;
@@ -299,8 +299,8 @@ rte_eth_dev_init(struct rte_pci_driver *pci_drv,
return diag;
 }

-static int
-rte_eth_dev_uninit(struct rte_pci_device *pci_dev)
+int
+rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev)
 {
const struct eth_driver *eth_drv;
struct rte_eth_dev *eth_dev;
@@ -357,8 +357,8 @@ rte_eth_dev_uninit(struct rte_pci_device *pci_dev)
 void
 rte_eth_driver_register(struct eth_driver *eth_drv)
 {
-   eth_drv->pci_drv.devinit = rte_eth_dev_init;
-   eth_drv->pci_drv.devuninit = rte_eth_dev_uninit;
+   eth_drv->pci_drv.devinit = rte_eth_dev_pci_probe;
+   eth_drv->pci_drv.devuninit = rte_eth_dev_pci_remove;
rte_eal_pci_register(_drv->pci_drv);
 }

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index b0fe033..37d78bf 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -4368,6 +4368,19 @@ rte_eth_dev_get_port_by_name(const char *name, uint8_t 
*port_id);
 int
 rte_eth_dev_get_name_by_port(uint8_t port_id, char *name);

+/**
+ * Wrapper for use by pci drivers as a .devinit function to attach to a ethdev
+ * interface.
+ */
+int rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,
+ struct rte_pci_device *pci_dev);
+
+/**
+ * Wrapper for use by pci drivers as a .devuninit function to detach a ethdev
+ * interface.
+ */
+int rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_ether/rte_ether_version.map 
b/lib/librte_ether/rte_ether_version.map
index 45ddf44..17e7448 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -138,4 +138,13 @@ DPDK_16.07 {
rte_eth_dev_get_name_by_port;
rte_eth_dev_get_port_by_name;
rte_eth_xstats_get_names;
+
 } DPDK_16.04;
+
+DPDK_16.11 {
+   global:
+
+   rte_eth_dev_pci_probe;
+   rte_eth_dev_pci_remove;
+
+} DPDK_16.07;
-- 
2.7.4



[dpdk-dev] [PATCH v7 06/17] crypto: export init/uninit common wrappers for pci drivers

2016-08-01 Thread Shreyansh Jain
Preparing for getting rid of rte_cryptodev_driver, here are two wrappers
that can be used by pci drivers that assume a 1 to 1 association between
pci resource and upper interface.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_cryptodev/rte_cryptodev.c   | 16 
 lib/librte_cryptodev/rte_cryptodev_pmd.h   | 12 
 lib/librte_cryptodev/rte_cryptodev_version.map |  7 +++
 3 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index 6434894..b1e82b6 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -429,9 +429,9 @@ rte_cryptodev_pmd_virtual_dev_init(const char *name, size_t 
dev_private_size,
return cryptodev;
 }

-static int
-rte_cryptodev_init(struct rte_pci_driver *pci_drv,
-   struct rte_pci_device *pci_dev)
+int
+rte_cryptodev_pci_probe(struct rte_pci_driver *pci_drv,
+   struct rte_pci_device *pci_dev)
 {
struct rte_cryptodev_driver *cryptodrv;
struct rte_cryptodev *cryptodev;
@@ -490,8 +490,8 @@ rte_cryptodev_init(struct rte_pci_driver *pci_drv,
return -ENXIO;
 }

-static int
-rte_cryptodev_uninit(struct rte_pci_device *pci_dev)
+int
+rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
 {
const struct rte_cryptodev_driver *cryptodrv;
struct rte_cryptodev *cryptodev;
@@ -539,15 +539,15 @@ rte_cryptodev_pmd_driver_register(struct 
rte_cryptodev_driver *cryptodrv,
 {
/* Call crypto device initialization directly if device is virtual */
if (type == PMD_VDEV)
-   return rte_cryptodev_init((struct rte_pci_driver *)cryptodrv,
+   return rte_cryptodev_pci_probe((struct rte_pci_driver 
*)cryptodrv,
NULL);

/*
 * Register PCI driver for physical device intialisation during
 * PCI probing
 */
-   cryptodrv->pci_drv.devinit = rte_cryptodev_init;
-   cryptodrv->pci_drv.devuninit = rte_cryptodev_uninit;
+   cryptodrv->pci_drv.devinit = rte_cryptodev_pci_probe;
+   cryptodrv->pci_drv.devuninit = rte_cryptodev_pci_remove;

rte_eal_pci_register(>pci_drv);

diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index c977c61..3fb7c7c 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -534,6 +534,18 @@ rte_cryptodev_pmd_driver_register(struct 
rte_cryptodev_driver *crypto_drv,
 void rte_cryptodev_pmd_callback_process(struct rte_cryptodev *dev,
enum rte_cryptodev_event_type event);

+/**
+ * Wrapper for use by pci drivers as a .devinit function to attach to a crypto
+ * interface.
+ */
+int rte_cryptodev_pci_probe(struct rte_pci_driver *pci_drv,
+   struct rte_pci_device *pci_dev);
+
+/**
+ * Wrapper for use by pci drivers as a .devuninit function to detach a crypto
+ * interface.
+ */
+int rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev);

 #ifdef __cplusplus
 }
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map 
b/lib/librte_cryptodev/rte_cryptodev_version.map
index a08fd20..1fc0d57 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -39,3 +39,10 @@ DPDK_16.07 {
rte_cryptodev_parse_vdev_init_params;

 } DPDK_16.04;
+
+DPDK_16.11 {
+   global:
+
+   rte_cryptodev_pci_probe;
+   rte_cryptodev_pci_remove;
+} DPDK_16.07;
-- 
2.7.4



[dpdk-dev] [PATCH v7 05/17] eal: introduce init macros

2016-08-01 Thread Shreyansh Jain
Introduce a RTE_INIT macro used to mark an init function as a constructor.
Current eal macros have been converted to use this (no functional impact).
DRIVER_REGISTER_PCI is added as a helper for pci drivers.

Suggested-by: Jan Viktorin 
Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/common/include/rte_dev.h   | 4 ++--
 lib/librte_eal/common/include/rte_eal.h   | 3 +++
 lib/librte_eal/common/include/rte_pci.h   | 9 +
 lib/librte_eal/common/include/rte_tailq.h | 4 ++--
 4 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_dev.h 
b/lib/librte_eal/common/include/rte_dev.h
index 95789f9..994650b 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -185,8 +185,8 @@ static const char DRIVER_EXPORT_NAME_ARRAY(this_pmd_name, 
idx) \
 __attribute__((used)) = RTE_STR(name)

 #define PMD_REGISTER_DRIVER(drv, nm)\
-void devinitfn_ ##drv(void);\
-void __attribute__((constructor, used)) devinitfn_ ##drv(void)\
+RTE_INIT(devinitfn_ ##drv);\
+static void devinitfn_ ##drv(void)\
 {\
(drv).name = RTE_STR(nm);\
rte_eal_driver_register();\
diff --git a/lib/librte_eal/common/include/rte_eal.h 
b/lib/librte_eal/common/include/rte_eal.h
index a71d6f5..186f3c6 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -252,6 +252,9 @@ static inline int rte_gettid(void)
return RTE_PER_LCORE(_thread_id);
 }

+#define RTE_INIT(func) \
+static void __attribute__((constructor, used)) func(void)
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_eal/common/include/rte_pci.h 
b/lib/librte_eal/common/include/rte_pci.h
index fa74962..ffeb94c 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -470,6 +470,15 @@ void rte_eal_pci_dump(FILE *f);
  */
 void rte_eal_pci_register(struct rte_pci_driver *driver);

+/** Helper for PCI device registeration from driver (eth, crypto) instance */
+#define DRIVER_REGISTER_PCI(nm, pci_drv) \
+RTE_INIT(pciinitfn_ ##nm); \
+static void pciinitfn_ ##nm(void) \
+{ \
+   (pci_drv).name = RTE_STR(nm);\
+   rte_eal_pci_register(_drv); \
+}
+
 /**
  * Unregister a PCI driver.
  *
diff --git a/lib/librte_eal/common/include/rte_tailq.h 
b/lib/librte_eal/common/include/rte_tailq.h
index cc3c0f1..cc386e4 100644
--- a/lib/librte_eal/common/include/rte_tailq.h
+++ b/lib/librte_eal/common/include/rte_tailq.h
@@ -148,8 +148,8 @@ struct rte_tailq_head *rte_eal_tailq_lookup(const char 
*name);
 int rte_eal_tailq_register(struct rte_tailq_elem *t);

 #define EAL_REGISTER_TAILQ(t) \
-void tailqinitfn_ ##t(void); \
-void __attribute__((constructor, used)) tailqinitfn_ ##t(void) \
+RTE_INIT(tailqinitfn_ ##t); \
+static void tailqinitfn_ ##t(void) \
 { \
if (rte_eal_tailq_register() < 0) \
rte_panic("Cannot initialize tailq: %s\n", t.name); \
-- 
2.7.4



[dpdk-dev] [PATCH v7 04/17] eal: remove duplicate function declaration

2016-08-01 Thread Shreyansh Jain
rte_eal_dev_init is declared in both eal_private.h and rte_dev.h since its
introduction.
This function has been exported in ABI, so remove it from eal_private.h

Fixes: e57f20e05177 ("eal: make vdev init path generic for both virtual and pci 
devices")
Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/common/eal_private.h | 7 ---
 lib/librte_eal/linuxapp/eal/eal.c   | 1 +
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index 857dc3e..06a68f6 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -259,13 +259,6 @@ int rte_eal_intr_init(void);
 int rte_eal_alarm_init(void);

 /**
- * This function initialises any virtual devices
- *
- * This function is private to the EAL.
- */
-int rte_eal_dev_init(void);
-
-/**
  * Function is to check if the kernel module(like, vfio, vfio_iommu_type1,
  * etc.) loaded.
  *
diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index 3fb2188..fe9c704 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -70,6 +70,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.7.4



[dpdk-dev] [PATCH v7 03/17] drivers: align pci driver definitions

2016-08-01 Thread Shreyansh Jain
Pure coding style, but it might make it easier later if we want to move
fields in rte_cryptodev_driver and eth_driver structures.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 drivers/crypto/qat/rte_qat_cryptodev.c | 2 +-
 drivers/net/ena/ena_ethdev.c   | 2 +-
 drivers/net/nfp/nfp_net.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c 
b/drivers/crypto/qat/rte_qat_cryptodev.c
index 82ab047..1e9e0ba 100644
--- a/drivers/crypto/qat/rte_qat_cryptodev.c
+++ b/drivers/crypto/qat/rte_qat_cryptodev.c
@@ -113,7 +113,7 @@ crypto_qat_dev_init(__attribute__((unused)) struct 
rte_cryptodev_driver *crypto_
 }

 static struct rte_cryptodev_driver rte_qat_pmd = {
-   {
+   .pci_drv = {
.id_table = pci_id_qat_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
},
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index ac0803d..9418d50 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -1685,7 +1685,7 @@ static uint16_t eth_ena_xmit_pkts(void *tx_queue, struct 
rte_mbuf **tx_pkts,
 }

 static struct eth_driver rte_ena_pmd = {
-   {
+   .pci_drv = {
.name = "rte_ena_pmd",
.id_table = pci_id_ena_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 82e3e4e..99a258a 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2459,7 +2459,7 @@ static struct rte_pci_id pci_id_nfp_net_map[] = {
 };

 static struct eth_driver rte_nfp_net_pmd = {
-   {
+   .pci_drv = {
.name = "rte_nfp_net_pmd",
.id_table = pci_id_nfp_net_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC |
-- 
2.7.4



[dpdk-dev] [PATCH v7 02/17] crypto: no need for a crypto pmd type

2016-08-01 Thread Shreyansh Jain
This information is not used and just adds noise.

Signed-off-by: David Marchand 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_cryptodev/rte_cryptodev.c | 8 +++-
 lib/librte_cryptodev/rte_cryptodev.h | 2 --
 lib/librte_cryptodev/rte_cryptodev_pmd.h | 3 +--
 3 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index fc4123b..6434894 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -319,7 +319,7 @@ rte_cryptodev_find_free_device_index(void)
 }

 struct rte_cryptodev *
-rte_cryptodev_pmd_allocate(const char *name, enum pmd_type type, int socket_id)
+rte_cryptodev_pmd_allocate(const char *name, int socket_id)
 {
struct rte_cryptodev *cryptodev;
uint8_t dev_id;
@@ -358,7 +358,6 @@ rte_cryptodev_pmd_allocate(const char *name, enum pmd_type 
type, int socket_id)
cryptodev->data->dev_started = 0;

cryptodev->attached = RTE_CRYPTODEV_ATTACHED;
-   cryptodev->pmd_type = type;

cryptodev_globals.nb_devs++;
}
@@ -407,7 +406,7 @@ rte_cryptodev_pmd_virtual_dev_init(const char *name, size_t 
dev_private_size,
struct rte_cryptodev *cryptodev;

/* allocate device structure */
-   cryptodev = rte_cryptodev_pmd_allocate(name, PMD_VDEV, socket_id);
+   cryptodev = rte_cryptodev_pmd_allocate(name, socket_id);
if (cryptodev == NULL)
return NULL;

@@ -449,8 +448,7 @@ rte_cryptodev_init(struct rte_pci_driver *pci_drv,
rte_cryptodev_create_unique_device_name(cryptodev_name,
sizeof(cryptodev_name), pci_dev);

-   cryptodev = rte_cryptodev_pmd_allocate(cryptodev_name, PMD_PDEV,
-   rte_socket_id());
+   cryptodev = rte_cryptodev_pmd_allocate(cryptodev_name, rte_socket_id());
if (cryptodev == NULL)
return -ENOMEM;

diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
b/lib/librte_cryptodev/rte_cryptodev.h
index affbdec..13f46e4 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -613,8 +613,6 @@ struct rte_cryptodev {

enum rte_cryptodev_type dev_type;
/**< Crypto device type */
-   enum pmd_type pmd_type;
-   /**< PMD type - PDEV / VDEV */

struct rte_cryptodev_cb_list link_intr_cbs;
/**< User application callback for interrupts if present */
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 7d049ea..c977c61 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -454,13 +454,12 @@ struct rte_cryptodev_ops {
  * to that slot for the driver to use.
  *
  * @param  nameUnique identifier name for each device
- * @param  typeDevice type of this Crypto device
  * @param  socket_id   Socket to allocate resources on.
  * @return
  *   - Slot in the rte_dev_devices array for a new device;
  */
 struct rte_cryptodev *
-rte_cryptodev_pmd_allocate(const char *name, enum pmd_type type, int 
socket_id);
+rte_cryptodev_pmd_allocate(const char *name, int socket_id);

 /**
  * Creates a new virtual crypto device and returns the pointer
-- 
2.7.4



[dpdk-dev] [PATCH v7 01/17] pci: no need for dynamic tailq init

2016-08-01 Thread Shreyansh Jain
These lists can be initialized once and for all at build time.
With this, those lists are only manipulated in a common place
(and we could even make them private).

A nice side effect is that pci drivers can now register in constructors.

Signed-off-by: David Marchand 
Reviewed-by: Jan Viktorin 
Signed-off-by: Shreyansh Jain 
---
 lib/librte_eal/bsdapp/eal/eal_pci.c| 3 ---
 lib/librte_eal/common/eal_common_pci.c | 6 --
 lib/librte_eal/linuxapp/eal/eal_pci.c  | 3 ---
 3 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c 
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 374b68f..a73cbb0 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -623,9 +623,6 @@ rte_eal_pci_ioport_unmap(struct rte_pci_ioport *p)
 int
 rte_eal_pci_init(void)
 {
-   TAILQ_INIT(_driver_list);
-   TAILQ_INIT(_device_list);
-
/* for debug purposes, PCI can be disabled */
if (internal_config.no_pci)
return 0;
diff --git a/lib/librte_eal/common/eal_common_pci.c 
b/lib/librte_eal/common/eal_common_pci.c
index 7248c38..6a0f6ac 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -82,8 +82,10 @@

 #include "eal_private.h"

-struct pci_driver_list pci_driver_list;
-struct pci_device_list pci_device_list;
+struct pci_driver_list pci_driver_list =
+   TAILQ_HEAD_INITIALIZER(pci_driver_list);
+struct pci_device_list pci_device_list =
+   TAILQ_HEAD_INITIALIZER(pci_device_list);

 #define SYSFS_PCI_DEVICES "/sys/bus/pci/devices"

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index cd9de7c..f0215ee 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -743,9 +743,6 @@ rte_eal_pci_ioport_unmap(struct rte_pci_ioport *p)
 int
 rte_eal_pci_init(void)
 {
-   TAILQ_INIT(_driver_list);
-   TAILQ_INIT(_device_list);
-
/* for debug purposes, PCI can be disabled */
if (internal_config.no_pci)
return 0;
-- 
2.7.4



[dpdk-dev] [PATCH v7 00/17] Prepare for rte_device / rte_driver

2016-08-01 Thread Shreyansh Jain
* Original patch series is from David Marchand [1], [2].
* Link with patch series [4] from Jan Viktorin for a more complete picture
  of proposed EAL device heirarchy changes.
* This might not be in-sync with pmdinfogen as PMD_REGISTER_DRIVER is
  removed [7].

David created the original patchset based on the discussions on list [3].
Being a large piece of work, this patchset introduces first level of changes
for generalizing the driver-device relationship for supporting hotplug.

Overview of this work as per David [3], as well as notes from Thomas [9] &
Jan:
- pdev -> PCI registeration using helpers (introduced in this series)
- removal of eth/crypto driver registeration callbacks. These are now handled
  by PCI registeration helpers (this patch)
- rte_device=>pci/vdev device heirarchy (by this [4] series)
- removal of PMD_PDEV type (this patch) and PMD_VDEV (by this [4] series)
- Support for hotplugging

This patchset is based on master (b0a1419)

[1] http://dpdk.org/ml/archives/dev/2016-January/032387.html
[2] http://dpdk.org/ml/archives/dev/2016-April/037686.html
[3] http://dpdk.org/ml/archives/dev/2016-January/031390.html
[4] http://dpdk.org/ml/archives/dev/2016-July/043645.html
[5] http://dpdk.org/ml/archives/dev/2016-June/042439.html
[6] http://dpdk.org/ml/archives/dev/2016-June/042444.html
[7] http://dpdk.org/ml/archives/dev/2016-July/043172.html
[8] http://dpdk.org/ml/archives/dev/2016-July/044004.html
[9] http://dpdk.org/ml/archives/dev/2016-July/044086.html

Changes since v6:
- rebase over 16.07 (b0a1419)
- DRIVER_REGISTER_PCI macro is now passed pci_drv rather than drv
- review comments regarding missing information in log messages
- new API additions to 16.11 map objects
- review comment in [5] and [7] are not included in this series.

Changes since v5:
- Rebase over master (11c5e45d8)
- Rename RTE_EAL_PCI_REGISTER helper macro to DRIVER_REGISTER_PCI to be in sync
  with DRIVER_REGISTER_PCI_TABLE. [Probably, in future, both can be merged]
- Modifications to bnxt and thunderx driver PMD registeration files for
  using the simplified PCI device registeration helper macro

Changes since v4:
- Fix compilation issue after rebase on HEAD (913154e) in previous series
- Retain rte_eth_dev_get_port_by_name and rte_eth_dev_get_name_by_port which
  were removed by previous patchset. These are being used by pdump library

Changes since v3:
- rebase over HEAD (913154e)
- Update arguments to RTE_EAL_PCI_REGISTER macro as per Jan's suggestion
- modify qede driver to use RTE_EAL_PCI_REGISTER
- Argument check in hotplug functions

Changes since v2:
- rebase over HEAD (d76c193)
- Move SYSFS_PCI_DRIVERS macro to rte_pci.h to avoid compilation issue

Changes since v1:
- rebased on HEAD, new drivers should be okay
- patches have been split into smaller pieces
- RTE_INIT macro has been added, but in the end, I am not sure it is useful
- device type has been removed from ethdev, as it was used only by hotplug
- getting rid of pmd type in eal patch (patch 5 of initial series) has been
  dropped for now, we can do this once vdev drivers have been converted

David Marchand, Shreyansh Jain (17):
  pci: no need for dynamic tailq init
  crypto: no need for a crypto pmd type
  drivers: align pci driver definitions
  eal: remove duplicate function declaration
  eal: introduce init macros
  crypto: export init/uninit common wrappers for pci drivers
  ethdev: export init/uninit common wrappers for pci drivers
  drivers: convert all pdev drivers as pci drivers
  crypto: get rid of crypto driver register callback
  ethdev: get rid of eth driver register callback
  eal/linux: move back interrupt thread init before setting affinity
  pci: add a helper for device name
  pci: add a helper to update a device
  ethdev: do not scan all pci devices on attach
  eal: add hotplug operations for pci and vdev
  ethdev: convert to eal hotplug
  ethdev: get rid of device type

 app/test/virtual_pmd.c  |   2 +-
 drivers/crypto/qat/rte_qat_cryptodev.c  |  18 +-
 drivers/net/af_packet/rte_eth_af_packet.c   |   2 +-
 drivers/net/bnx2x/bnx2x_ethdev.c|  34 +--
 drivers/net/bnxt/bnxt_ethdev.c  |  16 +-
 drivers/net/bonding/rte_eth_bond_api.c  |   2 +-
 drivers/net/cxgbe/cxgbe_ethdev.c|  24 +--
 drivers/net/cxgbe/cxgbe_main.c  |   2 +-
 drivers/net/e1000/em_ethdev.c   |  16 +-
 drivers/net/e1000/igb_ethdev.c  |  39 +---
 drivers/net/ena/ena_ethdev.c|  19 +-
 drivers/net/enic/enic_ethdev.c  |  23 +-
 drivers/net/fm10k/fm10k_ethdev.c|  23 +-
 drivers/net/i40e/i40e_ethdev.c  |  24 +--
 drivers/net/i40e/i40e_ethdev_vf.c   |  25 +--
 drivers/net/ixgbe/ixgbe_ethdev.c|  46 +---
 drivers/net/mlx4/mlx4.c |  17 +-
 drivers/net/mlx5/mlx5.c |  16 +-
 drivers/net/mpipe/mpipe_tilegx.c 

[dpdk-dev] [RFC] Generic flow director/filtering/classification API

2016-08-01 Thread Kieran Mansley
Apologies for coming a little late to this thread about the proposed new
API for filtering etc.

I've reviewed it based on Solarflare's needs and hardware capabilities,
and think the proposal is likely to be a big improvement on the current
system.

I worry slightly that the goal of having applications that are not aware
of the hardware they are running on will be difficult to meet.  My guess
is that the different hardware platforms will have so little overlap in
the functionality they support that to get best performance the
applications will still be heavily tailored to the subsets of the API
that the hardware they are using provides.  The discussion of filter
priorities is a good example of this: to get best performance the
application will want to use the hardware's filtering capabilities to do
all the heavy lifting, but the abilities of different NICs to support
particular priorities and combinations of filters will mean what works
very well for one NIC may well return "I can't do that" for another, and
vice versa.

One suggestion for extending the API further would be to allow it to
also describe transmit filters as well as receive filters.

There are also some filters that can prove very useful to our customers
that while they could be achieved through the careful insertion of
multiple filters with the right order and priorities, could be made more
application-friendly by having a more meaningful alias. For example:
  - multicast-mismatch (all multicast traffic that doesn't match another
filter and would otherwise be discarded)
  - unicast-mismatch (all unicast traffic that doesn't match another
filter and would otherwise be discarded)
  - all-multicast (all multicast traffic)
  - all-unicast (all unicast traffic)

Finally, I wonder if any thought has been given to dealing with
situations where there is a conflict between different virtual or
physical functions.  E.g. attempting to insert a MAC filter on one VF
that would steal traffic destined to a different VF.  Will it be up to
each driver to enforce these sorts of policies or will there be a
general vendor-neutral framework to deal with this?

I should reiterate that I think this will be a big improvement, so thank
you for proposing it.

Kieran
The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.


[dpdk-dev] l3fwd LPM memory allocation failed

2016-08-01 Thread De Lara Guarch, Pablo
Hi Raja,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Raja Jayapal
> Sent: Monday, August 01, 2016 2:32 AM
> To: dev at dpdk.org
> Cc: Rafat Jahan; Nagaratna Patagar
> Subject: [dpdk-dev] l3fwd LPM memory allocation failed
> 
> Hi All,
> 
> I have installed dpdk-2.2.0 on VM and when i try to run l3fwd sample
> application, facing the below memory error.
> 
> root at tcs-Standard-PC-i440FX-PIIX-1996:/home/tcs/Downloads/dpdk-
> 2.2.0/examples/l3fwd# ./build/l3fwd -c 0x1 -n 1 -- -p 0x3 --
> config="(0,0,0),(1,0,0)"
> EAL: Detected lcore 0 as core 0 on socket 0
> EAL: Detected lcore 1 as core 0 on socket 0
> EAL: Support maximum 128 logical core(s) by configuration.
> EAL: Detected 2 lcore(s)
> EAL: VFIO modules not all loaded, skip VFIO support...
> EAL: Setting up physically contiguous memory...
> EAL: Ask a virtual area of 0x60 bytes
> EAL: Virtual area found at 0x7f2f9a80 (size = 0x60)
> EAL: Ask a virtual area of 0xc0 bytes
> EAL: Virtual area found at 0x7f2f99a0 (size = 0xc0)
> EAL: Ask a virtual area of 0x40 bytes

[...]

> EAL: Virtual area found at 0x7f2f7520 (size = 0x460)
> EAL: Ask a virtual area of 0x60 bytes
> EAL: Virtual area found at 0x7f2f74a0 (size = 0x60)
> EAL: Ask a virtual area of 0xa0 bytes
> EAL: Virtual area found at 0x7f2f73e0 (size = 0xa0)
> EAL: Requesting 263 pages of size 2MB from socket 0
> EAL: TSC frequency is ~3092976 KHz
> EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using
> unreliable clock cycles !
> EAL: Master lcore 0 is ready (tid=9cb32940;cpuset=[0])
> EAL: PCI device :00:03.0 on NUMA socket -1
> EAL:?? probe driver: 8086:100e rte_em_pmd
> EAL:?? PCI memory mapped at 0x7f2f9ae0
> PMD: eth_em_dev_init(): port_id 0 vendorID=0x8086 deviceID=0x100e
> EAL: PCI device :00:07.0 on NUMA socket -1
> EAL:?? probe driver: 8086:100e rte_em_pmd
> EAL:?? PCI memory mapped at 0x7f2f9ae2
> PMD: eth_em_dev_init(): port_id 1 vendorID=0x8086 deviceID=0x100e
> EAL: PCI device :00:08.0 on NUMA socket -1
> EAL:?? probe driver: 8086:100e rte_em_pmd
> EAL:?? PCI memory mapped at 0x7f2f9ae4
> PMD: eth_em_dev_init(): port_id 2 vendorID=0x8086 deviceID=0x100e
> EAL: PCI device :00:09.0 on NUMA socket -1
> EAL:?? probe driver: 8086:100e rte_em_pmd
> EAL:?? PCI memory mapped at 0x7f2f9ae6
> PMD: eth_em_dev_init(): port_id 3 vendorID=0x8086 deviceID=0x100e
> Initializing port 0 ... Creating queues: nb_rxq=1 nb_txq=1...?
> Address:52:54:00:0D:AF:AF, Destination:02:00:00:00:00:00, Allocated mbuf
> pool on socket 0
> LPM: Adding route 0x01010100 / 24 (0)
> LPM: Adding route 0x02010100 / 24 (1)
> LPM: LPM memory allocation failed
> EAL: Error - exiting with code: 1
> ? Cause: Unable to create the l3fwd LPM table on socket 0
> 
> 
> As mentioned in previous dpdkthreads, i tried after changing the hugepage
> size to 1024 as well.
> http://dpdk.org/ml/archives/dev/2014-November/007770.html
> http://dpdk.org/ml/archives/users/2015-November/66.html
> echo 512 > /sys/devices/system/node/node0/hugepages/hugepages-
> 2048kB/nr_hugepages
>  echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-
> 2048kB/nr_hugepages
> 
> Tried setting the hugepage through ./tools/setup.sh (1024,4096...) as well. 
> but
> facing the same error.
> 
> Could somebody help how to resolve this issue?

It looks like your memory is too fragmented. Your should reboot your machine and
reserve the hugepages as soon as possible, or even better, pass it to the 
kernel parameters,
adding in grub.cfg, at the end of the rest of the parameters "hugepages=1024",
to reserve 1024 pages of 2M.

Btw, next time, for this kind of questions, you should use the users list users 
at dpdk.org.

Best regards,
Pablo

> 
> Thanks,
> Raja
> 
> =-=-=
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
> 



[dpdk-dev] Application framework vs. library

2016-08-01 Thread Wiles, Keith

> On Aug 1, 2016, at 5:04 AM, Thomas Monjalon  
> wrote:
> 
> Hi,
> 
> Thanks for explaining your context.
> Your concerns are known under the term "usability enhancements".
> As they require some API changes, we won't make them in the release 16.11.
> But we must work on it now to be able to announce the API changes for 17.02
> before the 16.11 release.
> 
> 2016-08-01 10:18, Steffen.Bauch at rohde-schwarz.com:
>> Concerning the integration we try to cope with the circumstance that
>> DPDK is more comparable to an application framework and less to a
>> library.
> 
> I think DPDK should be easier to use and considered as a normal library.
> 
> 
> [...]
>> Logging behavior
>> 
>> Opening a connection to the system logger for our program is within the
>> responsibility of our specific logging module that is also used in the
>> proprietary parts of the application. For this reason openlog() should
>> not be called in our use case. In addition, using rte_openlog_stream()
>> is not usable before rte_eal_init() as logging init will overwrite the
>> used log stream. For this reason a large part of the init logs can not
>> be handled by a custom log stream. Btw, after removal of the log caching,
>> is there a fundamental difference between early log and normal logging?
> 
> You're right. Now that the log history is removed, we can rework the log
> initialization and reconsider early logging.
> 
>> A possible approach for the future could be to initialize rte_logs.file
>> to NULL (in fact it is, as it is static) and only set it during
>> initialization if it is NULL with the goal to be able to use
>> rte_openlog_stream() before rte_eal_init(). As the openlog() call is
>> only relevant when the default log stream is used (and architecture
>> dependent!) I introduced a specific entry point for calling openlog. The
>> main complexity to this changeset is added due to two reasons. First
>> reason is the circumstance that rte_eal_common_log_init() is used several
>> times during early logging and real logging initialization. Second
>> aspect is that a user might revert to the use of the default_log_stream
>> after a custom log stream has be used straight from the beginning (even
>> before rte_eal_init()). A dedicated changeset towards v16.07 for this
>> improvement is attached for review, feedback and possible inclusion.
> 
> Before entering in the proposed design for a custom log handler, we should
> discuss the desired features in DPDK logging.
> Is there some developer who would like to see the logs improved to be
> dynamically tuned in run-time live?
> Or should we just allow a custom log handler and provide only a default
> minimal handler?

I would suggest we have a custom log handler for applications that have their 
own logging system. I believe we still need a logging system in DPDK as a 
complete ?none? library type system. DPDK was designed as a complete system (or 
appears that way), but I understand moving toward a library design is 
reasonable. I just do not want to lose the complete system design as we should 
be able to have both.

The only down side to a library design is testing becomes more complex IMO as 
we do not have a standard configuration(s) and ?complete? applications. DPDK is 
a complex designed system and it can become difficult to test the library 
interactions if we do not have a clean way to test the complete set of 
libraries.

> 
> 
>> Process termination behavior
>> 
>> As the DPDK functionality is only a small part of the whole application
>> ownership of the running process is not with DPDK and it is not allowed
>> to cancel the running process as a result of an error. For this reason,
>> the current changeset instead of calling rte_panic or rte_exit returns
>> an error code and handles it in the calling function. Unfortunately this
>> change was only implemented in rte_eal_init() and not in other places
>> (drivers, libs ...), so there is currently no safety that an unknown
>> code part terminates the whole application on the spot. Future changes
>> and patches could change the error handling in a more thorough approach,
>> but I would like to have some feedback and opinions before I start the
>> heavy-lifting work in over 700 code locations. Even some interfaces
>> might be affected, as lots of functions return void now,
> 
> Yes, please let's remove every panic/exit calls from DPDK.
> The only reason it is still there is that nobody took the time to remove
> these traces from the early support of bare metal environment (now dropped).

Removing the panic calls is find, but the patch just replaces them with return 
-1 and will not do as you need to know why the calls failed. Replacing them 
with returning an error code and calling a log output would be much more 
reasonable.

> 
> 
>> Thread creation
>> 
>> In our application thread creation and setting the affinity is already
>> handled in a proprietary module. Frames are polled and processed
>> in non-EAL pthreads. For this 

[dpdk-dev] [PATCH] examples: fix unusual-interpreter

2016-08-01 Thread Thomas Monjalon
2016-08-01 15:12, Christian Ehrhardt:
> On Mon, Aug 1, 2016 at 2:50 PM, Thomas Monjalon 
> wrote:
> > 2016-08-01 14:28, Christian Ehrhardt:
> > > Due to regular lintian checks in Debian packaging it surfaced that these
> > > two scripts had a space in their #! statement which renders it to be
> > > human, but not shell readable.
> > [...]
> > > -#! /usr/bin/python2
> > > +#!/usr/bin/python2
> >
> > I think we can have a space in the shebang (it works with shells I know).
> > But maybe lintian do not like it (and it is a sufficient reason to accept
> > this trivial patch).
> >
> > However, a better fix would be to run something else than python2,
> > like /usr/bin/env python.
> >
> > Some other python scripts in tools dir may be fixed.
> 
> I agree on both changes you suggested, but not being the scripts author I
> wanted to change as few as possible.
> Also thanks for taking it into consideration even if just for lintian :-)
> 
> If acceptable to you I'd ask to accept this as-is and consider the patch a
> head-up for all script owners to change their headers.

We can remove the space in every scripts, at least.
Then we can wait a little for the opinion of the script authors to do
more changes.

PS: Please avoid top posting.


[dpdk-dev] [PATCH] examples: fix unusual-interpreter

2016-08-01 Thread Christian Ehrhardt
Hi Thomas,
I agree on both changes you suggested, but not being the scripts author I
wanted to change as few as possible.
Also thanks for taking it into consideration even if just for lintian :-)

If acceptable to you I'd ask to accept this as-is and consider the patch a
head-up for all script owners to change their headers.



Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Mon, Aug 1, 2016 at 2:50 PM, Thomas Monjalon 
wrote:

> 2016-08-01 14:28, Christian Ehrhardt:
> > Due to regular lintian checks in Debian packaging it surfaced that these
> > two scripts had a space in their #! statement which renders it to be
> > human, but not shell readable.
> [...]
> > -#! /usr/bin/python2
> > +#!/usr/bin/python2
>
> I think we can have a space in the shebang (it works with shells I know).
> But maybe lintian do not like it (and it is a sufficient reason to accept
> this trivial patch).
>
> However, a better fix would be to run something else than python2,
> like /usr/bin/env python.
>
> Some other python scripts in tools dir may be fixed.
>


[dpdk-dev] [PATCH] examples: fix unusual-interpreter

2016-08-01 Thread Mcnamara, John
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Monday, August 1, 2016 2:26 PM
> To: Christian Ehrhardt 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] examples: fix unusual-interpreter
> 
> 2016-08-01 15:12, Christian Ehrhardt:
> > On Mon, Aug 1, 2016 at 2:50 PM, Thomas Monjalon
> > 
> > wrote:
> > > 2016-08-01 14:28, Christian Ehrhardt:
> > > > Due to regular lintian checks in Debian packaging it surfaced that
> > > > these two scripts had a space in their #! statement which renders
> > > > it to be human, but not shell readable.
> > > [...]
> > > > -#! /usr/bin/python2
> > > > +#!/usr/bin/python2
> > >
> > > I think we can have a space in the shebang (it works with shells I
> know).
> > > But maybe lintian do not like it (and it is a sufficient reason to
> > > accept this trivial patch).
> > >
> > > However, a better fix would be to run something else than python2,
> > > like /usr/bin/env python.
> > >
> > > Some other python scripts in tools dir may be fixed.
> >
> > I agree on both changes you suggested, but not being the scripts
> > author I wanted to change as few as possible.
> > Also thanks for taking it into consideration even if just for lintian
> > :-)
> >
> > If acceptable to you I'd ask to accept this as-is and consider the
> > patch a head-up for all script owners to change their headers.
> 
> We can remove the space in every scripts, at least.
> Then we can wait a little for the opinion of the script authors to do more
> changes.
> 

Hi,

The script is Python2/3 compatible so remove the space and change to 
/usr/bin/python or similar.

John




[dpdk-dev] [PATCH] examples: fix unusual-interpreter

2016-08-01 Thread Dumitrescu, Cristian


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Christian Ehrhardt
> Sent: Monday, August 1, 2016 1:29 PM
> To: christian.ehrhardt at canonical.com; dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] examples: fix unusual-interpreter
> 
> Due to regular lintian checks in Debian packaging it surfaced that these
> two scripts had a space in their #! statement which renders it to be
> human, but not shell readable.
> 
> Fixes: 8673a3e8 ("examples/ip_pipeline: add config diagram generator")
> Fixes: fa667b46 ("examples/ip_pipeline: add core mappings script")
> 
> Signed-off-by: Christian Ehrhardt 
> ---

Acked-by: Cristian Dumitrescu 

Christian and Thomas, 

Looking at this email thread, if there is an even better more robust solution, 
please suggest. It would not hurt to document it in the coding guidelines for 
scripts.

Thanks,
Cristian



[dpdk-dev] [PATCH] mbuf: remove deprecated internal function

2016-08-01 Thread Thomas Monjalon
The function __rte_mbuf_raw_alloc was reserved for internal use and
has been deprecated in favor of the public function rte_mbuf_raw_alloc.
It can be safely removed now.

Signed-off-by: Thomas Monjalon 
---
 lib/librte_mbuf/rte_mbuf.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 101485f..7ea66ed 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -1157,13 +1157,6 @@ static inline struct rte_mbuf *rte_mbuf_raw_alloc(struct 
rte_mempool *mp)
return m;
 }

-/* compat with older versions */
-__rte_deprecated static inline struct rte_mbuf *
-__rte_mbuf_raw_alloc(struct rte_mempool *mp)
-{
-   return rte_mbuf_raw_alloc(mp);
-}
-
 /**
  * @internal Put mbuf back into its original mempool.
  * The use of that function is reserved for RTE internal needs.
-- 
2.7.0



[dpdk-dev] [PATCH 2/2] app/test: add a case to verify lpm tlb8 recycle

2016-08-01 Thread Wei Dai
As a bug-fix for lpm tlb8 recycle is introduced,
add a test case to verify tlb8 group is correctly
freed when it only includes a rule with depth=24.

Signed-off-by: Wei Dai 
---
 app/test/test_lpm.c | 81 -
 1 file changed, 80 insertions(+), 1 deletion(-)

diff --git a/app/test/test_lpm.c b/app/test/test_lpm.c
index b6ad2eb..e053f99 100644
--- a/app/test/test_lpm.c
+++ b/app/test/test_lpm.c
@@ -68,6 +68,7 @@ static int32_t test14(void);
 static int32_t test15(void);
 static int32_t test16(void);
 static int32_t test17(void);
+static int32_t test18(void);

 rte_lpm_test tests[] = {
 /* Test Cases */
@@ -89,6 +90,7 @@ rte_lpm_test tests[] = {
test15,
test16,
test17,
+   test18
 };

 #define NUM_LPM_TESTS (sizeof(tests)/sizeof(tests[0]))
@@ -1218,6 +1220,83 @@ test17(void)
 }

 /*
+ * Test for recycle of tlb8
+ *  - step 1: add a rule with depth=28 (> 24)
+ *  - step 2: add a rule with same 24-bit prefix and depth=23 (< 24)
+ *  - step 3: delete the first rule
+ *  - step 4: check tlb8 is freed
+ *  - step 5: add a rule same as the first one (depth=28)
+ *  - step 6: check same tlb8 is allocated
+ *  - step 7: add a rule with same 24-bit prefix and depth=24
+ *  - step 8: delete the rule (depth=28) added in step 5
+ *  - step 9: check tlb8 is freed
+ *  - step 10: add a rule with same 24-bit prefix and depth = 28
+ *  - setp 11: check same tlb8 is allocated again
+ */
+int32_t
+test18(void)
+{
+#define group_idx next_hop
+   struct rte_lpm *lpm = NULL;
+   struct rte_lpm_config config;
+   uint32_t ip, next_hop;
+   uint8_t depth;
+   uint32_t tbl8_group_index;
+
+   config.max_rules = MAX_RULES;
+   config.number_tbl8s = NUMBER_TBL8S;
+   config.flags = 0;
+
+   lpm = rte_lpm_create(__func__, SOCKET_ID_ANY, );
+   TEST_LPM_ASSERT(lpm != NULL);
+
+   ip = IPv4(192, 168, 100, 100);
+   depth = 28;
+   next_hop = 1;
+   rte_lpm_add(lpm, ip, depth, next_hop);
+
+   TEST_LPM_ASSERT(lpm->tbl24[ip>>8].valid_group);
+   tbl8_group_index = lpm->tbl8[ip>>8].group_idx;
+
+   depth = 23;
+   next_hop = 2;
+   rte_lpm_add(lpm, ip, depth, next_hop);
+   TEST_LPM_ASSERT(lpm->tbl24[ip>>8].valid_group);
+
+   depth = 28;
+   rte_lpm_delete(lpm, ip, depth);
+
+   TEST_LPM_ASSERT(!lpm->tbl24[ip>>8].valid_group);
+
+   next_hop = 3;
+   rte_lpm_add(lpm, ip, depth, next_hop);
+
+   TEST_LPM_ASSERT(lpm->tbl24[ip>>8].valid_group);
+   TEST_LPM_ASSERT(tbl8_group_index == lpm->tbl8[ip>>8].group_idx);
+
+   depth = 24;
+   next_hop = 4;
+   rte_lpm_add(lpm, ip, depth, next_hop);
+   TEST_LPM_ASSERT(lpm->tbl24[ip>>8].valid_group);
+
+   depth = 28;
+   rte_lpm_delete(lpm, ip, depth);
+
+   TEST_LPM_ASSERT(!lpm->tbl24[ip>>8].valid_group);
+
+   next_hop = 5;
+   rte_lpm_add(lpm, ip, depth, next_hop);
+
+   TEST_LPM_ASSERT(lpm->tbl24[ip>>8].valid_group);
+   TEST_LPM_ASSERT(tbl8_group_index == lpm->tbl8[ip>>8].group_idx);
+
+   rte_lpm_free(lpm);
+#undef group_idx
+   return PASS;
+}
+
+
+/*
  * Do all unit tests.
  */

@@ -1230,7 +1309,7 @@ test_lpm(void)
for (i = 0; i < NUM_LPM_TESTS; i++) {
status = tests[i]();
if (status < 0) {
-   printf("ERROR: LPM Test %s: FAIL\n", RTE_STR(tests[i]));
+   printf("ERROR: LPM Test %u: FAIL\n", i);
global_status = status;
}
}
-- 
2.5.5



[dpdk-dev] [PATCH 1/2] lpm: fix tlb8 only not freed for depth=24

2016-08-01 Thread Wei Dai
When all rules with depth > 24 are deleted in a same tlb8 group
and only leave a rule with depth <= 24 in this group, the tlb8
group should be recycled.

Fixes: af75078fece3 ("first public release")

Signed-off-by: Wei Dai 
---
 lib/librte_lpm/rte_lpm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index 6f65d1c..24fec4b 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -1533,7 +1533,7 @@ tbl8_recycle_check_v20(struct rte_lpm_tbl_entry_v20 *tbl8,
 * and if so check the rest of the entries to verify that they
 * are all of this depth.
 */
-   if (tbl8[tbl8_group_start].depth < MAX_DEPTH_TBL24) {
+   if (tbl8[tbl8_group_start].depth <= MAX_DEPTH_TBL24) {
for (i = (tbl8_group_start + 1); i < tbl8_group_end;
i++) {

@@ -1580,7 +1580,7 @@ tbl8_recycle_check_v1604(struct rte_lpm_tbl_entry *tbl8,
 * and if so check the rest of the entries to verify that they
 * are all of this depth.
 */
-   if (tbl8[tbl8_group_start].depth < MAX_DEPTH_TBL24) {
+   if (tbl8[tbl8_group_start].depth <= MAX_DEPTH_TBL24) {
for (i = (tbl8_group_start + 1); i < tbl8_group_end;
i++) {

-- 
2.5.5



[dpdk-dev] l3fwd LPM memory allocation failed

2016-08-01 Thread Raja Jayapal
Hi All,

I have installed dpdk-2.2.0 on VM and when i try to run l3fwd sample 
application, facing the below memory error.

root at 
tcs-Standard-PC-i440FX-PIIX-1996:/home/tcs/Downloads/dpdk-2.2.0/examples/l3fwd# 
./build/l3fwd -c 0x1 -n 1 -- -p 0x3 --config="(0,0,0),(1,0,0)" 
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 0 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 2 lcore(s)
EAL: VFIO modules not all loaded, skip VFIO support...
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0x60 bytes
EAL: Virtual area found at 0x7f2f9a80 (size = 0x60)
EAL: Ask a virtual area of 0xc0 bytes
EAL: Virtual area found at 0x7f2f99a0 (size = 0xc0)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7f2f9940 (size = 0x40)
EAL: Ask a virtual area of 0x80 bytes
EAL: Virtual area found at 0x7f2f98a0 (size = 0x80)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7f2f9840 (size = 0x40)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f9800 (size = 0x20)
EAL: Ask a virtual area of 0xa0 bytes
EAL: Virtual area found at 0x7f2f9740 (size = 0xa0)
EAL: Ask a virtual area of 0xc0 bytes
EAL: Virtual area found at 0x7f2f9660 (size = 0xc0)
EAL: Ask a virtual area of 0x160 bytes
EAL: Virtual area found at 0x7f2f94e0 (size = 0x160)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f94a0 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f9460 (size = 0x20)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7f2f9400 (size = 0x40)
EAL: Ask a virtual area of 0xe0 bytes
EAL: Virtual area found at 0x7f2f9300 (size = 0xe0)
EAL: Ask a virtual area of 0x1a0 bytes
EAL: Virtual area found at 0x7f2f9140 (size = 0x1a0)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f9100 (size = 0x20)
EAL: Ask a virtual area of 0x60 bytes
EAL: Virtual area found at 0x7f2f9080 (size = 0x60)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f9040 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f9000 (size = 0x20)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7f2f8fa0 (size = 0x40)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8f60 (size = 0x20)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7f2f8f00 (size = 0x40)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8ec0 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8e80 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8e40 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8e00 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8dc0 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8d80 (size = 0x20)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7f2f8d20 (size = 0x40)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8ce0 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8ca0 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8c60 (size = 0x20)
EAL: Ask a virtual area of 0x60 bytes
EAL: Virtual area found at 0x7f2f8be0 (size = 0x60)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8ba0 (size = 0x20)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7f2f8b40 (size = 0x40)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8b00 (size = 0x20)
EAL: Ask a virtual area of 0xa0 bytes
EAL: Virtual area found at 0x7f2f8a40 (size = 0xa0)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7f2f89e0 (size = 0x40)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f89a0 (size = 0x20)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7f2f8940 (size = 0x40)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8900 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f88c0 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8880 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f2f8840 (size = 0x20)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual 

[dpdk-dev] [PATCH] examples: fix unusual-interpreter

2016-08-01 Thread Thomas Monjalon
2016-08-01 14:28, Christian Ehrhardt:
> Due to regular lintian checks in Debian packaging it surfaced that these
> two scripts had a space in their #! statement which renders it to be
> human, but not shell readable.
[...]
> -#! /usr/bin/python2
> +#!/usr/bin/python2

I think we can have a space in the shebang (it works with shells I know).
But maybe lintian do not like it (and it is a sufficient reason to accept
this trivial patch).

However, a better fix would be to run something else than python2,
like /usr/bin/env python.

Some other python scripts in tools dir may be fixed.


[dpdk-dev] [PATCH] examples: fix unusual-interpreter

2016-08-01 Thread Christian Ehrhardt
Due to regular lintian checks in Debian packaging it surfaced that these
two scripts had a space in their #! statement which renders it to be
human, but not shell readable.

Fixes: 8673a3e8 ("examples/ip_pipeline: add config diagram generator")
Fixes: fa667b46 ("examples/ip_pipeline: add core mappings script")

Signed-off-by: Christian Ehrhardt 
---
 examples/ip_pipeline/config/diagram-generator.py| 2 +-
 examples/ip_pipeline/config/pipeline-to-core-mapping.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/ip_pipeline/config/diagram-generator.py 
b/examples/ip_pipeline/config/diagram-generator.py
index f20cbcb..7b1f8d6 100755
--- a/examples/ip_pipeline/config/diagram-generator.py
+++ b/examples/ip_pipeline/config/diagram-generator.py
@@ -1,4 +1,4 @@
-#! /usr/bin/python2
+#!/usr/bin/python2

 #   BSD LICENSE
 #
diff --git a/examples/ip_pipeline/config/pipeline-to-core-mapping.py 
b/examples/ip_pipeline/config/pipeline-to-core-mapping.py
index 37b131c..5ffc632 100755
--- a/examples/ip_pipeline/config/pipeline-to-core-mapping.py
+++ b/examples/ip_pipeline/config/pipeline-to-core-mapping.py
@@ -1,4 +1,4 @@
-#! /usr/bin/python2
+#!/usr/bin/python2

 #   BSD LICENSE
 #
-- 
2.7.4



[dpdk-dev] dpdk 16.07, issues with rte_mempool_create and rte_kni_alloc()

2016-08-01 Thread Gopakumar Choorakkot Edakkunni
Well, for my purpose I just ended up creating a seperate/smaller pool
earlier during bootup to try to guarantee its from one memseg.

But I am assuming that this KNI restriction is something thats "currently"
not fixed and is "fixable" ? Any ideas on what the summary of the reason
for this restriction is - I was gonna check if I can fix that

Rgds,
Gopa.

On Sat, Jul 30, 2016 at 10:39 PM, Gopakumar Choorakkot Edakkunni <
gopakumar.c.e at gmail.com> wrote:

> Hi all,
>
> So 16.07 seems to have an rte_mempool_create() which can allocate items
> from multiple memzones (commit d1d914eb), which is awesome and is the
> reason I upgraed to 16.07 !!
>
> But .. when I call rte_kni_alloc() with the mempool as parameter, theres a
> check in there which says below
>
> /* KNI currently requires to have only one memory chunk */
> if (mp->nb_mem_chunks != 1)
> goto kni_fail;
>
> And I hit that check because I am allocating a large mempool that happens
> to span multiple memzones. I am perfectly fine with allocating a seperate
> mempool just for KNI, except that I am unable to find any API or a flag or
> some setting which says "create me a mempool that doesnt span memzones",
> just so that I can use it with rte_kni_alloc()
>
> Any suggestions will be helpful !
>
> Rgds,
> Gopa.
>
>


[dpdk-dev] [PATCH] ethtool: remove triple license information

2016-08-01 Thread Christian Ehrhardt
License information is already in LICENSE.GPL.
Remove two extra copies and change referred filename in the files.

Signed-off-by: Christian Ehrhardt 
---
 lib/librte_eal/linuxapp/kni/ethtool/igb/COPYING| 339 -
 .../linuxapp/kni/ethtool/igb/e1000_82575.c |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_82575.h |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_api.c   |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_api.h   |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_defines.h   |   2 +-
 lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_hw.h |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_i210.c  |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_i210.h  |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_mac.c   |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_mac.h   |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_manage.c|   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_manage.h|   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_mbx.c   |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_mbx.h   |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_nvm.c   |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_nvm.h   |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_osdep.h |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_phy.c   |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_phy.h   |   2 +-
 .../linuxapp/kni/ethtool/igb/e1000_regs.h  |   2 +-
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb.h  |   2 +-
 .../linuxapp/kni/ethtool/igb/igb_debugfs.c |   2 +-
 .../linuxapp/kni/ethtool/igb/igb_ethtool.c |   2 +-
 .../linuxapp/kni/ethtool/igb/igb_hwmon.c   |   2 +-
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c |   2 +-
 .../linuxapp/kni/ethtool/igb/igb_param.c   |   2 +-
 .../linuxapp/kni/ethtool/igb/igb_procfs.c  |   2 +-
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb_ptp.c  |   2 +-
 .../linuxapp/kni/ethtool/igb/igb_regtest.h |   2 +-
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb_vmdq.c |   2 +-
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb_vmdq.h |   2 +-
 lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.c  |   2 +-
 lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h  |   2 +-
 .../linuxapp/kni/ethtool/igb/kcompat_ethtool.c |   2 +-
 lib/librte_eal/linuxapp/kni/ethtool/ixgbe/COPYING  | 339 -
 lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe.h  |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_82598.c   |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_82598.h   |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c   |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_82599.h   |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_api.c |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_api.h |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_common.c  |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_common.h  |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_dcb.h |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_fcoe.h|   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_main.c|   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_mbx.h |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_osdep.h   |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_phy.c |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_phy.h |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_sriov.h   |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_type.h|   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_x540.c|   2 +-
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_x540.h|   2 +-
 .../linuxapp/kni/ethtool/ixgbe/kcompat.c   |   2 +-
 .../linuxapp/kni/ethtool/ixgbe/kcompat.h   |   2 +-
 59 files changed, 57 insertions(+), 735 deletions(-)
 delete mode 100644 lib/librte_eal/linuxapp/kni/ethtool/igb/COPYING
 delete mode 100644 lib/librte_eal/linuxapp/kni/ethtool/ixgbe/COPYING

diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/COPYING 
b/lib/librte_eal/linuxapp/kni/ethtool/igb/COPYING
deleted file mode 100644
index 5f297e5..000
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/COPYING
+++ /dev/null
@@ -1,339 +0,0 @@
-
-"This software program is licensed subject to the GNU General Public License 
-(GPL). Version 2, June 1991, available at 
-"
-
-GNU General Public License 
-
-Version 2, June 1991
-
-Copyright (C) 1989, 1991 Free Software Foundation, Inc.  
-59 Temple Place - Suite 330, Boston, MA  02111-1307, USA
-
-Everyone is permitted to copy and distribute verbatim copies of this license
-document, but changing it is not allowed.
-
-Preamble
-
-The licenses for most software are designed to take away your freedom to 
-share and change it. By contrast, the GNU General Public License is intended
-to guarantee your freedom to share and change free software--to make sure 
-the software is free for all its users. This General Public 

[dpdk-dev] [PATCH] validate_abi: build faster by augmenting make with job count

2016-08-01 Thread Neil Horman
On Mon, Aug 01, 2016 at 04:16:12PM +, Wiles, Keith wrote:
> 
> >> Neil
> >> 
> > Sorry for the delayed response, I've been on vacation.
> > 
> >> Your modified copy of make has no bearing on the topic we are taking about 
> >> customers using dpdk in standard distros right?
> >> 
> > !?  I really don't know what you're saying here.  My only reason for 
> > commenting
> > on my copy of make was to consider an explination for why make -j 0 might be
> > working for me, and not for you.  I've since uninstalled and resinalled 
> > make on
> > my system, and my copy now behaves as yours does
> > 
> > But thats all really irrelevant.  I don't know what you mean by this not 
> > having
> > any bearing on the conversation since we're talking about customers using 
> > dpdk
> > in a distro.  We're not really talking about that at all (if we were using 
> > make
> > would be a moot point, since distro users tend to only use pre-compiled
> > binaries).  Were talking about accelerating the build process when comparing
> > ABIs on two different dpdk versions, thats all.
> 
> Neil, (I am trying to not read your style of text as condescending and I will 
> try to not do that as well)
> 
> Not everyone uses DPDK from prebuilt libraries and we need to support them as 
> well, correct?
> 
Correct, which is why I didn't understand your initial comment:
"Your modified copy of make has no bearing on the topic we are taking about
customers using dpdk in standard distros right?"

I read that as you saying that the topic we are discussing here is DPDK use in
standard distros, to which I am replying "No, that is not what we are talking
about here at all"

Standard Distros, as I am involved with them, are standard because the end user
typically strives to never build software included in the distro themselves.  As
such, this patch has no bearing whatsoever on those end users, because they
expect to just use a pre-built binary that conforms to a given ABI level.  They
have no need for this code

As you note, of course other upstream developers don't use pre-built binaries,
and that is who this change is targeting

> > 
> >> Seems odd to me to send this out with 0 or lspci as it may fail because of 
> >> no lspci and will fail on all Ubuntu systems. 
> >> 
> > Again, don't really understand what your saying.  If you look at the patch,
> > neither of your assertions are true.  With this patch and no other change, 
> > the
> > validate_abi script behaves exactly as it does now.  The only thing I've 
> > done is
> > add a check for the DPDK_MAKE_JOBS environment variable, and if its not set,
> > either:
> > 
> > a) Set DPDK_MAKE_JOBS to 1 if lscpu doesn't exist on the system
> > b) Set DPDK_MAKE_JOBS to the number of online cpus if lscpu does exist
> > 
> > All of that gets overridden if you manually set DPDK_MAKE_JOBS to something
> > else.
> > 
> > seems pretty straightforward to me.
> 
> At this point do we need to add yet another environment variable to get the 
> correct behavior with DPDK. DPDK is very simple to build today and I worry we 
> keep adding special variables to build DPDK. Can we just use a cleaner 
> default, then adding more and more special build requirements? Adding this 
> one is fine, but it also means the customer must read the docs to find this 
> new variable.
> 
Please read back through the thread.  The DPDK_MAKE_JOBS environment variable
was specifically used because it already exists in the build (see
test-build.sh).  Thomas specifically asked me to change the environment variable
name so that it can be resued.  We're not adding anything here that isn't
already there in other locations.

> DPDK should be build able with the least amount of docs to read, then they 
> can read the docs more later. Just looking at how the developer can get 
> started building DPDK without RTFM problem. At some point they need to read 
> the docs to possibly runs the examples, but to build DPDK should very simple 
> IMO.
So, this script has nothing to do with actually building the DPDK, only
analyzing differences in ABI between two arbitrary levels.  Nothing about this
change makes building the DPDK harder, easier, or in any way different.

> 
> > 
> >> If we ship with 1 then why even bother the adding code and if I have to 
> >> edit the file or some other method to get better compile performance then 
> >> why bother as well.
> >> 
> > Please stop and think for a minute.  Why would you need to edit a file to 
> > change
> > anything?  If lscpu exists, then everything happens automatically.  If it
> > doesn't you can still just run:
> > export DPDK_MAKE_JOBS=$BIGNUMBER; validate_abi.sh 
> 
> Please do not add extra environment variable we would start to get to the 
> point of having so many pre-build requirements it becomes the private 
> knowledge to just build DPDK or a huge setup/RTFM problem.
> 
See above, I'm getting the impression that you're just arguing without actually
looking at the code first.

> > 
> > and it 

[dpdk-dev] [PATCH] table: add missing exports

2016-08-01 Thread Aleksey Katargin
Signed-off-by: Aleksey Katargin 
---
 lib/librte_table/rte_table_version.map | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/librte_table/rte_table_version.map 
b/lib/librte_table/rte_table_version.map
index 2138698..459c2da 100644
--- a/lib/librte_table/rte_table_version.map
+++ b/lib/librte_table/rte_table_version.map
@@ -3,6 +3,7 @@ DPDK_2.0 {

rte_table_acl_ops;
rte_table_array_ops;
+   rte_table_hash_ext_dosig_ops;
rte_table_hash_ext_ops;
rte_table_hash_key8_ext_dosig_ops;
rte_table_hash_key8_ext_ops;
@@ -12,6 +13,7 @@ DPDK_2.0 {
rte_table_hash_key16_lru_ops;
rte_table_hash_key32_ext_ops;
rte_table_hash_key32_lru_ops;
+   rte_table_hash_lru_dosig_ops;
rte_table_hash_lru_ops;
rte_table_lpm_ipv6_ops;
rte_table_lpm_ops;
@@ -24,5 +26,6 @@ DPDK_2.2 {
global:

rte_table_hash_key16_ext_dosig_ops;
+   rte_table_hash_key16_lru_dosig_ops;

 } DPDK_2.0;
-- 
2.1.4



[dpdk-dev] Application framework vs. library

2016-08-01 Thread Thomas Monjalon
Hi,

Thanks for explaining your context.
Your concerns are known under the term "usability enhancements".
As they require some API changes, we won't make them in the release 16.11.
But we must work on it now to be able to announce the API changes for 17.02
before the 16.11 release.

2016-08-01 10:18, Steffen.Bauch at rohde-schwarz.com:
> Concerning the integration we try to cope with the circumstance that
> DPDK is more comparable to an application framework and less to a
> library.

I think DPDK should be easier to use and considered as a normal library.


[...]
> Logging behavior
> 
> Opening a connection to the system logger for our program is within the
> responsibility of our specific logging module that is also used in the
> proprietary parts of the application. For this reason openlog() should
> not be called in our use case. In addition, using rte_openlog_stream()
> is not usable before rte_eal_init() as logging init will overwrite the
> used log stream. For this reason a large part of the init logs can not
> be handled by a custom log stream. Btw, after removal of the log caching,
> is there a fundamental difference between early log and normal logging?

You're right. Now that the log history is removed, we can rework the log
initialization and reconsider early logging.

> A possible approach for the future could be to initialize rte_logs.file
> to NULL (in fact it is, as it is static) and only set it during
> initialization if it is NULL with the goal to be able to use
> rte_openlog_stream() before rte_eal_init(). As the openlog() call is
> only relevant when the default log stream is used (and architecture
> dependent!) I introduced a specific entry point for calling openlog. The
> main complexity to this changeset is added due to two reasons. First
> reason is the circumstance that rte_eal_common_log_init() is used several
> times during early logging and real logging initialization. Second
> aspect is that a user might revert to the use of the default_log_stream
> after a custom log stream has be used straight from the beginning (even
> before rte_eal_init()). A dedicated changeset towards v16.07 for this
> improvement is attached for review, feedback and possible inclusion.

Before entering in the proposed design for a custom log handler, we should
discuss the desired features in DPDK logging.
Is there some developer who would like to see the logs improved to be
dynamically tuned in run-time live?
Or should we just allow a custom log handler and provide only a default
minimal handler?


> Process termination behavior
> 
> As the DPDK functionality is only a small part of the whole application
> ownership of the running process is not with DPDK and it is not allowed
> to cancel the running process as a result of an error. For this reason,
> the current changeset instead of calling rte_panic or rte_exit returns
> an error code and handles it in the calling function. Unfortunately this
> change was only implemented in rte_eal_init() and not in other places
> (drivers, libs ...), so there is currently no safety that an unknown
> code part terminates the whole application on the spot. Future changes
> and patches could change the error handling in a more thorough approach,
> but I would like to have some feedback and opinions before I start the
> heavy-lifting work in over 700 code locations. Even some interfaces
> might be affected, as lots of functions return void now,

Yes, please let's remove every panic/exit calls from DPDK.
The only reason it is still there is that nobody took the time to remove
these traces from the early support of bare metal environment (now dropped).


> Thread creation
> 
> In our application thread creation and setting the affinity is already
> handled in a proprietary module. Frames are polled and processed
> in non-EAL pthreads. For this reason the lcore thread creation in
> rte_eal_init() is completely removed as we do not want additional threads
> to be assigned to processing CPUs. Unfortunately setting the coremask
> to 0 is not feasible directly. For the non-EAL threads a custom function
> within the application sets the per_thread _lcore variable to the right
> value to try to enable mbuf cacheing. The changeset also disables the
> interrupt handling thread as in our application it currently seems not
> necessary (maybe make this optional?)
> 
> In an experiment I removed the error check for the non-zero number of
> lcores and quick-fixed certain locations where rte_lcore_count() is used
> for memory size computations and at least got a running application.
> 
> A possible approach could be to enhance enum rte_lcore_role_t with an
> auxiliary thread type and introduce additional eal arguments to assign
> lcores with these auxiliary role.

My personal opinion is that DPDK (as a library) should not create some
threads at all.
The loops and workload strategy is the responsibility of the application.


[dpdk-dev] [PATCH] net/mlx5: Fix possible NULL deref in RX path

2016-08-01 Thread Sagi Grimberg
The user is allowed to call ->rx_pkt_burst() even without free
mbufs in the pool. In this scenario we'll fail allocating a rep mbuf
on the first iteration (where pkt is still NULL). This would cause us
to deref a NULL pkt (reset refcount and free).

Fix this by checking the pkt before freeing it.

Signed-off-by: Sagi Grimberg 
---
 drivers/net/mlx5/mlx5_rxtx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index fce3381ae87a..a07cc4794023 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -1572,7 +1572,7 @@ mlx5_rx_burst(void *dpdk_rxq, struct rte_mbuf **pkts, 
uint16_t pkts_n)
rte_prefetch0(wqe);
rep = rte_mbuf_raw_alloc(rxq->mp);
if (unlikely(rep == NULL)) {
-   while (pkt != seg) {
+   while (pkt && pkt != seg) {
assert(pkt != (*rxq->elts)[idx]);
seg = NEXT(pkt);
rte_mbuf_refcnt_set(pkt, 0);
-- 
1.9.1



[dpdk-dev] Application framework vs. library

2016-08-01 Thread steffen.ba...@rohde-schwarz.com
diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index bd770cf..f63f2f8 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -664,12 +664,6 @@ eal_check_mem_on_local_socket(void)
"memory on local socket!\n");
 }

-static int
-sync_func(__attribute__((unused)) void *arg)
-{
-   return 0;
-}
-
 inline static void
 rte_eal_mcfg_complete(void)
 {
@@ -699,26 +693,17 @@ rte_eal_iopl_init(void)
 int
 rte_eal_init(int argc, char **argv)
 {
-   int i, fctret, ret;
-   pthread_t thread_id;
-   static rte_atomic32_t run_once = RTE_ATOMIC32_INIT(0);
+   int fctret;
struct shared_driver *solib = NULL;
const char *logid;
-   char cpuset[RTE_CPU_AFFINITY_STR_LEN];
-
-   if (!rte_atomic32_test_and_set(_once))
-   return -1;

-   logid = strrchr(argv[0], '/');
-   logid = strdup(logid ? logid + 1: argv[0]);
-
-   thread_id = pthread_self();
+   logid = NULL;

if (rte_eal_log_early_init() < 0)
-   rte_panic("Cannot init early logs\n");
+   return -1;

if (rte_eal_cpu_init() < 0)
-   rte_panic("Cannot detect lcores\n");
+   return -1;

fctret = eal_parse_args(argc, argv);
if (fctret < 0)
@@ -731,7 +716,7 @@ rte_eal_init(int argc, char **argv)
internal_config.process_type != RTE_PROC_SECONDARY 
&&
internal_config.xen_dom0_support == 0 &&
eal_hugepage_info_init() < 0)
-   rte_panic("Cannot get hugepage information\n");
+   return -1;

if (internal_config.memory == 0 && internal_config.force_sockets 
== 0) {
if (internal_config.no_hugetlbfs)
@@ -756,41 +741,43 @@ rte_eal_init(int argc, char **argv)
rte_config_init();

if (rte_eal_pci_init() < 0)
-   rte_panic("Cannot init PCI\n");
+   return -1;

 #ifdef RTE_LIBRTE_IVSHMEM
if (rte_eal_ivshmem_init() < 0)
-   rte_panic("Cannot init IVSHMEM\n");
+   return -1;
 #endif

if (rte_eal_memory_init() < 0)
-   rte_panic("Cannot init memory\n");
+   return -1;

/* the directories are locked during eal_hugepage_info_init */
eal_hugedirs_unlock();

if (rte_eal_memzone_init() < 0)
-   rte_panic("Cannot init memzone\n");
+   return -1;

if (rte_eal_tailqs_init() < 0)
-   rte_panic("Cannot init tail queues for objects\n");
+   return -1;

 #ifdef RTE_LIBRTE_IVSHMEM
if (rte_eal_ivshmem_obj_init() < 0)
-   rte_panic("Cannot init IVSHMEM objects\n");
+   return -1;
 #endif

if (rte_eal_log_init(logid, internal_config.syslog_facility) < 0)
-   rte_panic("Cannot init logs\n");
+   return -1;

if (rte_eal_alarm_init() < 0)
-   rte_panic("Cannot init interrupt-handling thread\n");
+   return -1;

+   /* interrupt handling will be initialized but the thread is 
patched to immediately exit */
if (rte_eal_intr_init() < 0)
-   rte_panic("Cannot init interrupt-handling thread\n");
+   return -1;

+   /* timer stuff is initialized but hpet should be disabled in 
configuration */
if (rte_eal_timer_init() < 0)
-   rte_panic("Cannot init HPET or TSC timers\n");
+   return -1;

eal_check_mem_on_local_socket();

@@ -803,47 +790,12 @@ rte_eal_init(int argc, char **argv)
RTE_LOG(WARNING, EAL, "%s\n", dlerror());
}

-   eal_thread_init_master(rte_config.master_lcore);
-
-   ret = eal_thread_dump_affinity(cpuset, RTE_CPU_AFFINITY_STR_LEN);
-
-   RTE_LOG(DEBUG, EAL, "Master lcore %u is ready 
(tid=%x;cpuset=[%s%s])\n",
-   rte_config.master_lcore, (int)thread_id, cpuset,
-   ret == 0 ? "" : "...");
-
if (rte_eal_dev_init() < 0)
-   rte_panic("Cannot init pmd devices\n");
-
-   RTE_LCORE_FOREACH_SLAVE(i) {
-
-   /*
-* create communication pipes between master thread
-* and children
-*/
-   if (pipe(lcore_config[i].pipe_master2slave) < 0)
-   rte_panic("Cannot create pipe\n");
-   if (pipe(lcore_config[i].pipe_slave2master) < 0)
-   rte_panic("Cannot create pipe\n");
-
-   lcore_config[i].state = WAIT;
-
-   /* create a thread for each lcore */
-   ret = pthread_create(_config[i].thread_id, NULL,
-eal_thread_loop, NULL);
-   if (ret != 0)
-   rte_panic("Cannot create thread\n");
-   }
-
-   /*
-* Launch a dummy function on all slave lcores, so that master 
lcore
-* 

[dpdk-dev] Application framework vs. library

2016-08-01 Thread steffen.ba...@rohde-schwarz.com
>From c3be5420d921325559de9b1079354e1c4314220a Mon Sep 17 00:00:00 2001
From: Steffen Bauch 
Date: Mon, 25 Jul 2016 16:13:02 +0200
Subject: [PATCH] allow the call to rte_openlog_stream() before 
rte_eal_init()

- only initialize the default_log_stream if it was not initialized
  before main initialization of EAL
- save facility and logid in rte_default_log_args structure
- call openlog only on setup of the default_log_stream in 
rte_openlog_stream
---
 lib/librte_eal/bsdapp/eal/eal_log.c |  6 ++---
 lib/librte_eal/common/eal_common_log.c  | 47 
++---
 lib/librte_eal/common/eal_private.h | 40 +---
 lib/librte_eal/common/include/rte_log.h |  7 +
 lib/librte_eal/linuxapp/eal/eal_log.c   | 24 +
 5 files changed, 110 insertions(+), 14 deletions(-)

diff --git a/lib/librte_eal/bsdapp/eal/eal_log.c 
b/lib/librte_eal/bsdapp/eal/eal_log.c
index a425f7a..5abd906 100644
--- a/lib/librte_eal/bsdapp/eal/eal_log.c
+++ b/lib/librte_eal/bsdapp/eal/eal_log.c
@@ -42,9 +42,9 @@
  * once memzones are available.
  */
 int
-rte_eal_log_init(const char *id __rte_unused, int facility __rte_unused)
+rte_eal_log_init(const char *id, int facility)
 {
-   if (rte_eal_common_log_init(stderr) < 0)
+   if (rte_eal_common_log_init(stderr, id, facility) < 0)
return -1;
return 0;
 }
@@ -52,6 +52,6 @@ rte_eal_log_init(const char *id __rte_unused, int 
facility __rte_unused)
 int
 rte_eal_log_early_init(void)
 {
-   rte_openlog_stream(stderr);
+   rte_openlog_stream_initial(stderr);
return 0;
 }
diff --git a/lib/librte_eal/common/eal_common_log.c 
b/lib/librte_eal/common/eal_common_log.c
index 7916c78..197e6c9 100644
--- a/lib/librte_eal/common/eal_common_log.c
+++ b/lib/librte_eal/common/eal_common_log.c
@@ -48,6 +48,14 @@ struct rte_logs rte_logs = {
.file = NULL,
 };

+struct rte_default_log_args rte_default_log_args =
+{
+.facility = 0,
+.log_id = NULL,
+.prepare_default_log = NULL,
+};
+
+
 static FILE *default_log_stream;

 /**
@@ -82,9 +90,30 @@ int
 rte_openlog_stream(FILE *f)
 {
if (f == NULL)
+   {
+   if (rte_default_log_args.prepare_default_log)
+   {
+   if 
(rte_default_log_args.prepare_default_log(rte_default_log_args.log_id,
+   rte_default_log_args.facility) < 
0)
+   return -1;
+   }
rte_logs.file = default_log_stream;
+   }
else
+   {
rte_logs.file = f;
+   }
+   return 0;
+}
+
+int
+rte_openlog_stream_initial(FILE *f)
+{
+   /* only initialize if not configured before rte_eal_init() */
+   if (NULL == rte_logs.file)
+   {
+   return rte_openlog_stream(f);
+   }
return 0;
 }

@@ -176,14 +205,26 @@ rte_log(uint32_t level, uint32_t logtype, const char 
*format, ...)
return ret;
 }

+int rte_eal_set_default_log_stream(FILE *default_log,  const char *id, 
int facility,
+int (*prepare_log)(const char 
*log_id, int facility))
+{
+   rte_default_log_args.facility = facility;
+   rte_default_log_args.log_id = id;
+   rte_default_log_args.prepare_default_log = prepare_log;
+   default_log_stream = default_log;
+
+   return 0;
+}
+
 /*
  * called by environment-specific log init function
  */
 int
-rte_eal_common_log_init(FILE *default_log)
+rte_eal_common_log_init(FILE *default_log, const char *id, int facility,
+int (*prepare_log)(const char *log_id, int 
facility))
 {
-   default_log_stream = default_log;
-   rte_openlog_stream(default_log);
+   rte_eal_set_default_log_stream(default_log, id, facility, 
prepare_log);
+   rte_openlog_stream_initial(NULL); /* enable default log stream */

 #if RTE_LOG_LEVEL >= RTE_LOG_DEBUG
RTE_LOG(NOTICE, EAL, "Debug logs available - lower 
performance\n");
diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index 857dc3e..f12a00d 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -49,13 +49,26 @@ int rte_eal_memzone_init(void);
 /**
  * Common log initialization function (private to eal).
  *
- * @param default_log
- *   The default log stream to be used.
+ * @param default_log The default log stream to be used.
+ * @param id the id used for openlog call
+ * @param facility the facility used for openlog call
+ * @param prepare_log a platform specific log prepare function
  * @return
  *   - 0 on success
  *   - Negative on error
  */
-int rte_eal_common_log_init(FILE *default_log);
+int rte_eal_common_log_init(FILE *default_log, const char *id, int 
facility,
+  int (*prepare_log)(const char *log_id, int 
facility));
+
+/**
+ * A function that only sets the log stream if it has 

[dpdk-dev] [PATCH] ethdev: fix a typo in eth device API doc

2016-08-01 Thread Nikhil Rao
This patch fixes a typo in the eth device API doc, device
config. not stored between calls to rte_eth_dev_start/stop()
should be restored before a call to rte_eth_dev_start()
instead of after a call to rte_eth_dev_start().

Signed-off-by: Nikhil Rao 
---
 lib/librte_ether/rte_ethdev.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index b0fe033..099aeb1 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -118,7 +118,7 @@
  * - NIC queue statistics mappings
  *
  * Any other configuration will not be stored and will need to be re-entered
- * after a call to rte_eth_dev_start().
+ * before a call to rte_eth_dev_start().
  *
  * Finally, a network application can close an Ethernet device by invoking the
  * rte_eth_dev_close() function.
-- 
2.7.4



[dpdk-dev] Application framework vs. library

2016-08-01 Thread steffen.ba...@rohde-schwarz.com
Hi,

as a developer of a product that uses DPDK I inherited a custom changeset
towards DPDK 2.0 to allow better integration into our application stack. I
am currently underway of updating the used DPDK release and would like to
get rid of these local changes in the future by influencing the upstream
development to some degree.

Concerning the integration we try to cope with the circumstance that
DPDK is more comparable to an application framework and less to a
library. The main part of the changes deal with EAL and specifically with
rte_eal_init() and prune or replace functionality. The pruned features
are in the responsibility of other proprietary libraries and modules
within our application. For illustration purposes, I have included an
old changeset towards v2.0.0. for reference, but due to the nature
of the whole changeset it does not make sense to apply it directly,
as there is a total lack of generality in the specific implementation
(e.g. only the linuxapp part is customized, incomplete implemented concept
in termination behavior ...). Nonetheless I am underway of researching
concepts and approaches that are general enough for upstream inclusion.

The main reason for attaching this patchset is to be able to discuss
possible approaches of further development, as I would like to get
feedback on possible development approaches to address the named problems.

In detail the changes address the following areas:

Logging behavior

Opening a connection to the system logger for our program is within the
responsibility of our specific logging module that is also used in the
proprietary parts of the application. For this reason openlog() should
not be called in our use case. In addition, using rte_openlog_stream()
is not usable before rte_eal_init() as logging init will overwrite the
used log stream. For this reason a large part of the init logs can not
be handled by a custom log stream. Btw, after removal of the log caching,
is there a fundamental difference between early log and normal logging?

A possible approach for the future could be to initialize rte_logs.file
to NULL (in fact it is, as it is static) and only set it during
initialization if it is NULL with the goal to be able to use
rte_openlog_stream() before rte_eal_init(). As the openlog() call is
only relevant when the default log stream is used (and architecture
dependent!) I introduced a specific entry point for calling openlog. The
main complexity to this changeset is added due to two reasons. First
reason is the circumstance that rte_eal_common_log_init() is used several
times during early logging and real logging initialization. Second
aspect is that a user might revert to the use of the default_log_stream
after a custom log stream has be used straight from the beginning (even
before rte_eal_init()). A dedicated changeset towards v16.07 for this
improvement is attached for review, feedback and possible inclusion.

Process termination behavior

As the DPDK functionality is only a small part of the whole application
ownership of the running process is not with DPDK and it is not allowed
to cancel the running process as a result of an error. For this reason,
the current changeset instead of calling rte_panic or rte_exit returns
an error code and handles it in the calling function. Unfortunately this
change was only implemented in rte_eal_init() and not in other places
(drivers, libs ...), so there is currently no safety that an unknown
code part terminates the whole application on the spot. Future changes
and patches could change the error handling in a more thorough approach,
but I would like to have some feedback and opinions before I start the
heavy-lifting work in over 700 code locations. Even some interfaces
might be affected, as lots of functions return void now,

Thread creation

In our application thread creation and setting the affinity is already
handled in a proprietary module. Frames are polled and processed
in non-EAL pthreads. For this reason the lcore thread creation in
rte_eal_init() is completely removed as we do not want additional threads
to be assigned to processing CPUs. Unfortunately setting the coremask
to 0 is not feasible directly. For the non-EAL threads a custom function
within the application sets the per_thread _lcore variable to the right
value to try to enable mbuf cacheing. The changeset also disables the
interrupt handling thread as in our application it currently seems not
necessary (maybe make this optional?)

In an experiment I removed the error check for the non-zero number of
lcores and quick-fixed certain locations where rte_lcore_count() is used
for memory size computations and at least got a running application.

A possible approach could be to enhance enum rte_lcore_role_t with an
auxiliary thread type and introduce additional eal arguments to assign
lcores with these auxiliary role.

I would like to receive feedback on possible development directions.

Thank you,

Steffen Bauch




-- 

Steffen Bauch

[dpdk-dev] dpdk-pktgen how to show more than 4 ports in one page?

2016-08-01 Thread linhaifeng
 2016/7/30 21:30, Wiles, Keith :
>> On Jul 30, 2016, at 1:03 AM, linhaifeng  wrote:
>>
>> hi
>>
>> I use 6 ports to send pkts in VM, but can only 4 ports work, how to enable 
>> more ports to work?
>>
> In the help screen the command ?ppp [1-6]? is ports per page.
> 
> 
Thank you very much.

It works very good with 5 ports per page and the UI is very beautiful.
Thers is a probrem with 6 ports per page in my view -- The last column is show 
replace of the first column.

BTW is it support show latency and jitter ?
is it support save the result in pdf of excel?



[dpdk-dev] [PATCH v2] net/i40e: fix Rx statistic inconsistent

2016-08-01 Thread Zhao1, Wei
Hi, Kyle Larose 
   The core problem is i40e has no statistic of discard bytes, that means even 
if when ports are not stopped, the  
statistic  rx_good_bytes is consist of discard bytes?is that reasonable? In 
other words, I can just minus discard bytes  
from rx_good_bytes if I can get discard bytes number, that is much better.

-Original Message-
From: Kyle Larose [mailto:eomerea...@gmail.com] 
Sent: Saturday, July 30, 2016 1:17 AM
To: Zhao1, Wei 
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] net/i40e: fix Rx statistic inconsistent

On Fri, Jul 29, 2016 at 4:50 AM, Wei Zhao1  wrote:
> rx_good_bytes and rx_good_packets statistic is inconsistent when port 
> stopped,ipackets statistic is minus the discard packets but rx_bytes 
> statistic not.Also,i40e has no statistic of discard bytes, so we have 
> to delete discard packets item from rx_good_packets statistic.
>
> Fixes: 9aace75fc82e ("i40e: fix statistics")
>
> Signed-off-by: Wei Zhao1 
> ---
>  drivers/net/i40e/i40e_ethdev.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c 
> b/drivers/net/i40e/i40e_ethdev.c index 11a5804..553dfd9 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -2319,8 +2319,7 @@ i40e_dev_stats_get(struct rte_eth_dev *dev, 
> struct rte_eth_stats *stats)
>
> stats->ipackets = pf->main_vsi->eth_stats.rx_unicast +
> pf->main_vsi->eth_stats.rx_multicast +
> -   pf->main_vsi->eth_stats.rx_broadcast -
> -   pf->main_vsi->eth_stats.rx_discards;
> +   pf->main_vsi->eth_stats.rx_broadcast;
> stats->opackets = pf->main_vsi->eth_stats.tx_unicast +
> pf->main_vsi->eth_stats.tx_multicast +
> pf->main_vsi->eth_stats.tx_broadcast;
> --
> 2.5.5
>

Is it not worse to report a received packet when no packet was actually 
received by the upper layers under normal operations than to ensure that 
packets and  bytes are consistent when an interface is stopped? It seems like 
the first case is much more likely to occur than the second.

Are we just introducing a new issue to fix another?

How does this behaviour compare to other NICs? Does the ixgbe report discarded 
packets in its ipackets? My reading of the driver is that it does not. In fact, 
it does something interesting to deal with the
problem:

from: http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/ixgbe_ethdev.c

/*
* An errata states that gprc actually counts good + missed packets:
* Workaround to set gprc to summated queue packet receives */ hw_stats->gprc = 
*total_qprc;

total_gprc is equal to the sum of the qprc per queue. Can we do something 
similar on the i40e instead of adding unicast, mulitcast and broadcast?


[dpdk-dev] [PATCH 0/2] add ensure consistent device data in multiprocess mode

2016-08-01 Thread Kerlin, MarcinX
Self-Nack this patch because the commit log needs change.

> -Original Message-
> From: Kerlin, MarcinX
> Sent: Friday, July 29, 2016 5:57 PM
> To: dev at dpdk.org
> Cc: De Lara Guarch, Pablo ;
> thomas.monjalon at 6wind.com; Kerlin, MarcinX 
> Subject: [PATCH 0/2] add ensure consistent device data in multiprocess mode
> 
> This patch ensure not overwrite device data in the multiprocess application.
> 
> 1)Changes in the library introduces continuity in device data
> rte_eth_dev_data[] common for to all processes. Functionality detach cleans
> data of detachable device and leaves space for other devices or for the next
> run app.
> 
> 2)Changes in application testpmd allow secondary process to attach the
> mempool created by primary process rather than create new and in the case of
> quit or force quit to free devices of this process from shared array
> rte_eth_dev_data[].
> 
> Marcin Kerlin (2):
>   lib/librte_ether: ensure not overwrite device data in multiprocess app
>   app/testpmd: fix handling of multiprocess
> 
>  app/test-pmd/testpmd.c | 30 +++-
>  app/test-pmd/testpmd.h |  1 +
>  lib/librte_ether/rte_ethdev.c  | 87 ++---
> -
>  lib/librte_ether/rte_ethdev.h  | 23 +
>  lib/librte_ether/rte_ether_version.map |  8 
>  5 files changed, 139 insertions(+), 10 deletions(-)
> 
> --
> 1.9.1



[dpdk-dev] [PATCH] net/i40e: Fix a typo in a comment (Fortville instead of IXGBE).

2016-08-01 Thread Rami Rosen
This patch fixes a typo in a comment in i40e_ethdev.c: use Fortville instead of 
IXGBE. 

Signed-off-by: Rami Rosen 
---
 drivers/net/i40e/i40e_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index d0aeb70..fd95f5f 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -704,7 +704,7 @@ rte_i40e_dev_atomic_write_link_status(struct rte_eth_dev 
*dev,
 /*
  * Driver initialization routine.
  * Invoked once at EAL init time.
- * Register itself as the [Poll Mode] Driver of PCI IXGBE devices.
+ * Register itself as the [Poll Mode] Driver of PCI Fortville devices.
  */
 static int
 rte_i40e_pmd_init(const char *name __rte_unused,
-- 
2.7.4



[dpdk-dev] [PATCH] validate_abi: build faster by augmenting make with job count

2016-08-01 Thread Neil Horman
On Sun, Jul 24, 2016 at 06:08:00PM +, Wiles, Keith wrote:
> 
> 
> Sent from my iPhone
> 
> > On Jul 21, 2016, at 1:34 PM, Neil Horman  wrote:
> > 
> >> On Thu, Jul 21, 2016 at 03:22:45PM +, Wiles, Keith wrote:
> >> 
> >>> On Jul 21, 2016, at 10:06 AM, Neil Horman  wrote:
> >>> 
> >>> On Thu, Jul 21, 2016 at 02:09:19PM +, Wiles, Keith wrote:
>  
> > On Jul 21, 2016, at 8:54 AM, Neil Horman  
> > wrote:
> > 
> > On Wed, Jul 20, 2016 at 10:32:28PM +, Wiles, Keith wrote:
> >> 
> >>> On Jul 20, 2016, at 3:16 PM, Neil Horman  
> >>> wrote:
> >>> 
> >>> On Wed, Jul 20, 2016 at 07:47:32PM +, Wiles, Keith wrote:
>  
> > On Jul 20, 2016, at 12:48 PM, Neil Horman  
> > wrote:
> > 
> > On Wed, Jul 20, 2016 at 07:40:49PM +0200, Thomas Monjalon wrote:
> >> 2016-07-20 13:09, Neil Horman:
> >>> From: Neil Horman 
> >>> 
> >>> John Mcnamara and I were discussing enhacing the validate_abi 
> >>> script to build
> >>> the dpdk tree faster with multiple jobs.  Theres no reason not to 
> >>> do it, so this
> >>> implements that requirement.  It uses a MAKE_JOBS variable that 
> >>> can be set by
> >>> the user to limit the job count.  By default the job count is set 
> >>> to the number
> >>> of online cpus.
> >> 
> >> Please could you use the variable name DPDK_MAKE_JOBS?
> >> This name is already used in scripts/test-build.sh.
> > Sure
> > 
> >>> +if [ -z "$MAKE_JOBS" ]
> >>> +then
> >>> +# This counts the number of cpus on the system
> >>> +MAKE_JOBS=`lscpu -p=cpu | grep -v "#" | wc -l`
> >>> +fi
> >> 
> >> Is lscpu common enough?
> > I'm not sure how to answer that.  lscpu is part of the util-linux 
> > package, which
> > is part of any base install.  Theres a variant for BSD, but I'm not 
> > sure how
> > common it is there.
> > Neil
> > 
> >> Another acceptable default would be just "-j" without any number.
> >> It would make the number of jobs unlimited.
>  
>  I think the best is just use -j as it tries to use the correct 
>  number of jobs based on the number of cores, right?
> >>> -j with no argument (or -j 0), is sort of, maybe what you want.  With 
> >>> either of
> >>> those options, make will just issue jobs as fast as it processes 
> >>> dependencies.
> >>> Dependent on how parallel the build is, that can lead to tons of 
> >>> waiting process
> >>> (i.e. more than your number of online cpus), which can actually hurt 
> >>> your build
> >>> time.
> >> 
> >> I read the manual and looked at the code, which supports your 
> >> statement. (I think I had some statement on stack overflow and the 
> >> last time I believe anything on the internet :-) I have not seen a lot 
> >> of differences in compile times with -j on my system. Mostly I suspect 
> >> it is the number of paths in the dependency, cores and memory on the 
> >> system.
> >> 
> >> I have 72 lcores or 2 sockets, 18 cores per socket. Xeon 2.3Ghz cores.
> >> 
> >> $ export RTE_TARGET=x86_64-native-linuxapp-gcc 
> >> 
> >> $ time make install T=${RTE_TARGET}
> >> real0m59.445s user0m27.344s sys0m7.040s
> >> 
> >> $ time make install T=${RTE_TARGET} -j
> >> real0m26.584s user0m14.380s sys0m5.120s
> >> 
> >> # Remove the x86_64-native-linuxapp-gcc
> >> 
> >> $ time make install T=${RTE_TARGET} -j 72
> >> real0m23.454s user0m10.832s sys0m4.664s
> >> 
> >> $ time make install T=${RTE_TARGET} -j 8
> >> real0m23.812s user0m10.672s sys0m4.276s
> >> 
> >> cd x86_64-native-linuxapp-gcc
> >> $ make clean
> >> $ time make
> >> real0m28.539s user0m9.820s sys0m3.620s
> >> 
> >> # Do a make clean between each build.
> >> 
> >> $ time make -j
> >> real0m7.217s user0m6.532s sys0m2.332s
> >> 
> >> $ time make -j 8
> >> real0m8.256s user0m6.472s sys0m2.456s
> >> 
> >> $ time make -j 72
> >> real0m6.866s user0m6.184s sys0m2.216s
> >> 
> >> Just the real time numbers in the following table.
> >> 
> >> processes real Time   depdirs
> >>   no -j 59.4sYes
> >> -j 8 23.8sYes
> >>-j 7223.5sYes
> >>  -j   26.5sYes
> >> 
> >>   no -j 28.5s No
> >> -j 8   8.2s No
> >>-j 72  6.8s No
> >>  -j 7.2s No
> >> 
> >> Looks like the depdirs build time on my system:
> 

[dpdk-dev] dpdk example qos meter compile error

2016-08-01 Thread 张伟

Please ignore this message. It works. I just made a mistake by myself. Sorry. 







At 2016-08-01 06:10:24, "??"  wrote:
>Hi, 
>
>
>I want to compile and run dpdk example qos_meter. But it shows compile errors. 
>
>
>qos_meter/rte_policer.h:34:20: error: #include nested too deeply
>
>qos_meter/rte_policer.h:35:25: error: #include nested too deeply
>
>qos_meter/rte_policer.h:38:43: error: unknown type name ?uint32_t?
>
>...
>
>I am using dpdk-16.04. Does anyone know how to fix the bugs? 


[dpdk-dev] dpdk example qos meter compile error

2016-08-01 Thread 张伟
Hi, 


I want to compile and run dpdk example qos_meter. But it shows compile errors. 


qos_meter/rte_policer.h:34:20: error: #include nested too deeply

qos_meter/rte_policer.h:35:25: error: #include nested too deeply

qos_meter/rte_policer.h:38:43: error: unknown type name ?uint32_t?

...

I am using dpdk-16.04. Does anyone know how to fix the bugs? 


[dpdk-dev] [PATCH v4 3/3] app/testpmd: fix Tx offload on tunneling packet

2016-08-01 Thread Jianfeng Tan
Tx offload on tunneling packet now requires applications to correctly
set tunneling type. Without setting it, i40e driver does not parse
tunneling parameters. Besides that, add a check to see if NIC supports
TSO on tunneling packet when executing "csum parse_tunnel on _port"
after "tso set _size _port" or the other way around.

Fixes: b51c47536a9e ("app/testpmd: support TSO in checksum forward engine")

Signed-off-by: Zhe Tao 
Signed-off-by: Jianfeng Tan 
---
 app/test-pmd/cmdline.c  | 42 --
 app/test-pmd/csumonly.c | 37 +
 2 files changed, 65 insertions(+), 14 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index f90befc..561839f 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -3426,6 +3426,26 @@ struct cmd_csum_tunnel_result {
 };

 static void
+check_tunnel_tso_support(uint8_t port_id)
+{
+   struct rte_eth_dev_info dev_info;
+
+   rte_eth_dev_info_get(port_id, _info);
+   if (!(dev_info.tx_offload_capa & DEV_TX_OFFLOAD_VXLAN_TNL_TSO))
+   printf("Warning: TSO enabled but VXLAN TUNNEL TSO not "
+  "supported by port %d\n", port_id);
+   if (!(dev_info.tx_offload_capa & DEV_TX_OFFLOAD_GRE_TNL_TSO))
+   printf("Warning: TSO enabled but GRE TUNNEL TSO not "
+   "supported by port %d\n", port_id);
+   if (!(dev_info.tx_offload_capa & DEV_TX_OFFLOAD_IPIP_TNL_TSO))
+   printf("Warning: TSO enabled but IPIP TUNNEL TSO not "
+  "supported by port %d\n", port_id);
+   if (!(dev_info.tx_offload_capa & DEV_TX_OFFLOAD_GENEVE_TNL_TSO))
+   printf("Warning: TSO enabled but GENEVE TUNNEL TSO not "
+  "supported by port %d\n", port_id);
+}
+
+static void
 cmd_csum_tunnel_parsed(void *parsed_result,
   __attribute__((unused)) struct cmdline *cl,
   __attribute__((unused)) void *data)
@@ -3435,10 +3455,13 @@ cmd_csum_tunnel_parsed(void *parsed_result,
if (port_id_is_invalid(res->port_id, ENABLED_WARN))
return;

-   if (!strcmp(res->onoff, "on"))
+   if (!strcmp(res->onoff, "on")) {
ports[res->port_id].tx_ol_flags |=
TESTPMD_TX_OFFLOAD_PARSE_TUNNEL;
-   else
+
+   if (ports[res->port_id].tso_segsz != 0)
+   check_tunnel_tso_support(res->port_id);
+   } else
ports[res->port_id].tx_ol_flags &=
(~TESTPMD_TX_OFFLOAD_PARSE_TUNNEL);

@@ -3502,10 +3525,17 @@ cmd_tso_set_parsed(void *parsed_result,

/* display warnings if configuration is not supported by the NIC */
rte_eth_dev_info_get(res->port_id, _info);
-   if ((ports[res->port_id].tso_segsz != 0) &&
-   (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_TCP_TSO) == 0) {
-   printf("Warning: TSO enabled but not "
-   "supported by port %d\n", res->port_id);
+   if (ports[res->port_id].tso_segsz != 0) {
+   if (ports[res->port_id].tx_ol_flags &
+   TESTPMD_TX_OFFLOAD_PARSE_TUNNEL)
+   check_tunnel_tso_support(res->port_id);
+   /* For packets,
+* (1) when tnl parse is disabled;
+* (2) when tnl parse is enabled but not deemed as tnl pkts
+*/
+   if (!(dev_info.tx_offload_capa & DEV_TX_OFFLOAD_TCP_TSO))
+   printf("Warning: TSO enabled but not "
+  "supported by port %d\n", res->port_id);
}
 }

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index ac4bd8f..0a1f95d 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -412,12 +412,10 @@ process_inner_cksums(void *l3_hdr, const struct 
testpmd_offload_info *info,
return ol_flags;
 }

-/* Calculate the checksum of outer header (only vxlan is supported,
- * meaning IP + UDP). The caller already checked that it's a vxlan
- * packet */
+/* Calculate the checksum of outer header */
 static uint64_t
 process_outer_cksums(void *outer_l3_hdr, struct testpmd_offload_info *info,
-   uint16_t testpmd_ol_flags)
+   uint16_t testpmd_ol_flags, int tso_enabled)
 {
struct ipv4_hdr *ipv4_hdr = outer_l3_hdr;
struct ipv6_hdr *ipv6_hdr = outer_l3_hdr;
@@ -438,10 +436,20 @@ process_outer_cksums(void *outer_l3_hdr, struct 
testpmd_offload_info *info,
if (info->outer_l4_proto != IPPROTO_UDP)
return ol_flags;

-   /* outer UDP checksum is always done in software as we have no
-* hardware supporting it today, and no API for it. */
-
udp_hdr = (struct udp_hdr *)((char *)outer_l3_hdr + info->outer_l3_len);
+
+   /* outer UDP checksum is done in software as we have no hardware
+* supporting it today, and no API for it. In the other side, for
+

[dpdk-dev] [PATCH v4 2/3] net/i40e: add TSO support on tunneling packet

2016-08-01 Thread Jianfeng Tan
To enable Tx side offload on tunneling packet, driver should set
correct tunneling parameters: (1) EIPT, External IP header type;
(2) EIPLEN, External IP; (3) L4TUNT; (4) L4TUNLEN. This parsing
behavior is based on (ol_flag & PKT_TX_TUNNEL_MASK). And when
it's a tunneling packet, MACLEN defines the outer L2 header.

Also, we define TSO on each kind of tunneling type as a capabilities.
Now only i40e declares to support them.

Signed-off-by: Zhe Tao 
Signed-off-by: Jianfeng Tan 
---
 drivers/net/i40e/i40e_ethdev.c |  6 ++-
 drivers/net/i40e/i40e_rxtx.c   | 90 +-
 lib/librte_ether/rte_ethdev.h  |  4 ++
 3 files changed, 72 insertions(+), 28 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index d0aeb70..64ba570 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2576,7 +2576,11 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
DEV_TX_OFFLOAD_TCP_CKSUM |
DEV_TX_OFFLOAD_SCTP_CKSUM |
DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM |
-   DEV_TX_OFFLOAD_TCP_TSO;
+   DEV_TX_OFFLOAD_TCP_TSO |
+   DEV_TX_OFFLOAD_VXLAN_TNL_TSO |
+   DEV_TX_OFFLOAD_GRE_TNL_TSO |
+   DEV_TX_OFFLOAD_IPIP_TNL_TSO |
+   DEV_TX_OFFLOAD_GENEVE_TNL_TSO;
dev_info->hash_key_size = (I40E_PFQF_HKEY_MAX_INDEX + 1) *
sizeof(uint32_t);
dev_info->reta_size = pf->hash_lut_size;
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 554d167..4eac713 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -779,33 +779,65 @@ i40e_rxd_build_fdir(volatile union i40e_rx_desc *rxdp, 
struct rte_mbuf *mb)
 #endif
return flags;
 }
+
+static inline void
+i40e_parse_tunneling_params(uint64_t ol_flags,
+   union i40e_tx_offload tx_offload,
+   uint32_t *cd_tunneling)
+{
+   /* EIPT: External (outer) IP header type */
+   if (ol_flags & PKT_TX_OUTER_IP_CKSUM)
+   *cd_tunneling |= I40E_TX_CTX_EXT_IP_IPV4;
+   else if (ol_flags & PKT_TX_OUTER_IPV4)
+   *cd_tunneling |= I40E_TX_CTX_EXT_IP_IPV4_NO_CSUM;
+   else if (ol_flags & PKT_TX_OUTER_IPV6)
+   *cd_tunneling |= I40E_TX_CTX_EXT_IP_IPV6;
+
+   /* EIPLEN: External (outer) IP header length, in DWords */
+   *cd_tunneling |= (tx_offload.outer_l3_len >> 2) <<
+   I40E_TXD_CTX_QW0_EXT_IPLEN_SHIFT;
+
+   /* L4TUNT: L4 Tunneling Type */
+   switch (ol_flags & PKT_TX_TUNNEL_MASK) {
+   case PKT_TX_TUNNEL_IPIP:
+   /* for non UDP / GRE tunneling, set to 00b */
+   break;
+   case PKT_TX_TUNNEL_VXLAN:
+   case PKT_TX_TUNNEL_GENEVE:
+   *cd_tunneling |= I40E_TXD_CTX_UDP_TUNNELING;
+   break;
+   case PKT_TX_TUNNEL_GRE:
+   *cd_tunneling |= I40E_TXD_CTX_GRE_TUNNELING;
+   break;
+   default:
+   PMD_TX_LOG(ERR, "Tunnel type not supported\n");
+   return;
+   }
+
+   /* L4TUNLEN: L4 Tunneling Length, in Words
+*
+* We depend on app to set rte_mbuf.l2_len correctly.
+* For IP in GRE it should be set to the length of the GRE
+* header;
+* for MAC in GRE or MAC in UDP it should be set to the length
+* of the GRE or UDP headers plus the inner MAC up to including
+* its last Ethertype.
+*/
+   *cd_tunneling |= (tx_offload.l2_len >> 1) <<
+   I40E_TXD_CTX_QW0_NATLEN_SHIFT;
+}
+
 static inline void
 i40e_txd_enable_checksum(uint64_t ol_flags,
uint32_t *td_cmd,
uint32_t *td_offset,
-   union i40e_tx_offload tx_offload,
-   uint32_t *cd_tunneling)
+   union i40e_tx_offload tx_offload)
 {
-   /* UDP tunneling packet TX checksum offload */
-   if (ol_flags & PKT_TX_OUTER_IP_CKSUM) {
-
+   /* Set MACLEN */
+   if (ol_flags & PKT_TX_TUNNEL_MASK)
*td_offset |= (tx_offload.outer_l2_len >> 1)
<< I40E_TX_DESC_LENGTH_MACLEN_SHIFT;
-
-   if (ol_flags & PKT_TX_OUTER_IP_CKSUM)
-   *cd_tunneling |= I40E_TX_CTX_EXT_IP_IPV4;
-   else if (ol_flags & PKT_TX_OUTER_IPV4)
-   *cd_tunneling |= I40E_TX_CTX_EXT_IP_IPV4_NO_CSUM;
-   else if (ol_flags & PKT_TX_OUTER_IPV6)
-   *cd_tunneling |= I40E_TX_CTX_EXT_IP_IPV6;
-
-   /* Now set the ctx descriptor fields */
-   *cd_tunneling |= (tx_offload.outer_l3_len >> 2) <<
-   I40E_TXD_CTX_QW0_EXT_IPLEN_SHIFT |
-   (tx_offload.l2_len >> 1) <<
-   

[dpdk-dev] [PATCH v4 1/3] mbuf: add Tx side tunneling type

2016-08-01 Thread Jianfeng Tan
To support tunneling packet offload capabilities on Tx side, PMDs
(e.g., i40e) need to know what kind of tunneling type of this packet.
Instead of analyzing the packet itself, we depend on applications to
correctly set the tunneling type. These flags are defined inside
rte_mbuf.ol_flags.

Signed-off-by: Zhe Tao 
Signed-off-by: Jianfeng Tan 
---
 lib/librte_mbuf/rte_mbuf.c |  4 
 lib/librte_mbuf/rte_mbuf.h | 17 -
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 4846b89..4505abb 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -302,6 +302,10 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask)
case PKT_TX_OUTER_IP_CKSUM: return "PKT_TX_OUTER_IP_CKSUM";
case PKT_TX_OUTER_IPV4: return "PKT_TX_OUTER_IPV4";
case PKT_TX_OUTER_IPV6: return "PKT_TX_OUTER_IPV6";
+   case PKT_TX_TUNNEL_VXLAN: return "PKT_TX_TUNNEL_VXLAN";
+   case PKT_TX_TUNNEL_GRE: return "PKT_TX_TUNNEL_GRE";
+   case PKT_TX_TUNNEL_IPIP: return "PKT_TX_TUNNEL_IPIP";
+   case PKT_TX_TUNNEL_GENEVE: return "PKT_TX_TUNNEL_GENEVE";
default: return NULL;
}
 }
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 101485f..0eec112 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -129,6 +129,18 @@ extern "C" {
 /* add new TX flags here */

 /**
+ * Bits 45:48 used for the tunnel type.
+ * When doing Tx offload like TSO or checksum, the HW needs to configure the
+ * tunnel type into the HW descriptors.
+ */
+#define PKT_TX_TUNNEL_VXLAN   (0x1ULL << 45)
+#define PKT_TX_TUNNEL_GRE (0x2ULL << 45)
+#define PKT_TX_TUNNEL_IPIP(0x3ULL << 45)
+#define PKT_TX_TUNNEL_GENEVE  (0x4ULL << 45)
+/* add new TX TUNNEL type here */
+#define PKT_TX_TUNNEL_MASK(0xFULL << 45)
+
+/**
  * Second VLAN insertion (QinQ) flag.
  */
 #define PKT_TX_QINQ_PKT(1ULL << 49)   /**< TX packet with double VLAN 
inserted. */
@@ -863,7 +875,10 @@ struct rte_mbuf {
union {
uint64_t tx_offload;   /**< combined for easy fetch */
struct {
-   uint64_t l2_len:7; /**< L2 (MAC) Header Length. */
+   uint64_t l2_len:7;
+   /**< L2 (MAC) Header Length for non-tunneling pkt.
+* Outer_L4_len + ... + Inner_L2_len for tunneling pkt.
+*/
uint64_t l3_len:9; /**< L3 (IP) Header Length. */
uint64_t l4_len:8; /**< L4 (TCP/UDP) Header Length. */
uint64_t tso_segsz:16; /**< TCP TSO segment size */
-- 
2.7.4



[dpdk-dev] [PATCH v4 0/3] Add TSO on tunneling packet

2016-08-01 Thread Jianfeng Tan
Patch 1: mbuf: add Tx side tunneling type
Patch 2: net/i40e: add TSO support on tunneling packet
Patch 3: app/testpmd: fix Tx offload on tunneling packet

v4:
  - According to tunnel type flag to parse tunneling parameters.
  - Add new capabilities to indicate support of TSO on tunneling packets.
  - Add check to see if TSO on tunneling packets are supported for the
specified NIC.
  - Add support for geneve (as i40e does not differentiate UDP tunneling.
  - Split into three patches.

v3:
  - added external IP offload flag when TSO is enabled for tunnelling packets
v2:
  - edited the comments

Signed-off-by: Zhe Tao 
Signed-off-by: Jianfeng Tan 

Jianfeng Tan (3):
  mbuf: add Tx side tunneling type
  net/i40e: add TSO support on tunneling packet
  app/testpmd: fix Tx offload on tunneling packet

 app/test-pmd/cmdline.c | 42 +---
 app/test-pmd/csumonly.c| 37 +
 drivers/net/i40e/i40e_ethdev.c |  6 ++-
 drivers/net/i40e/i40e_rxtx.c   | 90 +-
 lib/librte_ether/rte_ethdev.h  |  4 ++
 lib/librte_mbuf/rte_mbuf.c |  4 ++
 lib/librte_mbuf/rte_mbuf.h | 17 +++-
 7 files changed, 157 insertions(+), 43 deletions(-)

-- 
2.7.4



[dpdk-dev] VF default MAC change

2016-08-01 Thread Zhang, Helin
Garik

Currently the permanent mac address of VF should be configured from host side.
If you are using Linux kernel driver as the host driver. 'ip link set' is the 
right way to do that.

Regards,
Helin

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Garik E
> Sent: Monday, August 1, 2016 12:40 AM
> To: dev at dpdk.org
> Cc: Lu, Wenzhuo 
> Subject: [dpdk-dev] VF default MAC change
> 
> Hello,
> 
> I'm looking for API to update default VF MAC address during DPDK port
> initialization.
> The API should replace shell command  `ip link set  vf  mac
> '
> Target controllers are Intel 10G, Intel 40G
> 
> Thank you.


[dpdk-dev] VF default MAC change

2016-08-01 Thread Lu, Wenzhuo
Hi Garik,

From: Garik E [mailto:kira...@gmail.com]
Sent: Monday, August 1, 2016 12:40 AM
To: dev at dpdk.org
Cc: Lu, Wenzhuo
Subject: VF default MAC change

Hello,

I'm looking for API to update default VF MAC address during DPDK port 
initialization.
The API should replace shell command  `ip link set  vf  mac '
Target controllers are Intel 10G, Intel 40G
[Wenzhuo] I think you?re looking for this one, 
rte_eth_dev_default_mac_addr_set. But it?s not supported by all the NICs. 
Talking about VF, only igb and ixgbe support it.

Thank you.