[dpdk-dev] [PATCH v8 3/4] ethdev: redesign link speed config API

[Marc]

Matej,

On 16 February 2016 at 11:28, Matej Vido  wrote:

> D?a 14.02.2016 o 23:17 Marc Sune nap?sal(a):
>
>> This patch redesigns the API to set the link speed/s configure
>> for an ethernet port. Specifically:
>>
>> - it allows to define a set of advertised speeds for
>>auto-negociation.
>> - it allows to disable link auto-negociation (single fixed speed).
>> - default: auto-negociate all supported speeds.
>>
>> Other changes:
>>
>> * Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
>>values of all supported link speeds, in Mbps.
>> * Converted link_speed to uint64_t to accomodate 100G speeds
>>and beyond (bug).
>> * Added autoneg flag in struct rte_eth_link to indicate if
>>link speed was a result of auto-negociation or was fixed
>>by configuration.
>> * Added utility function to convert numeric speeds to bitmap
>>fields.
>> * Added rte_eth_speed_to_bm_flag() to version map.
>>
>> Signed-off-by: Marc Sune 
>> ---
>>   app/test-pipeline/init.c  |   2 +-
>>   app/test-pmd/cmdline.c| 124
>> +++---
>>   app/test-pmd/config.c |   4 +-
>>   app/test/virtual_pmd.c|   4 +-
>>   drivers/net/af_packet/rte_eth_af_packet.c |   5 +-
>>   drivers/net/bnx2x/bnx2x_ethdev.c  |   8 +-
>>   drivers/net/bonding/rte_eth_bond_8023ad.c |  14 ++--
>>   drivers/net/cxgbe/base/t4_hw.c|   8 +-
>>   drivers/net/cxgbe/cxgbe_ethdev.c  |   2 +-
>>   drivers/net/e1000/em_ethdev.c | 116
>> ++--
>>   drivers/net/e1000/igb_ethdev.c| 111
>> +-
>>   drivers/net/fm10k/fm10k_ethdev.c  |   8 +-
>>   drivers/net/i40e/i40e_ethdev.c|  73 +-
>>   drivers/net/i40e/i40e_ethdev_vf.c |  11 +--
>>   drivers/net/ixgbe/ixgbe_ethdev.c  |  78 ---
>>   drivers/net/mlx4/mlx4.c   |   6 +-
>>   drivers/net/mpipe/mpipe_tilegx.c  |   6 +-
>>   drivers/net/nfp/nfp_net.c |   4 +-
>>   drivers/net/null/rte_eth_null.c   |   5 +-
>>   drivers/net/pcap/rte_eth_pcap.c   |   9 ++-
>>   drivers/net/ring/rte_eth_ring.c   |   5 +-
>>   drivers/net/virtio/virtio_ethdev.c|   2 +-
>>   drivers/net/virtio/virtio_ethdev.h|   2 -
>>   drivers/net/vmxnet3/vmxnet3_ethdev.c  |   5 +-
>>   drivers/net/xenvirt/rte_eth_xenvirt.c |   5 +-
>>   examples/ip_pipeline/config_parse.c   |   3 +-
>>   lib/librte_ether/rte_ethdev.c |  49 
>>   lib/librte_ether/rte_ethdev.h | 113
>> +--
>>   lib/librte_ether/rte_ether_version.map|   6 ++
>>   29 files changed, 443 insertions(+), 345 deletions(-)
>>
>> [...]
>>
>
> Hi,
>
> some drivers (at least: e1000, i40e, ixgbe, mpipe, nfp, virtio, vmxnet3)
> use rte_atomic64_cmpset() to read and write link state like:
>
> static inline int
> rte_em_dev_atomic_read_link_status(struct rte_eth_dev *dev,
> struct rte_eth_link *link)
> {
> struct rte_eth_link *dst = link;
> struct rte_eth_link *src = &(dev->data->dev_link);
>
> if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst,
> *(uint64_t *)src) == 0)
> return -1;
>
> return 0;
> }
>
> static inline int
> rte_em_dev_atomic_write_link_status(struct rte_eth_dev *dev,
> struct rte_eth_link *link)
> {
> struct rte_eth_link *dst = &(dev->data->dev_link);
> struct rte_eth_link *src = link;
>
> if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst,
> *(uint64_t *)src) == 0)
> return -1;
>
> return 0;
> }
>
>
> When link_speed is changed to uint64_t, struct rte_eth_link exceeds 64
> bits. Shouldn't these functions be adapted in this patch series?
>
> Szedata2 PMD will also use rte_atomic64_cmpset() after patch [1].
> I can take care of this change in szedata2 PMD when patch [1] is accepted
> together with adjusting speeds in szedata2 PMD.
>

Indeed, thanks. I will take care of them in v9 (incl. szedata2).

marc


> [1] http://dpdk.org/ml/archives/dev/2016-January/032281.html
>
> Regards,
> Matej
>

[dpdk-dev] [PATCH v1 3/3] drivers/net/vmxnet3: Add ethdev functions

[Yong Wang]

On 1/28/16, 12:48 AM, "Remy Horton"  wrote:


>Implements driver support for fetching Tx and Rx queue information, and
>setting of MAC address.
>
>Signed-off-by: Remy Horton 
>---
> doc/guides/rel_notes/release_2_3.rst |  5 +++
> drivers/net/vmxnet3/vmxnet3_ethdev.c | 60 
> 2 files changed, 65 insertions(+)
>
>diff --git a/doc/guides/rel_notes/release_2_3.rst 
>b/doc/guides/rel_notes/release_2_3.rst
>index e6dab98..6a50e26 100644
>--- a/doc/guides/rel_notes/release_2_3.rst
>+++ b/doc/guides/rel_notes/release_2_3.rst
>@@ -13,6 +13,11 @@ New Features
> 
>   Implemented Tx & Rx queue information fetching functions.
> 
>+* **vmxnet3: Added ethdev support functions.**
>+
>+  Implemented Tx & Rx queue information fetching and MAC address setting
>+  functions.
>+
> 
> Resolved Issues
> ---
>diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c 
>b/drivers/net/vmxnet3/vmxnet3_ethdev.c
>index c363bf6..f7000d6 100644
>--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
>+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
>@@ -91,6 +91,15 @@ static int vmxnet3_dev_vlan_filter_set(struct rte_eth_dev 
>*dev,
> static void vmxnet3_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask);
> static void vmxnet3_dev_vlan_offload_set_clear(struct rte_eth_dev *dev,
>   int mask, int clear);
>+static void vmxnet3_mac_addr_set(struct rte_eth_dev *dev,
>+   struct ether_addr *mac_addr);
>+static void vmxnet3_rxq_info_get(struct rte_eth_dev *dev,
>+   uint16_t queue_id,
>+   struct rte_eth_rxq_info *qinfo);
>+static void vmxnet3_txq_info_get(struct rte_eth_dev *dev,
>+   uint16_t queue_id,
>+   struct rte_eth_txq_info *qinfo);
>+
> 
> #if PROCESS_SYS_EVENTS == 1
> static void vmxnet3_process_events(struct vmxnet3_hw *);
>@@ -124,6 +133,9 @@ static const struct eth_dev_ops vmxnet3_eth_dev_ops = {
>   .rx_queue_release = vmxnet3_dev_rx_queue_release,
>   .tx_queue_setup   = vmxnet3_dev_tx_queue_setup,
>   .tx_queue_release = vmxnet3_dev_tx_queue_release,
>+  .mac_addr_set = vmxnet3_mac_addr_set,
>+  .rxq_info_get = vmxnet3_rxq_info_get,
>+  .txq_info_get = vmxnet3_txq_info_get,
> };
> 
> static const struct rte_memzone *
>@@ -922,6 +934,54 @@ vmxnet3_process_events(struct vmxnet3_hw *hw)
> }
> #endif
> 
>+static void vmxnet3_mac_addr_set(struct rte_eth_dev *dev,
>+   struct ether_addr *mac_addr)
>+{
>+  struct vmxnet3_hw *hw = dev->data->dev_private;
>+  uint32_t mac_hi, mac_lo;
>+
>+  memcpy(_lo, mac_addr, 4);
>+  memcpy(_hi, mac_addr + 4, 2);
>+  VMXNET3_WRITE_BAR1_REG(hw, VMXNET3_REG_MACL, mac_lo);
>+  VMXNET3_WRITE_BAR1_REG(hw, VMXNET3_REG_MACH, mac_hi);
>+
>+  ether_addr_copy(mac_addr, >data->mac_addrs[0]);

Is this needed?  Looks like rte_eth_dev_default_mac_addr_set() already
called it before calling the callback.  Or is there another path that
this is not done?

>+}
>+
>+static void vmxnet3_rxq_info_get(struct rte_eth_dev *dev,
>+   uint16_t queue_id,
>+   struct rte_eth_rxq_info *qinfo)
>+{
>+  struct vmxnet3_rx_queue *rxq;
>+
>+  rxq = dev->data->rx_queues[queue_id];
>+
>+  qinfo->mp = rxq->mp;
>+  qinfo->scattered_rx = dev->data->scattered_rx;
>+  qinfo->nb_desc = dev->data->nb_rx_queues;

nb_rx_queues should be rxq->cmd_ring[0].size.

Furthermore, each rx queue have two rings that could in theory
be of different size.  But since this info only, I think it?s
good enough to just report ring0?s size here.

>+
>+  /* Driver does not use these values */
>+  qinfo->conf.rx_free_thresh = 0;
>+  qinfo->conf.rx_drop_en = 0;
>+  qinfo->conf.rx_deferred_start = 0;

What about rx_thresh here?

>+}
>+
>+static void vmxnet3_txq_info_get(struct rte_eth_dev *dev,
>+   __rte_unused uint16_t queue_id,
>+   struct rte_eth_txq_info *qinfo)
>+{
>+  qinfo->nb_desc = dev->data->nb_tx_queues;

nb_tx_queues here should be txq->cmd_ring.size

>+
>+  /* Driver does not use these values */
>+  qinfo->conf.tx_thresh.pthresh = 0;
>+  qinfo->conf.tx_thresh.hthresh = 0;
>+  qinfo->conf.tx_thresh.wthresh = 0;
>+  qinfo->conf.tx_free_thresh = 0;
>+  qinfo->conf.tx_rs_thresh = 0;
>+  qinfo->conf.txq_flags = 0;
>+  qinfo->conf.tx_deferred_start = 0;
>+}
>+
> static struct rte_driver rte_vmxnet3_driver = {
>   .type = PMD_PDEV,
>   .init = rte_vmxnet3_pmd_init,
>-- 
>2.5.0
>

[dpdk-dev] [PATCH v4 0/4] rework ioport access for virtio

[Thomas Monjalon]

2016-02-16 21:37, David Marchand:
> Introduce a new pci ioport api in eal to mask all arch / kernel driver
> specifics.
> 
> - rte_eal_pci_ioport_map is responsible for initialising an rte_pci_ioport
>   object that is used in subsequent calls, this function must be tweaked per
>   architecture and per kernel driver,
> - rte_eal_pci_ioport_read / rte_eal_pci_ioport_write uses a rte_pci_ioport
>   object to read / write those resources,
> - rte_eal_pci_ioport_unmap releases resources used by a rte_pci_ioport
>   object if necessary.

Applied, thanks

[dpdk-dev] DPDK-QoS - link sharing across classes

[Dumitrescu, Cristian]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of sreenaath
> vasudevan
> Sent: Tuesday, February 2, 2016 9:09 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] DPDK-QoS - link sharing across classes
> 
> Hi
> I currently have QoS implemented in hardware and I am thinking of using
> DPDK's QoS feature to move it to software.
> Currently in the hardware,Based on the 4 class per pipe and 4 queues per
> class limitation, I was thinking of using 4 classes in DPDK-QoS and spread
> out the 8 h/w queues across the 4 classes.
> Let me explain with an example. Currently, this is how the h/w queue is
> represented
> Q0 - 10% b/w
> Q1- 10%  b/w
> Q2- 15% b/w
> Q3 - 15% b/w
> Q4 - 15% b/w
> Q5 - 15% b/w
> Q6 - 10% b/w
> Q7 - 10% b/w
> 
> Translating the above config to DPDK-QoS, based on my application need, Q0
> and Q1 can be logically grouped under class0 with upper b/w = 20%; Q2, Q3,
> Q4, Q5 can be logically grouped under class2 with upper b/w = 60%; Q6 and
> Q7 can be logically grouped under class 3 with super b/w = 20%.
> 
> However, in the h/w, link sharing is available across all the 8 queues.
> DPDK materials say link sharing "typically" is enabled for last class, in
> this case class2. However, I also want class 1 or class 0 to use the
> remaining bandwidth when class2 does not have any traffic and so on. Can
> this be done in DPDK ? Do we have a concept of min and max b/w guarantee
> at
> the class level in DPDK-QoS ?

Your requirements seem to be:
- minimal rate for each class (with rates fully provisioned, i.e. sum of rate 
not exceeding 100%)
- avoid b/w waste by redistributing unused b/w to the traffic classes that 
currently have traffic according to their relative weights

In our implementation, traffic classes are scheduled in strict priority (with 
upper limit defined, to avoid starvation), so TC0 traffic is always prioritized 
for the current pipe over TC1 .. TC3 traffic (as long as current pipe has TC0 
traffic and pipe TC0 rate is not reached). Therefore, the traffic class 
hierarchy level is not going to help you here.

On the other hand, if you map all your queues/traffic classes to the queues of 
one of our pipe traffic classes (it does not matter which one of TC0 .. TC3 you 
pick, as long as you pick just one), your requirements become possible, as we 
have 4 queues per each pipe traffic class, and they are scheduled using 
weighted fair queuing (byte-level weighted round robin). Simply map your class0 
 to our pipe TC0 queue 0 (weight of 20%), your class2 to our pipe TC0 queue 1 
(weight of 60%) and your class3 to our pipe TC0 queue 2 (weight of 20%), with 
our pipe TC0 queue 3 unused, which should work exactly what you need. Makes 
sense?

Regards,
Cristian

> 
> Thanks !
> 
> --
> regards
> sreenaath

[dpdk-dev] [PATCH v4 0/3] add lpm support for NEON

[Jerin Jacob]

On Tue, Feb 16, 2016 at 01:27:02PM +, Kobylinski, MichalX wrote:
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jerin Jacob
> > Sent: Friday, February 12, 2016 1:29 PM
> > To: dev at dpdk.org
> > Cc: viktorin at rehivetech.com
> > Subject: [dpdk-dev] [PATCH v4 0/3] add lpm support for NEON
> > 
[snip]
> > 
> > Jerin Jacob (3):
> >   lpm: make rte_lpm_lookupx4 API definition architecture agnostic
> >   lpm: add support for NEON
> >   maintainers: claim responsibility for arm64 specific files of hash and
> > lpm
> > 
> >  MAINTAINERS|   3 +
> >  app/test/test_lpm.c|  21 ++--
> >  app/test/test_xmmt_ops.h   |  67 +
> >  config/defconfig_arm-armv7a-linuxapp-gcc   |   3 -
> >  config/defconfig_arm64-armv8a-linuxapp-gcc |   3 -
> >  lib/librte_lpm/Makefile|   6 ++
> >  lib/librte_lpm/rte_lpm.h   |  99 ++-
> >  lib/librte_lpm/rte_lpm_neon.h  | 148 
> > +
> >  lib/librte_lpm/rte_lpm_sse.h   | 143 
> > 
> >  9 files changed, 386 insertions(+), 107 deletions(-)  create mode 100644
> > app/test/test_xmmt_ops.h  create mode 100644 lib/librte_lpm/rte_lpm_neon.h
> > create mode 100644 lib/librte_lpm/rte_lpm_sse.h
> > 
> > --
> > 2.1.0
> 
> Hi Jerin,

Hi Michal,

> Are you planning increase next_hop field for ARM? I extended next_hop field 
> from 8 bits to 24 bits and created structure to configure LPM for x86.

Yes, I am planning to increase next_hop field for ARM as a separate
patch.  Let this base patchset get merges.

I will make  ARM specific changes for your new feature in
'rte_lpm_lookupx4' as a separate patch on top of your series.
So that in case if I want to go back to 8 bit then I can do it

Jerin

> Please look at my patchset with proposal increase next_hop field and 
> structure to configure.
> 
> http://patchwork.dpdk.org/dev/patchwork/patch/10249/
> http://patchwork.dpdk.org/dev/patchwork/patch/10250/
> 
> Best Regards,
> Michal
> 

[dpdk-dev] [PATCH v4 4/4] virtio: use pci ioport api

[David Marchand]

Move all os / arch specifics to eal.

Signed-off-by: David Marchand 
Reviewed-by: Santosh Shukla 
Tested-by: Santosh Shukla 
Acked-by: Yuanhan Liu 
---
Changes since v2:
- fixed bsd init issue (reported by Tetsuya M.)

---
 drivers/net/virtio/virtio_pci.c | 356 +++-
 drivers/net/virtio/virtio_pci.h |  38 +
 2 files changed, 59 insertions(+), 335 deletions(-)

diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index b4d4476..85fbe88 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -49,74 +49,35 @@
 #define PCI_CAPABILITY_LIST0x34
 #define PCI_CAP_ID_VNDR0x09

-#define VIRTIO_PCI_REG_ADDR(hw, reg) \
-   (unsigned short)((hw)->io_base + (reg))
-
-#define VIRTIO_READ_REG_1(hw, reg) \
-   inb((VIRTIO_PCI_REG_ADDR((hw), (reg
-#define VIRTIO_WRITE_REG_1(hw, reg, value) \
-   outb_p((unsigned char)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
-
-#define VIRTIO_READ_REG_2(hw, reg) \
-   inw((VIRTIO_PCI_REG_ADDR((hw), (reg
-#define VIRTIO_WRITE_REG_2(hw, reg, value) \
-   outw_p((unsigned short)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
-
-#define VIRTIO_READ_REG_4(hw, reg) \
-   inl((VIRTIO_PCI_REG_ADDR((hw), (reg
-#define VIRTIO_WRITE_REG_4(hw, reg, value) \
-   outl_p((unsigned int)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
+/*
+ * The remaining space is defined by each driver as the per-driver
+ * configuration space.
+ */
+#define VIRTIO_PCI_CONFIG(hw) (((hw)->use_msix) ? 24 : 20)

 static void
 legacy_read_dev_config(struct virtio_hw *hw, size_t offset,
   void *dst, int length)
 {
-   uint64_t off;
-   uint8_t *d;
-   int size;
-
-   off = VIRTIO_PCI_CONFIG(hw) + offset;
-   for (d = dst; length > 0; d += size, off += size, length -= size) {
-   if (length >= 4) {
-   size = 4;
-   *(uint32_t *)d = VIRTIO_READ_REG_4(hw, off);
-   } else if (length >= 2) {
-   size = 2;
-   *(uint16_t *)d = VIRTIO_READ_REG_2(hw, off);
-   } else {
-   size = 1;
-   *d = VIRTIO_READ_REG_1(hw, off);
-   }
-   }
+   rte_eal_pci_ioport_read(>io, dst, length,
+   VIRTIO_PCI_CONFIG(hw) + offset);
 }

 static void
 legacy_write_dev_config(struct virtio_hw *hw, size_t offset,
const void *src, int length)
 {
-   uint64_t off;
-   const uint8_t *s;
-   int size;
-
-   off = VIRTIO_PCI_CONFIG(hw) + offset;
-   for (s = src; length > 0; s += size, off += size, length -= size) {
-   if (length >= 4) {
-   size = 4;
-   VIRTIO_WRITE_REG_4(hw, off, *(const uint32_t *)s);
-   } else if (length >= 2) {
-   size = 2;
-   VIRTIO_WRITE_REG_2(hw, off, *(const uint16_t *)s);
-   } else {
-   size = 1;
-   VIRTIO_WRITE_REG_1(hw, off, *s);
-   }
-   }
+   rte_eal_pci_ioport_write(>io, src, length,
+VIRTIO_PCI_CONFIG(hw) + offset);
 }

 static uint64_t
 legacy_get_features(struct virtio_hw *hw)
 {
-   return VIRTIO_READ_REG_4(hw, VIRTIO_PCI_HOST_FEATURES);
+   uint64_t dst;
+
+   rte_eal_pci_ioport_read(>io, , 4, VIRTIO_PCI_HOST_FEATURES);
+   return dst;
 }

 static void
@@ -127,19 +88,23 @@ legacy_set_features(struct virtio_hw *hw, uint64_t 
features)
"only 32 bit features are allowed for legacy virtio!");
return;
}
-   VIRTIO_WRITE_REG_4(hw, VIRTIO_PCI_GUEST_FEATURES, features);
+   rte_eal_pci_ioport_write(>io, , 4,
+VIRTIO_PCI_GUEST_FEATURES);
 }

 static uint8_t
 legacy_get_status(struct virtio_hw *hw)
 {
-   return VIRTIO_READ_REG_1(hw, VIRTIO_PCI_STATUS);
+   uint8_t dst;
+
+   rte_eal_pci_ioport_read(>io, , 1, VIRTIO_PCI_STATUS);
+   return dst;
 }

 static void
 legacy_set_status(struct virtio_hw *hw, uint8_t status)
 {
-   VIRTIO_WRITE_REG_1(hw, VIRTIO_PCI_STATUS, status);
+   rte_eal_pci_ioport_write(>io, , 1, VIRTIO_PCI_STATUS);
 }

 static void
@@ -151,148 +116,63 @@ legacy_reset(struct virtio_hw *hw)
 static uint8_t
 legacy_get_isr(struct virtio_hw *hw)
 {
-   return VIRTIO_READ_REG_1(hw, VIRTIO_PCI_ISR);
+   uint8_t dst;
+
+   rte_eal_pci_ioport_read(>io, , 1, VIRTIO_PCI_ISR);
+   return dst;
 }

 /* Enable one vector (0) for Link State Intrerrupt */
 static uint16_t
 legacy_set_config_irq(struct virtio_hw *hw, uint16_t vec)
 {
-   VIRTIO_WRITE_REG_2(hw, VIRTIO_MSI_CONFIG_VECTOR, vec);
-   return VIRTIO_READ_REG_2(hw, VIRTIO_MSI_CONFIG_VECTOR);
+   uint16_t dst;
+
+   rte_eal_pci_ioport_write(>io, , 2, 

[dpdk-dev] [PATCH v4 2/4] virtio: fix incorrect check when mapping pci resources

[David Marchand]

According to the api, rte_eal_pci_map_device is only successful when returning
0.

Fixes: 6ba1f63b5ab0 ("virtio: support specification 1.0")
Signed-off-by: David Marchand 
Acked-by: Yuanhan Liu 
---
 drivers/net/virtio/virtio_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index 762e91c..b4d4476 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -795,7 +795,7 @@ virtio_read_caps(struct rte_pci_device *dev, struct 
virtio_hw *hw)
struct virtio_pci_cap cap;
int ret;

-   if (rte_eal_pci_map_device(dev) < 0) {
+   if (rte_eal_pci_map_device(dev)) {
PMD_INIT_LOG(DEBUG, "failed to map pci device!");
return -1;
}
-- 
1.9.1

[dpdk-dev] [PATCH v4 1/4] virtio/bsd: fix typo

[David Marchand]

Fixes: c52afa68d763 ("virtio: move left PCI stuff in the right file")
Signed-off-by: David Marchand 
Acked-by: Yuanhan Liu 
---
 drivers/net/virtio/virtio_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index 455e40d..762e91c 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -439,7 +439,7 @@ legacy_virtio_resource_init(struct rte_pci_device *pci_dev)

 #else
 static int
-legayc_virtio_has_msix(const struct rte_pci_addr *loc __rte_unused)
+legacy_virtio_has_msix(const struct rte_pci_addr *loc __rte_unused)
 {
/* nic_uio does not enable interrupts, return 0 (false). */
return 0;
-- 
1.9.1

[dpdk-dev] [PATCH v4 0/4] rework ioport access for virtio

[David Marchand]

Introduce a new pci ioport api in eal to mask all arch / kernel driver
specifics.

- rte_eal_pci_ioport_map is responsible for initialising an rte_pci_ioport
  object that is used in subsequent calls, this function must be tweaked per
  architecture and per kernel driver,
- rte_eal_pci_ioport_read / rte_eal_pci_ioport_write uses a rte_pci_ioport
  object to read / write those resources,
- rte_eal_pci_ioport_unmap releases resources used by a rte_pci_ioport
  object if necessary.

There is still some more work to ensure intr handle are properly initialized
and released when used in conjonction with rte_eal_map_device() api calls.

BSD code has been neither run nor compiled, please can someone confirm I did
not break too much stuff ?

virtio legacy code has been updated accordingly.
With this, virtio code should be ready for other archs now.

So in the end, all that is missing on linux is some vfio update for support
of all architectures that have vfio.

Changes since v3:
- rebased on HEAD
- renamed "offset" field in rte_pci_ioport structure as "base"

Changes since v2:
- rebased on HEAD
- fixed a remaining reference to rte_ioport_t in comment
- fixed virtio driver for bsd

Changes since v1:
- dropped rte_ioport and removed the arch headers, if performance is an
  issue, we will see how to enhance this in later patches


Regards, 
-- 
David Marchand

David Marchand (4):
  virtio/bsd: fix typo
  virtio: fix incorrect check when mapping pci resources
  eal: introduce pci ioport api
  virtio: use pci ioport api

 drivers/net/virtio/virtio_pci.c | 358 
 drivers/net/virtio/virtio_pci.h |  38 +--
 lib/librte_eal/bsdapp/eal/eal_pci.c | 135 +
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |   4 +
 lib/librte_eal/common/include/rte_pci.h |  65 +
 lib/librte_eal/linuxapp/eal/eal_pci.c   | 170 +++
 lib/librte_eal/linuxapp/eal/eal_pci_init.h  |  16 ++
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c   | 132 -
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c  |  37 +++
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |   4 +
 10 files changed, 620 insertions(+), 339 deletions(-)

-- 
1.9.1

[dpdk-dev] [PATCH v3] cfgfile: support looking up sections by index

[Dumitrescu, Cristian]

> -Original Message-
> From: Rich Lane [mailto:rich.lane at bigswitch.com]
> Sent: Wednesday, February 10, 2016 7:12 PM
> To: dev at dpdk.org
> Cc: Dumitrescu, Cristian ; Panu Matilainen
> 
> Subject: [PATCH v3] cfgfile: support looking up sections by index
> 
> This is useful when sections have duplicate names.
> 
> Signed-off-by: Rich Lane 
> ---
> v2->v3
> - Added check for index < 0.
> v1->v2:
> - Added new symbol to version script.
> 
>  lib/librte_cfgfile/rte_cfgfile.c   | 16 
>  lib/librte_cfgfile/rte_cfgfile.h   | 23 +++
>  lib/librte_cfgfile/rte_cfgfile_version.map |  6 ++
>  3 files changed, 45 insertions(+)
> 
> diff --git a/lib/librte_cfgfile/rte_cfgfile.c 
> b/lib/librte_cfgfile/rte_cfgfile.c
> index a677dad..eba0713 100644
> --- a/lib/librte_cfgfile/rte_cfgfile.c
> +++ b/lib/librte_cfgfile/rte_cfgfile.c
> @@ -333,6 +333,22 @@ rte_cfgfile_section_entries(struct rte_cfgfile *cfg,
> const char *sectionname,
>   return i;
>  }
> 
> +int
> +rte_cfgfile_section_entries_by_index(struct rte_cfgfile *cfg, int index,
> + struct rte_cfgfile_entry *entries, int max_entries)
> +{
> + int i;
> + const struct rte_cfgfile_section *sect;
> +
> + if (index < 0 || index >= cfg->num_sections)
> + return -1;
> +
> + sect = cfg->sections[index];
> + for (i = 0; i < max_entries && i < sect->num_entries; i++)
> + entries[i] = *sect->entries[i];
> + return i;
> +}
> +
>  const char *
>  rte_cfgfile_get_entry(struct rte_cfgfile *cfg, const char *sectionname,
>   const char *entryname)
> diff --git a/lib/librte_cfgfile/rte_cfgfile.h 
> b/lib/librte_cfgfile/rte_cfgfile.h
> index d443782..8e69971 100644
> --- a/lib/librte_cfgfile/rte_cfgfile.h
> +++ b/lib/librte_cfgfile/rte_cfgfile.h
> @@ -155,6 +155,29 @@ int rte_cfgfile_section_entries(struct rte_cfgfile
> *cfg,
>   struct rte_cfgfile_entry *entries,
>   int max_entries);
> 
> +/** Get section entries as key-value pairs
> +*
> +* The index of a section is the same as the index of its name in the
> +* result of rte_cfgfile_sections. This API can be used when there are
> +* multiple sections with the same name.
> +*
> +* @param cfg
> +*   Config file
> +* @param index
> +*   Section index
> +* @param entries
> +*   Pre-allocated array of at least max_entries entries where the section
> +*   entries are stored as key-value pair after successful invocation
> +* @param max_entries
> +*   Maximum number of section entries to be stored in entries array
> +* @return
> +*   Number of entries populated on success, negative error code otherwise
> +*/
> +int rte_cfgfile_section_entries_by_index(struct rte_cfgfile *cfg,
> + int index,

For the purpose of consistency, this function should provide back to the user 
the name of the section as an output parameter: char *name.
This parameter should either be NULL (when user does not care about the section 
name) or pre-allocated by the user with at least CFG_NAME_LEN characters.

> + struct rte_cfgfile_entry *entries,
> + int max_entries);
> +

Also the doxygen comment of the following existing functions should be updated 
to state that, in the case multiple sections with the same name exist, these 
functions are working with the first section with this name:
- rte_cfgfile_section_num_entries()
- rte_cfgfile_section_entries()
- rte_cfgfile_get_entry()
- rte_cfgfile_has_entry()

>  /** Get value of the named entry in named config file section
>  *
>  * @param cfg
> diff --git a/lib/librte_cfgfile/rte_cfgfile_version.map
> b/lib/librte_cfgfile/rte_cfgfile_version.map
> index bf6c6fd..f6a27a9 100644
> --- a/lib/librte_cfgfile/rte_cfgfile_version.map
> +++ b/lib/librte_cfgfile/rte_cfgfile_version.map
> @@ -13,3 +13,9 @@ DPDK_2.0 {
> 
>   local: *;
>  };
> +
> +DPDK_2.3 {
> + global:
> +
> + rte_cfgfile_section_entries_by_index;
> +} DPDK_2.0;
> --
> 1.9.1

[dpdk-dev] [dpdk-dev, 1/6] mempool: add external mempool manager support

[Jan Viktorin]

Hello David,

(I wanted to reply to the 0/6 patch but I couldn't find it anywhere in
mbox format, nor on gmane which is strange.)

I could see both versions of the patch series quickly. I've got only
one question at the moment. Would it be possible to somehow integrate
calls to the dma_map/unmap_* interface of the kernel? I think, this is
possible to be implemented through the vfio iommu group zero (hope so).

The issue is that without being able to explicitly flush buffers before
a DMA transmission, it is not easily possible to use the mempool
manager on most ARMv7 chips. Well, it can be done by calling
dma_alloc_coherent and pass this memory into the mempool manager. But
such memory is very slow (it is, say, non-cacheable).

Regards
Jan

On Tue, 16 Feb 2016 14:48:10 +
David Hunt  wrote:

> Adds the new rte_mempool_create_ext api and callback mechanism for
> external mempool handlers
> 
> Modifies the existing rte_mempool_create to set up the handler_idx to
> the relevant mempool handler based on the handler name:
> ring_sp_sc
> ring_mp_mc
> ring_sp_mc
> ring_mp_sc
> 
> v2: merges the duplicated code in rte_mempool_xmem_create and
> rte_mempool_create_ext into one common function. The old functions
> now call the new common function with the relevant parameters.
> 
> Signed-off-by: David Hunt 
> 
> ---
> app/test/test_mempool_perf.c   |   1 -
>  lib/librte_mempool/Makefile|   2 +
>  lib/librte_mempool/rte_mempool.c   | 383 
> ++---
>  lib/librte_mempool/rte_mempool.h   | 200 ---
>  lib/librte_mempool/rte_mempool_default.c   | 236 ++
>  lib/librte_mempool/rte_mempool_internal.h  |  75 ++
>  lib/librte_mempool/rte_mempool_version.map |   1 +
>  7 files changed, 717 insertions(+), 181 deletions(-)
>  create mode 100644 lib/librte_mempool/rte_mempool_default.c
>  create mode 100644 lib/librte_mempool/rte_mempool_internal.h
> 
> diff --git a/app/test/test_mempool_perf.c b/app/test/test_mempool_perf.c
> index cdc02a0..091c1df 100644
> --- a/app/test/test_mempool_perf.c
> +++ b/app/test/test_mempool_perf.c
> @@ -161,7 +161,6 @@ per_lcore_mempool_test(__attribute__((unused)) void *arg)
>  n_get_bulk);
>   if (unlikely(ret < 0)) {
>   rte_mempool_dump(stdout, mp);
> - rte_ring_dump(stdout, mp->ring);
>   /* in this case, objects are lost... */
>   return -1;
>   }
> diff --git a/lib/librte_mempool/Makefile b/lib/librte_mempool/Makefile
> index a6898ef..aeaffd1 100644
> --- a/lib/librte_mempool/Makefile
> +++ b/lib/librte_mempool/Makefile
> @@ -42,6 +42,8 @@ LIBABIVER := 1
>  
>  # all source are stored in SRCS-y
>  SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool.c
> +SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool_default.c
> +
>  ifeq ($(CONFIG_RTE_LIBRTE_XEN_DOM0),y)
>  SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_dom0_mempool.c
>  endif
> diff --git a/lib/librte_mempool/rte_mempool.c 
> b/lib/librte_mempool/rte_mempool.c
> index aff5f6d..a577a3e 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -59,10 +59,11 @@
>  #include 
>  
>  #include "rte_mempool.h"
> +#include "rte_mempool_internal.h"
>  
>  TAILQ_HEAD(rte_mempool_list, rte_tailq_entry);
>  
> -static struct rte_tailq_elem rte_mempool_tailq = {
> +struct rte_tailq_elem rte_mempool_tailq = {
>   .name = "RTE_MEMPOOL",
>  };
>  EAL_REGISTER_TAILQ(rte_mempool_tailq)
> @@ -149,7 +150,7 @@ mempool_add_elem(struct rte_mempool *mp, void *obj, 
> uint32_t obj_idx,
>   obj_init(mp, obj_init_arg, obj, obj_idx);
>  
>   /* enqueue in ring */
> - rte_ring_sp_enqueue(mp->ring, obj);
> + rte_mempool_ext_put_bulk(mp, , 1);
>  }
>  
>  uint32_t
> @@ -375,26 +376,6 @@ rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num, 
> size_t elt_sz,
>   return usz;
>  }
>  
> -#ifndef RTE_LIBRTE_XEN_DOM0
> -/* stub if DOM0 support not configured */
> -struct rte_mempool *
> -rte_dom0_mempool_create(const char *name __rte_unused,
> - unsigned n __rte_unused,
> - unsigned elt_size __rte_unused,
> - unsigned cache_size __rte_unused,
> - unsigned private_data_size __rte_unused,
> - rte_mempool_ctor_t *mp_init __rte_unused,
> - void *mp_init_arg __rte_unused,
> - rte_mempool_obj_ctor_t *obj_init __rte_unused,
> - void *obj_init_arg __rte_unused,
> - int socket_id __rte_unused,
> - unsigned flags __rte_unused)
> -{
> - rte_errno = EINVAL;
> - return NULL;
> -}
> -#endif
> -
>  /* create the mempool */
>  struct rte_mempool *
>  

[dpdk-dev] [PATCH v2 2/5] EAL: Add new EAL "--qtest-virtio" option

[Tan, Jianfeng]

Hi David,

On 2/16/2016 1:53 PM, David Marchand wrote:
> On Wed, Feb 10, 2016 at 4:40 AM, Tetsuya Mukawa  wrote:
>> To work with qtest virtio-net PMD, virtual address that maps hugepages
>> should be between (1 << 31) to (1 << 44). This patch adds one more option
>> to map like this. Also all hugepages should consists of one file.
>> Because of this, the option will work only when '--single-file' option is
>> specified.
> This patch is pure virtio stuff.
> Please, rework this so that we have a generic api in eal (asking for a
> free region could be of use for something else).
> Then you can call this api from virtio pmd.
>
> If you need to pass options to virtio pmd, add some devargs for it.
>

Seems it's hard to slip this option into --vdev="eth_qtest_virtio0..." 
from my side because memory initialization happens before vdev option is 
parsed.

Can we make use of "--base-virtaddr" achieve the function of this option?

Thanks,
Jianfeng

[dpdk-dev] [PATCH] arm: fix name armv7-a used for dpdk purposes

[Jan Viktorin]

The CONFIG_RTE_MACHINE must not contain hyphens to work correctly. This was
initially done only for the file name defconfig_arm-armv7a-linuxapp-gcc. This
patch fixes install-sdk goal. Otherwise, it creates a wrong directory for this
platform.

Signed-off-by: Jan Viktorin 
---
 config/defconfig_arm-armv7a-linuxapp-gcc   | 2 +-
 mk/machine/{armv7-a => armv7a}/rte.vars.mk | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename mk/machine/{armv7-a => armv7a}/rte.vars.mk (100%)

diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
b/config/defconfig_arm-armv7a-linuxapp-gcc
index cbebd64..1e71a8c 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -30,7 +30,7 @@

 #include "common_linuxapp"

-CONFIG_RTE_MACHINE="armv7-a"
+CONFIG_RTE_MACHINE="armv7a"

 CONFIG_RTE_ARCH="arm"
 CONFIG_RTE_ARCH_ARM=y
diff --git a/mk/machine/armv7-a/rte.vars.mk b/mk/machine/armv7a/rte.vars.mk
similarity index 100%
rename from mk/machine/armv7-a/rte.vars.mk
rename to mk/machine/armv7a/rte.vars.mk
-- 
2.7.0

[dpdk-dev] [PATCH v2 0/3] fix C++ includes

[Marc]

On 16 February 2016 at 17:26, Thomas Monjalon 
wrote:

> 2016-02-16 16:21, Ferruh Yigit:
> > On Tue, Feb 16, 2016 at 08:14:22AM +0100, Thomas Monjalon wrote:
> > > When trying to build a C++ application, some errors appear from DPDK
> headers.
> > > 2 libraries are not fixed in this series:
> > > - cmdline
> > > - vhost which includes some not compliant Linux virtio headers
> >
> > Out of curiosity, how can we detect C++ compilation problems, do we have
> a C++ sample application?
> > Or how can we compile any existing application with c++, I tried
> "EXTRA_CFLAGS="-x c++" or "CC=g++" but both failed to compile.
>
> I will submit a test.
> At the moment, I use CC=g++ with this file:
>
> #ifdef RTE_LIBRTE_EAL
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #ifdef RTE_ARCH_X86
> #include 
> #endif
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #endif
> #ifdef RTE_LIBRTE_CMDLINE
> /* TODO: C++ support
> #include 
> #include 
> #include 
> */
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #endif
> #ifdef RTE_LIBRTE_ACL
> #include 
> #endif
> #ifdef RTE_LIBRTE_SCHED
> #include 
> #include 
> #include 
> #include 
> #include 
> #endif
> #ifdef RTE_LIBRTE_NET
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #endif
> #ifdef RTE_LIBRTE_CFGFILE
> #include 
> #endif
> #include 
> #include 
> #ifdef RTE_LIBRTE_CRYPTODEV
> #include 
> #include 
> #include 
> #endif
> #ifdef RTE_LIBRTE_DISTRIBUTOR
> #include 
> #endif
> #ifdef RTE_LIBRTE_PMD_AF_PACKET
> #include 
> #endif
> #ifdef RTE_LIBRTE_PMD_BOND
> #include 
> #include 
> #endif
> #ifdef RTE_LIBRTE_ETHER
> #include 
> #include 
> #include 
> #endif
> #ifdef RTE_LIBRTE_PMD_NULL
> #include 
> #endif
> #ifdef RTE_LIBRTE_PMD_RING
> #include 
> #endif
> #ifdef RTE_LIBRTE_HASH
> #include 
> #include 
> #include 
> #include 
> #include 
> #endif
> #ifdef RTE_LIBRTE_IP_FRAG
> #include 
> #endif
> #ifdef RTE_LIBRTE_JOBSTATS
> #include 
> #endif
> #ifdef RTE_LIBRTE_KNI
> #include 
> #endif
> #ifdef RTE_LIBRTE_KVARGS
> #include 
> #endif
> #ifdef RTE_LIBRTE_LPM
> #include 
> #include 
> #endif
> #ifdef RTE_LIBRTE_MBUF
> #include 
> #endif
> #ifdef RTE_LIBRTE_MBUF_OFFLOAD
> #include 
> #endif
> #ifdef RTE_LIBRTE_MEMPOOL
> #include 
> #endif
> #ifdef RTE_LIBRTE_METER
> #include 
> #endif
> #ifdef RTE_LIBRTE_PIPELINE
> #include 
> #endif
> #ifdef RTE_LIBRTE_PORT
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #endif
> #ifdef RTE_LIBRTE_POWER
> #include 
> #endif
> #ifdef RTE_LIBRTE_REORDER
> #include 
> #endif
> #ifdef RTE_LIBRTE_RING
> #include 
> #endif
> #ifdef RTE_LIBRTE_TABLE
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #endif
> #ifdef RTE_LIBRTE_VHOST
> /* TODO: fix vhost header for C++
> #include 
> */
> #endif
>
> int
> main(int argc, char **argv)
> {
> RTE_LOG(NOTICE, USER1, "function %s\n", __func__);
> return 0;
> }
>
>
I don't know what you have in mind for the test, but with this file you can
only detect things like using reserved keywords of C++ in DPDK headers and
things like that. It will not detect linking issues (fundamentally missing
extern "C" in function declarations), which happen from time to time,
specially with new headers.

We would need to compile a .cc/.cpp file including all these headers and
link against all the functions on those headers, similarly to what autoconf
does to test libs. I could help on that for 2.4.

Marc

[dpdk-dev] IPV6 RSS not working in i40e

[Rahul Ramachandran]

This is the RSS hash related queries in 40G NIC:

Hash Flags: 

Key Length: 52

Keys:
6D 5A 56 DA 25 5B E C2 41 67
25 3D 43 A3 8F B0 D0 CA 2B CB
AE 7B 30 B4 77 CB 2D A3 80 30
F2 C 6A 42 B7 3B BE AC 1 FA
0 0 0 0 0 0 0 0 0 0
0 0
Hash Algorithm: Toeplitz
Symmetric hash status: 1

RETA table size: 512

Entries 0-63:
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,
Entries 64-127:
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,
Entries 128-191:
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,
Entries 192-255:
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,
Entries 256-319:
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,
Entries 320-383:
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,
Entries 384-447:
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,
Entries 448-511:
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,


On 16 February 2016 at 17:14, Rahul Ramachandran 
wrote:

> Hi,
>
> I am using dpdk 2.1. I see the hash flags are unified compared to my
> previous version 1.8.
> But with DPDK 2.1 in Fortville NIC's, I see ipv6 RSS is not working,
> all the frames are queued to
> first queue even though I have 16 queues (RETA table looks correct).
>
> For IPV4 RSS works as expected in Fortville. Also in 10G, both ipv4
> and ipv6 RSS works.
>
> My RSS configuration is : rss_hf = ETH_RSS_IP | ETH_*RSS*
> _NONFRAG_IPV4_TCP | ETH_*RSS*_NONFRAG_IPV4_UDP
>
> I see ETH_RSS_IP contains Layer3 hash flags for ipv6.
>
> #define ETH_*RSS*_IP ( \
>   ETH_*RSS*_IPV4 | \
>   ETH_*RSS*_FRAG_IPV4 | \
>   ETH_*RSS*_NONFRAG_IPV4_OTHER | \
>   ETH_*RSS*_*IPV6* | \
>   ETH_*RSS*_FRAG_*IPV6* | \
>   ETH_*RSS*_NONFRAG_*IPV6*_OTHER | \
>   ETH_*RSS*_*IPV6*_EX)
>
> But when I query the hash flags, I get the value of . I understand
> while configuring RSS
> HF in the 40G NIC, we mask the configured RSS HF with NIC specific
> mask flags before writing to NIC. But I am not
> sure after masking it is taking the flags for IPV6.
>
> The mask or I40E:I40E_*RSS*_OFFLOAD_ALL. I see this
> conatins the flags ETH_*RSS*_FRAG_*IPV6 & *ETH_*RSS*_NONFRAG_*IPV6*
> _OTHER.
>
> Are you aware of any such problems?
>
> Please let me know if you need more information.
>
> Thanks
>

[dpdk-dev] [PATCH] build: set CFLAGS for ppc64el build

[Thomas Monjalon]

2016-02-16 16:04, Fernando Seiti Furusato:
> Hi Thomas.
> 
> On 02/12/2016 05:18 PM, Fernando Seiti Furusato wrote:
> > Hello Thomas.
> > Thanks for your quick response.
> >
> > On 02/12/2016 03:37 PM, Thomas Monjalon wrote:
> >> 2016-02-12 12:05, Fernando Seiti Furusato:
> >>> Add a proper ifeq statement to set the mcpu as needed for ppc64el, as
> >>> the only one originally set is not valid for ppc architectures.
> >>
> >> What is the benefit of using the default machine config, compared to
> >> the power8 one?
> >>
> >> Don't you think the default machine should be renamed core2?
> >
> > I think it would be better indeed. Thanks for pointing that out.
> >
> >>
> >> [...]
> >>> +ifeq (ppc64le,$(shell uname -m))
> >>> +MACHINE_CFLAGS += -mcpu=power8
> >>
> >> Why this flag is not set in mk/machine/power8/rte.vars.mk ?
> >>
> >
> > This and what observed above would make a better patch.
> > Let me try those.
> 
> I will be just changing the flag within mk/machine/power8/rte.vars.mk so
> it will be used on ppc64le.

Does it mean that only little endian is supported on POWER8?

> I thought since I am not sure how it will affect others, I will not mess
> with the default file.

Yes let's keep it for another patch if someone is concerned.

> I had to copy config/defconfig_ppc_64-power8-linuxapp-gcc to
> config/defconfig_ppc64le-native-linuxapp-gcc, because the build searches
> for it on ppc64le. Should I include that in the patch?
> Do you think there is a better approach?

Not sure to understand.
I think there is something wrong in the commands you use to compile.
Are you using "make config T=ppc_64-power8-linuxapp-gcc" ?

[dpdk-dev] vm_power_manager uses non-public API, broken build on top of installed SDK

[Thomas Monjalon]

Hi,

2016-02-16 18:21, Jan Viktorin:
> I have encountered an issue with the examples/vm_power_manager. It
> includes the file lib/librte_power/channel_commands.h which is not a
> public API. This breaks builds of examples based on just the installed
> SDK (after calling install-sdk) as the channel_commands.h header is
> missing there. I suppose that most of the time, the examples are being
> build directly from the DPDK base directory and so nobody could see
> this failing.

Please check this thread where it has already been reported:
http://dpdk.org/ml/archives/dev/2016-February/033202.html

> By the way, is there a command that installs the examples on the
> target? I didn't find any yet...

No you can only specify a build directory for the examples.

[dpdk-dev] vm_power_manager uses non-public API, broken build on top of installed SDK

[Jan Viktorin]

Hello Thomas,

I have encountered an issue with the examples/vm_power_manager. It
includes the file lib/librte_power/channel_commands.h which is not a
public API. This breaks builds of examples based on just the installed
SDK (after calling install-sdk) as the channel_commands.h header is
missing there. I suppose that most of the time, the examples are being
build directly from the DPDK base directory and so nobody could see
this failing.

Steps:

DPDK_CONFIG=arm-armv7a-linuxapp-gcc
$(MAKE) -C $(@D) T=$(DPDK_CONFIG) RTE_KERNELDIR=$(LINUX_DIR) \  
 CROSS=$(TARGET_CROSS) config
$(MAKE) -C $(@D) T=$(DPDK_CONFIG) RTE_KERNELDIR=$(LINUX_DIR) \  
 CROSS=$(TARGET_CROSS) all
$(MAKE) -C $(@D) DESTDIR=$(@D)/examples-sdk \   
 CROSS=$(TARGET_CROSS) install-sdk install-runtime  
$(MAKE) -C $(@D) RTE_KERNELDIR=$(LINUX_DIR) CROSS=$(TARGET_CROSS) \
RTE_SDK=$(@D)/examples-sdk/usr/local/share/dpdk \   
T=$(DPDK_CONFIG) examples

(I also set CONFIG_RTE_BUILD_SHARED_LIB=y and
CONFIG_RTE_BUILD_COMBINE_LIBS=y but I don't see any relation here.)

I am not sure about the solution. Probably, it's possible to move the
contents of channel_commands.h into the rte_power.h.

And, there is no maintainer listed for the librte_power and related
stuff...

By the way, is there a command that installs the examples on the
target? I didn't find any yet...

Regards
Jan

-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH] eal: Initial implementation of PQoS EAL extension

[Thomas Monjalon]

2016-01-29 13:29, Wojciech Andralojc:
> EAL extension allows CAT and CDP technologies to be
> configured via "--l3ca*" parameters.

EAL should not depend on the PQoS library.
Please could you hook the command line parsing and help to
add these new options from outside?

> Reworking existing applications to make use of DPDK PQoS library is
> a heavy lift. This EAL extension is to make it easier by adding
> new command line options. These new options allow to leverage CAT and
> CDP technologies with existing code base without any additional
> development effort.

The command line options may be convenient in some cases but not
straightforward for some applications.
>From now, the runtime options must be also configurable with an API.
Please consider a clean configuration API first in the library.
Then it can be hooked in the EAL command line.
A thought: should we move the EAL command line in a separate library
with a hook API?

[dpdk-dev] [PATCH v2 0/3] fix C++ includes

[Thomas Monjalon]

2016-02-16 16:21, Ferruh Yigit:
> On Tue, Feb 16, 2016 at 08:14:22AM +0100, Thomas Monjalon wrote:
> > When trying to build a C++ application, some errors appear from DPDK 
> > headers.
> > 2 libraries are not fixed in this series:
> > - cmdline
> > - vhost which includes some not compliant Linux virtio headers
> 
> Out of curiosity, how can we detect C++ compilation problems, do we have a 
> C++ sample application?
> Or how can we compile any existing application with c++, I tried 
> "EXTRA_CFLAGS="-x c++" or "CC=g++" but both failed to compile.

I will submit a test.
At the moment, I use CC=g++ with this file:

#ifdef RTE_LIBRTE_EAL
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#ifdef RTE_ARCH_X86
#include 
#endif
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#endif
#ifdef RTE_LIBRTE_CMDLINE
/* TODO: C++ support
#include 
#include 
#include 
*/
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#endif
#ifdef RTE_LIBRTE_ACL
#include 
#endif
#ifdef RTE_LIBRTE_SCHED
#include 
#include 
#include 
#include 
#include 
#endif
#ifdef RTE_LIBRTE_NET
#include 
#include 
#include 
#include 
#include 
#include 
#endif
#ifdef RTE_LIBRTE_CFGFILE
#include 
#endif
#include 
#include 
#ifdef RTE_LIBRTE_CRYPTODEV
#include 
#include 
#include 
#endif
#ifdef RTE_LIBRTE_DISTRIBUTOR
#include 
#endif
#ifdef RTE_LIBRTE_PMD_AF_PACKET
#include 
#endif
#ifdef RTE_LIBRTE_PMD_BOND
#include 
#include 
#endif
#ifdef RTE_LIBRTE_ETHER
#include 
#include 
#include 
#endif
#ifdef RTE_LIBRTE_PMD_NULL
#include 
#endif
#ifdef RTE_LIBRTE_PMD_RING
#include 
#endif
#ifdef RTE_LIBRTE_HASH
#include 
#include 
#include 
#include 
#include 
#endif
#ifdef RTE_LIBRTE_IP_FRAG
#include 
#endif
#ifdef RTE_LIBRTE_JOBSTATS
#include 
#endif
#ifdef RTE_LIBRTE_KNI
#include 
#endif
#ifdef RTE_LIBRTE_KVARGS
#include 
#endif
#ifdef RTE_LIBRTE_LPM
#include 
#include 
#endif
#ifdef RTE_LIBRTE_MBUF
#include 
#endif
#ifdef RTE_LIBRTE_MBUF_OFFLOAD
#include 
#endif
#ifdef RTE_LIBRTE_MEMPOOL
#include 
#endif
#ifdef RTE_LIBRTE_METER
#include 
#endif
#ifdef RTE_LIBRTE_PIPELINE
#include 
#endif
#ifdef RTE_LIBRTE_PORT
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#endif
#ifdef RTE_LIBRTE_POWER
#include 
#endif
#ifdef RTE_LIBRTE_REORDER
#include 
#endif
#ifdef RTE_LIBRTE_RING
#include 
#endif
#ifdef RTE_LIBRTE_TABLE
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#endif
#ifdef RTE_LIBRTE_VHOST
/* TODO: fix vhost header for C++
#include 
*/
#endif

int
main(int argc, char **argv)
{
RTE_LOG(NOTICE, USER1, "function %s\n", __func__);
return 0;
}

[dpdk-dev] [PATCH] lib: Initial implementation of PQoS lib with CAT and CDP support

[Thomas Monjalon]

Hi,

2016-01-29 13:17, Wojciech Andralojc:
>  25 files changed, 2111 insertions(+)

The patch is too big to be easily reviewed.

> +PQoS API
> +M: Kantecki, Tomasz 
> +K: RTE_LIBRTE_PQOS
> +F: lib/librte_pqos/
>  
>  Drivers
>  ---
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 74bc515..553e640 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -99,6 +99,7 @@ CONFIG_RTE_NEXT_ABI=y
>  CONFIG_RTE_LIBRTE_EAL=y
>  CONFIG_RTE_MAX_LCORE=128
>  CONFIG_RTE_MAX_NUMA_NODES=8
> +CONFIG_RTE_MAX_PHY_PKGS=8

The physical packages management should be a separate patch.

>  CONFIG_RTE_MAX_MEMSEG=256
>  CONFIG_RTE_MAX_MEMZONE=2560
>  CONFIG_RTE_MAX_TAILQ=32
> @@ -514,6 +515,13 @@ CONFIG_RTE_LIBRTE_VHOST_NUMA=n
>  CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
>  
>  #
> +# Compile librte_pqos
> +# IA only
> +# LIBRTE_PQOS is for librte_pqos only

I think this line is not needed.

> +CONFIG_RTE_LIBRTE_PQOS=n
> +CONFIG_RTE_LIBRTE_PQOS_DEBUG=n

> --- a/lib/librte_eal/common/eal_private.h
> +++ b/lib/librte_eal/common/eal_private.h
> @@ -346,4 +346,13 @@ int rte_eal_hugepage_init(void);
>   */
>  int rte_eal_hugepage_attach(void);
>  
> +#ifdef RTE_LIBRTE_PQOS
> +/**
> + * Get cpu physical_package_id.
> + *
> + * This function is private to the EAL.
> + */
> +unsigned eal_cpu_phy_pkg_id(unsigned lcore_id);
> +#endif

No need to restrict this function to LIBRTE_PQOS.
Maybe it should be a public API.

> --- a/lib/librte_eal/common/include/rte_log.h
> +++ b/lib/librte_eal/common/include/rte_log.h
> @@ -79,6 +79,9 @@ extern struct rte_logs rte_logs;
>  #define RTE_LOGTYPE_PIPELINE 0x8000 /**< Log related to pipeline. */
>  #define RTE_LOGTYPE_MBUF0x0001 /**< Log related to mbuf. */
>  #define RTE_LOGTYPE_CRYPTODEV 0x0002 /**< Log related to cryptodev. */
> +#ifdef RTE_LIBRTE_PQOS
> +#define RTE_LOGTYPE_PQOS0x0004 /**< Log related to pqos. */
> +#endif

The ifdef is useless and forbidden in a header.

> --- a/lib/librte_eal/linuxapp/eal/Makefile
> +++ b/lib/librte_eal/linuxapp/eal/Makefile
> @@ -45,6 +45,9 @@ CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common/include
>  CFLAGS += -I$(RTE_SDK)/lib/librte_ring
>  CFLAGS += -I$(RTE_SDK)/lib/librte_mempool
>  CFLAGS += -I$(RTE_SDK)/lib/librte_ivshmem
> +ifeq ($(CONFIG_RTE_LIBRTE_PQOS),y)
> +CFLAGS += -I$(RTE_SDK)/lib/librte_pqos
> +endif

Please make EAL independent of librte_pqos.

> +++ b/lib/librte_pqos/rte_pqos_version.map
> @@ -0,0 +1,16 @@
> +DPDK_2.3 {

It will be DPDK_16.04.

I won't comment the library itself in this version.
Please rework EAL and patch splitting first.
Thanks

[dpdk-dev] IPV6 RSS not working in i40e

[Rahul Ramachandran]

Hi,

I am using dpdk 2.1. I see the hash flags are unified compared to my
previous version 1.8.
But with DPDK 2.1 in Fortville NIC's, I see ipv6 RSS is not working,
all the frames are queued to
first queue even though I have 16 queues (RETA table looks correct).

For IPV4 RSS works as expected in Fortville. Also in 10G, both ipv4 and
ipv6 RSS works.

My RSS configuration is : rss_hf = ETH_RSS_IP | ETH_*RSS*
_NONFRAG_IPV4_TCP | ETH_*RSS*_NONFRAG_IPV4_UDP

I see ETH_RSS_IP contains Layer3 hash flags for ipv6.

#define ETH_*RSS*_IP ( \
  ETH_*RSS*_IPV4 | \
  ETH_*RSS*_FRAG_IPV4 | \
  ETH_*RSS*_NONFRAG_IPV4_OTHER | \
  ETH_*RSS*_*IPV6* | \
  ETH_*RSS*_FRAG_*IPV6* | \
  ETH_*RSS*_NONFRAG_*IPV6*_OTHER | \
  ETH_*RSS*_*IPV6*_EX)

But when I query the hash flags, I get the value of . I understand
while configuring RSS
HF in the 40G NIC, we mask the configured RSS HF with NIC specific mask
flags before writing to NIC. But I am not
sure after masking it is taking the flags for IPV6.

The mask or I40E:I40E_*RSS*_OFFLOAD_ALL. I see this
conatins the flags ETH_*RSS*_FRAG_*IPV6 & *ETH_*RSS*_NONFRAG_*IPV6*_OTHER.

Are you aware of any such problems?

Please let me know if you need more information.

Thanks

[dpdk-dev] [PATCH] build: set CFLAGS for ppc64el build

[Fernando Seiti Furusato]

On 02/16/2016 04:09 PM, Thomas Monjalon wrote:
> 2016-02-16 16:04, Fernando Seiti Furusato:
>> Hi Thomas.
>>
>> On 02/12/2016 05:18 PM, Fernando Seiti Furusato wrote:
>>> Hello Thomas.
>>> Thanks for your quick response.
>>>
>>> On 02/12/2016 03:37 PM, Thomas Monjalon wrote:
 2016-02-12 12:05, Fernando Seiti Furusato:
> Add a proper ifeq statement to set the mcpu as needed for ppc64el, as
> the only one originally set is not valid for ppc architectures.

 What is the benefit of using the default machine config, compared to
 the power8 one?

 Don't you think the default machine should be renamed core2?
>>>
>>> I think it would be better indeed. Thanks for pointing that out.
>>>

 [...]
> +ifeq (ppc64le,$(shell uname -m))
> +MACHINE_CFLAGS += -mcpu=power8

 Why this flag is not set in mk/machine/power8/rte.vars.mk ?

>>>
>>> This and what observed above would make a better patch.
>>> Let me try those.
>>
>> I will be just changing the flag within mk/machine/power8/rte.vars.mk so
>> it will be used on ppc64le.
>
> Does it mean that only little endian is supported on POWER8?

Not exactly. It is just that I work mainly on LE.
It would probably work on big endian too.

>
>> I thought since I am not sure how it will affect others, I will not mess
>> with the default file.
>
> Yes let's keep it for another patch if someone is concerned.
>
>> I had to copy config/defconfig_ppc_64-power8-linuxapp-gcc to
>> config/defconfig_ppc64le-native-linuxapp-gcc, because the build searches
>> for it on ppc64le. Should I include that in the patch?
>> Do you think there is a better approach?
>
> Not sure to understand.
> I think there is something wrong in the commands you use to compile.
> Are you using "make config T=ppc_64-power8-linuxapp-gcc" ?
>

Nah, never mind about this one. You are right, I messed it up.
I copied the line from what was generated by debian/rules on the ubuntu package.

Thanks.

-- 

Fernando Seiti Furusato
IBM Linux Technology Center

[dpdk-dev] [PATCH v2] doc: introduce networking driver matrix

[Rahul Lakkireddy]

Hi Thomas,

Got a couple of questions on how to mark some of the features for CXGBE
below.

On Wednesday, January 01/27/16, 2016 at 21:07:09 +0100, Thomas Monjalon wrote:
> In order to better compare the drivers and check what is missing
> for a common baseline, we need to fill a matrix.
> 
> A CSS trick is used to fit the HTML page.
> The PDF output needs some LaTeX wizardry.
> 
> Signed-off-by: Thomas Monjalon 
> ---
> v2: add vector PMDs
> ---
>  doc/guides/nics/index.rst|   1 +
>  doc/guides/nics/overview.rst | 147 
> +++
>  2 files changed, 148 insertions(+)
>  create mode 100644 doc/guides/nics/overview.rst
> 

[...]

> +
> +    = = = = = = = = = = = = = = = = = = = = = = = = = = 
> = = = = =
> +   Feature  a b b b c e e i i i i i i i i i i f f m m m n n p r 
> s v v v x
> +f n n o x 1 n 4 4 4 4 g g x x x x m m l l p f u c i 
> z i i m e
> +p x x n g 0 i 0 0 0 0 b b g g g g 1 1 x x i p l a n 
> e r r x n
> +a 2 2 d b 0 c e e e e   v b b b b 0 0 4 5 p   l p g 
> d t t n v
> +c x x i e 0 . v v   f e e e e k k e 
> a i i e i
> +k   v n . f f   . v v   .   
> t o o t r
> +e   f g .   .   . f f   .   
> a   . 3 t
> +t   v   v   v   v   v   
> 2   v
> +e   e   e   e   e
>e
> +c   c   c   c   c
>c
> +    = = = = = = = = = = = = = = = = = = = = = = = = = = 
> = = = = =
> +   link status
> +   link status event
> +   Rx interrupt
> +   queue start/stop
> +   MTU update
> +   jumbo frame
> +   scattered Rx

[...]

> +   VLAN filter
> +   ethertype filter
> +   n-tuple filter
> +   SYN filter
> +   tunnel filter
> +   flexible filter
> +   hash filter
> +   flow director

It is possible to set some of the above filters via our cxgbe flow
director. Do we mark these filter features as supported?

[...]

> +   packet type parsing

Is this the same as the driver's ability to fill the mbuf->packet_type
field?

Thanks,
Rahul

[dpdk-dev] [PATCH v8 2/4] ethdev: Fill speed capability bitmaps in the PMDs

[Nélio Laranjeiro]

Hi Marc,

On Mon, Feb 15, 2016 at 06:14:42PM +0100, Marc wrote:
> Rahul, Neilo, Jing D, et al
> 
> On 15 February 2016 at 15:43, Rahul Lakkireddy  chelsio.com
> > wrote:
> 
> > Hi Marc,
> >
> > On Sunday, February 02/14/16, 2016 at 23:17:37 +0100, Marc Sune wrote:
> > > Added speed capabilities to all pmds supporting physical NICs:
> > >
> > > * e1000
> > > * ixgbe
> > > * i40
> > > * bnx2x
> > > * cxgbe
> > > * mlx4
> > > * mlx5
> > > * nfp
> > > * fm10k
> > >
> > > Signed-off-by: Marc Sune 
> > > ---
> > >  drivers/net/bnx2x/bnx2x_ethdev.c |  1 +
> > >  drivers/net/cxgbe/cxgbe_ethdev.c |  1 +
> > >  drivers/net/e1000/em_ethdev.c|  6 ++
> > >  drivers/net/e1000/igb_ethdev.c   |  6 ++
> > >  drivers/net/fm10k/fm10k_ethdev.c |  4 
> > >  drivers/net/i40e/i40e_ethdev.c   |  9 +
> > >  drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++
> > >  drivers/net/mlx4/mlx4.c  |  4 
> > >  drivers/net/mlx5/mlx5_ethdev.c   |  5 +
> > >  drivers/net/nfp/nfp_net.c|  2 ++
> > >  10 files changed, 48 insertions(+)
> > >
> >
> > [...]
> >
> > > diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c
> > b/drivers/net/cxgbe/cxgbe_ethdev.c
> > > index 97ef152..203e119 100644
> > > --- a/drivers/net/cxgbe/cxgbe_ethdev.c
> > > +++ b/drivers/net/cxgbe/cxgbe_ethdev.c
> > > @@ -171,6 +171,7 @@ static void cxgbe_dev_info_get(struct rte_eth_dev
> > *eth_dev,
> > >
> > >   device_info->rx_desc_lim = cxgbe_desc_lim;
> > >   device_info->tx_desc_lim = cxgbe_desc_lim;
> > > + device_info->speed_capa = ETH_SPEED_CAP_10G | ETH_SPEED_CAP_40G;
> > >  }
> > >
> >
> > Not all Chelsio NICs support _both_ 10G and 40G speed capabilities on a
> > single card.  You can query pi->link_cfg.supported to get the supported
> > speeds.  Check out print_port_info() in cxgbe_main.c to help you fill
> > in your speed capabilities for Chelsio NICs.
> >
> 
> This patch series has been long delayed, and I've been requested to merge
> it for next release if possible. Most of the feedback has been coming late
> (not for cxgbe, which is introduced in this new v8, but it did for most of
> the rest of drivers).
> 
> My proposal is simply to add in this patch series ALL possible speeds for
> that driver. Other patches can be later submitted to adjust speeds
> according to specific device model.

I agree with this.  I was asking in order to understand what your were
expecting from this API, for me it is clear.

You should just maintain the current situation i.e.
rte_eth_link.link_speed.  This is already what your patches do.

For the link speed capability (aka device_info->speed_capa), you should
add a new line "speed capability" in the doc/guides/nics/overview.rst.
Those who think it is useful will implement it in their PMD.

Regards,

-- 
N?lio Laranjeiro
6WIND

[dpdk-dev] [dpdk-announce] call to join Linux Foundation

[O'Driscoll, Tim]

> -Original Message-
> From: announce [mailto:announce-bounces at dpdk.org] On Behalf Of Thomas
> Monjalon
> Sent: Monday, February 15, 2016 3:15 PM
> To: announce at dpdk.org
> Subject: [dpdk-announce] call to join Linux Foundation
> 
> After few meetings and emails, it has been agreed to work with
> the Linux Foundation to assist the growing community of the DPDK. 
> 
> The outlines and the budget are described in this email by Tim
> O'Driscoll:
>   http://dpdk.org/ml/archives/dev/2016-February/032720.html
> 
> We need around ten companies to contribute to this small effort and
> become a supporter of the initiative.
> 
> As suggested by Dave Neary, the next step is to draft a membership
> agreement and identify the members of this new lightweight foundation:
>   http://dpdk.org/ml/archives/dev/2016-February/032909.html
> 
> Please, it would be great to use this thread to announce the official
> commitment of your company to support the DPDK community!

Thanks Thomas for progressing this. Intel will support moving the DPDK 
community to the Linux Foundation as we believe this will be in the best 
long-term interests of the project.


Tim

[dpdk-dev] [PATCH v2 0/3] fix C++ includes

[Ferruh Yigit]

On Tue, Feb 16, 2016 at 08:14:22AM +0100, Thomas Monjalon wrote:
> When trying to build a C++ application, some errors appear from DPDK headers.
> 2 libraries are not fixed in this series:
> - cmdline
> - vhost which includes some not compliant Linux virtio headers
> 
Hi Thomas,

Out of curiosity, how can we detect C++ compilation problems, do we have a C++ 
sample application?
Or how can we compile any existing application with c++, I tried 
"EXTRA_CFLAGS="-x c++" or "CC=g++" but both failed to compile.

Thanks,
ferruh

[dpdk-dev] [PATCH v3 7/7] app/testpmd: add CLIs for E-tag operation

[Wenzhuo Lu]

Add the CLIs to support the E-tag operation.
1, Offloading of E-tag insertion and stripping.
2, Forwarding the E-tag packets to pools based on the GRP and E-CID_base.

Signed-off-by: Wenzhuo Lu 
---
 app/test-pmd/cmdline.c  | 378 
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  26 ++
 2 files changed, 404 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 718fe93..294f6d0 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -500,6 +500,27 @@ static void cmd_help_long_parsed(void *parsed_result,
"set link-down port (port_id)\n"
"   Set link down for a port.\n\n"

+   "E-tag set insertion on port-tag-id (value)"
+   " port (port_id) vf (vf_id)\n"
+   "Enable E-tag insertion for a VF on a port\n\n"
+
+   "E-tag set insertion off port (port_id) vf (vf_id)\n"
+   "Disable E-tag insertion for a VF on a port\n\n"
+
+   "E-tag set stripping (on|off) port (port_id)\n"
+   "Enable/disable E-tag stripping on a port\n\n"
+
+   "E-tag set forwarding (on|off) port (port_id)\n"
+   "Enable/disable E-tag based forwarding"
+   " on a port\n\n"
+
+   "E-tag set filter add e-tag-id (value) dst-pool"
+   " (pool_id) port (port_id)\n"
+   "Add an E-tag forwarding filter on a port\n\n"
+
+   "E-tag set filter del e-tag-id (value) port (port_id)\n"
+   "Delete an E-tag forwarding filter on a port\n\n"
+
, list_pkt_forwarding_modes()
);
}
@@ -9893,6 +9914,357 @@ cmdline_parse_inst_t 
cmd_config_l2_tunnel_en_dis_specific = {
},
 };

+/* E-tag configuration */
+
+/* Common result structure for all E-tag configuration */
+struct cmd_config_e_tag_result {
+   cmdline_fixed_string_t e_tag;
+   cmdline_fixed_string_t set;
+   cmdline_fixed_string_t insertion;
+   cmdline_fixed_string_t stripping;
+   cmdline_fixed_string_t forwarding;
+   cmdline_fixed_string_t filter;
+   cmdline_fixed_string_t add;
+   cmdline_fixed_string_t del;
+   cmdline_fixed_string_t on;
+   cmdline_fixed_string_t off;
+   cmdline_fixed_string_t on_off;
+   cmdline_fixed_string_t port_tag_id;
+   uint32_t port_tag_id_val;
+   cmdline_fixed_string_t e_tag_id;
+   uint16_t e_tag_id_val;
+   cmdline_fixed_string_t dst_pool;
+   uint8_t dst_pool_val;
+   cmdline_fixed_string_t port;
+   uint8_t port_id;
+   cmdline_fixed_string_t vf;
+   uint8_t vf_id;
+};
+
+/* Common CLI fields for all E-tag configuration */
+cmdline_parse_token_string_t cmd_config_e_tag_e_tag =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_e_tag_result,
+e_tag, "E-tag");
+cmdline_parse_token_string_t cmd_config_e_tag_set =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_e_tag_result,
+set, "set");
+cmdline_parse_token_string_t cmd_config_e_tag_insertion =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_e_tag_result,
+insertion, "insertion");
+cmdline_parse_token_string_t cmd_config_e_tag_stripping =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_e_tag_result,
+stripping, "stripping");
+cmdline_parse_token_string_t cmd_config_e_tag_forwarding =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_e_tag_result,
+forwarding, "forwarding");
+cmdline_parse_token_string_t cmd_config_e_tag_filter =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_e_tag_result,
+filter, "filter");
+cmdline_parse_token_string_t cmd_config_e_tag_add =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_e_tag_result,
+add, "add");
+cmdline_parse_token_string_t cmd_config_e_tag_del =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_e_tag_result,
+del, "del");
+cmdline_parse_token_string_t cmd_config_e_tag_on =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_e_tag_result,
+on, "on");
+cmdline_parse_token_string_t cmd_config_e_tag_off =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_e_tag_result,
+off, "off");
+cmdline_parse_token_string_t cmd_config_e_tag_on_off =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_e_tag_result,
+on_off, "on#off");
+cmdline_parse_token_string_t cmd_config_e_tag_port_tag_id =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_e_tag_result,
+port_tag_id, "port-tag-id");

[dpdk-dev] [PATCH v3 6/7] ixgbe: support l2 tunnel operation

[Wenzhuo Lu]

Add support of l2 tunnel operation.
Support enabling/disabling l2 tunnel tag insertion/stripping.
Support enabling/disabling l2 tunnel packets forwarding.
Support adding/deleting forwarding rules for l2 tunnel packets.
Only support E-tag now.

Also update the release note.

Signed-off-by: Wenzhuo Lu 
---
 doc/guides/rel_notes/release_2_3.rst |   6 +
 drivers/net/ixgbe/ixgbe_ethdev.c | 368 +++
 2 files changed, 374 insertions(+)

diff --git a/doc/guides/rel_notes/release_2_3.rst 
b/doc/guides/rel_notes/release_2_3.rst
index 99de186..16bd80b 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -4,6 +4,12 @@ DPDK Release 2.3
 New Features
 

+* **Added support for E-tag on X550.**
+
+  * Support E-tag offloading of insertion and stripping.
+  * Support Forwarding E-tag packets to pools based on
+GRP and E-CID_base.
+

 Resolved Issues
 ---
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 55ab474..6533d96 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -139,10 +139,17 @@
 #define IXGBE_CYCLECOUNTER_MASK   0xULL

 #define IXGBE_VT_CTL_POOLING_MODE_MASK 0x0003
+#define IXGBE_VT_CTL_POOLING_MODE_ETAG 0x0001
 #define DEFAULT_ETAG_ETYPE 0x893f
 #define IXGBE_ETAG_ETYPE   0x5084
 #define IXGBE_ETAG_ETYPE_MASK  0x
 #define IXGBE_ETAG_ETYPE_VALID 0x8000
+#define IXGBE_RAH_ADTYPE   0x4000
+#define IXGBE_RAL_ETAG_FILTER_MASK 0x3fff
+#define IXGBE_VMVIR_TAGA_MASK  0x1800
+#define IXGBE_VMVIR_TAGA_ETAG_INSERT   0x0800
+#define IXGBE_VMTIR(_i) (0x00017000 + ((_i) * 4)) /* 64 of these (0-63) */
+#define IXGBE_QDE_STRIP_TAG0x0004

 static int eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev);
 static int eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev);
@@ -351,6 +358,33 @@ static int ixgbe_dev_l2_tunnel_enable
 static int ixgbe_dev_l2_tunnel_disable
(struct rte_eth_dev *dev,
 enum rte_eth_l2_tunnel_type l2_tunnel_type);
+static int ixgbe_dev_l2_tunnel_insertion_enable
+   (struct rte_eth_dev *dev,
+struct rte_eth_l2_tunnel *l2_tunnel,
+uint16_t vf_id);
+static int ixgbe_dev_l2_tunnel_insertion_disable
+   (struct rte_eth_dev *dev,
+enum rte_eth_l2_tunnel_type l2_tunnel_type,
+uint16_t vf_id);
+static int ixgbe_dev_l2_tunnel_stripping_enable
+   (struct rte_eth_dev *dev,
+enum rte_eth_l2_tunnel_type l2_tunnel_type);
+static int ixgbe_dev_l2_tunnel_stripping_disable
+   (struct rte_eth_dev *dev,
+enum rte_eth_l2_tunnel_type l2_tunnel_type);
+static int ixgbe_dev_l2_tunnel_forwarding_enable
+   (struct rte_eth_dev *dev,
+enum rte_eth_l2_tunnel_type l2_tunnel_type);
+static int ixgbe_dev_l2_tunnel_forwarding_disable
+   (struct rte_eth_dev *dev,
+enum rte_eth_l2_tunnel_type l2_tunnel_type);
+static int ixgbe_dev_l2_tunnel_filter_add
+   (struct rte_eth_dev *dev,
+struct rte_eth_l2_tunnel *l2_tunnel,
+uint32_t pool);
+static int ixgbe_dev_l2_tunnel_filter_del
+   (struct rte_eth_dev *dev,
+struct rte_eth_l2_tunnel *l2_tunnel);

 /*
  * Define VF Stats MACRO for Non "cleared on read" register
@@ -512,6 +546,14 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
.l2_tunnel_eth_type_conf = ixgbe_dev_l2_tunnel_eth_type_conf,
.l2_tunnel_enable= ixgbe_dev_l2_tunnel_enable,
.l2_tunnel_disable   = ixgbe_dev_l2_tunnel_disable,
+   .l2_tunnel_insertion_enable   = ixgbe_dev_l2_tunnel_insertion_enable,
+   .l2_tunnel_insertion_disable  = ixgbe_dev_l2_tunnel_insertion_disable,
+   .l2_tunnel_stripping_enable   = ixgbe_dev_l2_tunnel_stripping_enable,
+   .l2_tunnel_stripping_disable  = ixgbe_dev_l2_tunnel_stripping_disable,
+   .l2_tunnel_forwarding_enable  = ixgbe_dev_l2_tunnel_forwarding_enable,
+   .l2_tunnel_forwarding_disable = ixgbe_dev_l2_tunnel_forwarding_disable,
+   .l2_tunnel_filter_add = ixgbe_dev_l2_tunnel_filter_add,
+   .l2_tunnel_filter_del = ixgbe_dev_l2_tunnel_filter_del,
 };

 /*
@@ -6341,6 +6383,332 @@ ixgbe_dev_l2_tunnel_disable(struct rte_eth_dev *dev,
return ret;
 }

+static int
+ixgbe_e_tag_filter_add(struct rte_eth_dev *dev,
+  struct rte_eth_l2_tunnel *l2_tunnel,
+  uint32_t pool)
+{
+   int ret = 0;
+   struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   u32 i, rar_entries;
+   u32 rar_low, rar_high;
+
+   if (hw->mac.type != ixgbe_mac_X550 &&
+   hw->mac.type != ixgbe_mac_X550EM_x) {
+   return -ENOTSUP;
+   }
+
+   rar_entries = ixgbe_get_num_rx_addrs(hw);
+
+   for (i = 

[dpdk-dev] [PATCH v3 5/7] lib/librte_ether: support new l2 tunnel operation

[Wenzhuo Lu]

Add functions to support the new l2 tunnel operation.
1, Insertion and stripping for l2 tunnel tag.
2, Forwarding the packets to a pool based on l2 tunnel tag.

Signed-off-by: Wenzhuo Lu 
---
 lib/librte_ether/rte_ethdev.c | 183 
 lib/librte_ether/rte_ethdev.h | 214 ++
 2 files changed, 397 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 1b90e09..4ab3fd3 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3300,3 +3300,186 @@ rte_eth_dev_l2_tunnel_disable(uint8_t port_id,
-ENOTSUP);
return (*dev->dev_ops->l2_tunnel_disable)(dev, l2_tunnel_type);
 }
+
+int
+rte_eth_dev_l2_tunnel_insertion_enable(uint8_t port_id,
+  struct rte_eth_l2_tunnel *l2_tunnel,
+  uint16_t vf_id)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+   if (l2_tunnel == NULL) {
+   RTE_PMD_DEBUG_TRACE("Invalid l2_tunnel parameter\n");
+   return -EINVAL;
+   }
+
+   if (l2_tunnel->l2_tunnel_type >= RTE_L2_TUNNEL_TYPE_MAX) {
+   RTE_PMD_DEBUG_TRACE("Invalid l2 tunnel type\n");
+   return -EINVAL;
+   }
+
+   dev = _eth_devices[port_id];
+   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->l2_tunnel_insertion_enable,
+   -ENOTSUP);
+   return (*dev->dev_ops->l2_tunnel_insertion_enable)(dev,
+  l2_tunnel,
+  vf_id);
+}
+
+int
+rte_eth_dev_l2_tunnel_insertion_disable(uint8_t port_id,
+   enum rte_eth_l2_tunnel_type
+   l2_tunnel_type,
+   uint16_t vf_id)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+   if (l2_tunnel_type >= RTE_L2_TUNNEL_TYPE_MAX) {
+   RTE_PMD_DEBUG_TRACE("Invalid l2 tunnel type\n");
+   return -EINVAL;
+   }
+
+   dev = _eth_devices[port_id];
+   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->l2_tunnel_insertion_disable,
+   -ENOTSUP);
+   return (*dev->dev_ops->l2_tunnel_insertion_disable)(dev,
+   l2_tunnel_type,
+   vf_id);
+}
+
+int
+rte_eth_dev_l2_tunnel_stripping_enable(uint8_t port_id,
+  enum rte_eth_l2_tunnel_type
+  l2_tunnel_type)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+   if (l2_tunnel_type >= RTE_L2_TUNNEL_TYPE_MAX) {
+   RTE_PMD_DEBUG_TRACE("Invalid l2 tunnel type\n");
+   return -EINVAL;
+   }
+
+   dev = _eth_devices[port_id];
+   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->l2_tunnel_stripping_enable,
+   -ENOTSUP);
+   return (*dev->dev_ops->l2_tunnel_stripping_enable)(dev,
+  l2_tunnel_type);
+}
+
+int
+rte_eth_dev_l2_tunnel_stripping_disable(uint8_t port_id,
+enum rte_eth_l2_tunnel_type
+l2_tunnel_type)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+   if (l2_tunnel_type >= RTE_L2_TUNNEL_TYPE_MAX) {
+   RTE_PMD_DEBUG_TRACE("Invalid l2 tunnel type\n");
+   return -EINVAL;
+   }
+
+   dev = _eth_devices[port_id];
+   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->l2_tunnel_stripping_disable,
+   -ENOTSUP);
+   return (*dev->dev_ops->l2_tunnel_stripping_disable)(dev,
+   l2_tunnel_type);
+}
+
+int
+rte_eth_dev_l2_tunnel_forwarding_enable(uint8_t port_id,
+enum rte_eth_l2_tunnel_type
+l2_tunnel_type)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+   if (l2_tunnel_type >= RTE_L2_TUNNEL_TYPE_MAX) {
+   RTE_PMD_DEBUG_TRACE("Invalid l2 tunnel type\n");
+   return -EINVAL;
+   }
+
+   dev = _eth_devices[port_id];
+   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->l2_tunnel_forwarding_enable,
+   -ENOTSUP);
+   return (*dev->dev_ops->l2_tunnel_forwarding_enable)(dev,
+   l2_tunnel_type);
+}
+
+int
+rte_eth_dev_l2_tunnel_forwarding_disable(uint8_t port_id,
+

[dpdk-dev] [PATCH v3 4/7] app/testpmd: add CLIs for l2 tunnel config

[Wenzhuo Lu]

Add CLIs to config ether type of l2 tunnel, and to enable/disable
a type of l2 tunnel.
Now only e-tag tunnel is supported.

Signed-off-by: Wenzhuo Lu 
---
 app/test-pmd/cmdline.c  | 269 +++-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  11 ++
 2 files changed, 279 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..718fe93 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -570,7 +570,15 @@ static void cmd_help_long_parsed(void *parsed_result,

"port (port_id) (rxq|txq) (queue_id) (start|stop)\n"
"Start/stop a rx/tx queue of port X. Only take 
effect"
-   " when port X is started\n"
+   " when port X is started\n\n"
+
+   "port config (port_id|all) l2-tunnel E-tag ether-type"
+   " (value)\n"
+   "Set the value of E-tag ether-type.\n\n"
+
+   "port config (port_id|all) l2-tunnel E-tag"
+   " (enable|disable)\n"
+   "Enable/disable the E-tag support.\n\n"
);
}

@@ -9630,6 +9638,261 @@ cmdline_parse_inst_t cmd_mcast_addr = {
},
 };

+/* l2 tunnel config
+ * only support E-tag now.
+ */
+
+/* Ether type config */
+struct cmd_config_l2_tunnel_eth_type_result {
+   cmdline_fixed_string_t port;
+   cmdline_fixed_string_t config;
+   cmdline_fixed_string_t all;
+   uint8_t id;
+   cmdline_fixed_string_t l2_tunnel;
+   cmdline_fixed_string_t l2_tunnel_type;
+   cmdline_fixed_string_t eth_type;
+   uint16_t eth_type_val;
+};
+
+cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_port =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_l2_tunnel_eth_type_result,
+port, "port");
+cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_config =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_l2_tunnel_eth_type_result,
+config, "config");
+cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_all_str =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_l2_tunnel_eth_type_result,
+all, "all");
+cmdline_parse_token_num_t cmd_config_l2_tunnel_eth_type_id =
+   TOKEN_NUM_INITIALIZER
+   (struct cmd_config_l2_tunnel_eth_type_result,
+id, UINT8);
+cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_l2_tunnel =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_l2_tunnel_eth_type_result,
+l2_tunnel, "l2-tunnel");
+cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_l2_tunnel_type =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_l2_tunnel_eth_type_result,
+l2_tunnel_type, "E-tag");
+cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_eth_type =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_config_l2_tunnel_eth_type_result,
+eth_type, "ether-type");
+cmdline_parse_token_num_t cmd_config_l2_tunnel_eth_type_eth_type_val =
+   TOKEN_NUM_INITIALIZER
+   (struct cmd_config_l2_tunnel_eth_type_result,
+eth_type_val, UINT16);
+
+static uint32_t
+str2fdir_l2_tunnel_type(char *string)
+{
+   uint32_t i = 0;
+
+   static const struct {
+   char str[32];
+   uint32_t type;
+   } l2_tunnel_type_str[] = {
+   {"E-tag", RTE_L2_TUNNEL_TYPE_E_TAG},
+   };
+
+   for (i = 0; i < RTE_DIM(l2_tunnel_type_str); i++) {
+   if (!strcmp(l2_tunnel_type_str[i].str, string))
+   return l2_tunnel_type_str[i].type;
+   }
+   return RTE_L2_TUNNEL_TYPE_NONE;
+}
+
+/* ether type config for all ports */
+static void
+cmd_config_l2_tunnel_eth_type_all_parsed
+   (void *parsed_result,
+__attribute__((unused)) struct cmdline *cl,
+__attribute__((unused)) void *data)
+{
+   struct cmd_config_l2_tunnel_eth_type_result *res = parsed_result;
+   struct rte_eth_l2_tunnel entry;
+   portid_t pid;
+
+   entry.l2_tunnel_type = str2fdir_l2_tunnel_type(res->l2_tunnel_type);
+   entry.ether_type = res->eth_type_val;
+
+   FOREACH_PORT(pid, ports) {
+   rte_eth_dev_l2_tunnel_eth_type_conf(pid, );
+   }
+}
+
+cmdline_parse_inst_t cmd_config_l2_tunnel_eth_type_all = {
+   .f = cmd_config_l2_tunnel_eth_type_all_parsed,
+   .data = NULL,
+   .help_str = "port config all l2-tunnel ether-type",
+   .tokens = {
+   (void *)_config_l2_tunnel_eth_type_port,
+   (void *)_config_l2_tunnel_eth_type_config,
+   (void *)_config_l2_tunnel_eth_type_all_str,
+   (void *)_config_l2_tunnel_eth_type_l2_tunnel,
+   (void *)_config_l2_tunnel_eth_type_l2_tunnel_type,
+

[dpdk-dev] [PATCH v3 3/7] ixgbe: support l2 tunnel config

[Wenzhuo Lu]

Add support of l2 tunnel configuration.
Support modifying ether type of a type of l2 tunnel.
Support enabling and disabling the support of a type of l2 tunnel.
Only E-tag tunnel is supported now.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 140 +++
 1 file changed, 140 insertions(+)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 83df0c0..55ab474 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -139,6 +139,10 @@
 #define IXGBE_CYCLECOUNTER_MASK   0xULL

 #define IXGBE_VT_CTL_POOLING_MODE_MASK 0x0003
+#define DEFAULT_ETAG_ETYPE 0x893f
+#define IXGBE_ETAG_ETYPE   0x5084
+#define IXGBE_ETAG_ETYPE_MASK  0x
+#define IXGBE_ETAG_ETYPE_VALID 0x8000

 static int eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev);
 static int eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev);
@@ -339,6 +343,14 @@ static int ixgbe_timesync_read_time(struct rte_eth_dev 
*dev,
   struct timespec *timestamp);
 static int ixgbe_timesync_write_time(struct rte_eth_dev *dev,
   const struct timespec *timestamp);
+static int ixgbe_dev_l2_tunnel_eth_type_conf
+   (struct rte_eth_dev *dev, struct rte_eth_l2_tunnel *l2_tunnel);
+static int ixgbe_dev_l2_tunnel_enable
+   (struct rte_eth_dev *dev,
+enum rte_eth_l2_tunnel_type l2_tunnel_type);
+static int ixgbe_dev_l2_tunnel_disable
+   (struct rte_eth_dev *dev,
+enum rte_eth_l2_tunnel_type l2_tunnel_type);

 /*
  * Define VF Stats MACRO for Non "cleared on read" register
@@ -497,6 +509,9 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
.timesync_adjust_time = ixgbe_timesync_adjust_time,
.timesync_read_time   = ixgbe_timesync_read_time,
.timesync_write_time  = ixgbe_timesync_write_time,
+   .l2_tunnel_eth_type_conf = ixgbe_dev_l2_tunnel_eth_type_conf,
+   .l2_tunnel_enable= ixgbe_dev_l2_tunnel_enable,
+   .l2_tunnel_disable   = ixgbe_dev_l2_tunnel_disable,
 };

 /*
@@ -6201,6 +6216,131 @@ ixgbe_dev_get_dcb_info(struct rte_eth_dev *dev,
return 0;
 }

+/* Update e-tag ether type */
+static int
+ixgbe_update_e_tag_eth_type(struct ixgbe_hw *hw,
+   uint16_t ether_type)
+{
+   uint32_t etag_etype;
+
+   if (hw->mac.type != ixgbe_mac_X550 &&
+   hw->mac.type != ixgbe_mac_X550EM_x) {
+   return -ENOTSUP;
+   }
+
+   etag_etype = IXGBE_READ_REG(hw, IXGBE_ETAG_ETYPE);
+   etag_etype &= ~IXGBE_ETAG_ETYPE_MASK;
+   etag_etype |= ether_type;
+   IXGBE_WRITE_REG(hw, IXGBE_ETAG_ETYPE, etag_etype);
+   IXGBE_WRITE_FLUSH(hw);
+
+   return 0;
+}
+
+/* Config l2 tunnel ether type */
+static int
+ixgbe_dev_l2_tunnel_eth_type_conf(struct rte_eth_dev *dev,
+ struct rte_eth_l2_tunnel *l2_tunnel)
+{
+   int ret = 0;
+   struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   if (l2_tunnel == NULL)
+   return -EINVAL;
+
+   switch (l2_tunnel->l2_tunnel_type) {
+   case RTE_L2_TUNNEL_TYPE_E_TAG:
+   ret = ixgbe_update_e_tag_eth_type(hw, l2_tunnel->ether_type);
+   break;
+   default:
+   PMD_DRV_LOG(ERR, "Invalid tunnel type");
+   ret = -1;
+   break;
+   }
+
+   return ret;
+}
+
+/* Enable e-tag tunnel */
+static int
+ixgbe_e_tag_enable(struct ixgbe_hw *hw)
+{
+   uint32_t etag_etype;
+
+   if (hw->mac.type != ixgbe_mac_X550 &&
+   hw->mac.type != ixgbe_mac_X550EM_x) {
+   return -ENOTSUP;
+   }
+
+   etag_etype = IXGBE_READ_REG(hw, IXGBE_ETAG_ETYPE);
+   etag_etype |= IXGBE_ETAG_ETYPE_VALID;
+   IXGBE_WRITE_REG(hw, IXGBE_ETAG_ETYPE, etag_etype);
+   IXGBE_WRITE_FLUSH(hw);
+
+   return 0;
+}
+
+/* Enable l2 tunnel */
+static int
+ixgbe_dev_l2_tunnel_enable(struct rte_eth_dev *dev,
+  enum rte_eth_l2_tunnel_type l2_tunnel_type)
+{
+   int ret = 0;
+   struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   switch (l2_tunnel_type) {
+   case RTE_L2_TUNNEL_TYPE_E_TAG:
+   ret = ixgbe_e_tag_enable(hw);
+   break;
+   default:
+   PMD_DRV_LOG(ERR, "Invalid tunnel type");
+   ret = -1;
+   break;
+   }
+
+   return ret;
+}
+
+/* Disable e-tag tunnel */
+static int
+ixgbe_e_tag_disable(struct ixgbe_hw *hw)
+{
+   uint32_t etag_etype;
+
+   if (hw->mac.type != ixgbe_mac_X550 &&
+   hw->mac.type != ixgbe_mac_X550EM_x) {
+   return -ENOTSUP;
+   }
+
+   etag_etype = IXGBE_READ_REG(hw, IXGBE_ETAG_ETYPE);
+   etag_etype &= ~IXGBE_ETAG_ETYPE_VALID;
+   IXGBE_WRITE_REG(hw, 

[dpdk-dev] [PATCH v3 2/7] lib/librte_ether: support l2 tunnel config

[Wenzhuo Lu]

Add functions to support l2 tunnel configuration.
The support includes ether type modification and the tunnel support
enabling/disabling.
Ether type modification means modifying the ether type of a specific
type of tunnel. So the packet with this ether type will be parsed as
this type of tunnel.
Enabling/disabling a tunnel support means enabling/disabling the
ability of parsing the specific type of tunnel. This ability should
be enabled before we enable filtering, forwarding, offloading for
this specific type of tunnel.
Only support e-tag tunnel now.

Signed-off-by: Wenzhuo Lu 
---
 lib/librte_ether/rte_eth_ctrl.h |  9 +
 lib/librte_ether/rte_ethdev.c   | 61 ++
 lib/librte_ether/rte_ethdev.h   | 84 +
 3 files changed, 154 insertions(+)

diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index ce224ad..09af6fb 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -804,6 +804,15 @@ struct rte_eth_hash_filter_info {
} info;
 };

+/**
+ * l2 tunnel type.
+ */
+enum rte_eth_l2_tunnel_type {
+   RTE_L2_TUNNEL_TYPE_NONE = 0,
+   RTE_L2_TUNNEL_TYPE_E_TAG,
+   RTE_L2_TUNNEL_TYPE_MAX,
+};
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index ed971b4..1b90e09 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3239,3 +3239,64 @@ rte_eth_copy_pci_info(struct rte_eth_dev *eth_dev, 
struct rte_pci_device *pci_de
eth_dev->data->numa_node = pci_dev->numa_node;
eth_dev->data->drv_name = pci_dev->driver->name;
 }
+
+int
+rte_eth_dev_l2_tunnel_eth_type_conf(uint8_t port_id,
+   struct rte_eth_l2_tunnel *l2_tunnel)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+   if (l2_tunnel == NULL) {
+   RTE_PMD_DEBUG_TRACE("Invalid l2_tunnel parameter\n");
+   return -EINVAL;
+   }
+
+   if (l2_tunnel->l2_tunnel_type >= RTE_L2_TUNNEL_TYPE_MAX) {
+   RTE_PMD_DEBUG_TRACE("Invalid l2 tunnel type\n");
+   return -EINVAL;
+   }
+
+   dev = _eth_devices[port_id];
+   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->l2_tunnel_eth_type_conf,
+   -ENOTSUP);
+   return (*dev->dev_ops->l2_tunnel_eth_type_conf)(dev, l2_tunnel);
+}
+
+int
+rte_eth_dev_l2_tunnel_enable(uint8_t port_id,
+enum rte_eth_l2_tunnel_type l2_tunnel_type)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+   if (l2_tunnel_type >= RTE_L2_TUNNEL_TYPE_MAX) {
+   RTE_PMD_DEBUG_TRACE("Invalid l2 tunnel type\n");
+   return -EINVAL;
+   }
+
+   dev = _eth_devices[port_id];
+   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->l2_tunnel_enable,
+   -ENOTSUP);
+   return (*dev->dev_ops->l2_tunnel_enable)(dev, l2_tunnel_type);
+}
+
+int
+rte_eth_dev_l2_tunnel_disable(uint8_t port_id,
+ enum rte_eth_l2_tunnel_type l2_tunnel_type)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+   if (l2_tunnel_type >= RTE_L2_TUNNEL_TYPE_MAX) {
+   RTE_PMD_DEBUG_TRACE("Invalid l2 tunnel type\n");
+   return -EINVAL;
+   }
+
+   dev = _eth_devices[port_id];
+   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->l2_tunnel_disable,
+   -ENOTSUP);
+   return (*dev->dev_ops->l2_tunnel_disable)(dev, l2_tunnel_type);
+}
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index bada8ad..9b594b8 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -957,6 +957,14 @@ TAILQ_HEAD(rte_eth_dev_cb_list, rte_eth_dev_callback);
} \
 } while (0)

+/**
+ * l2 tunnel configuration.
+ */
+struct rte_eth_l2_tunnel {
+   enum rte_eth_l2_tunnel_type l2_tunnel_type;
+   uint16_t ether_type;
+};
+
 /*
  * Definitions of all functions exported by an Ethernet driver through the
  * the generic structure of type *eth_dev_ops* supplied in the *rte_eth_dev*
@@ -1261,6 +1269,20 @@ typedef int (*eth_set_eeprom_t)(struct rte_eth_dev *dev,
struct rte_dev_eeprom_info *info);
 /**< @internal Program eeprom data  */

+typedef int (*eth_l2_tunnel_eth_type_conf_t)
+   (struct rte_eth_dev *dev, struct rte_eth_l2_tunnel *l2_tunnel);
+/**< @internal config l2 tunnel ether type */
+
+typedef int (*eth_l2_tunnel_enable_t)
+   (struct rte_eth_dev *dev,
+enum rte_eth_l2_tunnel_type l2_tunnel_type);
+/**< @internal enable a type of l2 tunnel */
+
+typedef int (*eth_l2_tunnel_disable_t)
+   (struct rte_eth_dev *dev,
+enum rte_eth_l2_tunnel_type l2_tunnel_type);
+/**< @internal disable a type of l2 tunnel */
+
 #ifdef 

[dpdk-dev] [PATCH v3 1/7] ixgbe: select pool by MAC when using double VLAN

[Wenzhuo Lu]

On X550, as required by datasheet, E-tag packets are not expected
when double VLAN are used. So modify the register PFVTCTL after
enabling double VLAN to select pool by MAC but not MAC or E-tag.

An introduction of E-tag:
It's defined in IEEE802.1br. Please reference this website,
http://www.ieee802.org/1/pages/802.1br.html.

A brief description.
E-tag means external tag, and it's a kind of l2 tunnel. It means a
tag will be inserted in the l2 header. Like below,
   |3124|23   16|15 8|7   0|
  0|   Destination MAC address |
  4| Dest MAC address(cont.)| Src MAC address  |
  8|  Source MAC address(cont.)|
 12| E-tag Etherenet type (0x893f)  |  E-tag header|
 16|E-tag header(cont.)|
 20|   VLAN Ethertype(optional) |   VLAN header(optional)  |
 24| Original type  | ..   |
...|  ..   |
The E-tag format is like below,
   |015|16   18|19 |20   31|
   |   Ethertype - 0x893f  | E-PCP |DEI|   Ingress E-CID_base  |

   |32  33|34 35|36  47|48 55|56 63|
   |  RSV | GRP |E-CID_base|Ingress_E-CID_ext|E-CID_ext|

The Ingess_E-CID_ext and E-CID_ext are always zero for endpoints
and are effectively reserved.

The more details of E-tag is in IEEE 802.1BR. 802.1BR is used to
replace 802.1Qbh. 802.1BR is a standard for Bridge Port Extension.
It specifies the operation of Bridge Port Extenders, including
management, protocols, and algorithms. Bridge Port Extenders
operate in support of the MAC Service by Extended Bridges.
The E-tag is added to l2 header to identify the VM channel and
the virtual port.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 4c4c6df..83df0c0 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -138,6 +138,8 @@

 #define IXGBE_CYCLECOUNTER_MASK   0xULL

+#define IXGBE_VT_CTL_POOLING_MODE_MASK 0x0003
+
 static int eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev);
 static int eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev);
 static int  ixgbe_dev_configure(struct rte_eth_dev *dev);
@@ -1725,6 +1727,14 @@ ixgbe_vlan_hw_extend_enable(struct rte_eth_dev *dev)
ctrl |= IXGBE_EXTENDED_VLAN;
IXGBE_WRITE_REG(hw, IXGBE_CTRL_EXT, ctrl);

+   /* Clear pooling mode of PFVTCTL. It's required by X550. */
+   if (hw->mac.type == ixgbe_mac_X550 ||
+   hw->mac.type == ixgbe_mac_X550EM_x) {
+   ctrl = IXGBE_READ_REG(hw, IXGBE_VT_CTL);
+   ctrl &= ~IXGBE_VT_CTL_POOLING_MODE_MASK;
+   IXGBE_WRITE_REG(hw, IXGBE_VT_CTL, ctrl);
+   }
+
/*
 * VET EXT field in the EXVET register = 0x8100 by default
 * So no need to change. Same to VT field of DMATXCTL register
-- 
1.9.3

[dpdk-dev] [PATCH v3 0/7] support E-tag offloading and forwarding on Intel X550 NIC

[Wenzhuo Lu]

This patch set adds the support of E-tag offloading and forwarding
on X550.
The offloading means E-tag can be inserted and stripped by HW.
And E-tag packets can be recognized and forwarded to specific pools
based on GRP and E-CID_base in E-tag.

E-tag is defined in IEEE802.1br. Please reference
http://www.ieee802.org/1/pages/802.1br.html.

V2:
* Add the introduction for E-tag.

V3:
* Add the hlep info for the new CLIs.
* Update the doc for testpmd.
* Update the E-tag insertion setting. Should insert different tunnel
  id for every VF, not a common one for all.

Wenzhuo Lu (7):
  ixgbe: select pool by MAC when using double VLAN
  lib/librte_ether: support l2 tunnel config
  ixgbe: support l2 tunnel config
  app/testpmd: add CLIs for l2 tunnel config
  lib/librte_ether: support new l2 tunnel operation
  ixgbe: support l2 tunnel operation
  app/testpmd: add CLIs for E-tag operation

 app/test-pmd/cmdline.c  | 647 +++-
 doc/guides/rel_notes/release_2_3.rst|   6 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  37 ++
 drivers/net/ixgbe/ixgbe_ethdev.c| 518 ++
 lib/librte_ether/rte_eth_ctrl.h |   9 +
 lib/librte_ether/rte_ethdev.c   | 244 +++
 lib/librte_ether/rte_ethdev.h   | 298 +
 7 files changed, 1758 insertions(+), 1 deletion(-)

-- 
1.9.3

[dpdk-dev] [PATCH] build: set CFLAGS for ppc64el build

[Fernando Seiti Furusato]

Hi Thomas.

On 02/12/2016 05:18 PM, Fernando Seiti Furusato wrote:
> Hello Thomas.
> Thanks for your quick response.
>
> On 02/12/2016 03:37 PM, Thomas Monjalon wrote:
>> 2016-02-12 12:05, Fernando Seiti Furusato:
>>> Add a proper ifeq statement to set the mcpu as needed for ppc64el, as
>>> the only one originally set is not valid for ppc architectures.
>>
>> What is the benefit of using the default machine config, compared to
>> the power8 one?
>>
>> Don't you think the default machine should be renamed core2?
>
> I think it would be better indeed. Thanks for pointing that out.
>
>>
>> [...]
>>> +ifeq (ppc64le,$(shell uname -m))
>>> +MACHINE_CFLAGS += -mcpu=power8
>>
>> Why this flag is not set in mk/machine/power8/rte.vars.mk ?
>>
>
> This and what observed above would make a better patch.
> Let me try those.

I will be just changing the flag within mk/machine/power8/rte.vars.mk so
it will be used on ppc64le.
I thought since I am not sure how it will affect others, I will not mess
with the default file.

I had to copy config/defconfig_ppc_64-power8-linuxapp-gcc to
config/defconfig_ppc64le-native-linuxapp-gcc, because the build searches
for it on ppc64le. Should I include that in the patch?
Do you think there is a better approach?

Thanks and regards.
-- 

Fernando Seiti Furusato
IBM Linux Technology Center

[dpdk-dev] [PATCH] qat pmd:Fixing build issue on 32-bit systems

[De Lara Guarch, Pablo]

Hi John,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John Griffin
> Sent: Tuesday, February 16, 2016 9:45 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] qat pmd:Fixing build issue on 32-bit systems
> 
> Fixing build issue on 32-bit systems.
> Fixes: 1703e94ac5ce ("qat: add driver for QuickAssist devices")
> 
> Signed-off-by: John Griffin 
Acked-by: Pablo de Lara 

Could you include the error that you are fixing on this patch?

For example:

drivers/crypto/qat/qat_crypto.c:345:13: 
error: cast to pointer from integer of different size 
[-Werror=int-to-pointer-cast]

Also, as a general rule, patch titles start with lowercase and do not include 
the name "issue" if we use "fix".
e.g. (qat: fix build on 32-bit systems).

Apart from this, patch looks OK to me, so you can leave the acknowledgment in 
the v2.

Thanks!
Pablo

[dpdk-dev] [PATCH] mempool: fix leak when mempool creation fails

[Olivier Matz]

Since commits ff909fe21f and 4e32101f9b, it is now possible to free
memzones and rings.

The rte_mempool_create() should be modified to take advantage of this
and not leak memory when an allocation fails.

Signed-off-by: Olivier Matz 
---
 lib/librte_mempool/rte_mempool.c | 28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index aff5f6d..f8781e1 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -438,8 +438,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
unsigned elt_size,
char rg_name[RTE_RING_NAMESIZE];
struct rte_mempool_list *mempool_list;
struct rte_mempool *mp = NULL;
-   struct rte_tailq_entry *te;
-   struct rte_ring *r;
+   struct rte_tailq_entry *te = NULL;
+   struct rte_ring *r = NULL;
const struct rte_memzone *mz;
size_t mempool_size;
int mz_flags = RTE_MEMZONE_1GB|RTE_MEMZONE_SIZE_HINT_ONLY;
@@ -511,7 +511,7 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
unsigned elt_size,
snprintf(rg_name, sizeof(rg_name), RTE_MEMPOOL_MZ_FORMAT, name);
r = rte_ring_create(rg_name, rte_align32pow2(n+1), socket_id, rg_flags);
if (r == NULL)
-   goto exit;
+   goto exit_unlock;

/*
 * reserve a memory zone for this mempool: private data is
@@ -536,7 +536,7 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
unsigned elt_size,
te = rte_zmalloc("MEMPOOL_TAILQ_ENTRY", sizeof(*te), 0);
if (te == NULL) {
RTE_LOG(ERR, MEMPOOL, "Cannot allocate tailq entry!\n");
-   goto exit;
+   goto exit_unlock;
}

/*
@@ -561,15 +561,8 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
unsigned elt_size,
snprintf(mz_name, sizeof(mz_name), RTE_MEMPOOL_MZ_FORMAT, name);

mz = rte_memzone_reserve(mz_name, mempool_size, socket_id, mz_flags);
-
-   /*
-* no more memory: in this case we loose previously reserved
-* space for the ring as we cannot free it
-*/
-   if (mz == NULL) {
-   rte_free(te);
-   goto exit;
-   }
+   if (mz == NULL)
+   goto exit_unlock;

if (rte_eal_has_hugepages()) {
startaddr = (void*)mz->addr;
@@ -633,11 +626,16 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
unsigned elt_size,
rte_rwlock_write_lock(RTE_EAL_TAILQ_RWLOCK);
TAILQ_INSERT_TAIL(mempool_list, te, next);
rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);
-
-exit:
rte_rwlock_write_unlock(RTE_EAL_MEMPOOL_RWLOCK);

return mp;
+
+exit_unlock:
+   rte_rwlock_write_unlock(RTE_EAL_MEMPOOL_RWLOCK);
+   rte_ring_free(r);
+   rte_free(te);
+
+   return NULL;
 }

 /* Return the number of entries in the mempool */
-- 
2.1.4

[dpdk-dev] [PATCH] scripts: fix checkpatch help

[Olivier Matz]

When started without defining DPDK_CHECKPATCH_PATH, the usage was not
displayed.

Signed-off-by: Olivier Matz 
---
 scripts/checkpatches.sh | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/scripts/checkpatches.sh b/scripts/checkpatches.sh
index afc611b..1e765e3 100755
--- a/scripts/checkpatches.sh
+++ b/scripts/checkpatches.sh
@@ -34,10 +34,6 @@
 # - DPDK_CHECKPATCH_PATH
 # - DPDK_CHECKPATCH_LINE_LENGTH
 . scripts/load-devel-config.sh
-if [ ! -x "$DPDK_CHECKPATCH_PATH" ] ; then
-   echo 'Cannot execute DPDK_CHECKPATCH_PATH' >&2
-   exit 1
-fi

 length=${DPDK_CHECKPATCH_LINE_LENGTH:-80}

@@ -51,7 +47,12 @@ 
SPLIT_STRING,LINE_SPACING,PARENTHESIS_ALIGNMENT,NETWORKING_BLOCK_COMMENT_STYLE,\
 NEW_TYPEDEFS,COMPARISON_TO_NULL"

 print_usage () {
-   echo "usage: $(basename $0) [-q] [-v] [patch1 [patch2] ...]]"
+   cat <<- END_OF_HELP
+   usage: $(basename $0) [-q] [-v] [patch1 [patch2] ...]]
+
+   Run Linux kernel checkpatch.pl with DPDK options.
+   The environment variable DPDK_CHECKPATCH_PATH must be set.
+   END_OF_HELP
 }

 quiet=false
@@ -66,6 +67,13 @@ while getopts hqv ARG ; do
 done
 shift $(($OPTIND - 1))

+if [ ! -x "$DPDK_CHECKPATCH_PATH" ] ; then
+   print_usage
+   echo
+   echo 'Cannot execute DPDK_CHECKPATCH_PATH' >&2
+   exit 1
+fi
+
 status=0
 for p in "$@" ; do
! $verbose || printf '\n### %s\n\n' "$p"
-- 
2.1.4

[dpdk-dev] [PATCH] fm10k: optimize legacy TX func

[Chen, Jing D]

Hi,  Bruce,

> -Original Message-
> From: Richardson, Bruce
> Sent: Tuesday, February 16, 2016 11:28 PM
> To: Chen, Jing D
> Cc: Qiu, Michael; Ananyev, Konstantin; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] fm10k: optimize legacy TX func
> 
> On Thu, Jan 28, 2016 at 05:45:59PM +0800, Chen Jing D(Mark) wrote:
> > From: "Chen Jing D(Mark)" 
> >
> > When legacy TX func tries to free a bunch of mbufs, it will free them
> > one by one. This change will scan the free list and merge the requests
> > in case they belongs to same pool, then free once, which will reduce
> > cycles on freeing mbufs.
> >
> > Signed-off-by: Chen Jing D(Mark) 
> > ---
> >  doc/guides/rel_notes/release_2_3.rst |2 +
> >  drivers/net/fm10k/fm10k_rxtx.c   |   59
> -
> >  2 files changed, 52 insertions(+), 9 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/release_2_3.rst
> > b/doc/guides/rel_notes/release_2_3.rst
> > index 99de186..20ce78d 100644
> > --- a/doc/guides/rel_notes/release_2_3.rst
> > +++ b/doc/guides/rel_notes/release_2_3.rst
> > @@ -3,7 +3,9 @@ DPDK Release 2.3
> >
> >  New Features
> >  
> > +* **Optimize fm10k Tx func.**
> >
> > +  * Free multiple mbufs at a time to reduce freeing mbuf cycles.
> >
> 
> Is this really a significant enough change to warrant being called out in the
> release notes?
> Personally, I don't think so, so if you are ok with it, I'll just apply this 
> patch
> without the RN update.
> 
> /Bruce

This change will have some performance gain with legacy TX func.
That's why I'd like to add a line in release notes.
If you thinks it's not necessary, please kindly remove it.

[dpdk-dev] [PATCH] pcap: fix captured frame length

[Bruce Richardson]

On Thu, Jan 28, 2016 at 06:14:45PM +, Nicolas Pernas Maradei wrote:
> Hi Dror,
> 
> Good catch. What you are saying makes sense and it is also explained in
> pcap's documentation. Was your setup unusual though?
> This might sound like a silly question but I don't remember seeing that
> issue and I should have since your fix is correct.
> 
> Nico.
> 

Hi Nico,

I assume from your reply that you are ok with this patch. Can you please 
confirm 
this by acking it using the proper form "Acked-by: " line.

Thanks,
/Bruce

[dpdk-dev] [PATCH] fm10k: optimize legacy TX func

[Bruce Richardson]

On Thu, Jan 28, 2016 at 05:45:59PM +0800, Chen Jing D(Mark) wrote:
> From: "Chen Jing D(Mark)" 
> 
> When legacy TX func tries to free a bunch of mbufs, it will free
> them one by one. This change will scan the free list and merge the
> requests in case they belongs to same pool, then free once, which
> will reduce cycles on freeing mbufs.
> 
> Signed-off-by: Chen Jing D(Mark) 
> ---
>  doc/guides/rel_notes/release_2_3.rst |2 +
>  drivers/net/fm10k/fm10k_rxtx.c   |   59 -
>  2 files changed, 52 insertions(+), 9 deletions(-)
> 
> diff --git a/doc/guides/rel_notes/release_2_3.rst 
> b/doc/guides/rel_notes/release_2_3.rst
> index 99de186..20ce78d 100644
> --- a/doc/guides/rel_notes/release_2_3.rst
> +++ b/doc/guides/rel_notes/release_2_3.rst
> @@ -3,7 +3,9 @@ DPDK Release 2.3
>  
>  New Features
>  
> +* **Optimize fm10k Tx func.**
>  
> +  * Free multiple mbufs at a time to reduce freeing mbuf cycles.
>  

Is this really a significant enough change to warrant being called out in the
release notes? 
Personally, I don't think so, so if you are ok with it, I'll just apply this
patch without the RN update.

/Bruce

[dpdk-dev] [PATCH v2 1/1] examples/l3fwd: modify and modularize l3fwd code

[Piotr Azarewicz]

Many thanks to Intel team (Konstantin, Bruce and Declan) for below
proposal to
make changes to l3fwd code, their valuable inputs during interal review
and help
in performance tests.

The main problem with l3fwd is that it is too monolithic with everything
being
in one file, and the various options all controlled by compile time
flags. This
means that it's hard to read and understand, and when making any
changes, you need
to go to a lot of work to try and ensure you cover all the code paths,
since a
compile of the app will not touch large parts of the l3fwd codebase.

Following changes were done to fix the issues mentioned above

> Split out the various lpm and hash specific functionality into
separate
  files, so that l3fwd code has one file for common code e.g. args
  processing, mempool creation, and then individual files for the
various
  forwarding approaches.

  Following are new file lists

  main.c (Common code for args processing, memppol creation, etc)
  l3fwd_em.c (Hash/Exact match aka 'EM' functionality)
  l3fwd_em_sse.h (SSE4_1 buffer optimizated 'EM' code)
  l3fwd_lpm.c (Longest Prefix Match aka 'LPM' functionality)
  l3fwd_lpm_sse.h (SSE4_1 buffer optimizated 'LPM' code)
  l3fwd.h (Common include for 'EM' and 'LPM')

> The choosing of the lpm/hash path should be done at runtime, not
  compile time, via a command-line argument. This will ensure that
  both code paths get compiled in a single go

  Following examples show runtime options provided

  Select 'LPM' or 'EM' based on run time selection f.e.
> l3fwd -c 0x1 -n 1 -- -p 0x1 -E ... (EM)
> l3fwd -c 0x1 -n 1 -- -p 0x1 -L ... (LPM)

  Options "E" and "L" are mutualy-exclusive.

  If none selected, "L" is default.

Signed-off-by: Ravi Kerur 
Signed-off-by: Piotr Azarewicz 

Tested-by: Tomasz Kulasek 
Acked-by: Tomasz Kulasek 
Acked-by: Konstantin Ananyev 
---

v2 changes:
 Rebase to latest code

v1 changes:
 Rebase to latest code base for DPDK team review.
 Intel team's (Konstantin, Bruce and Declan) review comments

 v4<-v3:
 > Fix code review comments from Konstantin
 > Move buffer optimization code into l3fwd_lpm_sse.h
   and l3fwd_em_sse.h for LPM and EM respectively
 > Add compile time __SSE4_1__ for header file inclusion
 > Tested with CONFIG_RTE_MACHINE=default for non
   __SSE4_1__ compilation and build
 > Compiled for GCC 4.8.4 and 5.1 on Ubuntu 14.04

 v3<-v2:
 > Fix code review comments from Bruce
 > Fix multiple static definitions
 > Move local #defines to C files, common #defines
 to H file.
 > Rename ipv4_l3fwd_route to ipv4_l3fwd_lpm and ipv4_l3fwd_em
 > Rename ipv6_l3fwd_route to ipv6_l3fwd_lpm and ipv6_l3fwd_lpm
 > Pass additional parameter to send_single_packet
 > Compiled for GCC 4.8.4 and 5.1 on Ubuntu 14.04

 v2<-v1:
 > Fix errors in GCC 5.1
 > Restore "static inline" functions, rearrange
 functions to take "static inline" into account
 > Duplicate main_loop for LPM and EM

 v1:
 > Split main.c into following 3 files
 > main.c, (parsing, buffer alloc, and other utilities)
 > l3fwd_lpm.c, (Longest Prefix Match functions)
 > l3fwd_em.c, (Exact Match f.e. Hash functions)
 > l3fwd.h, (Common defines and prototypes)

 > Select LPM or EM based on run time selection f.e.
 > l3fwd -c 0x1 -n 1 -- -p 0x1 -E ... (Exact Match)
 > l3fwd -c 0x1 -n 1 -- -p 0x1 -L ... (LPM)

 > Options "E" and "L" are mutualy-exclusive.

 > Use function pointers during initialiation of relevant
 data structures.

 > Remove unwanted #ifdefs in the code with exception to
 > DO_RFC_1812_CHECKS
 > RTE_MACHINE_CPUFLAG_SSE4_2

 > Compiled for
 > i686-native-linuxapp-gcc
 > x86_64-native-linuxapp-gcc
 > x86_x32-native-linuxapp-gcc
 > x86_64-native-bsdapp-gcc

 > Tested on
 > Ubuntu 14.04 (GCC 4.8.4)
 > FreeBSD 10.0 (GCC 4.8)
 > I217 and I218 respectively.

 examples/l3fwd/Makefile|9 +-
 examples/l3fwd/l3fwd.h |  211 
 examples/l3fwd/l3fwd_em.c  |  776 ++
 examples/l3fwd/l3fwd_em_sse.h  |  479 +
 examples/l3fwd/l3fwd_lpm.c |  417 
 examples/l3fwd/l3fwd_lpm_sse.h |  610 +++
 examples/l3fwd/main.c  | 2207 
 7 files changed, 2703 insertions(+), 2006 deletions(-)
 create mode 100644 examples/l3fwd/l3fwd.h
 create mode 100644 examples/l3fwd/l3fwd_em.c
 create mode 100644 examples/l3fwd/l3fwd_em_sse.h
 create 

[dpdk-dev] [PATCH v2] aesni_mb: strict-aliasing rule compilation fix

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Declan Doherty
> Sent: Monday, February 15, 2016 5:06 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] aesni_mb: strict-aliasing rule compilation fix
> 
> Fixes: 924e84f87306 ("aesni_mb: add driver for multi buffer based crypto")
> 
> When compiling the AESNI_MB PMD with GCC 4.4.7 on Centos 6.7 a
> "dereferencing
> pointer ?obj_p? does break strict-aliasing rules" warning occurs in the
> get_session() function.
> 
> Signed-off-by: Declan Doherty 

Acked-by: Pablo de Lara 

[dpdk-dev] [PATCH 6/6] mempool: add in the RTE_NEXT_ABI protection for ABI breakages

[David Hunt]

v2: Kept all the NEXT_ABI defs to this patch so as to make the
previous patches easier to read, and also to imake it clear what
code is necessary to keep ABI compatibility when NEXT_ABI is
disabled.

Signed-off-by: David Hunt 
---
 app/test/Makefile|   2 +
 app/test/test_mempool_perf.c |   3 +
 lib/librte_mbuf/rte_mbuf.c   |   7 ++
 lib/librte_mempool/Makefile  |   2 +
 lib/librte_mempool/rte_mempool.c | 240 ++-
 lib/librte_mempool/rte_mempool.h |  68 ++-
 6 files changed, 320 insertions(+), 2 deletions(-)

diff --git a/app/test/Makefile b/app/test/Makefile
index 9a2f75f..8fcf0c2 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -74,7 +74,9 @@ SRCS-$(CONFIG_RTE_LIBRTE_TIMER) += test_timer_perf.c
 SRCS-$(CONFIG_RTE_LIBRTE_TIMER) += test_timer_racecond.c

 SRCS-y += test_mempool.c
+ifeq ($(CONFIG_RTE_NEXT_ABI),y)
 SRCS-y += test_ext_mempool.c
+endif
 SRCS-y += test_mempool_perf.c

 SRCS-y += test_mbuf.c
diff --git a/app/test/test_mempool_perf.c b/app/test/test_mempool_perf.c
index 091c1df..ca69e49 100644
--- a/app/test/test_mempool_perf.c
+++ b/app/test/test_mempool_perf.c
@@ -161,6 +161,9 @@ per_lcore_mempool_test(__attribute__((unused)) void *arg)
   n_get_bulk);
if (unlikely(ret < 0)) {
rte_mempool_dump(stdout, mp);
+#ifndef RTE_NEXT_ABI
+   rte_ring_dump(stdout, mp->ring);
+#endif
/* in this case, objects are lost... */
return -1;
}
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 42b0cd1..967d987 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -167,6 +167,7 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,
mbp_priv.mbuf_data_room_size = data_room_size;
mbp_priv.mbuf_priv_size = priv_size;

+#ifdef RTE_NEXT_ABI
 #ifdef RTE_MEMPOOL_HANDLER_EXT
return rte_mempool_create_ext(name, n, elt_size,
cache_size, sizeof(struct rte_pktmbuf_pool_private),
@@ -179,6 +180,12 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,
rte_pktmbuf_pool_init, _priv, rte_pktmbuf_init, NULL,
socket_id, 0);
 #endif
+#else
+   return rte_mempool_create(name, n, elt_size,
+   cache_size, sizeof(struct rte_pktmbuf_pool_private),
+   rte_pktmbuf_pool_init, _priv, rte_pktmbuf_init, NULL,
+   socket_id, 0);
+#endif
 }

 /* do some sanity checks on a mbuf: panic if it fails */
diff --git a/lib/librte_mempool/Makefile b/lib/librte_mempool/Makefile
index 4f72546..8038785 100644
--- a/lib/librte_mempool/Makefile
+++ b/lib/librte_mempool/Makefile
@@ -42,9 +42,11 @@ LIBABIVER := 1

 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool.c
+ifeq ($(CONFIG_RTE_NEXT_ABI),y)
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool_default.c
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool_stack.c
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  custom_mempool.c
+endif
 ifeq ($(CONFIG_RTE_LIBRTE_XEN_DOM0),y)
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_dom0_mempool.c
 endif
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 44bc92f..53e44ff 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -59,7 +59,9 @@
 #include 

 #include "rte_mempool.h"
+#ifdef RTE_NEXT_ABI
 #include "rte_mempool_internal.h"
+#endif

 TAILQ_HEAD(rte_mempool_list, rte_tailq_entry);

@@ -400,6 +402,7 @@ rte_mempool_create(const char *name, unsigned n, unsigned 
elt_size,
   MEMPOOL_PG_SHIFT_MAX);
 }

+#ifdef RTE_NEXT_ABI
 /*
  * Common mempool create function.
  * Create the mempool over already allocated chunk of memory.
@@ -698,6 +701,229 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
unsigned elt_size,

return mp;
 }
+#else
+/*
+ * Create the mempool over already allocated chunk of memory.
+ * That external memory buffer can consists of physically disjoint pages.
+ * Setting vaddr to NULL, makes mempool to fallback to original behaviour
+ * and allocate space for mempool and it's elements as one big chunk of
+ * physically continuos memory.
+ * */
+struct rte_mempool *
+rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
+   unsigned cache_size, unsigned private_data_size,
+   rte_mempool_ctor_t *mp_init, void *mp_init_arg,
+   rte_mempool_obj_ctor_t *obj_init, void *obj_init_arg,
+   int socket_id, unsigned flags, void *vaddr,
+   const phys_addr_t paddr[], uint32_t pg_num, uint32_t pg_shift)
+{
+   char mz_name[RTE_MEMZONE_NAMESIZE];
+   char rg_name[RTE_RING_NAMESIZE];
+   struct rte_mempool_list 

[dpdk-dev] [PATCH 5/6] mempool: allow rte_pktmbuf_pool_create switch between memool handlers

[David Hunt]

v2 changes: added to linux and bsd config files:
If the user wants to have rte_pktmbuf_pool_create() use an external mempool
handler, they define RTE_MEMPOOL_HANDLER_NAME to be the name of the
mempool handler they wish to use, and change RTE_MEMPOOL_HANDLER_EXT to 'y'
Applies to both linux and bsd config files

Signed-off-by: David Hunt 
---
 config/common_bsdapp   | 2 ++
 config/common_linuxapp | 2 ++
 lib/librte_mbuf/rte_mbuf.c | 8 
 3 files changed, 12 insertions(+)

diff --git a/config/common_bsdapp b/config/common_bsdapp
index 696382c..e0c812a 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -347,6 +347,8 @@ CONFIG_RTE_RING_PAUSE_REP_COUNT=0
 CONFIG_RTE_LIBRTE_MEMPOOL=y
 CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
 CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
+CONFIG_RTE_MEMPOOL_HANDLER_EXT=n
+CONFIG_RTE_MEMPOOL_HANDLER_NAME="custom_handler"

 #
 # Compile librte_mbuf
diff --git a/config/common_linuxapp b/config/common_linuxapp
index f1638db..9aa62ca 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -363,6 +363,8 @@ CONFIG_RTE_RING_PAUSE_REP_COUNT=0
 CONFIG_RTE_LIBRTE_MEMPOOL=y
 CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
 CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
+CONFIG_RTE_MEMPOOL_HANDLER_EXT=n
+CONFIG_RTE_MEMPOOL_HANDLER_NAME="custom_handler"

 #
 # Compile librte_mbuf
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index c18b438..42b0cd1 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -167,10 +167,18 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,
mbp_priv.mbuf_data_room_size = data_room_size;
mbp_priv.mbuf_priv_size = priv_size;

+#ifdef RTE_MEMPOOL_HANDLER_EXT
+   return rte_mempool_create_ext(name, n, elt_size,
+   cache_size, sizeof(struct rte_pktmbuf_pool_private),
+   rte_pktmbuf_pool_init, _priv, rte_pktmbuf_init, NULL,
+   socket_id, 0,
+   RTE_MEMPOOL_HANDLER_NAME);
+#else
return rte_mempool_create(name, n, elt_size,
cache_size, sizeof(struct rte_pktmbuf_pool_private),
rte_pktmbuf_pool_init, _priv, rte_pktmbuf_init, NULL,
socket_id, 0);
+#endif
 }

 /* do some sanity checks on a mbuf: panic if it fails */
-- 
2.5.0

[dpdk-dev] [PATCH 4/6] mempool: add autotest for external mempool custom example

[David Hunt]

Signed-off-by: David Hunt 
---
 app/test/Makefile   |   1 +
 app/test/test_ext_mempool.c | 451 
 2 files changed, 452 insertions(+)
 create mode 100644 app/test/test_ext_mempool.c

diff --git a/app/test/Makefile b/app/test/Makefile
index ec33e1a..9a2f75f 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -74,6 +74,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_TIMER) += test_timer_perf.c
 SRCS-$(CONFIG_RTE_LIBRTE_TIMER) += test_timer_racecond.c

 SRCS-y += test_mempool.c
+SRCS-y += test_ext_mempool.c
 SRCS-y += test_mempool_perf.c

 SRCS-y += test_mbuf.c
diff --git a/app/test/test_ext_mempool.c b/app/test/test_ext_mempool.c
new file mode 100644
index 000..6beada0
--- /dev/null
+++ b/app/test/test_ext_mempool.c
@@ -0,0 +1,451 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "test.h"
+
+/*
+ * Mempool
+ * ===
+ *
+ * Basic tests: done on one core with and without cache:
+ *
+ *- Get one object, put one object
+ *- Get two objects, put two objects
+ *- Get all objects, test that their content is not modified and
+ *  put them back in the pool.
+ */
+
+#define TIME_S 5
+#define MEMPOOL_ELT_SIZE 2048
+#define MAX_KEEP 128
+#define MEMPOOL_SIZE 8192
+
+static struct rte_mempool *mp;
+static struct rte_mempool *ext_nocache, *ext_cache;
+
+static rte_atomic32_t synchro;
+
+/*
+ * For our tests, we use the following struct to pass info to our create
+ *  callback so it can call rte_mempool_create
+ */
+struct custom_mempool_alloc_params {
+   char ring_name[RTE_RING_NAMESIZE];
+   unsigned n_elt;
+   unsigned elt_size;
+};
+
+/*
+ * Simple example of custom mempool structure. Holds pointers to all the
+ * elements which are simply malloc'd in this example.
+ */
+struct custom_mempool {
+   struct rte_ring *r;/* Ring to manage elements */
+   void *elements[MEMPOOL_SIZE];  /* Element pointers */
+};
+
+/*
+ * save the object number in the first 4 bytes of object data. All
+ * other bytes are set to 0.
+ */
+static void
+my_obj_init(struct rte_mempool *mp, __attribute__((unused)) void *arg,
+   void *obj, unsigned i)
+{
+   uint32_t *objnum = obj;
+
+   memset(obj, 0, mp->elt_size);
+   *objnum = i;
+   printf("Setting objnum to %d\n", i);
+}
+
+/* basic tests (done on one core) */
+static int
+test_mempool_basic(void)
+{
+   uint32_t *objnum;
+   void **objtable;
+   void *obj, *obj2;
+   char *obj_data;
+   int ret = 0;
+   unsigned i, j;
+
+   /* dump the mempool status */
+   rte_mempool_dump(stdout, mp);
+
+   printf("Count = %d\n", rte_mempool_count(mp));
+   printf("get an object\n");
+   if (rte_mempool_get(mp, ) < 0) {
+   printf("get Failed\n");
+   return -1;
+   }
+   printf("Count = %d\n", rte_mempool_count(mp));
+   rte_mempool_dump(stdout, mp);
+
+   /* tests that improve coverage */
+   printf("get object count\n");
+   if (rte_mempool_count(mp) != MEMPOOL_SIZE - 1)

[dpdk-dev] [PATCH 3/6] mempool: adds a simple ring-based mempool handler using mallocs for objects

[David Hunt]

Signed-off-by: David Hunt 
---
 lib/librte_mempool/Makefile |   1 +
 lib/librte_mempool/custom_mempool.c | 146 
 2 files changed, 147 insertions(+)
 create mode 100644 lib/librte_mempool/custom_mempool.c

diff --git a/lib/librte_mempool/Makefile b/lib/librte_mempool/Makefile
index d795b48..4f72546 100644
--- a/lib/librte_mempool/Makefile
+++ b/lib/librte_mempool/Makefile
@@ -44,6 +44,7 @@ LIBABIVER := 1
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool.c
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool_default.c
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool_stack.c
+SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  custom_mempool.c
 ifeq ($(CONFIG_RTE_LIBRTE_XEN_DOM0),y)
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_dom0_mempool.c
 endif
diff --git a/lib/librte_mempool/custom_mempool.c 
b/lib/librte_mempool/custom_mempool.c
new file mode 100644
index 000..5c85203
--- /dev/null
+++ b/lib/librte_mempool/custom_mempool.c
@@ -0,0 +1,146 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "rte_mempool_internal.h"
+
+/*
+ * Mempool
+ * ===
+ *
+ * Basic tests: done on one core with and without cache:
+ *
+ *- Get one object, put one object
+ *- Get two objects, put two objects
+ *- Get all objects, test that their content is not modified and
+ *  put them back in the pool.
+ */
+
+#define TIME_S 5
+#define MEMPOOL_ELT_SIZE 2048
+#define MAX_KEEP 128
+#define MEMPOOL_SIZE 8192
+
+/*
+ * Simple example of custom mempool structure. Holds pointers to all the
+ * elements which are simply malloc'd in this example.
+ */
+struct custom_mempool {
+   struct rte_ring *r; /* Ring to manage elements */
+   void *elements[MEMPOOL_SIZE];   /* Element pointers */
+};
+
+/*
+ * Loop though all the element pointers and allocate a chunk of memory, then
+ * insert that memory into the ring.
+ */
+static void *
+custom_mempool_alloc(struct rte_mempool *mp,
+   const char *name, unsigned n,
+   __attribute__((unused)) int socket_id,
+   __attribute__((unused)) unsigned flags)
+
+{
+   static struct custom_mempool *cm;
+   uint32_t *objnum;
+   unsigned int i;
+
+   cm = malloc(sizeof(struct custom_mempool));
+
+   /* Create the ring so we can enqueue/dequeue */
+   cm->r = rte_ring_create(name,
+   rte_align32pow2(n+1), 0, 0);
+   if (cm->r == NULL)
+   return NULL;
+
+   /*
+* Loop around the elements an allocate the required memory
+* and place them in the ring.
+* Not worried about alignment or performance for this example.
+* Also, set the first 32-bits to be the element number so we
+* can check later on.
+*/
+   for (i = 0; i < n; i++) {
+   cm->elements[i] = malloc(mp->elt_size);
+   memset(cm->elements[i], 0, mp->elt_size);
+   objnum = (uint32_t *)cm->elements[i];
+   *objnum = i;
+   rte_ring_sp_enqueue_bulk(cm->r, &(cm->elements[i]), 1);
+   }
+
+   return cm;
+}
+
+static int
+custom_mempool_put(void *p, void * const *obj_table, unsigned n)
+{

[dpdk-dev] [PATCH 2/6] mempool: add stack (lifo) based external mempool handler

[David Hunt]

adds a simple stack based mempool handler

Signed-off-by: David Hunt 
---
 lib/librte_mempool/Makefile|   2 +-
 lib/librte_mempool/rte_mempool.c   |   4 +-
 lib/librte_mempool/rte_mempool.h   |   1 +
 lib/librte_mempool/rte_mempool_stack.c | 164 +
 4 files changed, 169 insertions(+), 2 deletions(-)
 create mode 100644 lib/librte_mempool/rte_mempool_stack.c

diff --git a/lib/librte_mempool/Makefile b/lib/librte_mempool/Makefile
index aeaffd1..d795b48 100644
--- a/lib/librte_mempool/Makefile
+++ b/lib/librte_mempool/Makefile
@@ -43,7 +43,7 @@ LIBABIVER := 1
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool.c
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool_default.c
-
+SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool_stack.c
 ifeq ($(CONFIG_RTE_LIBRTE_XEN_DOM0),y)
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_dom0_mempool.c
 endif
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index a577a3e..44bc92f 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -672,7 +672,9 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
unsigned elt_size,
 * examine the
 * flags to set the correct index into the handler table.
 */
-   if (flags & (MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET))
+   if (flags & MEMPOOL_F_USE_STACK)
+   sprintf(handler_name, "%s", "stack");
+   else if (flags & (MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET))
sprintf(handler_name, "%s", "ring_sp_sc");
else if (flags & MEMPOOL_F_SP_PUT)
sprintf(handler_name, "%s", "ring_sp_mc");
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 3705fbd..8d8201f 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -303,6 +303,7 @@ struct rte_mempool {
 #define MEMPOOL_F_NO_CACHE_ALIGN 0x0002 /**< Do not align objs on cache 
lines.*/
 #define MEMPOOL_F_SP_PUT 0x0004 /**< Default put is 
"single-producer".*/
 #define MEMPOOL_F_SC_GET 0x0008 /**< Default get is 
"single-consumer".*/
+#define MEMPOOL_F_USE_STACK  0x0010 /**< Use a stack for the common pool. 
*/
 #define MEMPOOL_F_INT_HANDLER0x0020 /**< Using internal mempool handler */


diff --git a/lib/librte_mempool/rte_mempool_stack.c 
b/lib/librte_mempool/rte_mempool_stack.c
new file mode 100644
index 000..d341793
--- /dev/null
+++ b/lib/librte_mempool/rte_mempool_stack.c
@@ -0,0 +1,164 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "rte_mempool_internal.h"
+
+struct rte_mempool_common_stack {
+   /* Spinlock to protect access */
+   rte_spinlock_t sl;
+
+   uint32_t size;
+   uint32_t len;
+   void *objs[];
+};
+
+static void *
+common_stack_alloc(struct rte_mempool *mp,
+   const char *name, unsigned n, int socket_id, unsigned flags)
+{
+   struct rte_mempool_common_stack *s;
+   char stack_name[RTE_RING_NAMESIZE];
+
+   int size = sizeof(*s) + (n+16)*sizeof(void *);
+
+   flags = flags;
+
+   /* Allocate our local memory structure */
+   snprintf(stack_name, sizeof(stack_name), "%s-common-stack", name);
+   s = 

[dpdk-dev] [PATCH 1/6] mempool: add external mempool manager support

[David Hunt]

Adds the new rte_mempool_create_ext api and callback mechanism for
external mempool handlers

Modifies the existing rte_mempool_create to set up the handler_idx to
the relevant mempool handler based on the handler name:
ring_sp_sc
ring_mp_mc
ring_sp_mc
ring_mp_sc

v2: merges the duplicated code in rte_mempool_xmem_create and
rte_mempool_create_ext into one common function. The old functions
now call the new common function with the relevant parameters.

Signed-off-by: David Hunt 
---
 app/test/test_mempool_perf.c   |   1 -
 lib/librte_mempool/Makefile|   2 +
 lib/librte_mempool/rte_mempool.c   | 383 ++---
 lib/librte_mempool/rte_mempool.h   | 200 ---
 lib/librte_mempool/rte_mempool_default.c   | 236 ++
 lib/librte_mempool/rte_mempool_internal.h  |  75 ++
 lib/librte_mempool/rte_mempool_version.map |   1 +
 7 files changed, 717 insertions(+), 181 deletions(-)
 create mode 100644 lib/librte_mempool/rte_mempool_default.c
 create mode 100644 lib/librte_mempool/rte_mempool_internal.h

diff --git a/app/test/test_mempool_perf.c b/app/test/test_mempool_perf.c
index cdc02a0..091c1df 100644
--- a/app/test/test_mempool_perf.c
+++ b/app/test/test_mempool_perf.c
@@ -161,7 +161,6 @@ per_lcore_mempool_test(__attribute__((unused)) void *arg)
   n_get_bulk);
if (unlikely(ret < 0)) {
rte_mempool_dump(stdout, mp);
-   rte_ring_dump(stdout, mp->ring);
/* in this case, objects are lost... */
return -1;
}
diff --git a/lib/librte_mempool/Makefile b/lib/librte_mempool/Makefile
index a6898ef..aeaffd1 100644
--- a/lib/librte_mempool/Makefile
+++ b/lib/librte_mempool/Makefile
@@ -42,6 +42,8 @@ LIBABIVER := 1

 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool.c
+SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_mempool_default.c
+
 ifeq ($(CONFIG_RTE_LIBRTE_XEN_DOM0),y)
 SRCS-$(CONFIG_RTE_LIBRTE_MEMPOOL) +=  rte_dom0_mempool.c
 endif
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index aff5f6d..a577a3e 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -59,10 +59,11 @@
 #include 

 #include "rte_mempool.h"
+#include "rte_mempool_internal.h"

 TAILQ_HEAD(rte_mempool_list, rte_tailq_entry);

-static struct rte_tailq_elem rte_mempool_tailq = {
+struct rte_tailq_elem rte_mempool_tailq = {
.name = "RTE_MEMPOOL",
 };
 EAL_REGISTER_TAILQ(rte_mempool_tailq)
@@ -149,7 +150,7 @@ mempool_add_elem(struct rte_mempool *mp, void *obj, 
uint32_t obj_idx,
obj_init(mp, obj_init_arg, obj, obj_idx);

/* enqueue in ring */
-   rte_ring_sp_enqueue(mp->ring, obj);
+   rte_mempool_ext_put_bulk(mp, , 1);
 }

 uint32_t
@@ -375,26 +376,6 @@ rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num, 
size_t elt_sz,
return usz;
 }

-#ifndef RTE_LIBRTE_XEN_DOM0
-/* stub if DOM0 support not configured */
-struct rte_mempool *
-rte_dom0_mempool_create(const char *name __rte_unused,
-   unsigned n __rte_unused,
-   unsigned elt_size __rte_unused,
-   unsigned cache_size __rte_unused,
-   unsigned private_data_size __rte_unused,
-   rte_mempool_ctor_t *mp_init __rte_unused,
-   void *mp_init_arg __rte_unused,
-   rte_mempool_obj_ctor_t *obj_init __rte_unused,
-   void *obj_init_arg __rte_unused,
-   int socket_id __rte_unused,
-   unsigned flags __rte_unused)
-{
-   rte_errno = EINVAL;
-   return NULL;
-}
-#endif
-
 /* create the mempool */
 struct rte_mempool *
 rte_mempool_create(const char *name, unsigned n, unsigned elt_size,
@@ -420,117 +401,76 @@ rte_mempool_create(const char *name, unsigned n, 
unsigned elt_size,
 }

 /*
+ * Common mempool create function.
  * Create the mempool over already allocated chunk of memory.
  * That external memory buffer can consists of physically disjoint pages.
  * Setting vaddr to NULL, makes mempool to fallback to original behaviour
- * and allocate space for mempool and it's elements as one big chunk of
- * physically continuos memory.
- * */
-struct rte_mempool *
-rte_mempool_xmem_create(const char *name, unsigned n, unsigned elt_size,
+ * which will call rte_mempool_ext_alloc to allocate the object memory.
+ * If it is an intenal mempool handler, it will allocate space for mempool
+ * and it's elements as one big chunk of physically continuous memory.
+ * If it is an external mempool handler, it will allocate space for mempool
+ * and call the rte_mempool_ext_alloc for the object memory.
+ */

[dpdk-dev] [PATCH 0/6] external mempool manager

[David Hunt]

Hi list.

Here's the v2 version of a proposed patch for an external mempool manager

v2 changes:
 * There was a lot of duplicate code between rte_mempool_xmem_create and
   rte_mempool_create_ext. This has now been refactored and is now
   hopefully cleaner.
 * The RTE_NEXT_ABI define is now used to allow building of the library
   in a format that is compatible with binaries built against previous
   versions of DPDK.
 * Changes out of code reviews. Hopefully I've got most of them included.

The External Mempool Manager is an extension to the mempool API that allows
users to add and use an external mempool manager, which allows external memory
subsystems such as external hardware memory management systems and software
based memory allocators to be used with DPDK.

The existing API to the internal DPDK mempool manager will remain unchanged
and will be backward compatible. However, there will be an ABI breakage, as
the mempool struct is changing. These changes are all contained withing
RTE_NEXT_ABI defs, and the current or next code can be changed with
the CONFIG_RTE_NEXT_ABI config setting

There are two aspects to external mempool manager.
  1. Adding the code for your new mempool handler. This is achieved by adding a
 new mempool handler source file into the librte_mempool library, and
 using the REGISTER_MEMPOOL_HANDLER macro.
  2. Using the new API to call rte_mempool_create_ext to create a new mempool
 using the name parameter to identify which handler to use.

New API calls added
 1. A new mempool 'create' function which accepts mempool handler name.
 2. A new mempool 'rte_get_mempool_handler' function which accepts mempool
handler name, and returns the index to the relevant set of callbacks for
that mempool handler

Several external mempool managers may be used in the same application. A new
mempool can then be created by using the new 'create' function, providing the
mempool handler name to point the mempool to the relevant mempool manager
callback structure.

The old 'create' function can still be called by legacy programs, and will
internally work out the mempool handle based on the flags provided (single
producer, single consumer, etc). By default handles are created internally to
implement the built-in DPDK mempool manager and mempool types.

The external mempool manager needs to provide the following functions.
 1. alloc - allocates the mempool memory, and adds each object onto a ring
 2. put   - puts an object back into the mempool once an application has
finished with it
 3. get   - gets an object from the mempool for use by the application
 4. get_count - gets the number of available objects in the mempool
 5. free  - frees the mempool memory

Every time a get/put/get_count is called from the application/PMD, the
callback for that mempool is called. These functions are in the fastpath,
and any unoptimised handlers may limit performance.

The new APIs are as follows:

1. rte_mempool_create_ext

struct rte_mempool *
rte_mempool_create_ext(const char * name, unsigned n,
unsigned cache_size, unsigned private_data_size,
int socket_id, unsigned flags,
const char * handler_name);

2. rte_mempool_get_handler_name

char *
rte_mempool_get_handler_name(struct rte_mempool *mp);

Please see rte_mempool.h for further information on the parameters.


The important thing to note is that the mempool handler is passed by name
to rte_mempool_create_ext, and that in turn calls rte_get_mempool_handler to
get the handler index, which is stored in the rte_memool structure. This
allow multiple processes to use the same mempool, as the function pointers
are accessed via handler index.

The mempool handler structure contains callbacks to the implementation of
the handler, and is set up for registration as follows:

static struct rte_mempool_handler handler_sp_mc = {
.name = "ring_sp_mc",
.alloc = rte_mempool_common_ring_alloc,
.put = common_ring_sp_put,
.get = common_ring_mc_get,
.get_count = common_ring_get_count,
.free = common_ring_free,
};

And then the following macro will register the handler in the array of handlers

REGISTER_MEMPOOL_HANDLER(handler_mp_mc);

For and example of a simple malloc based mempool manager, see
lib/librte_mempool/custom_mempool.c

For an example of API usage, please see app/test/test_ext_mempool.c, which
implements a rudimentary mempool manager using simple mallocs for each
mempool object (custom_mempool.c).

David Hunt (6):
  mempool: add external mempool manager support
  mempool: add stack (lifo) based external mempool handler
  mempool: adds a simple ring-based mempool handler using mallocs for
objects
  mempool: add autotest for external mempool custom example
  mempool: allow rte_pktmbuf_pool_create switch between memool handlers
  mempool: add in the RTE_NEXT_ABI protection for ABI breakages

 app/test/Makefile  |   3 +
 app/test/test_ext_mempool.c

[dpdk-dev] [PATCH v2] vhost: remove vhost_net_device_ops

[Rich Lane]

The indirection is unnecessary because there is only one implementation
of the vhost common code. Removing it makes the code more readable.

Signed-off-by: Rich Lane 
---
v1->v2:
- Fix long lines.

 examples/vhost_xen/virtio-net.h   |  2 -
 lib/librte_vhost/vhost-net.h  | 41 +---
 lib/librte_vhost/vhost_cuse/vhost-net-cdev.c  | 27 
 lib/librte_vhost/vhost_cuse/virtio-net-cdev.c |  4 +-
 lib/librte_vhost/vhost_user/vhost-net-user.c  | 23 +++
 lib/librte_vhost/vhost_user/virtio-net-user.c |  6 +-
 lib/librte_vhost/virtio-net.c | 94 +--
 7 files changed, 73 insertions(+), 124 deletions(-)

diff --git a/examples/vhost_xen/virtio-net.h b/examples/vhost_xen/virtio-net.h
index c8c5a7a..ab69726 100644
--- a/examples/vhost_xen/virtio-net.h
+++ b/examples/vhost_xen/virtio-net.h
@@ -110,6 +110,4 @@ struct virtio_net_device_ops {
void (* destroy_device) (volatile struct virtio_net *); /* Remove 
device. */
 };

-struct vhost_net_device_ops const * get_virtio_net_callbacks(void);
-
 #endif
diff --git a/lib/librte_vhost/vhost-net.h b/lib/librte_vhost/vhost-net.h
index c69b60b..afa9829 100644
--- a/lib/librte_vhost/vhost-net.h
+++ b/lib/librte_vhost/vhost-net.h
@@ -43,8 +43,6 @@

 #include "rte_virtio_net.h"

-extern struct vhost_net_device_ops const *ops;
-
 /* Macros for printing using RTE_LOG */
 #define RTE_LOGTYPE_VHOST_CONFIG RTE_LOGTYPE_USER1
 #define RTE_LOGTYPE_VHOST_DATA   RTE_LOGTYPE_USER1
@@ -85,34 +83,27 @@ struct vhost_device_ctx {
uint64_tfh; /* Populated with fi->fh to track the device 
index. */
 };

-/*
- * Structure contains function pointers to be defined in virtio-net.c. These
- * functions are called in CUSE context and are used to configure devices.
- */
-struct vhost_net_device_ops {
-   int (*new_device)(struct vhost_device_ctx);
-   void (*destroy_device)(struct vhost_device_ctx);
+int vhost_new_device(struct vhost_device_ctx);
+void vhost_destroy_device(struct vhost_device_ctx);

-   void (*set_ifname)(struct vhost_device_ctx,
-   const char *if_name, unsigned int if_len);
+void vhost_set_ifname(struct vhost_device_ctx,
+   const char *if_name, unsigned int if_len);

-   int (*get_features)(struct vhost_device_ctx, uint64_t *);
-   int (*set_features)(struct vhost_device_ctx, uint64_t *);
+int vhost_get_features(struct vhost_device_ctx, uint64_t *);
+int vhost_set_features(struct vhost_device_ctx, uint64_t *);

-   int (*set_vring_num)(struct vhost_device_ctx, struct vhost_vring_state 
*);
-   int (*set_vring_addr)(struct vhost_device_ctx, struct vhost_vring_addr 
*);
-   int (*set_vring_base)(struct vhost_device_ctx, struct vhost_vring_state 
*);
-   int (*get_vring_base)(struct vhost_device_ctx, uint32_t, struct 
vhost_vring_state *);
+int vhost_set_vring_num(struct vhost_device_ctx, struct vhost_vring_state *);
+int vhost_set_vring_addr(struct vhost_device_ctx, struct vhost_vring_addr *);
+int vhost_set_vring_base(struct vhost_device_ctx, struct vhost_vring_state *);
+int vhost_get_vring_base(struct vhost_device_ctx,
+   uint32_t, struct vhost_vring_state *);

-   int (*set_vring_kick)(struct vhost_device_ctx, struct vhost_vring_file 
*);
-   int (*set_vring_call)(struct vhost_device_ctx, struct vhost_vring_file 
*);
+int vhost_set_vring_kick(struct vhost_device_ctx, struct vhost_vring_file *);
+int vhost_set_vring_call(struct vhost_device_ctx, struct vhost_vring_file *);

-   int (*set_backend)(struct vhost_device_ctx, struct vhost_vring_file *);
-
-   int (*set_owner)(struct vhost_device_ctx);
-   int (*reset_owner)(struct vhost_device_ctx);
-};
+int vhost_set_backend(struct vhost_device_ctx, struct vhost_vring_file *);

+int vhost_set_owner(struct vhost_device_ctx);
+int vhost_reset_owner(struct vhost_device_ctx);

-struct vhost_net_device_ops const *get_virtio_net_callbacks(void);
 #endif /* _VHOST_NET_CDEV_H_ */
diff --git a/lib/librte_vhost/vhost_cuse/vhost-net-cdev.c 
b/lib/librte_vhost/vhost_cuse/vhost-net-cdev.c
index ae7ad8d..c613e68 100644
--- a/lib/librte_vhost/vhost_cuse/vhost-net-cdev.c
+++ b/lib/librte_vhost/vhost_cuse/vhost-net-cdev.c
@@ -58,7 +58,6 @@ static const char cuse_device_name[] = "/dev/cuse";
 static const char default_cdev[] = "vhost-net";

 static struct fuse_session *session;
-struct vhost_net_device_ops const *ops;

 /*
  * Returns vhost_device_ctx from given fuse_req_t. The index is populated later
@@ -86,7 +85,7 @@ vhost_net_open(fuse_req_t req, struct fuse_file_info *fi)
struct vhost_device_ctx ctx = fuse_req_to_vhost_ctx(req, fi);
int err = 0;

-   err = ops->new_device(ctx);
+   err = vhost_new_device(ctx);
if (err == -1) {
fuse_reply_err(req, EPERM);
return;
@@ -108,7 +107,7 @@ vhost_net_release(fuse_req_t req, struct fuse_file_info *fi)
int err = 0;
struct vhost_device_ctx ctx = 

[dpdk-dev] [PATCH v3 3/4] eal: introduce pci ioport api

[Yuanhan Liu]

On Tue, Feb 16, 2016 at 07:09:49AM +0100, David Marchand wrote:
> On Tue, Feb 16, 2016 at 3:36 AM, Yuanhan Liu
>  wrote:
> > On Mon, Feb 15, 2016 at 02:24:25PM +0100, David Marchand wrote:
> >> +/**
> >> + * A structure used to access io resources for a pci device.
> >> + * rte_pci_ioport is arch, os, driver specific, and should not be used 
> >> outside
> >> + * of pci ioport api.
> >> + */
> >> +struct rte_pci_ioport {
> >> + struct rte_pci_device *dev;
> >> + uint64_t offset;
> >> +};
> >
> > "offset" dosen't sound like a good name to me; espeicially when I found
> > code like below:
> >
> > reg = p->offset + offset;
> >
> > Regarding that, maybe "base" is a better name? I don't like it too much,
> > though. Any better idea?
> 
> Hum, yes, base sounds better, and I have no better idea, will go with
> this unless someone else complains.
> 
> > Otherwise, this patch looks good to me.
> 
> Thanks.
> 
> I will respin this patchset and if nobody is against this, I think

Feel free to add:

Reviewed-by: Yuanhan Liu 

--yliu

> this patchset should be pulled quickly because other patches depend on
> it.
> 
> 
> -- 
> David Marchand

[dpdk-dev] [PATCH] doc/linux gsg: add gcc-multilib as package hint

[Harry van Haaren]

When compiling for i686 targets compilation could fail
if the 32bit libc6-dev package is not installed. The
gcc-multilib packages is a meta-package that will pull
in the necessary dependencies, making setup easier for
beginners.

Reported-by: Weichun Chen 
Signed-off-by: Harry van Haaren 
---
 doc/guides/linux_gsg/sys_reqs.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/doc/guides/linux_gsg/sys_reqs.rst 
b/doc/guides/linux_gsg/sys_reqs.rst
index a20a407..7f7e866 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -66,8 +66,7 @@ Compilation of the DPDK
 default and affect performance (``-fstack-protector``, for example). 
Please refer to the documentation
 of your distribution and to ``gcc -dumpspecs``.

-*   libc headers (glibc-devel.i686 / libc6-dev-i386; glibc-devel.x86_64 for 
64-bit compilation on Intel
-architecture; glibc-devel.ppc64 for 64 bit IBM Power architecture;)
+*   libc headers, often packaged as ``gcc-multilib`` (``glibc-devel.i686`` / 
``libc6-dev-i386``; ``glibc-devel.x86_64`` / ``libc6-dev`` for 64-bit 
compilation on Intel architecture; ``glibc-devel.ppc64`` for 64 bit IBM Power 
architecture;)

 *   Linux kernel headers or sources required to build kernel modules. (kernel 
- devel.x86_64;
 kernel - devel.ppc64)
-- 
2.5.0

[dpdk-dev] [PATCH v4 0/3] add lpm support for NEON

[Kobylinski, MichalX]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jerin Jacob
> Sent: Friday, February 12, 2016 1:29 PM
> To: dev at dpdk.org
> Cc: viktorin at rehivetech.com
> Subject: [dpdk-dev] [PATCH v4 0/3] add lpm support for NEON
> 
> - This patch enables lpm for ARM
> - Used architecture agnostic xmm_t to represent 128 bit SIMD variable in
> rte_lpm_lookupx4 API definition
> - Tested on Juno and Thunderx boards
> - Tested and verified the changes with following DPDK unit test cases
> --lpm_autotest
> --lpm6_autotest
> v1..v2
> - make rte_lpm_lookupx4 API definition architecture agnostic
> - vect_* abstraction scope reduce to only app/test as this abstraction used 
> only
> to load/store and set vectors in test application which is the consumer of
> rte_lpm_lookupx4 like API
> - support for armv7 apart from armv8
> - taken changes from Jianbo's lpm patches
> 
> v2..v3
> - add Acked-by for 0001-lpm-make-rte_lpm_lookupx4-API-definition-
> architectur.patch
> - re-based to DPDK 2.2
> -- fixed the conflict in config/defconfig_arm-armv7a-linuxapp-gcc and
> MAINTAINERS file
> 
> v3..v4
> -Instead of defaulting the lpm implementation to SSE, SSE implementation kept
> under RTE_ARCH_X86 conditional compilation check as suggested by Thomas
> 
> Jerin Jacob (3):
>   lpm: make rte_lpm_lookupx4 API definition architecture agnostic
>   lpm: add support for NEON
>   maintainers: claim responsibility for arm64 specific files of hash and
> lpm
> 
>  MAINTAINERS|   3 +
>  app/test/test_lpm.c|  21 ++--
>  app/test/test_xmmt_ops.h   |  67 +
>  config/defconfig_arm-armv7a-linuxapp-gcc   |   3 -
>  config/defconfig_arm64-armv8a-linuxapp-gcc |   3 -
>  lib/librte_lpm/Makefile|   6 ++
>  lib/librte_lpm/rte_lpm.h   |  99 ++-
>  lib/librte_lpm/rte_lpm_neon.h  | 148 
> +
>  lib/librte_lpm/rte_lpm_sse.h   | 143 
>  9 files changed, 386 insertions(+), 107 deletions(-)  create mode 100644
> app/test/test_xmmt_ops.h  create mode 100644 lib/librte_lpm/rte_lpm_neon.h
> create mode 100644 lib/librte_lpm/rte_lpm_sse.h
> 
> --
> 2.1.0

Hi Jerin,
Are you planning increase next_hop field for ARM? I extended next_hop field 
from 8 bits to 24 bits and created structure to configure LPM for x86.
Please look at my patchset with proposal increase next_hop field and structure 
to configure.

http://patchwork.dpdk.org/dev/patchwork/patch/10249/
http://patchwork.dpdk.org/dev/patchwork/patch/10250/

Best Regards,
Michal

[dpdk-dev] [PATCH v3 1/1] jobstats: added function abort for job

[Zhang, Roy Fan]

On 12/02/2016 16:04, Marcin Kerlin wrote:
> This patch adds new function rte_jobstats_abort. It marks *job* as finished 
> and
> time of this work will be add to management time instead of execution time. 
> This
> function should be used instead of rte_jobstats_finish if condition occurs,
> condition is defined by the application for example when receiving n>0 
> packets.
> Example of usage is added to the example l2fwd-jobstats. At maximum load 
> do-while
> loop inside Idle job will be execute once because one or more jobs waiting to 
> be
> executed, so this time should not be include as the execution time by calling
> rte_jobstats_abort().
>
> v2:
> * removed redundant field
> v3:
> * added an example of using
>
> Signed-off-by: Marcin Kerlin 
> ---
>   examples/l2fwd-jobstats/main.c   |  9 -
>   lib/librte_jobstats/rte_jobstats.c   | 20 
>   lib/librte_jobstats/rte_jobstats.h   | 14 ++
>   lib/librte_jobstats/rte_jobstats_version.map |  7 +++
>   4 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/examples/l2fwd-jobstats/main.c b/examples/l2fwd-jobstats/main.c
> index 7b59f4e..bd64e74 100644
> --- a/examples/l2fwd-jobstats/main.c
> +++ b/examples/l2fwd-jobstats/main.c
> @@ -577,10 +577,13 @@ l2fwd_main_loop(void)
>*/
>   rte_jobstats_start(>jobs_context, 
> >idle_job);
>   
> + uint64_t repeats = 0;
> +
>   do {
>   uint8_t i;
>   uint64_t now = rte_get_timer_cycles();
>   
> + repeats++;
>   need_manage = qconf->flush_timer.expire < now;
>   /* Check if we was esked to give a stats. */
>   stats_read_pending =
> @@ -591,7 +594,11 @@ l2fwd_main_loop(void)
>   need_manage = 
> qconf->rx_timers[i].expire < now;
>   
>   } while (!need_manage);
> - rte_jobstats_finish(>idle_job, 
> qconf->idle_job.target);
> +
> + if (likely(repeats != 1))
> + rte_jobstats_finish(>idle_job, 
> qconf->idle_job.target);
> + else
> + rte_jobstats_abort(>idle_job);
>   
>   rte_timer_manage();
>   rte_jobstats_context_finish(>jobs_context);
> diff --git a/lib/librte_jobstats/rte_jobstats.c 
> b/lib/librte_jobstats/rte_jobstats.c
> index 2eaac0c..2b42050 100644
> --- a/lib/librte_jobstats/rte_jobstats.c
> +++ b/lib/librte_jobstats/rte_jobstats.c
> @@ -170,6 +170,26 @@ rte_jobstats_start(struct rte_jobstats_context *ctx, 
> struct rte_jobstats *job)
>   }
>   
>   int
> +rte_jobstats_abort(struct rte_jobstats *job)
> +{
> + struct rte_jobstats_context *ctx;
> + uint64_t now, exec_time;
> +
> + /* Some sanity check. */
> + if (unlikely(job == NULL || job->context == NULL))
> + return -EINVAL;
> +
> + ctx = job->context;
> + now = get_time();
> + exec_time = now - ctx->state_time;
> + ADD_TIME_MIN_MAX(ctx, management, exec_time);
> + ctx->state_time = now;
> + job->context = NULL;
> +
> + return 0;
> +}
> +
> +int
>   rte_jobstats_finish(struct rte_jobstats *job, int64_t job_value)
>   {
>   struct rte_jobstats_context *ctx;
> diff --git a/lib/librte_jobstats/rte_jobstats.h 
> b/lib/librte_jobstats/rte_jobstats.h
> index de6a89a..c2b285f 100644
> --- a/lib/librte_jobstats/rte_jobstats.h
> +++ b/lib/librte_jobstats/rte_jobstats.h
> @@ -237,6 +237,20 @@ int
>   rte_jobstats_start(struct rte_jobstats_context *ctx, struct rte_jobstats 
> *job);
>   
>   /**
> + * Mark that *job* finished its execution, but time of this work will be 
> skipped
> + * and added to management time.
> + *
> + * @param job
> + *  Job object.
> + *
> + * @return
> + *  0 on success
> + *  -EINVAL if job is NULL or job was not started (it have no context).
> + */
> +int
> +rte_jobstats_abort(struct rte_jobstats *job);
> +
> +/**
>* Mark that *job* finished its execution. Context in which it was executing
>* will receive stat update. After this function call *job* object is ready 
> to
>* be executed in other context.
> diff --git a/lib/librte_jobstats/rte_jobstats_version.map 
> b/lib/librte_jobstats/rte_jobstats_version.map
> index cb01bfd..e3b21ca 100644
> --- a/lib/librte_jobstats/rte_jobstats_version.map
> +++ b/lib/librte_jobstats/rte_jobstats_version.map
> @@ -17,3 +17,10 @@ DPDK_2.0 {
>   
>   local: *;
>   };
> +
> +DPDK_2.3 {
> + global:
> +
> + rte_jobstats_abort;
> +
> +} DPDK_2.0;

Acked-by : Fan Zhang

[dpdk-dev] x86_64-native-linuxapp-clang compilation broken?

[Marc]

On 16 February 2016 at 12:49, Mcnamara, John 
wrote:

>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc
> > Sent: Sunday, February 14, 2016 10:21 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] x86_64-native-linuxapp-clang compilation broken?
> >
> > It seems compilation for clang Linux target is broken:
> >
> >...
> >
> > marc at dpdk:~/dpdk$ clang --version
> > Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM
> > 3.5.0)
> > Target: x86_64-pc-linux-gnu
> > Thread model: posix
> >
> > Any ideas?
>
> Hi,
>
> I built clang 3.5.0 and built DPDK successfully with it on FC23:
>
> $ /tmp/llvm-3.5.0.src/Release+Asserts/bin/clang --version
> clang version 3.5.0 (tags/RELEASE_350/final)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
>
> What OS version are you using?
>

Debian 8, amd64

Regards
Marc


>
> John
>
>

[dpdk-dev] x86_64-native-linuxapp-clang compilation broken?

[De Lara Guarch, Pablo]

Hi Marc,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc
> Sent: Tuesday, February 16, 2016 12:16 PM
> To: Mcnamara, John
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] x86_64-native-linuxapp-clang compilation broken?
> 
> On 16 February 2016 at 12:49, Mcnamara, John
> 
> wrote:
> 
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc
> > > Sent: Sunday, February 14, 2016 10:21 PM
> > > To: dev at dpdk.org
> > > Subject: [dpdk-dev] x86_64-native-linuxapp-clang compilation broken?
> > >
> > > It seems compilation for clang Linux target is broken:
> > >
> > >...
> > >
> > > marc at dpdk:~/dpdk$ clang --version
> > > Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM
> > > 3.5.0)
> > > Target: x86_64-pc-linux-gnu
> > > Thread model: posix
> > >
> > > Any ideas?
> >
> > Hi,
> >
> > I built clang 3.5.0 and built DPDK successfully with it on FC23:
> >
> > $ /tmp/llvm-3.5.0.src/Release+Asserts/bin/clang --version
> > clang version 3.5.0 (tags/RELEASE_350/final)
> > Target: x86_64-unknown-linux-gnu
> > Thread model: posix
> >
> > What OS version are you using?
> >
> 
> Debian 8, amd64

We suspect this might be an architecture dependent issue.
Could you tell us which CPU you are using?

Thanks,
Pablo

> 
> Regards
> Marc
> 
> 
> >
> > John
> >
> >

[dpdk-dev] [PATCH v8 1/4] ethdev: Added ETH_SPEED_CAP bitmap for ports

[Stephen Hemminger]

On Sun, 14 Feb 2016 23:17:36 +0100
Marc Sune  wrote:

> Added constants and bitmap to struct rte_eth_dev_info to be used by PMDs.
> 
> Signed-off-by: Marc Sune 
> ---
>  lib/librte_ether/rte_ethdev.h | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index 16da821..83ddbb7 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -824,6 +824,29 @@ struct rte_eth_conf {
>  #define DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM 0x0080 /**< Used for tunneling 
> packet. */
>  #define DEV_TX_OFFLOAD_QINQ_INSERT 0x0100
>  
> +/**
> + * Device supported speeds
> + */
> +#define ETH_SPEED_CAP_NOT_PHY(0)  /*< No phy media > */
> +#define ETH_SPEED_CAP_10M_HD (1 << 0)  /*< 10 Mbps half-duplex> */
> +#define ETH_SPEED_CAP_10M_FD (1 << 1)  /*< 10 Mbps full-duplex> */
> +#define ETH_SPEED_CAP_100M_HD(1 << 2)  /*< 100 Mbps half-duplex> */
> +#define ETH_SPEED_CAP_100M_FD(1 << 3)  /*< 100 Mbps full-duplex> */
> +#define ETH_SPEED_CAP_1G (1 << 4)  /*< 1 Gbps > */
> +#define ETH_SPEED_CAP_2_5G   (1 << 5)  /*< 2.5 Gbps > */
> +#define ETH_SPEED_CAP_5G (1 << 6)  /*< 5 Gbps > */
> +#define ETH_SPEED_CAP_10G(1 << 7)  /*< 10 Mbps > */
> +#define ETH_SPEED_CAP_20G(1 << 8)  /*< 20 Gbps > */
> +#define ETH_SPEED_CAP_25G(1 << 9)  /*< 25 Gbps > */
> +#define ETH_SPEED_CAP_40G(1 << 10)  /*< 40 Gbps > */
> +#define ETH_SPEED_CAP_50G(1 << 11)  /*< 50 Gbps > */
> +#define ETH_SPEED_CAP_56G(1 << 12)  /*< 56 Gbps > */
> +#define ETH_SPEED_CAP_100G   (1 << 13)  /*< 100 Gbps > */

Have you been following recent discussion about updates to ethtool
in Linux https://lwn.net/Articles/667794/

[dpdk-dev] [PATCH] config: add default linux configuration

[Thomas Monjalon]

2016-02-16 11:16, Ferruh Yigit:
> On Thu, Jan 28, 2016 at 02:31:45PM +, Bernard Iremonger wrote:
> > add config/defconfig_x86_64-default-linuxapp-gcc file.
> > 
> > Signed-off-by: Bernard Iremonger 
> 
> Apart from configuration related discussion,
> this patch was helpful for me to notice "default" machine type, and 
> difference between "native",
> so I believe it is good to have this as sample config.

The justification is strange. We are not going to have a config file
for every combinations.
Defaulting defconfig files to the native machine natural to me.

> Also not scope of this patch but I agree on Bruce's comment on renaming 
> "default" machine type to "generic",
> I can send a patch for this if there is a demand.

default is an Intel core 2. Why generic is a better name?

[dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure

[Ziye Yang]

From: Ziye 

The purpose of this patch is used to add a new field
"class" in rte_pci_id structure. The new class field includes
class_id, subcalss_id, programming interface of a pci device.
With this field, we can identify pci device by its class info,
which can be more flexible instead of probing the device by
vendor_id OR device_id OR subvendor_id OR subdevice_id.
For example, we can probe all nvme devices by class field, which
can be quite convenient.

As release_2_3.rst is replaced with release_16_04.rst.

Signed-off-by: Ziye Yang 
---
 doc/guides/rel_notes/release_16_04.rst | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 27fc624..fe843a5 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -95,9 +95,10 @@ This section should contain API changes. Sample format:
 ABI Changes
 ---

-* Add a short 1-2 sentence description of the ABI change that was announced in
-  the previous releases and made in this release. Use fixed width quotes for
-  ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+* New field ``class`` is added into ``rte_pci_id`` structure. This new
+  added ``class`` field can be used to probe pci devices by class related
+  info. With this new field, the size of structure ``rte_pci_device`` will
+  be increased.


 Shared Library Versions
-- 
1.9.3

[dpdk-dev] [PATCH] config: add default linux configuration

[Ferruh Yigit]

On Tue, Feb 16, 2016 at 12:23:12PM +0100, Thomas Monjalon wrote:
> 2016-02-16 11:16, Ferruh Yigit:
> > On Thu, Jan 28, 2016 at 02:31:45PM +, Bernard Iremonger wrote:
> > > add config/defconfig_x86_64-default-linuxapp-gcc file.
> > > 
> > > Signed-off-by: Bernard Iremonger 
> > 
> > Apart from configuration related discussion,
> > this patch was helpful for me to notice "default" machine type, and 
> > difference between "native",
> > so I believe it is good to have this as sample config.
> 
> The justification is strange. We are not going to have a config file
> for every combinations.
> 
Simply I found useful for me and thought others can be useful too, if you think 
not useful, that is OK,
and yes probably we shouldn't have a sample for every combination and this 
patch is not suggesting that.

> Defaulting defconfig files to the native machine natural to me.
> 
No issue on having native machine type, just another defconfig with another 
machine type.

> > Also not scope of this patch but I agree on Bruce's comment on renaming 
> > "default" machine type to "generic",
> > I can send a patch for this if there is a demand.
> 
> default is an Intel core 2. Why generic is a better name?

When you have "x86_64-default-linuxapp-icc", this feels like this is default 
configuration for given architecture among others, which will give best 
performance (what native suggests)
If I would know nothing about DPDK and see available configs first time, I 
would pick this one, because this is default one J.

"generic" stress more that this config supports generic features of different 
machine types.

But this is how I feel, as I said I would prefer "generic", but I can survive 
with existing one.

Thanks,
ferruh

[dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure

[Ziye Yang]

From: Ziye 

The purpose of this patch is used to add a new field
"class" in rte_pci_id structure. The new class field includes
class_id, subcalss_id, programming interface of a pci device.
With this field, we can identify pci device by its class info,
which can be more flexible instead of probing the device by
vendor_id OR device_id OR subvendor_id OR subdevice_id.
For example, we can probe all nvme devices by class field, which
can be quite convenient.

As release_2_3.rst is replaced with release_16_04.rst

Signed-off-by: Ziye Yang 
---
 doc/guides/rel_notes/release_16_04.rst | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 27fc624..fe843a5 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -95,9 +95,10 @@ This section should contain API changes. Sample format:
 ABI Changes
 ---

-* Add a short 1-2 sentence description of the ABI change that was announced in
-  the previous releases and made in this release. Use fixed width quotes for
-  ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+* New field ``class`` is added into ``rte_pci_id`` structure. This new
+  added ``class`` field can be used to probe pci devices by class related
+  info. With this new field, the size of structure ``rte_pci_device`` will
+  be increased.


 Shared Library Versions
-- 
1.9.3

[dpdk-dev] dpdk: vhost/virtio staging/testing tree

[Yuanhan Liu]

On Fri, Feb 12, 2016 at 01:54:21PM +0200, Victor Kaplansky wrote:
> Hi!

Hi Victor,

> Since I was maintaining an internal tree with patches related to
> vhost/virtio, I decided to make this staging tree public. It is
> useful to me and I hope it will be useful to others.
> 
> Collecting patches like this allows tracking dependencies between
> patches, their improvement etc. I also rebase the tree so
> contributors don't have to.

I had same thoughts, before, aiming to speed the patch review and
merge process.

DPDK community, likely, has a culture of very slow patch review and
merge process: I often saw patches not get reviewed for weeks, even
months! I also saw that a patch has been ACK-ed, but not get merged
until few weeks has been passed. While I am inside the team, I
understand it's a very reasonable phenomenon: every one of us has
lots of tasks to do, and we intend to do the review after all tasks
have been finished.

Despite the fact, I was thinking that I could maintain a tree, so
that I could apply all virtio/vhost patches that has been ACKed in
the first time. Later, I will send pull request to Thomas, from
time to time. Thomas, on the other hand, only need to have a double
check of the patches from my request. If he has any concerns on
some specific patch (or patch set), I will drop them, and let the
author to send a new version.

Put simply, it's a similar style Linux kernel (and QEMU) takes.

Another thing worthy noting is that Bruce started to maintain
a such tree recently:

http://dpdk.org/browse/next/dpdk-next-net/

So, as long as Bruce merges patches quickly, it should not matter.

> Before publishing, I test the tree so it can serve as a known
> good state for people interested in preliminary testing of
> patches that aren't yet upstream, improving testing/validation as
> multiple people can test the same code.

I was thinking to build a very rough and simple test bot to
achieve that; however, no time for that.

--yliu

[dpdk-dev] x86_64-native-linuxapp-clang compilation broken?

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc
> Sent: Sunday, February 14, 2016 10:21 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] x86_64-native-linuxapp-clang compilation broken?
> 
> It seems compilation for clang Linux target is broken:
> 
>...
>
> marc at dpdk:~/dpdk$ clang --version
> Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM
> 3.5.0)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> 
> Any ideas?

Hi,

I built clang 3.5.0 and built DPDK successfully with it on FC23:

$ /tmp/llvm-3.5.0.src/Release+Asserts/bin/clang --version
clang version 3.5.0 (tags/RELEASE_350/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

What OS version are you using?

John

[dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure

[Thomas Monjalon]

2016-02-16 10:11, Bruce Richardson:
> Thomas, is there some reason why the deprecation notices are not called out in
> the release notes for a new release? Why are they kept separately?

No strong reason.
It is part of the release notes but not in the versioned section.
Probably because there is no interest in keeping the history of planned
deprecations in the release notes. When the API/ABI is changed, the deprecation
notice is replaced by an entry in the versioned section.

[dpdk-dev] [PATCH v8 3/4] ethdev: redesign link speed config API

[Matej Vido]

D?a 14.02.2016 o 23:17 Marc Sune nap?sal(a):
> This patch redesigns the API to set the link speed/s configure
> for an ethernet port. Specifically:
>
> - it allows to define a set of advertised speeds for
>auto-negociation.
> - it allows to disable link auto-negociation (single fixed speed).
> - default: auto-negociate all supported speeds.
>
> Other changes:
>
> * Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
>values of all supported link speeds, in Mbps.
> * Converted link_speed to uint64_t to accomodate 100G speeds
>and beyond (bug).
> * Added autoneg flag in struct rte_eth_link to indicate if
>link speed was a result of auto-negociation or was fixed
>by configuration.
> * Added utility function to convert numeric speeds to bitmap
>fields.
> * Added rte_eth_speed_to_bm_flag() to version map.
>
> Signed-off-by: Marc Sune 
> ---
>   app/test-pipeline/init.c  |   2 +-
>   app/test-pmd/cmdline.c| 124 
> +++---
>   app/test-pmd/config.c |   4 +-
>   app/test/virtual_pmd.c|   4 +-
>   drivers/net/af_packet/rte_eth_af_packet.c |   5 +-
>   drivers/net/bnx2x/bnx2x_ethdev.c  |   8 +-
>   drivers/net/bonding/rte_eth_bond_8023ad.c |  14 ++--
>   drivers/net/cxgbe/base/t4_hw.c|   8 +-
>   drivers/net/cxgbe/cxgbe_ethdev.c  |   2 +-
>   drivers/net/e1000/em_ethdev.c | 116 ++--
>   drivers/net/e1000/igb_ethdev.c| 111 +-
>   drivers/net/fm10k/fm10k_ethdev.c  |   8 +-
>   drivers/net/i40e/i40e_ethdev.c|  73 +-
>   drivers/net/i40e/i40e_ethdev_vf.c |  11 +--
>   drivers/net/ixgbe/ixgbe_ethdev.c  |  78 ---
>   drivers/net/mlx4/mlx4.c   |   6 +-
>   drivers/net/mpipe/mpipe_tilegx.c  |   6 +-
>   drivers/net/nfp/nfp_net.c |   4 +-
>   drivers/net/null/rte_eth_null.c   |   5 +-
>   drivers/net/pcap/rte_eth_pcap.c   |   9 ++-
>   drivers/net/ring/rte_eth_ring.c   |   5 +-
>   drivers/net/virtio/virtio_ethdev.c|   2 +-
>   drivers/net/virtio/virtio_ethdev.h|   2 -
>   drivers/net/vmxnet3/vmxnet3_ethdev.c  |   5 +-
>   drivers/net/xenvirt/rte_eth_xenvirt.c |   5 +-
>   examples/ip_pipeline/config_parse.c   |   3 +-
>   lib/librte_ether/rte_ethdev.c |  49 
>   lib/librte_ether/rte_ethdev.h | 113 +--
>   lib/librte_ether/rte_ether_version.map|   6 ++
>   29 files changed, 443 insertions(+), 345 deletions(-)
>
> [...]

Hi,

some drivers (at least: e1000, i40e, ixgbe, mpipe, nfp, virtio, vmxnet3) 
use rte_atomic64_cmpset() to read and write link state like:

static inline int
rte_em_dev_atomic_read_link_status(struct rte_eth_dev *dev,
 struct rte_eth_link *link)
{
 struct rte_eth_link *dst = link;
 struct rte_eth_link *src = &(dev->data->dev_link);

 if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst,
 *(uint64_t *)src) == 0)
 return -1;

 return 0;
}

static inline int
rte_em_dev_atomic_write_link_status(struct rte_eth_dev *dev,
 struct rte_eth_link *link)
{
 struct rte_eth_link *dst = &(dev->data->dev_link);
 struct rte_eth_link *src = link;

 if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst,
 *(uint64_t *)src) == 0)
 return -1;

 return 0;
}


When link_speed is changed to uint64_t, struct rte_eth_link exceeds 64 
bits. Shouldn't these functions be adapted in this patch series?

Szedata2 PMD will also use rte_atomic64_cmpset() after patch [1].
I can take care of this change in szedata2 PMD when patch [1] is 
accepted together with adjusting speeds in szedata2 PMD.

[1] http://dpdk.org/ml/archives/dev/2016-January/032281.html

Regards,
Matej

[dpdk-dev] [PATCH] config: add default linux configuration

[Ferruh Yigit]

On Thu, Jan 28, 2016 at 02:31:45PM +, Bernard Iremonger wrote:
> add config/defconfig_x86_64-default-linuxapp-gcc file.
> 
> Signed-off-by: Bernard Iremonger 

Apart from configuration related discussion,
this patch was helpful for me to notice "default" machine type, and difference 
between "native",
so I believe it is good to have this as sample config.

Acked-by: Ferruh Yigit 


Also not scope of this patch but I agree on Bruce's comment on renaming 
"default" machine type to "generic",
I can send a patch for this if there is a demand.

Regards,
ferruh

[dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure

[Ziye Yang]

From: Ziye 

The purpose of this patch is used to add a new field
"class" in rte_pci_id structure. The new class field includes
class_id, subcalss_id, programming interface of a pci device.
With this field, we can identify pci device by its class info,
which can be more flexible instead of probing the device by
vendor_id OR device_id OR subvendor_id OR subdevice_id.
For example, we can probe all nvme devices by class field, which
can be quite convenient.

Signed-off-by: Ziye Yang 
---
 doc/guides/rel_notes/release_16_04.rst | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 27fc624..fe843a5 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -95,9 +95,10 @@ This section should contain API changes. Sample format:
 ABI Changes
 ---

-* Add a short 1-2 sentence description of the ABI change that was announced in
-  the previous releases and made in this release. Use fixed width quotes for
-  ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+* New field ``class`` is added into ``rte_pci_id`` structure. This new
+  added ``class`` field can be used to probe pci devices by class related
+  info. With this new field, the size of structure ``rte_pci_device`` will
+  be increased.


 Shared Library Versions
-- 
1.9.3

[dpdk-dev] [PATCH v7 2/4] virtio: Introduce config RTE_VIRTIO_INC_VECTOR

[Yuanhan Liu]

On Mon, Feb 15, 2016 at 04:48:36PM +0530, Santosh Shukla wrote:
> Hi Yuanhan,
> 
> On Mon, Feb 15, 2016 at 4:27 PM, Yuanhan Liu
>  wrote:
> > On Mon, Feb 15, 2016 at 03:22:11PM +0530, Santosh Shukla wrote:
> >> Hi Yuanhan,
> >>
> >> I guess you are back from vacation.
> >>
> >> Can you pl. review this patch, Except this patch, rest of patches
> >> received ack-by:
> >
> > I had a quick glimpse of the comments from Thomas: he made a good point.
> > I will have a deeper thought tomorrow, to see what I can do to fix it.
> >
> 
> I agree to what Thomas pointed out about runtime mode switch (vectored
> vs non-vectored). I have a proposal in my mind and Like to know you
> opinion:
> 
> - need for apis like is_arch_support_vec().
> 
> if (is_arch_support_vec())
>  simpple_ = 1 /* Switch code path to vector mode */
> else
>  simple_ = 0  /* Switch code path to non-vector mode */
> 
> That api should reside to arch file. i.e.. arch like i686/arm{for
> implementation not exist so say no supported} will return 0 and for
> x86_64 = 1

I was thinking that Thomas meant to something like below (like what
we did at rte_memcpy.h):

#ifdef RTE_MACHINE_CPUFLAG_SSE (or whatever)

/* with vec here */

#else

/* without vec here */

#endif

I mean, you have to bypass the build first; otherwise, you can't
go that further to runtime, right?


Huawei, since it's your patch introduced such issue, mind to fix
it?

--yliu
> 
> Does this make sense?
> 
> Thanks
> > --yliu
> >>
> >> Thanks
> >>
> >> On Mon, Feb 8, 2016 at 11:15 AM, Santosh Shukla  
> >> wrote:
> >> > On Mon, Feb 8, 2016 at 2:55 AM, Thomas Monjalon
> >> >  wrote:
> >> >> 2016-02-07 19:21, Santosh Shukla:
> >> >>> - virtio_recv_pkts_vec and other virtio vector friend apis are written 
> >> >>> for
> >> >>>   sse/avx instructions. For arm64 in particular, virtio vector 
> >> >>> implementation
> >> >>>   does not exist(todo).
> >> >>>
> >> >>> So virtio pmd driver wont build for targets like i686, arm64.  By 
> >> >>> making
> >> >>> RTE_VIRTIO_INC_VECTOR=n, Driver can build for non-sse/avx targets and 
> >> >>> will work
> >> >>> in non-vectored virtio mode.
> >> >>>
> >> >>> Disabling RTE_VIRTIO_INC_VECTOR config for :
> >> >>>
> >> >>> - i686 arch as i686 target config says:
> >> >>>   config/defconfig_i686-native-linuxapp-gcc says "Vectorized PMD is not
> >> >>>   supported on 32-bit".
> >> >>>
> >> >>> - armv7/v8 arch.
> >> >>
> >> >> Yes it can be useful to disable vector optimizations, but it should done
> >> >> at runtime, not a compilation option. I know it is already wrongly 
> >> >> configured
> >> >> at compilation for other drivers, we should fix them.
> >> >>
> >> >
> >> > Can't we consider this separate topic. My intent is virtio works for arm.
> >> >
> >> >> Here, you want to avoid SSE/AVX code on ARM. So we should just add the
> >> >> appropriate ifdefs. Adding a compilation option does not prevent from 
> >> >> enabling
> >> >> it on ARM or old x86 which do not support these instructions.
> >> >>
> >> >
> >> > By disabling VIRTIO_INC_VEC, compiler wont build
> >> > virtio_recv_pkts_vec(), so wont generate SSE/AVX code. Adding ifdef
> >> > for other arch example arm, is next step. Vector instruction for arm
> >> > are not fully supported, Its a todolist (Pl. refer my early v1/2
> >> > cover-letter), We'll add that after virtio functionally works for arm.
> >> >
> >> >> Please virtio maintainers, we need to fix this code. Thanks

[dpdk-dev] [PATCH v2 03/16] fm10k/base: cleanup namespace pollution and correct typecast

[Bruce Richardson]

On Wed, Jan 27, 2016 at 11:50:34AM +0800, Wang Xiao W wrote:
> Correct typecast in fm10k_update_xc_addr_pf.
> 
> Make functions that are only referenced locally static.
> 
> And fix the function header comment for fm10k_tlv_attr_nest_stop() while
> we're at it.
> 
> Wrap fm10k_msg_data fm10k_iov_msg_data_pf[] in the new ifndef
> NO_DEFAULT_SRIOV_MSG_HANDLERS so that drivers with custom SR-IOV
> message handlers can strip it.
> 
> remove unused struct element in struct fm10k_mac_ops.
> 
> Signed-off-by: Wang Xiao W 
> ---

>From the commit message it appears that a lot of things are being crammed into
one patch. Please consider splitting it up, so that each commit just looks at
doing one thing. If there are multiple one-line fixes, it's ok to put them into
a single patch with a generic title like "misc small fixes", but for multi-line
changes, it's best to have one change/fix per patch.

Note also, that for commits fixing problems, a "fixes" line should be included 
in
the commit message as documented here:
http://dpdk.org/doc/guides/contributing/patches.html#commit-messages-body

Thanks,
/Bruce

[dpdk-dev] [PATCH v1 0/3] Add missing ethdev driver support

[Stephen Hemminger]

On Thu, 28 Jan 2016 08:48:12 +
Remy Horton  wrote:

> Several rte_eth_dev_* functions are currently only supported
> by the ixgbe NIC driver. This patchset adds driver support
> for some of these functions to the i40e, virtio, and vmxnet3
> drivers.

It is good to make drivers more complete and compatible, but unless
the virtual driver has some useful data I can't see the point of providing
these functions in this case. The base infrastructure (rte_ethdev) should
deal with by returning not supported error (or all zeros); rather than
creating more code in other drivers for no real gain.

[dpdk-dev] [PATCH v2 02/16] fm10k/base: add macro definitions that are needed

[Bruce Richardson]

On Wed, Jan 27, 2016 at 11:50:33AM +0800, Wang Xiao W wrote:
> Some macros such as FM10K_RXINT_TIMER_SHIFT are removed in the share
> code drop, but they are needed in dpdk/fm10k. This patch put all these
> necessary macros into fm10k_osdep.h
> 
> Signed-off-by: Wang Xiao W 
> ---
>  drivers/net/fm10k/base/fm10k_osdep.h | 30 ++
>  1 file changed, 30 insertions(+)
> 
Compilation fails with this patch applied. Each patch of the set must leave the
repository in a compilable state. Please do a V3 patchset to fix.

Thanks,
/Bruce

  CC fm10k_ethdev.o
In file included from 
/home/bruce/next-net/dpdk-next-net/drivers/net/fm10k/fm10k.h:43:0,
   from 
/home/bruce/next-net/dpdk-next-net/drivers/net/fm10k/fm10k_ethdev.c:41:
/home/bruce/next-net/dpdk-next-net/drivers/net/fm10k/base/fm10k_type.h:904:6: 
error: nested redefiniti on of ?enum fm10k_rdesc_pkt_type?
enum fm10k_rdesc_pkt_type {
  ^
compilation terminated due to -Wfatal-errors.
/home/bruce/next-net/dpdk-next-net/mk/internal/rte.compile-pre.mk:126: recipe 
for target 'fm10k_ethdev .o' failed
make[5]: *** [fm10k_ethdev.o] Error 1

[dpdk-dev] [PATCH v2 01/16] fm10k: use default mailbox message handler for pf

[Bruce Richardson]

On Wed, Jan 27, 2016 at 11:50:32AM +0800, Wang Xiao W wrote:
> The new share code makes fm10k_msg_update_pvid_pf function static, so we can
> not refer to it now in fm10k_ethdev.c. The registered pf handler is almost the
> same as the default pf handler, removing it has no impact on mailbox.
> 
> Signed-off-by: Wang Xiao W 

While the patch itself looks ok, checkpatch gives a warning about the commit
message being too long.

  WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a
  maximum 75 chars per line)
  #6:
  The new share code makes fm10k_msg_update_pvid_pf function static, so we can

  total: 0 errors, 1 warnings, 0 checks, 31 lines checked

Since the next patch breaks compilation, a V3 will be needed, so please fix this
warning in the process. I'd also ask that you run checkpatch on all patches
before submitting and fix any issue raised.

Thanks,
/Bruce

[dpdk-dev] [PATCH v2 3/5] virtio/vdev: add embeded device emulation

[Tan, Jianfeng]

Hi Tetsuya,

On 2/8/2016 2:59 PM, Tetsuya Mukawa wrote:
> On 2016/02/05 20:20, Jianfeng Tan wrote:
>> To implement virtio vdev, we need way to interract with vhost backend.
>> And more importantly, needs way to emulate a device into DPDK. So this
>> patch acts as embedded device emulation.
>>
>> Depends on the type of vhost file: vhost-user is used if the given
>> path points to a unix socket; vhost-net is used if the given path
>> points to a char device.
>>
>> Signed-off-by: Huawei Xie 
>> Signed-off-by: Jianfeng Tan 
>> ---
>>  
>> +void
>> +virtio_vdev_init(struct rte_eth_dev_data *data, char *path,
>> + int nb_rx, int nb_tx, int nb_cq __attribute__ ((unused)),
>> + int queue_num, char *mac, char *ifname)
>> +{
>> +int i, r;
>> +struct stat s;
>> +uint32_t tmp[ETHER_ADDR_LEN];
>> +struct virtio_hw *hw = data->dev_private;
>> +
>> +hw->vtpci_ops = _ops;
>> +hw->io_base  = 0;
>> +hw->use_msix = 0;
>> +hw->modern   = 0;
>> +
>> +hw->data = data;
>> +hw->path = strdup(path);
>> +hw->max_rx_queues = nb_rx;
>> +hw->max_tx_queues = nb_tx;
>> +hw->queue_num = queue_num;
>> +hw->mac_specified = 0;
>> +if (mac) {
>> +r = sscanf(mac, "%x:%x:%x:%x:%x:%x", [0],
>> +   [1], [2], [3], [4], [5]);
>> +if (r == ETHER_ADDR_LEN) {
>> +for (i = 0; i < ETHER_ADDR_LEN; ++i)
>> +hw->mac_addr[i] = (uint8_t)tmp[i];
>> +hw->mac_specified = 1;
>> +} else
>> +PMD_DRV_LOG(WARN, "wrong format of mac: %s", mac);
> It seems you cannot use 'WARN' here.

Thanks, I'll change it to ERR.

Thanks,
Jianfeng
>
> Thanks,
> Tetsuya
>

[dpdk-dev] x86_64-native-linuxapp-clang compilation broken?

[Matthew Hall]

On Tue, Feb 16, 2016 at 12:57:24PM +, De Lara Guarch, Pablo wrote:
> We suspect this might be an architecture dependent issue.
> Could you tell us which CPU you are using?
> 
> Thanks,
> Pablo

When it happens to me I am using a Skylake Core i7-6700K.

Matthew.

[dpdk-dev] [PATCH v2 3/5] virtio/vdev: add embeded device emulation

[Tan, Jianfeng]

Hi Michael,

Don't know why, I have not received the email you comment on this commit.

On 2/5/2016 7:20 PM, Jianfeng Tan wrote:
> To implement virtio vdev, we need way to interract with vhost backend.
> And more importantly, needs way to emulate a device into DPDK. So this
> patch acts as embedded device emulation.
>
> Depends on the type of vhost file: vhost-user is used if the given
> path points to a unix socket; vhost-net is used if the given path
> points to a char device.
>
> Signed-off-by: Huawei Xie 
> Signed-off-by: Jianfeng Tan 
> ---
>   config/common_linuxapp  |   5 +
>   drivers/net/virtio/Makefile |   4 +
>   drivers/net/virtio/vhost.h  | 194 +
>   drivers/net/virtio/vhost_embedded.c | 809 
> 
>   drivers/net/virtio/virtio_ethdev.h  |   6 +-
>   drivers/net/virtio/virtio_pci.h |  15 +-
>   6 files changed, 1031 insertions(+), 2 deletions(-)
>   create mode 100644 drivers/net/virtio/vhost.h
>   create mode 100644 drivers/net/virtio/vhost_embedded.c
>
...
> Don't hard-code this, it's not nice.

Actually, it comes from in lib/librte_vhost/rte_virtio_net.h. If we 
follow your suggestion below, it'll be addressed.

> Why do you duplicate ioctls?
> Use them from /usr/include/linux/vhost.h, etc.
>
> In fact, what's not coming from linux here
> comes from lib/librte_vhost/vhost_user/vhost-net-user.h.
>
> I think you should reuse code, avoid code duplication.

The reason I was considering is:
a. If we include /usr/include/linux/vhost.h, then virtio cannot be used 
in FreeBSD.
b. To use definitions in lib/librte_vhost/vhost_user/vhost-net-user.h, 
we need expose this header file outside.

Thanks,
Jianfeng

[dpdk-dev] [PATCH v3 3/4] eal: introduce pci ioport api

[Yuanhan Liu]

On Mon, Feb 15, 2016 at 02:24:25PM +0100, David Marchand wrote:
> +/**
> + * A structure used to access io resources for a pci device.
> + * rte_pci_ioport is arch, os, driver specific, and should not be used 
> outside
> + * of pci ioport api.
> + */
> +struct rte_pci_ioport {
> + struct rte_pci_device *dev;
> + uint64_t offset;
> +};

"offset" dosen't sound like a good name to me; espeicially when I found
code like below:

reg = p->offset + offset;

Regarding that, maybe "base" is a better name? I don't like it too much,
though. Any better idea?

Otherwise, this patch looks good to me.

--yliu

[dpdk-dev] [PATCH] igb: set default thresholds correctly based on mac type

[Bruce Richardson]

On Mon, Feb 01, 2016 at 02:59:13AM +, Lu, Wenzhuo wrote:
> 
> 
> > -Original Message-
> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > Sent: Friday, January 22, 2016 9:39 AM
> > To: Lu, Wenzhuo
> > Cc: dev at dpdk.org; Stephen Hemminger
> > Subject: [PATCH] igb: set default thresholds correctly based on mac type
> > 
> > This brings the DPDK igb driver inline with the behavior used by the 
> > current Linux
> > driver. The IGB hardware has several different MAC types and the threshold
> > values that work vary based on the hardware.
> > 
> > Since DPDK 1.8 it has been up to devices to provide the correct default
> > configuration parameter. But the igb driver gives values that are broken on
> > some devices, and always causes a warning message at startup.
> > 
> > Please test this on real hardware, I don't have the luxury of a hardware 
> > lab full
> > of variations of this chip.
> > 
> > Signed-off-by: Stephen Hemminger 
> Acked-by: Wenzhuo Lu 
> 
Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH v2 2/5] EAL: Add new EAL "--qtest-virtio" option

[Tetsuya Mukawa]

On 2016/02/15 16:52, Tan, Jianfeng wrote:
> Hi Tetsuya,
>
> On 2/10/2016 11:40 AM, Tetsuya Mukawa wrote:
>> To work with qtest virtio-net PMD, virtual address that maps hugepages
>> should be between (1 << 31) to (1 << 44). This patch adds one more
>> option
>
> Is there any reference about this limitation? And is it also true for
> 32 bit machine?
>

Hi Jianfeng,

44bit limitation is come from virtio legacy device spec.
The queue address register of virtio device is 32bit width.
And we should set page number to this register.
As a result, EAL memory should be under 44 bits.

I only support virtio modern device with this patch series.
So we can relax this limitation a bit.
(Next limitation may be 47 bits. It seems it is come from QEMU
implementation.)
But I guess 44bit limitation is still not so hard, also we can leave a
possibility to support legacy device.

31bits limitation is come from current memory mapping of QTest QEMU guest.
Here is.

 * 
 * Memory mapping of qtest quest
 * 
 * 0x_ - 0x_3fff : not used
 * 0x_4000 - 0x_4fff : virtio-net(BAR1)
 * 0x_40001000 - 0x_40ff : not used
 * 0x_4100 - 0x_417f : virtio-net(BAR4)
 * 0x_4180 - 0x_41ff : not used
 * 0x_4200 - 0x_42ff : ivshmem(BAR0)
 * 0x_42000100 - 0x_42ff : not used
 * 0x_8000 - 0x_ : ivshmem(BAR2)

Thanks,
Tetsuya


> Thanks,
> Jianfeng

[dpdk-dev] [PATCH v3 4/4] virtio: use pci ioport api

[Yuanhan Liu]

On Mon, Feb 15, 2016 at 02:24:26PM +0100, David Marchand wrote:
> Move all os / arch specifics to eal.

Great stuff; something I want to do long time ago! So, thank you, and

Acked-by: Yuanhan Liu 

--yliu

[dpdk-dev] [PATCH v2 1/3] eal: fix keep alive header for C++

[Remy Horton]

Suspect this will introduce an extra indirection and call/return into 
the generated code, but can't think of any alternative that doesn't 
potentially break source compatibility..


On 16/02/2016 07:14, Thomas Monjalon wrote:
> When built in a C++ application, the keepalive include fails:
>
> rte_keepalive.h:142:41: error: ?ALIVE? was not declared in this scope
>keepcfg->state_flags[rte_lcore_id()] = ALIVE;
>   ^
> C++ requires to use a scope operator to access an enum inside a struct.
> There was also a namespace issue for the values (no RTE prefix).
> The solution is to move the struct and related code out of the header file.
>
> Fixes: 75583b0d1efd ("eal: add keep alive monitoring")
>
> Signed-off-by: Thomas Monjalon 

Acked-by: Remy Horton 

[dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure

[Bruce Richardson]

On Tue, Feb 16, 2016 at 12:15:19PM +0800, Ziye Yang wrote:
> From: Ziye 
> 
> The purpose of this patch is used to add a new field
> "class" in rte_pci_id structure. The new class field includes
> class_id, subcalss_id, programming interface of a pci device.
> With this field, we can identify pci device by its class info,
> which can be more flexible instead of probing the device by
> vendor_id OR device_id OR subvendor_id OR subdevice_id.
> For example, we can probe all nvme devices by class field, which
> can be quite convenient.
> 
> As release_2_3.rst is replaced with release_16_04.rst.
> 
> Signed-off-by: Ziye Yang 
> ---
>  doc/guides/rel_notes/release_16_04.rst | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/guides/rel_notes/release_16_04.rst 
> b/doc/guides/rel_notes/release_16_04.rst
> index 27fc624..fe843a5 100644
> --- a/doc/guides/rel_notes/release_16_04.rst
> +++ b/doc/guides/rel_notes/release_16_04.rst
> @@ -95,9 +95,10 @@ This section should contain API changes. Sample format:
>  ABI Changes
>  ---
>  
> -* Add a short 1-2 sentence description of the ABI change that was announced 
> in
> -  the previous releases and made in this release. Use fixed width quotes for
> -  ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
> +* New field ``class`` is added into ``rte_pci_id`` structure. This new
> +  added ``class`` field can be used to probe pci devices by class related
> +  info. With this new field, the size of structure ``rte_pci_device`` will
> +  be increased.
>  
>  
>  Shared Library Versions
> -- 

Hi,

since this is new ABI change announcement, and not one that was previously
announced and is now being applied, this announcement should go in the 
deprecation.rst file, rather than release_16_04.rst.

Thomas, is there some reason why the deprecation notices are not called out in
the release notes for a new release? Why are they kept separately?

/Bruce

[dpdk-dev] Replacing KCP (Kernel Control Path) out-of-tree kernel module with in-kernel module

[Aaron Conole]

Hi Ferruh,

Ferruh Yigit  writes:
> This is continuation of previous mail thread:
>   http://dpdk.org/ml/archives/dev/2016-February/032701.html
>
> Since there were no comments, I want to give another try, this can be
> good opportunity to escape from out-of-kernel Linux module.

Awesome! I fully endorse this effort, btw :)

> First high level important question:
> - Do you think will Linux community welcome a network driver that
> enables/supports userspace network driver?
>
> And let me rephrase what I have in my mind:
>
> - Implement a Linux network driver, that uses rtnetlink, so that
> userspace applications can create network interfaces.
> - This driver implements net_device_ops as a forwarding layer to
> userspace; using netlink sockets.

I think a new driver isn't needed. There exists the TUN/TAP driver, so
it might be better to provide a way of implementing a (for lack of
better terms) forwarding layer in that device. There are some things
that I think would make sense for upstream to accept (after all, if
userspace creates this tun/tap device and wants to get involved in the
control side, there are many hoops that need to be jumped). I also think
such an effort could gain some traction upstream.

On the other hand, for most actions there exists already a bunch of APIs
for interacting with TAP/TUN devices for monitoring changes.

If you want more info on what the heck I'm talking about, there's a
project called switchlink which aims to do some kind of switch
management in P4; the library they have uses event listeners and
rtnetlink to know when a device has been added, monitors state, etc. I
think such an approach from the dpdk side would be useful to accomplish
this task.

> - Each userspace network driver has a unique identifier.
> - Userspace drivers listens netlink group created by kernel driver.
> - An application, or userspace driver itself, attaches userspace
> driver, by providing its unique id, to the created network
> interface. This associates network interface to userspace driver.
> - After this point userspace driver detects its own id in netlink
> messages and responds back to the requests.
> - Anytime userspace driver can be detached and network interface can
> be removed by a userspace application.
>
> I believe this can work, but not sure if this worths to the investment
> because this can be quite some work. Also not sure if this gets
> accepted by Linux upstream.

As always, it's the actual code that counts. No amount of pontification
or prognostication changes that.

> I would like to have some support/feedback to undertake something like this.

I am happy to work with you on this effort. I can feed you some of my
old "unpolished" (read hacky proof of concept) patches if you want to
see what I've done in this area. I am currently trying to get some other
stuff cleared off my backlog.

> Any comment is welcome.
>
> Thanks,
> ferruh

-Aaron

[dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure

[Panu Matilainen]

On 02/16/2016 09:43 AM, Yang, Ziye wrote:
> Hi Panu,
>
> " ABI breakage announcements go into doc/guides/rel_notes/deprecation.rst,
> see the examples there. Also you can't break the ABI in the version under 
> development but only the next one, so right now the earliest ABI breakage 
> opportunity is in the release *after* 16.04, which is supposed to be 16.07 
> according to the roadmap."
>
> So I only need to do the ABI breakage announcements  into 
> doc/guides/rel_notes/deprecation.rst, right?
>

Yes.

The version-specific release notes ABI/API changes section is to be 
updated along with the actual changes to the code.

If you haven't already done so, do read
http://dpdk.org/doc/guides/contributing/versioning.html

- Panu -

[dpdk-dev] [PATCH] qat pmd:Fixing build issue on 32-bit systems

[John Griffin]

Fixing build issue on 32-bit systems.
Fixes: 1703e94ac5ce ("qat: add driver for QuickAssist devices")

Signed-off-by: John Griffin 
---
 drivers/crypto/qat/qat_crypto.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
index 129e96d..828756b 100644
--- a/drivers/crypto/qat/qat_crypto.c
+++ b/drivers/crypto/qat/qat_crypto.c
@@ -342,7 +342,7 @@ qat_crypto_pkt_rx_burst(void *qp, struct rte_mbuf 
**rx_pkts, uint16_t nb_pkts)

while (*(uint32_t *)resp_msg != ADF_RING_EMPTY_SIG &&
msg_counter != nb_pkts) {
-   rx_mbuf = (struct rte_mbuf *)(resp_msg->opaque_data);
+   rx_mbuf = (struct rte_mbuf *)(uintptr_t)(resp_msg->opaque_data);
ol = rte_pktmbuf_offload_get(rx_mbuf, RTE_PKTMBUF_OL_CRYPTO);

if (ICP_QAT_FW_COMN_STATUS_FLAG_OK !=
@@ -405,7 +405,7 @@ qat_alg_write_mbuf_entry(struct rte_mbuf *mbuf, uint8_t 
*out_msg)
ctx = (struct qat_session *)ol->op.crypto.session->_private;
qat_req = (struct icp_qat_fw_la_bulk_req *)out_msg;
*qat_req = ctx->fw_req;
-   qat_req->comn_mid.opaque_data = (uint64_t)mbuf;
+   qat_req->comn_mid.opaque_data = (uint64_t)(uintptr_t)mbuf;

/*
 * The following code assumes:
-- 
2.1.0

[dpdk-dev] [PATCH v2] PCI: ABI change request for adding new field in rte_pci_id structure

[Panu Matilainen]

On 02/16/2016 05:16 AM, Ziye Yang wrote:
> From: Ziye 
>
> The purpose of this patch is used to add a new field
> "class" in rte_pci_id structure. The new class field includes
> class_id, subcalss_id, programming interface of a pci device.
> With this field, we can identify pci device by its class info,
> which can be more flexible instead of probing the device by
> vendor_id OR device_id OR subvendor_id OR subdevice_id.
> For example, we can probe all nvme devices by class field, which
> can be quite convenient.
>
> Signed-off-by: Ziye Yang 
> ---
>   doc/guides/rel_notes/release_16_04.rst | 7 ---
>   1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_16_04.rst 
> b/doc/guides/rel_notes/release_16_04.rst
> index 27fc624..fe843a5 100644
> --- a/doc/guides/rel_notes/release_16_04.rst
> +++ b/doc/guides/rel_notes/release_16_04.rst
> @@ -95,9 +95,10 @@ This section should contain API changes. Sample format:
>   ABI Changes
>   ---
>
> -* Add a short 1-2 sentence description of the ABI change that was announced 
> in
> -  the previous releases and made in this release. Use fixed width quotes for
> -  ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
> +* New field ``class`` is added into ``rte_pci_id`` structure. This new
> +  added ``class`` field can be used to probe pci devices by class related
> +  info. With this new field, the size of structure ``rte_pci_device`` will
> +  be increased.
>
>
>   Shared Library Versions
>

ABI breakage announcements go into doc/guides/rel_notes/deprecation.rst, 
see the examples there. Also you can't break the ABI in the version 
under development but only the next one, so right now the earliest ABI 
breakage opportunity is in the release *after* 16.04, which is supposed 
to be 16.07 according to the roadmap.

- Panu -

[dpdk-dev] [dpdk-announce] call to join Linux Foundation

[Stephen Hemminger]

On Mon, 15 Feb 2016 16:15:17 +0100
Thomas Monjalon  wrote:

> After few meetings and emails, it has been agreed to work with
> the Linux Foundation to assist the growing community of the DPDK.
> 
> The outlines and the budget are described in this email by Tim O'Driscoll:
>   http://dpdk.org/ml/archives/dev/2016-February/032720.html
> 
> We need around ten companies to contribute to this small effort and
> become a supporter of the initiative.
> 
> As suggested by Dave Neary, the next step is to draft a membership
> agreement and identify the members of this new lightweight foundation:
>   http://dpdk.org/ml/archives/dev/2016-February/032909.html
> 
> Please, it would be great to use this thread to announce the official
> commitment of your company to support the DPDK community!
> 

Brocade supports this transition and is happy to be part of the community
ensuring the long term support of DPDK.

[dpdk-dev] [PATCH v3] fm10k: fix switch manager high CPU usage

[Chen, Jing D]

Hi,

Best Regards,
Mark


> -Original Message-
> From: He, Shaopeng
> Sent: Friday, February 05, 2016 10:46 AM
> To: dev at dpdk.org
> Cc: Chen, Jing D; Wang, Xiao W; He, Shaopeng
> Subject: [PATCH v3] fm10k: fix switch manager high CPU usage
> 
> fm10k switch core uses source MAC + VID + SGLORT to do
> look up in MAC table. If no match, an exception interrupt
> will be sent to the switch manager. Too much of this kind
> of exception interrupts cause switch manager side high CPU
> usage.
> To reproduce this issue, one DPDK testpmd runs on a server
> with one fm10k NIC, mac forwards test traffic from one of
> fm10k ports to another port. The CPU usage for the switch
> manager will go up to about 20% for test traffic rate at
> 10G bps, comparing to near 0% for no test traffic.
> This patch fixes this issue. A default SGLORT is assigned
> to each TX queue. This default value works for non-VMDq mode
> and current VMDq example. For advanced VMDq usage, e.g.
> different source MAC address for different TX queue, FTAG
> forwarding function could be used to change this default
> SGLORT value.
> 
> Fixes: 9ae6068c ("fm10k: add dev start/stop")
> 
> Signed-off-by: Shaopeng He 
Acked-by : Jing Chen 

[dpdk-dev] [PATCH v2 0/5] clean-up cpuflags

[Thomas Monjalon]

2016-02-06 23:17, Thomas Monjalon:
> Following the work of Ferruh, I suggest this cleanup to remove as much
> as possible of the code from the cpuflags headers.
> The goal is to un-inline these functions (not performance sensitive)
> and remove the CPU flags table from the ABI (just added recently).
> The bonus is to stop mimic x86 in ARM and PPC implementations.
> 
> WARNING: it has not been tested nor compiled on Tilera and POWER8.
> 
> v2 changes:
> - fix maintainers file
> - fix include from C++ app
> - fix missing REG_PLATFORM for ARM
> - suggested ARM refactor from Jerin

Applied

[dpdk-dev] [PATCH v2 3/3] mbuf_offload: fix header for C++

[Thomas Monjalon]

When built in a C++ application, the include fails for 2 reasons:

rte_mbuf_offload.h:128:24: error:
invalid conversion from ?void*? to ?rte_pktmbuf_offload_pool_private*? 
[-fpermissive]
rte_mempool_get_priv(mpool);
^
The cast must be explicit for C++.

rte_mbuf_offload.h:304:1: error: expected declaration before ?}? token

There was a closing brace for __cplusplus but not an opening one.

Fixes: 78c8709b5ddb ("mbuf_offload: introduce library to attach offloads to 
mbuf")

Signed-off-by: Thomas Monjalon 
---
 lib/librte_mbuf_offload/rte_mbuf_offload.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

v2:
- add struct keyword

diff --git a/lib/librte_mbuf_offload/rte_mbuf_offload.h 
b/lib/librte_mbuf_offload/rte_mbuf_offload.h
index 4345f06..77993b6 100644
--- a/lib/librte_mbuf_offload/rte_mbuf_offload.h
+++ b/lib/librte_mbuf_offload/rte_mbuf_offload.h
@@ -59,6 +59,9 @@
 #include 
 #include 

+#ifdef __cplusplus
+extern "C" {
+#endif

 /** packet mbuf offload operation types */
 enum rte_mbuf_ol_op_type {
@@ -125,7 +128,7 @@ static inline uint16_t
 __rte_pktmbuf_offload_priv_size(struct rte_mempool *mpool)
 {
struct rte_pktmbuf_offload_pool_private *priv =
-   rte_mempool_get_priv(mpool);
+   (struct rte_pktmbuf_offload_pool_private 
*)rte_mempool_get_priv(mpool);

return priv->offload_priv_size;
 }
-- 
2.7.0

[dpdk-dev] [PATCH v2 2/3] hash: fix header for C++

[Thomas Monjalon]

When built in a C++ application, the jhash include fails:

rte_jhash.h:123:22: error:
invalid conversion from ?const void*? to ?const uint32_t*? [-fpermissive]
  const uint32_t *k = key;
  ^
The cast must be explicit for C++.

Fixes: 8718219a8737 ("hash: add new jhash functions")

Signed-off-by: Thomas Monjalon 
Acked-by: Pablo de Lara 
---
 lib/librte_hash/rte_jhash.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_hash/rte_jhash.h b/lib/librte_hash/rte_jhash.h
index 457f225..207478c 100644
--- a/lib/librte_hash/rte_jhash.h
+++ b/lib/librte_hash/rte_jhash.h
@@ -120,7 +120,7 @@ __rte_jhash_2hashes(const void *key, uint32_t length, 
uint32_t *pc,
 * If check_align is not set, first case will be used
 */
 #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686) || 
defined(RTE_ARCH_X86_X32)
-   const uint32_t *k = key;
+   const uint32_t *k = (const uint32_t *)key;
const uint32_t s = 0;
 #else
const uint32_t *k = (uint32_t *)((uintptr_t)key & (uintptr_t)~3);
-- 
2.7.0

[dpdk-dev] [PATCH v2 1/3] eal: fix keep alive header for C++

[Thomas Monjalon]

When built in a C++ application, the keepalive include fails:

rte_keepalive.h:142:41: error: ?ALIVE? was not declared in this scope
  keepcfg->state_flags[rte_lcore_id()] = ALIVE;
 ^
C++ requires to use a scope operator to access an enum inside a struct.
There was also a namespace issue for the values (no RTE prefix).
The solution is to move the struct and related code out of the header file.

Fixes: 75583b0d1efd ("eal: add keep alive monitoring")

Signed-off-by: Thomas Monjalon 
---
 lib/librte_eal/common/include/rte_keepalive.h | 37 +++---
 lib/librte_eal/common/rte_keepalive.c | 38 +++
 2 files changed, 41 insertions(+), 34 deletions(-)

v2:
- move keep-alive struct out of header
- uninline mark_alive function

diff --git a/lib/librte_eal/common/include/rte_keepalive.h 
b/lib/librte_eal/common/include/rte_keepalive.h
index 02472c0..f4cec04 100644
--- a/lib/librte_eal/common/include/rte_keepalive.h
+++ b/lib/librte_eal/common/include/rte_keepalive.h
@@ -64,35 +64,7 @@ typedef void (*rte_keepalive_failure_callback_t)(
  * Keepalive state structure.
  * @internal
  */
-struct rte_keepalive {
-   /** Core Liveness. */
-   enum {
-   ALIVE = 1,
-   MISSING = 0,
-   DEAD = 2,
-   GONE = 3
-   } __rte_cache_aligned state_flags[RTE_KEEPALIVE_MAXCORES];
-
-   /** Last-seen-alive timestamps */
-   uint64_t last_alive[RTE_KEEPALIVE_MAXCORES];
-
-   /**
-* Cores to check.
-* Indexed by core id, non-zero if the core should be checked.
-*/
-   uint8_t active_cores[RTE_KEEPALIVE_MAXCORES];
-
-   /** Dead core handler. */
-   rte_keepalive_failure_callback_t callback;
-
-   /**
-* Dead core handler app data.
-* Pointer is passed to dead core handler.
-*/
-   void *callback_data;
-   uint64_t tsc_initial;
-   uint64_t tsc_mhz;
-};
+struct rte_keepalive;


 /**
@@ -136,11 +108,8 @@ void rte_keepalive_register_core(struct rte_keepalive 
*keepcfg,
  * This function needs to be called from within the main process loop of
  * the LCore to be checked.
  */
-static inline void
-rte_keepalive_mark_alive(struct rte_keepalive *keepcfg)
-{
-   keepcfg->state_flags[rte_lcore_id()] = ALIVE;
-}
+void
+rte_keepalive_mark_alive(struct rte_keepalive *keepcfg);


 #endif /* _KEEPALIVE_H_ */
diff --git a/lib/librte_eal/common/rte_keepalive.c 
b/lib/librte_eal/common/rte_keepalive.c
index 736fd0f..bd1f16b 100644
--- a/lib/librte_eal/common/rte_keepalive.c
+++ b/lib/librte_eal/common/rte_keepalive.c
@@ -39,6 +39,37 @@
 #include 
 #include 

+struct rte_keepalive {
+   /** Core Liveness. */
+   enum rte_keepalive_state {
+   ALIVE = 1,
+   MISSING = 0,
+   DEAD = 2,
+   GONE = 3
+   } __rte_cache_aligned state_flags[RTE_KEEPALIVE_MAXCORES];
+
+   /** Last-seen-alive timestamps */
+   uint64_t last_alive[RTE_KEEPALIVE_MAXCORES];
+
+   /**
+* Cores to check.
+* Indexed by core id, non-zero if the core should be checked.
+*/
+   uint8_t active_cores[RTE_KEEPALIVE_MAXCORES];
+
+   /** Dead core handler. */
+   rte_keepalive_failure_callback_t callback;
+
+   /**
+* Dead core handler app data.
+* Pointer is passed to dead core handler.
+*/
+   void *callback_data;
+   uint64_t tsc_initial;
+   uint64_t tsc_mhz;
+};
+
+
 static void
 print_trace(const char *msg, struct rte_keepalive *keepcfg, int idx_core)
 {
@@ -111,3 +142,10 @@ rte_keepalive_register_core(struct rte_keepalive *keepcfg, 
const int id_core)
if (id_core < RTE_KEEPALIVE_MAXCORES)
keepcfg->active_cores[id_core] = 1;
 }
+
+
+void
+rte_keepalive_mark_alive(struct rte_keepalive *keepcfg)
+{
+   keepcfg->state_flags[rte_lcore_id()] = ALIVE;
+}
-- 
2.7.0

[dpdk-dev] [PATCH v2 0/3] fix C++ includes

[Thomas Monjalon]

When trying to build a C++ application, some errors appear from DPDK headers.
2 libraries are not fixed in this series:
- cmdline
- vhost which includes some not compliant Linux virtio headers

v2:
- move keep-alive struct out of header
- fix syntax in mbuf_offload cast

Thomas Monjalon (3):
  eal: fix keep alive header for C++
  hash: fix header for C++
  mbuf_offload: fix header for C++

 lib/librte_eal/common/include/rte_keepalive.h | 37 +++---
 lib/librte_eal/common/rte_keepalive.c | 38 +++
 lib/librte_hash/rte_jhash.h   |  2 +-
 lib/librte_mbuf_offload/rte_mbuf_offload.h|  5 +++-
 4 files changed, 46 insertions(+), 36 deletions(-)

-- 
2.7.0

[dpdk-dev] [PATCH v2 00/16] fm10k: update shared code

[Chen, Jing D]

Hi,

Best Regards,
Mark


> -Original Message-
> From: Wang, Xiao W
> Sent: Wednesday, January 27, 2016 11:51 AM
> To: Chen, Jing D
> Cc: dev at dpdk.org; Richardson, Bruce; He, Shaopeng; Wang, Xiao W
> Subject: [PATCH v2 00/16] fm10k: update shared code
> 
> v2:
> * Put the two extra fix patches ahead of the base code patches.
> 
> Wang Xiao W (16):
>   fm10k: use default mailbox message handler for pf
>   fm10k/base: add macro definitions that are needed
>   fm10k/base: cleanup namespace pollution and correct typecast
>   fm10k/base: use bitshift for itr_scale
>   fm10k/base: reset max_queues on init_hw_vf failure
>   fm10k/base: document ITR scale workaround in VF TDLEN register
>   fm10k/base: fix checkpatch warning
>   fm10k/base: use BIT macro instead of open-coded bit-shifting of 1
>   fm10k/base: do not use CamelCase
>   fm10k/base: use memcpy for mac addr copy
>   fm10k/base: allow removal of is_slot_appropriate function
>   fm10k/base: consistently use VLAN ID when referencing vid variables
>   fm10k/base: fix comment per upstream review changes
>   fm10k/base: TLV structures must be 4byte aligned, not 1byte aligned
>   fm10k/base: move constants to the right of binary operators
>   fm10k/base: minor cleanups
> 
>  drivers/net/fm10k/base/fm10k_api.c   |   2 +
>  drivers/net/fm10k/base/fm10k_api.h   |   2 +
>  drivers/net/fm10k/base/fm10k_mbx.c   |  63 +++-
>  drivers/net/fm10k/base/fm10k_mbx.h   |  11 +--
>  drivers/net/fm10k/base/fm10k_osdep.h |  30 ++
>  drivers/net/fm10k/base/fm10k_pf.c|  88 +
>  drivers/net/fm10k/base/fm10k_pf.h|  18 ++--
>  drivers/net/fm10k/base/fm10k_tlv.c   |  40 
>  drivers/net/fm10k/base/fm10k_tlv.h   |   9 +-
>  drivers/net/fm10k/base/fm10k_type.h  | 182 +++--
> --
>  drivers/net/fm10k/base/fm10k_vf.c|  32 --
>  drivers/net/fm10k/fm10k_ethdev.c |  41 +++-
>  12 files changed, 220 insertions(+), 298 deletions(-)
> 
> --
> 1.9.3

Acked-by : Jing Chen 

[dpdk-dev] [PATCH v2 0/4] fix examples build

[Thomas Monjalon]

2016-02-16 07:46, Thomas Monjalon:
> I've sent some patchsets previously to fixes examples:
> - "fix build for default machine"
> - "fix compilation of examples for ARM"
> 
> Gather the non-rejected patches of these series here.
> 
> Thomas Monjalon (4):
>   examples/l3fwd: fix build without SSE4.1
>   examples/ip_pipeline: fix build for x86_64 without SSE4.2
>   examples/ethtool: fix build
>   examples: fix build dependencies

Applied

[dpdk-dev] [PATCH 0/3] fix build for default machine

[Thomas Monjalon]

2016-02-03 19:56, Thomas Monjalon:
> When checking build with clang and RTE_MACHINE=default,
> 3 errors appeared.
> 
> Thomas Monjalon (3):
>   eal/x86: fix build with clang for old AVX
>   examples/l3fwd: fix build without SSE4.1
>   examples/ip_pipeline: fix build for x86_64 without SSE4.2

Patch 1 is rejected, because fixed differently:
http://dpdk.org/ml/archives/dev/2016-February/032718.html
Others are re-sent in this series:
http://dpdk.org/ml/archives/dev/2016-February/033223.html

[dpdk-dev] [PATCH 0/3] fix compilation of examples for ARM

[Thomas Monjalon]

2016-02-05 15:54, Thomas Monjalon:
> Thomas Monjalon (3):
>   examples/distributor: fix build for non-x86 arch
>   examples/ethtool: fix build
>   examples: fix build dependencies

Patch 1 is rejected. Others are re-sent in this series:
http://dpdk.org/ml/archives/dev/2016-February/033223.html

[dpdk-dev] [PATCH v2 4/4] examples: fix build dependencies

[Thomas Monjalon]

When building for ARM some examples were failing to compile because
of some dependencies disabled.
Declaring these dependencies prevent from trying to compile some
not supported examples.

Signed-off-by: Thomas Monjalon 
---
 examples/Makefile | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/examples/Makefile b/examples/Makefile
index 1cb4785..1665df1 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -46,21 +46,25 @@ endif
 DIRS-y += ethtool
 DIRS-y += exception_path
 DIRS-y += helloworld
-DIRS-y += ip_pipeline
-DIRS-y += ip_reassembly
+DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += ip_pipeline
+ifeq ($(CONFIG_RTE_LIBRTE_LPM),y)
+DIRS-$(CONFIG_RTE_IP_FRAG) += ip_reassembly
 DIRS-$(CONFIG_RTE_IP_FRAG) += ip_fragmentation
+endif
 DIRS-y += ipv4_multicast
 DIRS-$(CONFIG_RTE_LIBRTE_KNI) += kni
 DIRS-y += l2fwd
 DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += l2fwd-ivshmem
 DIRS-$(CONFIG_RTE_LIBRTE_JOBSTATS) += l2fwd-jobstats
 DIRS-y += l2fwd-keepalive
-DIRS-y += l3fwd
+DIRS-$(CONFIG_RTE_LIBRTE_LPM) += l3fwd
 DIRS-$(CONFIG_RTE_LIBRTE_ACL) += l3fwd-acl
+ifeq ($(CONFIG_RTE_LIBRTE_LPM),y)
 DIRS-$(CONFIG_RTE_LIBRTE_POWER) += l3fwd-power
 DIRS-y += l3fwd-vf
+endif
 DIRS-y += link_status_interrupt
-DIRS-y += load_balancer
+DIRS-$(CONFIG_RTE_LIBRTE_LPM) += load_balancer
 DIRS-y += multi_process
 DIRS-y += netmap_compat/bridge
 DIRS-$(CONFIG_RTE_LIBRTE_REORDER) += packet_ordering
-- 
2.7.0

[dpdk-dev] [PATCH v2 3/4] examples/ethtool: fix build

[Thomas Monjalon]

When building for ARM, the spinlock structure was not found.
It appears to be a mismatch with rwlock which is not used in this file.

Fixes: bda68ab9d1e7 ("examples/ethtool: add user-space ethtool sample 
application")

Signed-off-by: Thomas Monjalon 
Acked-by: Remy Horton 
---
 examples/ethtool/ethtool-app/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/ethtool/ethtool-app/main.c 
b/examples/ethtool/ethtool-app/main.c
index e21abcd..2c655d8 100644
--- a/examples/ethtool/ethtool-app/main.c
+++ b/examples/ethtool/ethtool-app/main.c
@@ -36,7 +36,7 @@
 #include 

 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.7.0