[dpdk-dev] [PATCH v5 1/9] ethdev: extend flow director for input selection

[Wu, Jingjing]

Hi, Thomas

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, March 23, 2016 6:06 AM
> To: Wu, Jingjing
> Cc: dev at dpdk.org; Zhang, Helin
> Subject: Re: [dpdk-dev] [PATCH v5 1/9] ethdev: extend flow director for
> input selection
> 
> 2016-03-21 14:18, Jingjing Wu:
> > This patch added RTE_ETH_INPUT_SET_L3_IP4_TTL,
> > RTE_ETH_INPUT_SET_L3_IP6_HOP_LIMITS input field type and extended
> > struct rte_eth_ipv4_flow and rte_eth_ipv6_flow to support filtering by
> > tos, protocol and ttl.
> [...]
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -22,10 +22,6 @@ Deprecation Notices
> >  * The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
> >must be updated to support 100G link and to have a cleaner link speed
> API.
> >
> > -* ABI changes are planned for struct rte_eth_fdir_flow in order to
> > support
> > -  extend flow director's input set. The release 2.2 does not contain
> > these ABI
> > -  changes, but release 2.3 will, and no backwards compatibility is planned.
> 
> The changed structures are part of rte_eth_fdir_flow.
> So this deprecation notice apply to this patch.
> 
> >  * ABI changes are planned for rte_eth_ipv4_flow and rte_eth_ipv6_flow
> to
> >include more fields to be matched against. The release 2.2 does not
> >contain these ABI changes, but release 2.3 will.
> 
> These are the structures changed in this patch.
> I think this section must be also removed.
> 


This deprecation notice is not raised by me. It is raised by rahul.lakkireddy 
at chelsio.com at commit 954f1545a1ab.
So, I'm not sure if it is OK for me to remove it in my patch.

/Jingjing

> > --- a/doc/guides/rel_notes/release_16_04.rst
> > +++ b/doc/guides/rel_notes/release_16_04.rst
> > @@ -435,6 +435,8 @@ ABI Changes
> >
> >  * The cmdline buffer size has been increase from 256 to 512.
> >
> > +* The ethdev flow director structure ``rte_eth_fdir_flow`` structure
> > +was
> > +  changed. New fields were added to extend flow director's input set.
> 
> For reading ease, it's better to group ethdev changes (before cmdline
> change).

[dpdk-dev] [PATCH] vhost PMD: Fix wrong handling of maximum value of rx/tx queues

[Tetsuya Mukawa]

On 2016/03/23 2:17, Loftus, Ciara wrote:
>> Currently, the maximum value of rx/tx queueus are kept by EAL. But,
>> the value are used like below different meanings in vhost PMD.
>>  - The maximum value of current enabled queues.
>>  - The maximum value of current supported queues.
>>
>> This wrong double meaning will cause an issue like below steps.
>>
>> * Invoke application with below option.
>>   --vdev 'eth_vhost0,iface=,queues=4'
>> * Configure queues like below.
>>   rte_eth_dev_configure(portid, 2, 2, ...);
>> * Configure queues again like below.
>>   rte_eth_dev_configure(portid, 4, 4, ...);
>>
>> The second rte_eth_dev_configure() will be failed because both
>> the maximum value of current enabled queues and supported queues
>> will be '2' after calling first rte_eth_dev_configure().
>>
>> To fix the issue, the patch prepare one more variable to keep the
>> number of maximum supported queues in vhost PMD.
>>
>> Signed-off-by: Tetsuya Mukawa 
>> ---
>>  drivers/net/vhost/rte_eth_vhost.c | 14 --
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/vhost/rte_eth_vhost.c
>> b/drivers/net/vhost/rte_eth_vhost.c
>> index 6b9d287..5fd8c70 100644
>> --- a/drivers/net/vhost/rte_eth_vhost.c
>> +++ b/drivers/net/vhost/rte_eth_vhost.c
>> @@ -88,6 +88,7 @@ struct vhost_queue {
>>  struct pmd_internal {
>>  char *dev_name;
>>  char *iface_name;
>> +uint16_t max_queues;
>>
>>  volatile uint16_t once;
>>  };
>> @@ -555,11 +556,19 @@ static void
>>  eth_dev_info(struct rte_eth_dev *dev,
>>   struct rte_eth_dev_info *dev_info)
>>  {
>> +struct pmd_internal *internal;
>> +
>> +internal = dev->data->dev_private;
>> +if (internal == NULL) {
>> +RTE_LOG(ERR, PMD, "Invalid device specified\n");
>> +return;
>> +}
>> +
>>  dev_info->driver_name = drivername;
>>  dev_info->max_mac_addrs = 1;
>>  dev_info->max_rx_pktlen = (uint32_t)-1;
>> -dev_info->max_rx_queues = dev->data->nb_rx_queues;
>> -dev_info->max_tx_queues = dev->data->nb_tx_queues;
>> +dev_info->max_rx_queues = internal->max_queues;
>> +dev_info->max_tx_queues = internal->max_queues;
>>  dev_info->min_rx_bufsize = 0;
>>  }
>>
>> @@ -751,6 +760,7 @@ eth_dev_vhost_create(const char *name, char
>> *iface_name, int16_t queues,
>>  memmove(data->name, eth_dev->data->name, sizeof(data-
>>> name));
>>  data->nb_rx_queues = queues;
>>  data->nb_tx_queues = queues;
>> +internal->max_queues = queues;
>>  data->dev_link = pmd_link;
>>  data->mac_addrs = eth_addr;
>>
>> --
>> 2.1.4
> Hi Tetsuya,
>
> Thanks again for the patch.
>
> Acked-by: Ciara Loftus 
>
> Thanks,
> Ciara
>

I appreciate your reviewing and testing.

Thanks,
Tetsuya

[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring

[Xu, Qian Q]

We have tested with intel nic and found port can't be started for all 
nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please check 
and fix it. 


Thanks
Qian

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Wednesday, March 23, 2016 3:59 AM
To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin
Cc: marcdevel at gmail.com; Richardson, Bruce; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API 
refactoring

2016-03-17 19:08, Thomas Monjalon:
> There are still too few tests and reviews, especially for 
> autonegotiation with Intel devices (patch #6).
> I would not be surprised to see some bugs in this rework.

Any feedback about autoneg in e1000/ixgbe/i40e?
Has it been tested before its integration in RC2?

> The capabilities must be adapted per device. It can be improved in a 
> separate patch.
> 
> It will be integrated in 16.04-rc2.
> Please test and review shortly, thanks!

[dpdk-dev] [PATCH] igb_uio: fix vmware e1000 input/output error

[Xu, Qian Q]

In fact, Masaru is the author, and I'm not sure how to detect a VWMARE E1000 
device, anyone from vmware can check this? Thx. 

Thanks
Qian


-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Monday, March 21, 2016 6:08 PM
To: Xu, Qian Q; Masaru OKI
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: Re: [dpdk-dev] [PATCH] igb_uio: fix vmware e1000 input/output error

2016-03-21 17:01, Qian Xu:
> INTX is badly emulated in Vmware, INTX toggle check didn't work with 
> Vmware e1000 device. The patch is to fix the issue.

Is it possible to detect a VMware e1000 device?

> --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
>   case RTE_INTR_MODE_LEGACY:
> - if (pci_intx_mask_supported(dev)) {
> - dev_dbg(&dev->dev, "using INTX");
> - udev->info.irq_flags = IRQF_SHARED;
> - udev->info.irq = dev->irq;
> - udev->mode = RTE_INTR_MODE_LEGACY;
> - break;
> - }
> - dev_notice(&dev->dev, "PCI INTX mask not supported\n");
> +dev_dbg(&dev->dev, "using INTX");
> +udev->info.irq_flags = IRQF_SHARED;
> +udev->info.irq = dev->irq;
> +udev->mode = RTE_INTR_MODE_LEGACY;
> +break;
>   /* fall back to no IRQ */
>   case RTE_INTR_MODE_NONE:

This patch is removing the INTX support detection and the fallback to no IRQ.

[dpdk-dev] [PATCH v2] testpmd: fix build on FreeBSD

[Wu, Jingjing]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marvin Liu
> Sent: Tuesday, March 22, 2016 2:50 PM
> To: dev at dpdk.org
> Cc: Liu, Yong
> Subject: [dpdk-dev] [PATCH v2] testpmd: fix build on FreeBSD
> 
> Build log:
> /root/dpdk/app/test-pmd/cmdline.c:6687:45: error: no member named
> 's6_addr32' in 'struct in6_addr'
> rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
> 
> This is caused by macro "s6_addr32" not defined on FreeBSD and testpmd
> swap big endian parameter to host endian. Move the swap action to i40e
> ethdev will fix this issue.
> 
> Fixes: 7b1312891b69 ("ethdev: add IP in GRE tunnel")
> 
> Signed-off-by: Marvin Liu 
Acked-by: Jingjing Wu 

[dpdk-dev] [PATCH v11 2/8] ethdev: use constants for link duplex

[Zhang, Helin]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, March 18, 2016 2:09 AM
> To: marcdevel at gmail.com; Richardson, Bruce; Doherty, Declan; Ananyev,
> Konstantin; Lu, Wenzhuo; Zhang, Helin; Chen, Jing D;
> harish.patil at qlogic.com; rahul.lakkireddy at chelsio.com;
> johndale at cisco.com; vido at cesnet.cz; adrien.mazarguil at 6wind.com;
> alejandro.lucero at netronome.com
> Cc: dev at dpdk.org
> Subject: [PATCH v11 2/8] ethdev: use constants for link duplex
> 
> From: Marc Sune 
> 
> Some duplex values are replaced from 0 to half-duplex when link is down.
> 
> Some drivers are still using their own constants for duplex modes.
> 
> Signed-off-by: Marc Sune 
> ---
>  drivers/net/e1000/em_ethdev.c  | 2 +-
>  drivers/net/e1000/igb_ethdev.c | 2 +-
>  drivers/net/ixgbe/ixgbe_ethdev.c   | 2 +-
>  drivers/net/virtio/virtio_ethdev.c | 2 +-  
> drivers/net/virtio/virtio_ethdev.h |
> 2 --
>  lib/librte_ether/rte_ethdev.h  | 2 +-
>  6 files changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/e1000/em_ethdev.c
> b/drivers/net/e1000/em_ethdev.c index 58093c6..943a270 100644
> --- a/drivers/net/e1000/em_ethdev.c
> +++ b/drivers/net/e1000/em_ethdev.c
> @@ -1108,7 +1108,7 @@ eth_em_link_update(struct rte_eth_dev *dev, int
> wait_to_complete)
>   link.link_status = ETH_LINK_UP;
>   } else if (!link_check && (link.link_status == ETH_LINK_UP)) {
>   link.link_speed = 0;
> - link.link_duplex = 0;
> + link.link_duplex = ETH_LINK_HALF_DUPLEX;
>   link.link_status = ETH_LINK_DOWN;
>   }
>   rte_em_dev_atomic_write_link_status(dev, &link); diff --git
> a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c index
> 311f866..ea156ce 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -2033,7 +2033,7 @@ eth_igb_link_update(struct rte_eth_dev *dev, int
> wait_to_complete)
>   link.link_status = ETH_LINK_UP;
>   } else if (!link_check) {
>   link.link_speed = 0;
> - link.link_duplex = 0;
> + link.link_duplex = ETH_LINK_HALF_DUPLEX;
>   link.link_status = ETH_LINK_DOWN;
>   }
>   rte_igb_dev_atomic_write_link_status(dev, &link); diff --git
> a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
> index be28f7e..35dac49 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -2997,7 +2997,7 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev,
> int wait_to_complete)
> 
>   link.link_status = ETH_LINK_DOWN;
>   link.link_speed = 0;
> - link.link_duplex = 0;
> + link.link_duplex = ETH_LINK_HALF_DUPLEX;
>   memset(&old, 0, sizeof(old));
>   rte_ixgbe_dev_atomic_read_link_status(dev, &old);
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index 3ebc221..63a368a 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1401,7 +1401,7 @@ virtio_dev_link_update(struct rte_eth_dev *dev,
> __rte_unused int wait_to_complet
>   memset(&link, 0, sizeof(link));
>   virtio_dev_atomic_read_link_status(dev, &link);
>   old = link;
> - link.link_duplex = FULL_DUPLEX;
> + link.link_duplex = ETH_LINK_FULL_DUPLEX;
>   link.link_speed  = SPEED_10G;
> 
>   if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS)) { diff --git
> a/drivers/net/virtio/virtio_ethdev.h b/drivers/net/virtio/virtio_ethdev.h
> index fed9571..66423a0 100644
> --- a/drivers/net/virtio/virtio_ethdev.h
> +++ b/drivers/net/virtio/virtio_ethdev.h
> @@ -42,8 +42,6 @@
>  #define SPEED_100100
>  #define SPEED_1000   1000
>  #define SPEED_10G1
> -#define HALF_DUPLEX  1
> -#define FULL_DUPLEX  2
> 
>  #ifndef PAGE_SIZE
>  #define PAGE_SIZE 4096
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index ec8d6b1..5379bee 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -246,7 +246,7 @@ struct rte_eth_stats {
>   */
>  struct rte_eth_link {
>   uint16_t link_speed;  /**< ETH_LINK_SPEED_[10, 100, 1000, 1]
> */
> - uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX,
> FULL_DUPLEX] */
> + uint16_t link_duplex; /**< ETH_LINK_[HALF/FULL]_DUPLEX */
>   uint8_t  link_status : 1; /**< ETH_LINK_[DOWN/UP] */
>  }__attribute__((aligned(8))); /**< aligned for atomic64 read/write */
For link speed and link duplex, I'd suggest to add one more status of 'UNKNOWN'.
Because, sometimes it cannot get all the information from hardware.
For link stauts, assume it in DOWN state is acceptable, while for other two, I 
don't think so.

Currently it can be seen that a default link speed and duplex will be set if it 
cannot
get the accurate info from hardware. That's not good, and I think UNKNOWN could 
be better.

What do you think?

Thanks,
Helin

> 
> --
>

[dpdk-dev] DPDK and HW offloads

[Qiu, Michael]

On 3/22/2016 6:20 PM, Richardson, Bruce wrote:
> On Tue, Mar 22, 2016 at 05:50:28AM +, Qiu, Michael wrote:
>> On 3/21/2016 11:27 PM, Kyle Larose wrote:
>>> On Mon, Mar 21, 2016 at 10:52 AM, Bruce Richardson
>>>  wrote:
 On Sun, Mar 20, 2016 at 08:18:57PM +0100, Thomas Monjalon wrote:
> 2016-03-20 14:17, Zhang, Helin:
>> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>>> 2016-03-18 10:16, Stephen Hemminger:
 Right now, all those offload features are pretty much unusable in a
 real product without lots and lots of extra codes and huge bug
 surface. It bothers me enough that I would recommend removing much of 
 the
>>> filter/offload/ptype stuff from DPDK!
>>>
>>> One of the biggest challenge is to think about a good filtering API.
>>> The offloading has some interaction with the mbuf struct.
>>>
>>> I would like to suggest rewriting ethdev API by keeping it as is for 
>>> some time for
>>> compatibility while creating a new one. What about the prefix 
>>> dpdk_netdev_ to
>>> progressively replace rte_eth_dev?
>> I totally agree with to add new and generic APIs for user applications. 
>> But I don't
>> think we need to remove all current APIs. Generic APIs may not support 
>> all advanced
>> hardware features, while specific APIs can. Why not support all? One 
>> generic APIs for
>> common users, and others APIs for advanced users.
> Yes we cannot access to every features of a device through generic API.
> Until now we were trying to add an ethdev API for every features even if 
> it
> is used by only one driver.
> I think we should allow a direct access to the driver by the applications 
> and
> work on generic API only for common features.
 Definite +1.
 I think that we need to start pushing driver-specific functionality to get 
 exposed
 via a driver's header files. That allow users who want to extract the max
 functionality from a particular NIC to do so via those APIs calls, while 
 not
 polluting the generic ethdev layer.

>>> What sort of requirements on ABI/API compatibility would this place on
>>> the drivers? I would hope that it would be treated like any other
>>> public API within DPDK. I don't think this would be too onerous, but
>>> it would require that the drivers be designed to deal with it. (I.e.
>>> don't just expose any old internal driver function).
>> Why not to implement one simple API with variable arguments, just like
>> syscall ioctl() does. And drivers implement it's specific hardware
>> features with a feature bit param, and other needed variable arguments.
>>
>> Thanks,
>> Michael
> A very much dislike that idea. 
> * It makes the code much harder to read as you have to closely examine all the
>   parameters to work out what a function call is actually meant to do.

It's not a big deal, if we have a document.

> * It makes it much harder to see that you have an implicit dependency on a
>   specific device. Having to include a driver specific header file e.g. 
> i40e.h,
>   and call a function named e.g. i40e_do_magic_stuff(), makes it pretty 
> explicit
>   that you have a dependency on i40e-based hardware

Software does not want to bind to specific hardware I think, what about
the transportability?

> * It prevents the compiler from doing type-checking on parameters and 
> informing
>   you of little inconsistencies.

Maybe, we could do self-check for the parameters I think.

>
> For all these reasons, I prefer the device-specific functions option. However,
> at the same time, we also need to ensure we have a reasonable set of generic
> APIs so that the cases where users are forced to drop down to the lower-level
> device-specific primitives are reduced.

For software, it do not care which hardware it is, it only cares about
what ability you have.

Thanks,
Michael

> Regards,
> /Bruce
>
 On the other hand, I don't like the idea of dpdk_netdev. I think we can 
 work
 within the existing rte_eth_dev framework.

 /Bruce

>>

[dpdk-dev] [PATCH v11 4/8] ethdev: rename link speed constants

[Zhang, Helin]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, March 18, 2016 2:09 AM
> To: marcdevel at gmail.com; Richardson, Bruce; Doherty, Declan; Ananyev,
> Konstantin; Lu, Wenzhuo; Zhang, Helin; Chen, Jing D;
> harish.patil at qlogic.com; rahul.lakkireddy at chelsio.com;
> johndale at cisco.com; vido at cesnet.cz; adrien.mazarguil at 6wind.com;
> alejandro.lucero at netronome.com
> Cc: dev at dpdk.org
> Subject: [PATCH v11 4/8] ethdev: rename link speed constants
> 
> From: Marc Sune 
> 
> The speed numbers ETH_LINK_SPEED_ are renamed ETH_SPEED_NUM_.
> The prefix ETH_LINK_SPEED_ is kept for AUTONEG and will be used for bit
> flags in next patch.
> 
> Signed-off-by: Marc Sune 
> ---
>  app/test-pmd/cmdline.c| 10 +-
>  app/test/virtual_pmd.c|  2 +-
>  drivers/net/af_packet/rte_eth_af_packet.c |  2 +-
> drivers/net/bonding/rte_eth_bond_8023ad.c | 12 ++--
>  drivers/net/cxgbe/base/t4_hw.c|  8 
>  drivers/net/e1000/em_ethdev.c |  8 
>  drivers/net/e1000/igb_ethdev.c|  8 
>  drivers/net/i40e/i40e_ethdev.c| 30 +++---
>  drivers/net/i40e/i40e_ethdev_vf.c |  2 +-
>  drivers/net/ixgbe/ixgbe_ethdev.c  | 22 +++---
>  drivers/net/mpipe/mpipe_tilegx.c  |  4 ++--
>  drivers/net/nfp/nfp_net.c |  2 +-
>  drivers/net/null/rte_eth_null.c   |  2 +-
>  drivers/net/pcap/rte_eth_pcap.c   |  2 +-
>  drivers/net/ring/rte_eth_ring.c   |  2 +-
>  drivers/net/szedata2/rte_eth_szedata2.c   |  8 
>  drivers/net/vmxnet3/vmxnet3_ethdev.c  |  2 +-
>  drivers/net/xenvirt/rte_eth_xenvirt.c |  2 +-
>  lib/librte_ether/rte_ethdev.h | 29 ++---
>  19 files changed, 82 insertions(+), 75 deletions(-)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> 37be5cd..874129a 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -1001,20 +1001,20 @@ parse_and_check_speed_duplex(char *speedstr,
> char *duplexstr, uint16_t *speed)
>   }
> 
>   if (!strcmp(speedstr, "10")) {
> - *speed = ETH_LINK_SPEED_10;
> + *speed = ETH_SPEED_NUM_10M;
>   } else if (!strcmp(speedstr, "100")) {
> - *speed = ETH_LINK_SPEED_100;
> + *speed = ETH_SPEED_NUM_100M;
>   } else {
>   if (duplex != ETH_LINK_FULL_DUPLEX) {
>   printf("Invalid speed/duplex parameters\n");
>   return -1;
>   }
>   if (!strcmp(speedstr, "1000")) {
> - *speed = ETH_LINK_SPEED_1000;
> + *speed = ETH_SPEED_NUM_1G;
>   } else if (!strcmp(speedstr, "1")) {
> - *speed = ETH_LINK_SPEED_10G;
> + *speed = ETH_SPEED_NUM_10G;
>   } else if (!strcmp(speedstr, "4")) {
> - *speed = ETH_LINK_SPEED_40G;
> + *speed = ETH_SPEED_NUM_40G;
>   } else if (!strcmp(speedstr, "auto")) {
>   *speed = ETH_LINK_SPEED_AUTONEG;
>   } else {
> diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c index
> b1d40d7..b4bd2f2 100644
> --- a/app/test/virtual_pmd.c
> +++ b/app/test/virtual_pmd.c
> @@ -604,7 +604,7 @@ virtual_ethdev_create(const char *name, struct
> ether_addr *mac_addr,
>   TAILQ_INIT(&(eth_dev->link_intr_cbs));
> 
>   eth_dev->data->dev_link.link_status = ETH_LINK_DOWN;
> - eth_dev->data->dev_link.link_speed = ETH_LINK_SPEED_1;
> + eth_dev->data->dev_link.link_speed = ETH_SPEED_NUM_10G;
>   eth_dev->data->dev_link.link_duplex = ETH_LINK_FULL_DUPLEX;
> 
>   eth_dev->data->mac_addrs = rte_zmalloc(name, ETHER_ADDR_LEN,
> 0); diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
> b/drivers/net/af_packet/rte_eth_af_packet.c
> index dee7b59..641f849 100644
> --- a/drivers/net/af_packet/rte_eth_af_packet.c
> +++ b/drivers/net/af_packet/rte_eth_af_packet.c
> @@ -116,7 +116,7 @@ static const char *valid_arguments[] = {  static const
> char *drivername = "AF_PACKET PMD";
> 
>  static struct rte_eth_link pmd_link = {
> - .link_speed = 1,
> + .link_speed = ETH_SPEED_NUM_10G,
>   .link_duplex = ETH_LINK_FULL_DUPLEX,
>   .link_status = ETH_LINK_DOWN,
>  };
> diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c
> b/drivers/net/bonding/rte_eth_bond_8023ad.c
> index 1b7e93a..ac8306f 100644
> --- a/drivers/net/bonding/rte_eth_bond_8023ad.c
> +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
> @@ -711,22 +711,22 @@ link_speed_key(uint16_t speed) {
>   case ETH_LINK_SPEED_AUTONEG:
>   key_speed = 0x00;
>   break;
> - case ETH_LINK_SPEED_10:
> + case ETH_SPEED_NUM_10M:
>   key_speed = BOND_LINK_SPEED_KEY_10M;
>   break;
> -  

[dpdk-dev] [PATCH] ixgbe: fix vector RX can't always set packet_type properly

[Liang, Cunming]

Hi,

On 3/22/2016 10:30 PM, Konstantin Ananyev wrote:
> Fixes: 39625417585 ("mbuf: redefine packet type")
>
> Current vector RX can't always set packet_type properly.
> To be more specific:
> a) it never sets RTE_PTYPE_L2_ETHER
> b) it doesn't handle tunnel ipv4/ipv6 case correctly.
> c) it doesn't check is IXGBE_RXDADV_PKTTYPE_ETQF set or not.
> While a) is pretty easy to fix, b) and c) are not that straightforward
> in terms of SIMD ops (specially b).
> So far I wasn't able to make vRX support packet_type properly without
> noticeable performance loss.
> So for now, just remove that functionality at all from vector RX and
> update dev_supported_ptypes_get().
>
> Signed-off-by: Konstantin Ananyev 
> ---
>   drivers/net/ixgbe/ixgbe_ethdev.c   |  4 +---
>   drivers/net/ixgbe/ixgbe_rxtx_vec.c | 34 +++---
>   2 files changed, 12 insertions(+), 26 deletions(-)
>
>
Acked-by: Liang Cunming 

[dpdk-dev] [PATCH] i40e: fix ipv6 TSO issue for tx function

[Zhe Tao]

On Tue, Mar 22, 2016 at 09:38:55PM +0800, Ananyev, Konstantin wrote:
> Hi, 
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhe Tao
> > Sent: Tuesday, March 22, 2016 1:14 PM
> > To: dev at dpdk.org
> > Cc: Tao, Zhe
> > Subject: [dpdk-dev] [PATCH] i40e: fix ipv6 TSO issue for tx function
> > 
> > Issue:
> > when using the following CLI in testpmd to enable ipv6 TSO feature
> > =
> > set verbose 1
> > csum set ip hw 0
> > csum set udp hw 0
> > csum set tcp hw 0
> > csum set sctp hw 0
> > csum set outer-ip hw 0
> > csum parse_tunnel on 0
> > tso set 800 0
> > set fwd csum
> > 
> > start
> > =
> > 
> > We will not get we want, the ipv6 packets sent out from IXIA can be 
> > received by
> > i40e, but cannot forward to another port.
> > The root cause is when HW doing the TSO offload for packets, it not only 
> > depends
> > on the context descriptor to define the MSS and TSO payload size, it also
> > need to know whether this packets is ipv4 or ipv6, ipv4 need the header 
> > csum,
> > but ipv6 doesn't need the csum. We need to use the i40e_txd_enable_checksum 
> > to
> > set the ipv6 type flag into the data descriptor when the packets are for
> > ipv6 TSO.
> > 
> > Fixes: e3f0151f (i40e: enable Tx checksum only for offloaded packets)
> > 
> > Signed-off-by: Zhe Tao 
> > ---
> >  drivers/net/i40e/i40e_rxtx.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> > index 1488f2f..ffd6dba 100644
> > --- a/drivers/net/i40e/i40e_rxtx.c
> > +++ b/drivers/net/i40e/i40e_rxtx.c
> > @@ -1545,6 +1545,7 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf 
> > **tx_pkts, uint16_t nb_pkts)
> > uint16_t slen;
> > uint64_t buf_dma_addr;
> > union i40e_tx_offload tx_offload = {0};
> > +   bool enable_checksum = 0;
> > 
> > txq = tx_queue;
> > sw_ring = txq->sw_ring;
> > @@ -1620,7 +1621,13 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf 
> > **tx_pkts, uint16_t nb_pkts)
> > 
> > /* Enable checksum offloading */
> > cd_tunneling_params = 0;
> > -   if (ol_flags & I40E_TX_CKSUM_OFFLOAD_MASK) {
> > +   /* Check whether need to do checksum or not */
> > +   if ((ol_flags & I40E_TX_CKSUM_OFFLOAD_MASK) ||
> > +   ((ol_flags & PKT_TX_IPV6) && (ol_flags & PKT_TX_TCP_SEG))) {
> > +   enable_checksum = 1;
> > +   }
> > +
> > +   if (enable_checksum) {
> > i40e_txd_enable_checksum(ol_flags, &td_cmd, &td_offset,
> > tx_offload, &cd_tunneling_params);
> > }
> 
> 
> Wonder can't we just include PKT_TX_TCP_SEG into I40E_TX_CKSUM_OFFLOAD_MASK,
> and keep i40e_xmit_pkts() unchanged?
> Konstantin
agreed with you, checked the code again, the logic for ipv4 TSO also has some 
problem,
so should add PKT_TX_TCP_SEG flag for both ipv4&ipv6 TSO to the offload mask.

> 

[dpdk-dev] [PATCH] fm10k: conditionally disable RSS during device initialization

[Chen, Jing D]

Hi,

> -Original Message-
> From: Michael Frasca [mailto:michael.frasca at oracle.com]
> Sent: Wednesday, March 23, 2016 12:58 AM
> To: Chen, Jing D
> Cc: dev at dpdk.org; Michael Frasca
> Subject: [PATCH] fm10k: conditionally disable RSS during device initialization
> 
> If the provided configuration does not call for RSS, then RSS is
> explicitly disabled. Without this change, the device continues to
> operate under the previous RSS configuration.
> 
> Fixes: 57033cdf8fdc ("fm10k: add PF RSS")
> 
> Signed-off-by: Michael Frasca 
Acked-by : Jing Chen 

[dpdk-dev] [dpdk-dev, 1/3] rte_interrupts: add rte_eal_intr_exit to shut down IRQ thread

[Liang, Cunming]

Hi Mattew,

Thank you for your time.

On 3/22/2016 3:39 PM, Matthew Hall wrote:
> On Mon, Mar 21, 2016 at 03:58:44PM +0800, Liang, Cunming wrote:
>> the default termination handler
> I am not so experienced with this "default termination handler". Can someone
> clarify what it is so I could comment better about it?
For example, you're handling SIGINT. After finishing your necessary app 
cleanup, then 'signal(SIGINT, SIG_DFL); raise(SIGINT);'.
The default signal handler can terminate the interrupt thread.

>
>> If EINTR is caused by some non-term purpose signals, are you going
>> to exit the interrupt thread any way?
> We should discuss what makes sense here. I'm just trying to get some things
> working and finding EINTR was getting eaten and causing infinite looping.
SIGINT/SIGTERM causes EINTR return, while SIGUSR1 also can cause the 
EINTR return. For the dedicated EAL interrupt thread, it won't be 
expected to exit for all kinds of the cause.
On this view, I'm in favor of your patch which cancel the interrupt 
thread, but don't directly return by the EINTR.

>
>> Without setting 'PTHREAD_CREATE_DETACHED' won't cause the infinite
>> loop. However by using pthread_cancel to terminate the thread,
>> indeed it's necessary to set 'PTHREAD_CREATE_DETACHED'.
> My general understanding is that PTHREAD_CREATE_DETACHED should be used for
> any thread, which should not keep a process open by itself if it is executing,
> i.e. a "daemon thread". I believe the interrupt thread qualifies as such a
> thread if I have understood everything right (which is hard to promise when
> you only work in DPDK in spare time).
>
>> It looks like 'pthread_cancel' is the right way and I saw it
>> continue keeps current EINTR handling in EAL interrupt thread.
> It is one option. Depending what makes the most sense.
>
>> 1. Can you explain and add patch comments why default signal handler
>> is not good enough to terminate app.
> Yes if someone call tell me more about what it is so I can check it.
>
>> 2. I propose to add addition comments on rte_epoll_wait() API
>> description. For any signal, it causes an error return, user needs
>> to handle.
> Agreed.
>
>> 3. Will you do a favorite to add 'PTHREAD_CREATE_DETACHED' to all
>> EAL pthread too.
> As a spare time developer I am a bit conservative about too large of a scope
> and messing with code for other threads or features I didn't personally use or
> test. This is because I don't have the same QA resources as Intel / 6WIND /
> etc.. Some help from a full time developer would be great here.
All right, reasonable to me.

>
>> Cunming
> Matthew.

[dpdk-dev] testpmd could not start up with vmxnet3 port

[Ding, HengX]

Testpmd will fail to start up with vmxnet3 port. You can reproduce this issue 
follow these steps:


1.   Right click your VM and click edit settings

2.   Click "Add..." button.

3.   Choose Ethernet Adapter and click next

4.   Choose vmxnet3 as the Adapter Type, and select a network connection. 
Click next and finish config.

5.   Add another vmxnet3 port to VM follow step 1-4.

6.   Compile dpdk, bind vmxnet3 port to igb_uio and run testpmd: 
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -- -i


Here is the  bisect result:
f598fd063bb17eba9310ff48164014d09f40c759 is the first bad commit
commit f598fd063bb17eba9310ff48164014d09f40c759
Author: Yong Wang 
Date:   Tue Jan 12 18:08:35 2016 -0800

vmxnet3: add Tx L4 checksum offload

Support TCP/UDP checksum offload.

Signed-off-by: Yong Wang 
Acked-by: Stephen Hemminger 

:04 04 4524306879c4c0093ac54b0c66b8a8f895af8337 
8e1473e7cc9052003abe6caae8e8b232810972d4 M  doc
:04 04 ad9cd888717dd976a43cfe05aaf33f3b83a2f7bc 
9fbd6fefb95f67bb407bb9a7efcf39e707ab21a7 M  drivers

[dpdk-dev] [PATCH v2] i40e: fix ipv6 TSO issue for tx function

[Zhe Tao]

Issue:
when using the following CLI in testpmd to enable ipv6 TSO feature
=
set verbose 1
csum set ip hw 0
csum set udp hw 0
csum set tcp hw 0
csum set sctp hw 0
csum set outer-ip hw 0
csum parse_tunnel on 0
tso set 800 0
set fwd csum

start
=

We will not get we want, the ipv6 packets sent out from IXIA can be received by
i40e, but cannot forward to another port.
The root cause is when HW doing the TSO offload for packets, it not only depends
on the context descriptor to define the MSS and TSO payload size, it also
need to know whether this packets is ipv4 or ipv6, ipv4 need the header csum,
but ipv6 doesn't need the csum. We need to use the i40e_txd_enable_checksum to
set the ipv6 type flag into the data descriptor when the packets are for
ipv6 TSO.  

Fixes: e3f0151f (i40e: enable Tx checksum only for offloaded packets)

Signed-off-by: Zhe Tao 
---
v2: change condition check for ipv6 TSO checksum offload
use a more clear check method which include both ipv4 & ipv6 TSO


 drivers/net/i40e/i40e_rxtx.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 1488f2f..3422ec2 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -73,9 +73,16 @@

 #define I40E_TXD_CMD (I40E_TX_DESC_CMD_EOP | I40E_TX_DESC_CMD_RS)

+/* need to add the TSO flag to the checksum offload mask
+ * even the packets like ipv6 doesn't need the checksum for ip header
+ * but the FW need to know whether this TCP packets is ipv4 or ipv6,
+ * so add this kind of information in the checksum offload field in the
+ * normal data descriptor.
+ */
 #define I40E_TX_CKSUM_OFFLOAD_MASK (\
PKT_TX_IP_CKSUM |\
PKT_TX_L4_MASK | \
+   PKT_TX_TCP_SEG | \
PKT_TX_OUTER_IP_CKSUM)

 static uint16_t i40e_xmit_pkts_simple(void *tx_queue,
-- 
2.1.4

[dpdk-dev] vmxnet3 can't work now and found the patch which broke it.

[Ding, HengX]

Testpmd will fail to start up with vmxnet3 port. You can reproduce this issue 
follow these steps:


1.   Right click your VM and click edit settings

2.   Click "Add..." button.

3.   Choose Ethernet Adapter and click next

4.   Choose vmxnet3 as the Adapter Type, and select a network connection. 
Click next and finish config.

5.   Add another vmxnet3 port to VM follow step 1-4.

6.   Compile dpdk, bind vmxnet3 port to igb_uio and run testpmd: 
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -- -i


Here is the  bisect result:
f598fd063bb17eba9310ff48164014d09f40c759 is the first bad commit
commit f598fd063bb17eba9310ff48164014d09f40c759
Author: Yong Wang 
Date:   Tue Jan 12 18:08:35 2016 -0800

vmxnet3: add Tx L4 checksum offload

Support TCP/UDP checksum offload.

Signed-off-by: Yong Wang 
Acked-by: Stephen Hemminger 

:04 04 4524306879c4c0093ac54b0c66b8a8f895af8337 
8e1473e7cc9052003abe6caae8e8b232810972d4 M  doc
:04 04 ad9cd888717dd976a43cfe05aaf33f3b83a2f7bc 
9fbd6fefb95f67bb407bb9a7efcf39e707ab21a7 M  drivers

[dpdk-dev] testpmd could not start up with vmxnet3 port

[Xu, Qian Q]

It's a regression, vmxnet3 can work with dpdk2.2, but now it can't work well.
Yong,
Heng found that your patch may be the first one to break the function, could 
you check it? Thx.

Thanks
Qian

From: Ding, HengX
Sent: Wednesday, March 23, 2016 11:28 AM
To: yongwang at vmware.com
Cc: Xu, Qian Q; dev at dpdk.org
Subject: testpmd could not start up with vmxnet3 port

Testpmd will fail to start up with vmxnet3 port. You can reproduce this issue 
follow these steps:


1.   Right click your VM and click edit settings

2.   Click "Add..." button.

3.   Choose Ethernet Adapter and click next

4.   Choose vmxnet3 as the Adapter Type, and select a network connection. 
Click next and finish config.

5.   Add another vmxnet3 port to VM follow step 1-4.

6.   Compile dpdk, bind vmxnet3 port to igb_uio and run testpmd: 
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -- -i


Here is the  bisect result:
f598fd063bb17eba9310ff48164014d09f40c759 is the first bad commit
commit f598fd063bb17eba9310ff48164014d09f40c759
Author: Yong Wang mailto:yongwang at vmware.com>>
Date:   Tue Jan 12 18:08:35 2016 -0800

vmxnet3: add Tx L4 checksum offload

Support TCP/UDP checksum offload.

Signed-off-by: Yong Wang mailto:yongwang at 
vmware.com>>
Acked-by: Stephen Hemminger mailto:stephen 
at networkplumber.org>>

:04 04 4524306879c4c0093ac54b0c66b8a8f895af8337 
8e1473e7cc9052003abe6caae8e8b232810972d4 M  doc
:04 04 ad9cd888717dd976a43cfe05aaf33f3b83a2f7bc 
9fbd6fefb95f67bb407bb9a7efcf39e707ab21a7 M  drivers

[dpdk-dev] testpmd could not start up with vmxnet3 port

[Yong Wang]

From: "Xu, Qian Q" mailto:qian.q...@intel.com>>
Date: Tuesday, March 22, 2016 at 8:31 PM
To: "Ding, HengX" mailto:hengx.ding at intel.com>>, 
Yong mailto:yongwang at vmware.com>>
Cc: "dev at dpdk.org" mailto:dev at 
dpdk.org>>
Subject: RE: testpmd could not start up with vmxnet3 port

It?s a regression, vmxnet3 can work with dpdk2.2, but now it can?t work well.
Yong,
Heng found that your patch may be the first one to break the function, could 
you check it? Thx.

Thanks
Qian

From: Ding, HengX
Sent: Wednesday, March 23, 2016 11:28 AM
To: yongwang at vmware.com
Cc: Xu, Qian Q; dev at dpdk.org
Subject: testpmd could not start up with vmxnet3 port

Testpmd will fail to start up with vmxnet3 port. You can reproduce this issue 
follow these steps:


1.   Right click your VM and click edit settings

2.   Click ?Add?? button.

3.   Choose Ethernet Adapter and click next

4.   Choose vmxnet3 as the Adapter Type, and select a network connection. 
Click next and finish config.

5.   Add another vmxnet3 port to VM follow step 1-4.

6.   Compile dpdk, bind vmxnet3 port to igb_uio and run testpmd: 
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -- -i


Here is the  bisect result:
f598fd063bb17eba9310ff48164014d09f40c759 is the first bad commit
commit f598fd063bb17eba9310ff48164014d09f40c759
Author: Yong Wang mailto:yongwang at vmware.com>>
Date:   Tue Jan 12 18:08:35 2016 -0800

vmxnet3: add Tx L4 checksum offload

Support TCP/UDP checksum offload.

Signed-off-by: Yong Wang mailto:yongwang at 
vmware.com>>
Acked-by: Stephen Hemminger mailto:stephen 
at networkplumber.org>>

:04 04 4524306879c4c0093ac54b0c66b8a8f895af8337 
8e1473e7cc9052003abe6caae8e8b232810972d4 M  doc
:04 04 ad9cd888717dd976a43cfe05aaf33f3b83a2f7bc 
9fbd6fefb95f67bb407bb9a7efcf39e707ab21a7 M  drivers

Currently vmxnet3?s default_txconf.txq_flags is set to the following, which is 
used by testpmd
as there is no explicit txconf passed when initializing tx queue:

dev_info->default_txconf.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS;

With the referred patch that introduced l4 cksum offload, we should update the 
default txq
flags check accordingly.  Heng, can you post the error logs to confirm this is 
indeed the cause
of the error you reported?

Related to this, I saw that the check for NOMULTISEGS has been removed and the 
check for
NOVLANOFF was never implemented.  Should we just remove the offload flags check 
as well
as I don?t see much value of this check.  Basically we know that the device 
does not support
certain offload and we have to set those flags to let the device initialize. 
But doing this does
nothing to prevent users to request these non-supported offload.  I also saw 
another thread
discussing better device capability APIs and hopefully this will not be needed 
then.

[dpdk-dev] testpmd could not start up with vmxnet3 port

[Yong Wang]

From: "Xu, Qian Q" mailto:qian.q...@intel.com>>
Date: Tuesday, March 22, 2016 at 8:31 PM
To: "Ding, HengX" mailto:hengx.ding at intel.com>>, 
Yong mailto:yongwang at vmware.com>>
Cc: "dev at dpdk.org" mailto:dev at 
dpdk.org>>
Subject: RE: testpmd could not start up with vmxnet3 port

It?s a regression, vmxnet3 can work with dpdk2.2, but now it can?t work well.
Yong,
Heng found that your patch may be the first one to break the function, could 
you check it? Thx.

Thanks
Qian

From: Ding, HengX
Sent: Wednesday, March 23, 2016 11:28 AM
To: yongwang at vmware.com
Cc: Xu, Qian Q; dev at dpdk.org
Subject: testpmd could not start up with vmxnet3 port

Testpmd will fail to start up with vmxnet3 port. You can reproduce this issue 
follow these steps:


1.   Right click your VM and click edit settings

2.   Click ?Add?? button.

3.   Choose Ethernet Adapter and click next

4.   Choose vmxnet3 as the Adapter Type, and select a network connection. 
Click next and finish config.

5.   Add another vmxnet3 port to VM follow step 1-4.

6.   Compile dpdk, bind vmxnet3 port to igb_uio and run testpmd: 
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -- -i


Here is the  bisect result:
f598fd063bb17eba9310ff48164014d09f40c759 is the first bad commit
commit f598fd063bb17eba9310ff48164014d09f40c759
Author: Yong Wang mailto:yongwang at vmware.com>>
Date:   Tue Jan 12 18:08:35 2016 -0800

vmxnet3: add Tx L4 checksum offload

Support TCP/UDP checksum offload.

Signed-off-by: Yong Wang mailto:yongwang at 
vmware.com>>
Acked-by: Stephen Hemminger mailto:stephen 
at networkplumber.org>>

:04 04 4524306879c4c0093ac54b0c66b8a8f895af8337 
8e1473e7cc9052003abe6caae8e8b232810972d4 M  doc
:04 04 ad9cd888717dd976a43cfe05aaf33f3b83a2f7bc 
9fbd6fefb95f67bb407bb9a7efcf39e707ab21a7 M  drivers

Resend due to formatting issues.

Currently vmxnet3?s default_txconf.txq_flags is set to the following, which is 
used by testpmd
as there is no explicit txconf passed when initializing tx queue:

dev_info->default_txconf.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS;

With the referred patch that introduced l4 cksum offload, we should update the 
default txq
flags check accordingly.  Heng, can you post the error logs to confirm this is 
indeed the cause
of the error you reported?

Related to this, I saw that the check for NOMULTISEGS has been removed and the 
check for
NOVLANOFF was never implemented.  Should we just remove the offload flags check 
as well
as I don?t see much value of this check.  Basically we know that the device 
does not support
certain offload and we have to set those flags to let the device initialize. 
But doing this does
nothing to prevent users to request these non-supported offload.  I also saw 
another thread
discussing better device capability APIs and hopefully this will not be needed 
then

[dpdk-dev] testpmd could not start up with vmxnet3 port

[Ding, HengX]

Testpmd output is as below:

./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --  -i
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 0 on socket 0
EAL: Detected lcore 3 as core 1 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 4 lcore(s)
EAL: Probing VFIO support...
EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or directory)
EAL: VFIO modules not loaded, skipping VFIO support...
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0x80 bytes
EAL: Virtual area found at 0x7ff3c560 (size = 0x80)
EAL: Ask a virtual area of 0x60 bytes
EAL: Virtual area found at 0x7ff3c4e0 (size = 0x60)
EAL: Ask a virtual area of 0x5680 bytes
EAL: Virtual area found at 0x7ff36e40 (size = 0x5680)
EAL: Ask a virtual area of 0x2800 bytes
EAL: Virtual area found at 0x7ff34620 (size = 0x2800)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7ff345e0 (size = 0x20)
EAL: Ask a virtual area of 0x60 bytes
EAL: Virtual area found at 0x7ff34560 (size = 0x60)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7ff34520 (size = 0x20)
EAL: Requesting 1024 pages of size 2MB from socket 0
EAL: TSC frequency is ~2793268 KHz
EAL: Master lcore 0 is ready (tid=c62c9940;cpuset=[0])
EAL: lcore 3 is ready (tid=435f0700;cpuset=[3])
EAL: lcore 1 is ready (tid=445f2700;cpuset=[1])
EAL: lcore 2 is ready (tid=43df1700;cpuset=[2])
EAL: PCI device :03:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   Not managed by a supported kernel driver, skipped
EAL: PCI device :0b:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   PCI memory mapped at 0x7ff3c5e0
EAL:   PCI memory mapped at 0x7ff3c5e01000
EAL:   PCI memory mapped at 0x7ff3c5e02000
EAL: PCI device :13:00.0 on NUMA socket -1
EAL:   probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL:   PCI memory mapped at 0x7ff3c5e04000
EAL:   PCI memory mapped at 0x7ff3c5e05000
EAL:   PCI memory mapped at 0x7ff3c5e06000
Interactive-mode selected
Configuring Port 0 (socket 0)
Fail to configure port 0 tx queues
EAL: Error - exiting with code: 1
  Cause: Start ports failed

From: Yong Wang [mailto:yongw...@vmware.com]
Sent: Wednesday, March 23, 2016 1:58 PM
To: Xu, Qian Q; Ding, HengX
Cc: dev at dpdk.org; Stephen Hemminger
Subject: Re: testpmd could not start up with vmxnet3 port


From: "Xu, Qian Q" mailto:qian.q...@intel.com>>
Date: Tuesday, March 22, 2016 at 8:31 PM
To: "Ding, HengX" mailto:hengx.ding at intel.com>>, 
Yong mailto:yongwang at vmware.com>>
Cc: "dev at dpdk.org" mailto:dev at 
dpdk.org>>
Subject: RE: testpmd could not start up with vmxnet3 port

It?s a regression, vmxnet3 can work with dpdk2.2, but now it can?t work well.
Yong,
Heng found that your patch may be the first one to break the function, could 
you check it? Thx.

Thanks
Qian

From: Ding, HengX
Sent: Wednesday, March 23, 2016 11:28 AM
To: yongwang at vmware.com
Cc: Xu, Qian Q; dev at dpdk.org
Subject: testpmd could not start up with vmxnet3 port

Testpmd will fail to start up with vmxnet3 port. You can reproduce this issue 
follow these steps:


1.   Right click your VM and click edit settings

2.   Click ?Add?? button.

3.   Choose Ethernet Adapter and click next

4.   Choose vmxnet3 as the Adapter Type, and select a network connection. 
Click next and finish config.

5.   Add another vmxnet3 port to VM follow step 1-4.

6.   Compile dpdk, bind vmxnet3 port to igb_uio and run testpmd: 
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -- -i


Here is the  bisect result:
f598fd063bb17eba9310ff48164014d09f40c759 is the first bad commit
commit f598fd063bb17eba9310ff48164014d09f40c759
Author: Yong Wang mailto:yongwang at vmware.com>>
Date:   Tue Jan 12 18:08:35 2016 -0800

vmxnet3: add Tx L4 checksum offload

Support TCP/UDP checksum offload.

Signed-off-by: Yong Wang mailto:yongwang at 
vmware.com>>
Acked-by: Stephen Hemminger mailto:stephen 
at networkplumber.org>>

:04 04 4524306879c4c0093ac54b0c66b8a8f895af8337 
8e1473e7cc9052003abe6caae8e8b232810972d4 M  doc
:04 04 ad9cd888717dd976a43cfe05aaf33f3b83a2f7bc 
9fbd6fefb95f67bb407bb9a7efcf39e707ab21a7 M  drivers

Resend due to formatting issues.

Currently vmxnet3?s default_txconf.txq_flags is set to the following, which is 
used by testpmd
as there is no explicit txconf passed when initializing tx queue:

dev_info->default_txconf.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS;

With the referred patch that introduced l4 cksum offload, we should update the 
default txq
flags check accordingly.  Heng, can you post the error logs to confirm this is 
indeed the cause
of t

[dpdk-dev] Issues with openvswitch2.5+dpdk2.2+kvm/virtio-pci

[Christian Ehrhardt]

On Tue, Mar 22, 2016 at 9:47 PM, Daniele Di Proietto  wrote:

> Hi Christian,
>
> thanks for the report.  I've managed to reproduce the problem and I
> observed two separate issues:
>
> 1) short version: it appears to be a problem in DPDK 2.2 and it should be
> fixed by 9a0615af7746("virtio: fix restart"), now on master.
>
[...]

> It appears that simply backporting 9a0615af7746("virtio: fix restart")
> fixes the issue.
>

Yeah debugging it I came to the double configuration as cause as well
yesterday.
Eventually I saw that virtqueue->vq_ring structs got reallocated but stayed
zeroed out by the second call.

I didn't realize there was a fix for it already - thanks so much for
pointing it out.
I'll give a backport a try and let you know if it worked.



> 2) When ovs-vswitchd is started with --monitor, there will be a parent
> process (the monitor) that simply restarts the child if it crashes, while
> the child does the actual ovs-vswitchd job.
>
> It appears that the monitor feature is broken with DPDK, because the DPDK
> library is wrongly initialized in the parent process.  If the child
> crashes, all the DPDK memzones are preserved, meaning that new allocations
> will likely fail.
>
> The fix for this is calling rte_eal_init() in the child process, after
> parsing other ovs-vswitchd command line options. This is done (among other
> things) in Aaron's series currently under review:
>
> http://openvswitch.org/pipermail/dev/2016-March/067422.html
>
> I think we need a separate fix for branch-2.5.
>

Yeah I was on discussing and testing that series already as the series was
also related to a socket ownership/permission issue (back in time).
http://openvswitch.org/pipermail/dev/2015-December/063567.html
I think eventually we need separate fixes for both on the branch-2.5

[...]

[dpdk-dev] [PATCH v11 4/8] ethdev: rename link speed constants

[Thomas Monjalon]

2016-03-23 02:52, Zhang, Helin:
> >  struct rte_eth_conf {
> >   uint16_t link_speed;
> 100G support?
> Uint16_t -> uint32_t to support 100G?

Yes, see next patches.

[dpdk-dev] [PATCH v11 2/8] ethdev: use constants for link duplex

[Thomas Monjalon]

2016-03-23 02:44, Zhang, Helin:
> >  struct rte_eth_link {
> >   uint16_t link_speed;  /**< ETH_LINK_SPEED_[10, 100, 1000, 1]
> > */
> > - uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX,
> > FULL_DUPLEX] */
> > + uint16_t link_duplex; /**< ETH_LINK_[HALF/FULL]_DUPLEX */
> >   uint8_t  link_status : 1; /**< ETH_LINK_[DOWN/UP] */
> >  }__attribute__((aligned(8))); /**< aligned for atomic64 read/write */
> For link speed and link duplex, I'd suggest to add one more status of 
> 'UNKNOWN'.
> Because, sometimes it cannot get all the information from hardware.
> For link stauts, assume it in DOWN state is acceptable, while for other two, 
> I don't think so.
> 
> Currently it can be seen that a default link speed and duplex will be set if 
> it cannot
> get the accurate info from hardware. That's not good, and I think UNKNOWN 
> could be better.
> 
> What do you think?

OK, please provide a patch on top of this one to set ETH_LINK_UNKNOWN_DUPLEX
in the drivers where appropriate.

[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring

[Thomas Monjalon]

2016-03-23 01:18, Xu, Qian Q:
> We have tested with intel nic and found port can't be started for all
> nics:ixgbe/i40e/igb/bonding, see attached mail for more details.
> Please check and fix it. 

Thanks for testing.

This patchset was in the air for several months but unfortunately there was
no test of Intel devices until now.
Please Intel drivers maintainers, help to fix it quickly.
Thanks

[dpdk-dev] [PATCH v5 1/9] ethdev: extend flow director for input selection

[Thomas Monjalon]

2016-03-23 00:42, Wu, Jingjing:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > 2016-03-21 14:18, Jingjing Wu:
> > > This patch added RTE_ETH_INPUT_SET_L3_IP4_TTL,
> > > RTE_ETH_INPUT_SET_L3_IP6_HOP_LIMITS input field type and extended
> > > struct rte_eth_ipv4_flow and rte_eth_ipv6_flow to support filtering by
> > > tos, protocol and ttl.
> > [...]
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > @@ -22,10 +22,6 @@ Deprecation Notices
> > >  * The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
> > >must be updated to support 100G link and to have a cleaner link speed
> > API.
> > >
> > > -* ABI changes are planned for struct rte_eth_fdir_flow in order to
> > > support
> > > -  extend flow director's input set. The release 2.2 does not contain
> > > these ABI
> > > -  changes, but release 2.3 will, and no backwards compatibility is 
> > > planned.
> > 
> > The changed structures are part of rte_eth_fdir_flow.
> > So this deprecation notice apply to this patch.
> > 
> > >  * ABI changes are planned for rte_eth_ipv4_flow and rte_eth_ipv6_flow
> > to
> > >include more fields to be matched against. The release 2.2 does not
> > >contain these ABI changes, but release 2.3 will.
> > 
> > These are the structures changed in this patch.
> > I think this section must be also removed.
> 
> This deprecation notice is not raised by me. It is raised by rahul.lakkireddy 
> at chelsio.com at commit 954f1545a1ab.
> So, I'm not sure if it is OK for me to remove it in my patch.

It does not matter who raised the notice.
Your patch match with it. Please remove it.

[dpdk-dev] [PATCH] ethdev: fix rte_eth_dev_xstats_get with NULL

[Olivier Matz]

Hi Stephen,

On 03/22/2016 11:09 PM, Stephen Hemminger wrote:
> Normal usage of rte_eth_dev_xstats_get is to call twice. The
> first time the function is called with portid, xstats = NULL
> and n = 0; this returns the number of entries in the statistics
> table that need to be allocated.
> 
> The problem is that the routine adds a count value to NULL (0)
> and assumes that this is a valid pointer (it isn't). Device drivers
> all have a check for NULL, and this no longer matches.
> 
> Bug was introduced by commit d4fef8b0d5e5
> ("ethdev: expose generic and driver specific stats in xstats")
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  lib/librte_ether/rte_ethdev.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index db35102..8721a6b 100644
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -1495,8 +1495,9 @@ rte_eth_xstats_get(uint8_t port_id, struct 
> rte_eth_xstats *xstats,
>   /* Retrieve the xstats from the driver at the end of the
>* xstats struct.
>*/
> - xcount = (*dev->dev_ops->xstats_get)(dev, &xstats[count],
> -  (n > count) ? n - count : 0);
> + xcount = (*dev->dev_ops->xstats_get)(dev,
> +  xstats ? xstats + count : NULL,
> +  (n > count) ? n - count : 0);
>  
>   if (xcount < 0)
>   return xcount;
> 


Acked-by: Olivier Matz 


Just one comment: I think the driver should not rely on the pointer
value, but on the count. From the documentation of rte_eth_xstats_get(),
the function returns a:

  "positive value higher than n: error, the given statistics table
   is too small. The return value corresponds to the size that should
   be given to succeed. The entries in the table are not valid and
   shall not be used by the caller."

So maybe it should be also fixed in the driver you are talking about.


Thanks,
Olivier

[dpdk-dev] [PATCH v2] testpmd: fix build on FreeBSD

[Liu, Yong]

> -Original Message-
> From: Qiu, Michael
> Sent: Tuesday, March 22, 2016 5:05 PM
> To: Liu, Yong; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] testpmd: fix build on FreeBSD
> 
> On 3/22/2016 2:51 PM, Marvin Liu wrote:
> > Build log:
> > /root/dpdk/app/test-pmd/cmdline.c:6687:45: error: no member named
> > 's6_addr32' in 'struct in6_addr'
> > rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
> >
> > This is caused by macro "s6_addr32" not defined on FreeBSD and testpmd
> > swap big endian parameter to host endian. Move the swap action to i40e
> > ethdev will fix this issue.
> >
> > Fixes: 7b1312891b69 ("ethdev: add IP in GRE tunnel")
> >
> > Signed-off-by: Marvin Liu 
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> > index 9d52b8c..4f3d1e4 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -6678,14 +6678,12 @@ cmd_tunnel_filter_parsed(void *parsed_result,
> >
> > if (res->ip_value.family == AF_INET) {
> > tunnel_filter_conf.ip_addr.ipv4_addr =
> > -   rte_be_to_cpu_32(res->ip_value.addr.ipv4.s_addr);
> > +   res->ip_value.addr.ipv4.s_addr;
> > tunnel_filter_conf.ip_type = RTE_TUNNEL_IPTYPE_IPV4;
> > } else {
> > -   int i;
> > -   for (i = 0; i < 4; i++) {
> > -   tunnel_filter_conf.ip_addr.ipv6_addr[i] =
> > -   rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
> > -   }
> > +   memcpy(&(tunnel_filter_conf.ip_addr.ipv6_addr),
> > +   &(res->ip_value.addr.ipv6),
> > +   sizeof(struct in6_addr));
> > tunnel_filter_conf.ip_type = RTE_TUNNEL_IPTYPE_IPV6;
> > }
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> b/drivers/net/i40e/i40e_ethdev.c
> > index 10e0d38..43c2d5c 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -6015,6 +6015,7 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
> > uint8_t add)
> >  {
> > uint16_t ip_type;
> > +   uint32_t ipv4_addr;
> > uint8_t i, tun_type = 0;
> > /* internal varialbe to convert ipv6 byte order */
> > uint32_t convert_ipv6[4];
> > @@ -6040,14 +6041,15 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
> > pfilter->inner_vlan = rte_cpu_to_le_16(tunnel_filter->inner_vlan);
> > if (tunnel_filter->ip_type == RTE_TUNNEL_IPTYPE_IPV4) {
> > ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV4;
> > +   ipv4_addr = rte_be_to_cpu_32(tunnel_filter-
> >ip_addr.ipv4_addr);
> 
> As I checked "ipv4_addr" is the host Endian, so does it need to covert
> again? Maybe I'm wrong.
> 

Michael,
This logic is for i40e API required little endian. Variable "ipv4_addr" parsed 
by cmdline library has been in big endian.
To fulfill the special requirement of admin queue, i40e drive will do the swap.

> Thanks,
> Michael
> > rte_memcpy(&pfilter->ipaddr.v4.data,
> > -   &rte_cpu_to_le_32(tunnel_filter-
> >ip_addr.ipv4_addr),
> > +   &rte_cpu_to_le_32(ipv4_addr),
> > sizeof(pfilter->ipaddr.v4.data));
> > } else {
> > ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV6;
> > for (i = 0; i < 4; i++) {
> > convert_ipv6[i] =
> > -   rte_cpu_to_le_32(tunnel_filter->ip_addr.ipv6_addr[i]);
> > +   rte_cpu_to_le_32(rte_be_to_cpu_32(tunnel_filter-
> >ip_addr.ipv6_addr[i]));
> > }
> > rte_memcpy(&pfilter->ipaddr.v6.data, &convert_ipv6,
> > sizeof(pfilter->ipaddr.v6.data));

[dpdk-dev] [PATCH] mlx5: fix packet padding macro check

[Adrien Mazarguil]

All instances of HAVE_EXP_CREATE_WQ_FLAG_RX_END_PADDING were not replaced by
HAVE_VERBS_RX_END_PADDING during a rework of the original patch, effectively
preventing this feature from being used.

Fixes: 89ed2405447d ("mlx5: add support for HW packet padding")

Unfortunately I did not catch this earlier (one should avoid last minute
changes).

Bruce, since the above commit is currently only present in your tree, can
you merge this fix with it during your next rebase? I do not mind keeping
a separate fix but the commit ID will have to be updated later. Thanks.

Adrien Mazarguil (1):
  mlx5: fix packet padding macro check

 drivers/net/mlx5/mlx5.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.1.4

[dpdk-dev] [PATCH] mlx5: fix packet padding macro check

[Adrien Mazarguil]

All instances of HAVE_EXP_CREATE_WQ_FLAG_RX_END_PADDING were not replaced by
HAVE_VERBS_RX_END_PADDING during a rework of the original patch, effectively
preventing this feature from being used.

Fixes: 89ed2405447d ("mlx5: add support for HW packet padding")

Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx5/mlx5.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 7ac495a..041cfc3 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -359,9 +359,9 @@ mlx5_pci_devinit(struct rte_pci_driver *pci_drv, struct 
rte_pci_device *pci_dev)
 #ifdef HAVE_EXP_DEVICE_ATTR_VLAN_OFFLOADS
IBV_EXP_DEVICE_ATTR_VLAN_OFFLOADS |
 #endif /* HAVE_EXP_DEVICE_ATTR_VLAN_OFFLOADS */
-#ifdef HAVE_EXP_CREATE_WQ_FLAG_RX_END_PADDING
+#ifdef HAVE_VERBS_RX_END_PADDING
IBV_EXP_DEVICE_ATTR_RX_PAD_END_ALIGN |
-#endif /* HAVE_EXP_CREATE_WQ_FLAG_RX_END_PADDING */
+#endif /* HAVE_VERBS_RX_END_PADDING */
0;
 #endif /* HAVE_EXP_QUERY_DEVICE */

-- 
2.1.4

[dpdk-dev] [PATCH] mk: toolchain: gcc: query the compiler macros to obtain the gcc version

[Thomas Monjalon]

2016-03-22 22:50, Markos Chandras:
> On 22/03/16 22:34, Thomas Monjalon wrote:
> > 2016-03-22 17:13, Markos Chandras:
> >> This is similar to what's being used in the Linux kernel. Querying the
> >> GCC macros directly gives more accurate results compared to -dumpversion
> >> which could vary across distributions.
> >>
> >> Signed-off-by: Markos Chandras 
> >> ---
> >> In openSUSE Tumbleweed (and in any other SUSE distribution which
> >> uses (or will use) gcc >= 5), gcc -dumpversion returns '5'. This is on
> >> purpose as discussed in 
> >> https://bugzilla.opensuse.org/show_bug.cgi?id=941428
> > 
> > Good to know. It could be in the commit log.
> 
> I can add this information to the commit message and send a v2 if needed.

I will apply with this info.

> >> -GCC_VERSION = $(subst .,,$(shell $(CC) -dumpversion | cut -f1-2 -d.))
> >> +GCC_MAJOR = $(shell echo __GNUC__ | $(CC) -E -x c - | tail -n 1)
> >> +GCC_MINOR = $(shell echo __GNUC_MINOR__ | $(CC) -E -x c - | tail -n 1)
> >> +GCC_VERSION = $(GCC_MAJOR)$(GCC_MINOR)
> > 
> > Are we sure the minor will always be only one digit?
> 
> Well, I can't be sure but minor has always been a single digit since gcc
> >= 3 if I am not mistaken. But does it matter? What if it is two or more
> digits? The previous code did something similar so if you had gcc
> 5.12.34 installed (and lets assume this is what is being returned by
> -dumpversion), it would have returned 512. The comparison would still
> work as it is at the moment no?

Yes, I was asking for an improvement in case it could happen.
But GCC is probably conservative with numbering so we can keep only one digit.

[dpdk-dev] [PATCH] mk: toolchain: gcc: query the compiler macros to obtain the gcc version

[Markos Chandras]

On 03/23/2016 09:49 AM, Thomas Monjalon wrote:
> 2016-03-22 22:50, Markos Chandras:
>> On 22/03/16 22:34, Thomas Monjalon wrote:
>>> 2016-03-22 17:13, Markos Chandras:
 This is similar to what's being used in the Linux kernel. Querying the
 GCC macros directly gives more accurate results compared to -dumpversion
 which could vary across distributions.

 Signed-off-by: Markos Chandras 
 ---
 In openSUSE Tumbleweed (and in any other SUSE distribution which
 uses (or will use) gcc >= 5), gcc -dumpversion returns '5'. This is on
 purpose as discussed in 
 https://bugzilla.opensuse.org/show_bug.cgi?id=941428
>>>
>>> Good to know. It could be in the commit log.
>>
>> I can add this information to the commit message and send a v2 if needed.
> 
> I will apply with this info.

Thank you Thomas.

-- 
markos

[dpdk-dev] [PATCH] mk: toolchain: gcc: query the compiler macros to obtain the gcc version

[Thomas Monjalon]

2016-03-22 17:13, Markos Chandras:
> This is similar to what's being used in the Linux kernel. Querying the
> GCC macros directly gives more accurate results compared to -dumpversion
> which could vary across distributions.
> 
> Signed-off-by: Markos Chandras 
> ---
> In openSUSE Tumbleweed (and in any other SUSE distribution which
> uses (or will use) gcc >= 5), gcc -dumpversion returns '5'. This is on
> purpose as discussed in https://bugzilla.opensuse.org/show_bug.cgi?id=941428
> As a result of which, the gcc-4.x comparison (40 against 5) does not
> work leading to tons of warnings and failures during build. This patch
> aims to change the way the gcc version is obtained by using the gcc macros
> directly.
> ---

Acked-by: Thomas Monjalon 

Applied, thanks

[dpdk-dev] [PATCH] ethdev: fix rte_eth_dev_xstats_get with NULL

[Thomas Monjalon]

2016-03-23 09:51, Olivier Matz:
> On 03/22/2016 11:09 PM, Stephen Hemminger wrote:
> > Normal usage of rte_eth_dev_xstats_get is to call twice. The
> > first time the function is called with portid, xstats = NULL
> > and n = 0; this returns the number of entries in the statistics
> > table that need to be allocated.
> > 
> > The problem is that the routine adds a count value to NULL (0)
> > and assumes that this is a valid pointer (it isn't). Device drivers
> > all have a check for NULL, and this no longer matches.

This check for NULL should be done after the check (n == 0).

> > Bug was introduced by commit d4fef8b0d5e5
> > ("ethdev: expose generic and driver specific stats in xstats")
> > 
> > Signed-off-by: Stephen Hemminger 
[...]
> > --- a/lib/librte_ether/rte_ethdev.c
> > +++ b/lib/librte_ether/rte_ethdev.c
> > @@ -1495,8 +1495,9 @@ rte_eth_xstats_get(uint8_t port_id, struct 
> > rte_eth_xstats *xstats,
> > /* Retrieve the xstats from the driver at the end of the
> >  * xstats struct.
> >  */
> > -   xcount = (*dev->dev_ops->xstats_get)(dev, &xstats[count],
> > -(n > count) ? n - count : 0);
> > +   xcount = (*dev->dev_ops->xstats_get)(dev,
> > +xstats ? xstats + count : NULL,
> > +(n > count) ? n - count : 0);
> >  
> > if (xcount < 0)
> > return xcount;
> 
> Acked-by: Olivier Matz 
> 
> Just one comment: I think the driver should not rely on the pointer
> value, but on the count. From the documentation of rte_eth_xstats_get(),
> the function returns a:
> 
>   "positive value higher than n: error, the given statistics table
>is too small. The return value corresponds to the size that should
>be given to succeed. The entries in the table are not valid and
>shall not be used by the caller."
> 
> So maybe it should be also fixed in the driver you are talking about.

In all known drivers, n is checked before xstats pointer.
So there is no issue but the patch is still valid for unknown drivers.

Applied, thanks

[dpdk-dev] [PATCH v2 2/7] drivers/net/e1000: Fix missing brackets

[Thomas Monjalon]

2016-03-22 17:37, Aaron Conole:
> The register read/write mphy functions have misleading whitespace around
> the locked check. This cleanup merely preserves the existing functionality
> while improving the ready check.
> 
> Fixes commit 38db3f7f50bd ("e1000: update base driver")
> 
> Signed-off-by: Aaron Conole 
> ---
> v2:
> * Changed from "whitespace-only" fix to a functional change
>   moving the phy writes into protection of the `if (locked)`
>   code
> * Added "Fixes" line.

Wenzhuo, do you agree to fix the base driver here?

[dpdk-dev] [PATCH v2 2/7] drivers/net/e1000: Fix missing brackets

[Thomas Monjalon]

fixing Wenzhuo email address...

2016-03-23 11:38, Thomas Monjalon:
> 2016-03-22 17:37, Aaron Conole:
> > The register read/write mphy functions have misleading whitespace around
> > the locked check. This cleanup merely preserves the existing functionality
> > while improving the ready check.
> > 
> > Fixes commit 38db3f7f50bd ("e1000: update base driver")
> > 
> > Signed-off-by: Aaron Conole 
> > ---
> > v2:
> > * Changed from "whitespace-only" fix to a functional change
> >   moving the phy writes into protection of the `if (locked)`
> >   code
> > * Added "Fixes" line.
> 
> Wenzhuo, do you agree to fix the base driver here?

[dpdk-dev] arch check in example dpdk_qat

[Thomas Monjalon]

When reading examples/dpdk_qat/Makefile, we can see this check:

ifneq ($(CONFIG_RTE_ARCH),"x86_64")
ifneq ($(LBITS),i686)
$(error The RTE_TARGET chosen is not compatible with this environment \
(x86_64), for this application. Please change the definition of the \
RTE_TARGET environment variable, or run the application on a 32-bit OS)
endif
endif

Is it on purpose to limit the 32-bit support to i686 only?
Instead of the message "run the application on a 32-bit OS", should it be
"on an i686 OS"?

[dpdk-dev] Question on examples/multi_process app

[Ananyev, Konstantin]

Hi everyone,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Tuesday, March 22, 2016 9:38 PM
> To: Harish Patil
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Question on examples/multi_process app
> 
> On Tue, Mar 22, 2016 at 08:03:42PM +, Harish Patil wrote:
> > Hi,
> > I have a question regarding symmetric_mp and mp_server applications under
> > examples/multi_process. In those apps, rte_eth_promiscuous_enable() is
> > called before rte_eth_dev_start(). Is this the correct way to initialize
> > the port/device? As per the description in
> > http://dpdk.org/doc/api/rte__ethdev_8h.html:
> >
> > "The functions exported by the application Ethernet API to setup a device
> > designated by its port identifier must be invoked in the following order:
> >
> > * rte_eth_dev_configure()
> > * rte_eth_tx_queue_setup()
> > * rte_eth_rx_queue_setup()
> > * rte_eth_dev_start()
> >
> > Then, the network application can invoke, in any order, the functions
> > exported by the Ethernet API to get the MAC address of a given device, to
> > get the speed and the status of a device physical link, to
> > receive/transmit [burst of] packets, and so on.?
> >
> > So should I consider this as an application issue or whether the PMD is
> > expected to handle it? If PMD is to handle it, then should the PMD be:
> >
> > 1) Rejecting the Promisc config? OR
> > 2) Cache the config and apply when dev_start() is called at later point?

Yes as I remember 2) is done.
dev_start() invokes rte_eth_dev_config_restore(), which restores 
promisc mode, mac addresses, etc.

> >
> > Thanks,
> > Harish
> >
> Good question. I think most/all of the Intel adapters, - for which the app was
> originally written, way back in the day when there were only 2 PMDs in DPDK :)
> - will handle the promiscuous mode call either before or after the dev start.
> Assuming that's the case, and if it makes life easier for other driver 
> writers,
> we should indeed standardize on one supported way of doing things - the way
> specified in the documentation being that one way, I would guess.
> 
> So, e1000, ixgbe maintainers - do you see any issues with forcing the 
> promiscuous
> mode set API to be called after the call to dev_start()?

Not sure, why do we need to enforce that restriction?
Is there any problem with current way?
Konstantin



> 
> /Bruce

[dpdk-dev] Question on examples/multi_process app

[Bruce Richardson]

On Wed, Mar 23, 2016 at 11:09:17AM +, Ananyev, Konstantin wrote:
> Hi everyone,
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> > Sent: Tuesday, March 22, 2016 9:38 PM
> > To: Harish Patil
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] Question on examples/multi_process app
> > 
> > On Tue, Mar 22, 2016 at 08:03:42PM +, Harish Patil wrote:
> > > Hi,
> > > I have a question regarding symmetric_mp and mp_server applications under
> > > examples/multi_process. In those apps, rte_eth_promiscuous_enable() is
> > > called before rte_eth_dev_start(). Is this the correct way to initialize
> > > the port/device? As per the description in
> > > http://dpdk.org/doc/api/rte__ethdev_8h.html:
> > >
> > > "The functions exported by the application Ethernet API to setup a device
> > > designated by its port identifier must be invoked in the following order:
> > >
> > > * rte_eth_dev_configure()
> > > * rte_eth_tx_queue_setup()
> > > * rte_eth_rx_queue_setup()
> > > * rte_eth_dev_start()
> > >
> > > Then, the network application can invoke, in any order, the functions
> > > exported by the Ethernet API to get the MAC address of a given device, to
> > > get the speed and the status of a device physical link, to
> > > receive/transmit [burst of] packets, and so on.?
> > >
> > > So should I consider this as an application issue or whether the PMD is
> > > expected to handle it? If PMD is to handle it, then should the PMD be:
> > >
> > > 1) Rejecting the Promisc config? OR
> > > 2) Cache the config and apply when dev_start() is called at later point?
> 
> Yes as I remember 2) is done.
> dev_start() invokes rte_eth_dev_config_restore(), which restores 
> promisc mode, mac addresses, etc.
> 
> > >
> > > Thanks,
> > > Harish
> > >
> > Good question. I think most/all of the Intel adapters, - for which the app 
> > was
> > originally written, way back in the day when there were only 2 PMDs in DPDK 
> > :)
> > - will handle the promiscuous mode call either before or after the dev 
> > start.
> > Assuming that's the case, and if it makes life easier for other driver 
> > writers,
> > we should indeed standardize on one supported way of doing things - the way
> > specified in the documentation being that one way, I would guess.
> > 
> > So, e1000, ixgbe maintainers - do you see any issues with forcing the 
> > promiscuous
> > mode set API to be called after the call to dev_start()?
> 
> Not sure, why do we need to enforce that restriction?
> Is there any problem with current way?

It complicates things for driver writers is all, and conflicts slightly with 
what is stated in the docs.

/Bruce

[dpdk-dev] Question on examples/multi_process app

[Ananyev, Konstantin]

> -Original Message-
> From: Richardson, Bruce
> Sent: Wednesday, March 23, 2016 11:45 AM
> To: Ananyev, Konstantin
> Cc: Harish Patil; dev at dpdk.org
> Subject: Re: [dpdk-dev] Question on examples/multi_process app
> 
> On Wed, Mar 23, 2016 at 11:09:17AM +, Ananyev, Konstantin wrote:
> > Hi everyone,
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> > > Sent: Tuesday, March 22, 2016 9:38 PM
> > > To: Harish Patil
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] Question on examples/multi_process app
> > >
> > > On Tue, Mar 22, 2016 at 08:03:42PM +, Harish Patil wrote:
> > > > Hi,
> > > > I have a question regarding symmetric_mp and mp_server applications 
> > > > under
> > > > examples/multi_process. In those apps, rte_eth_promiscuous_enable() is
> > > > called before rte_eth_dev_start(). Is this the correct way to initialize
> > > > the port/device? As per the description in
> > > > http://dpdk.org/doc/api/rte__ethdev_8h.html:
> > > >
> > > > "The functions exported by the application Ethernet API to setup a 
> > > > device
> > > > designated by its port identifier must be invoked in the following 
> > > > order:
> > > >
> > > > * rte_eth_dev_configure()
> > > > * rte_eth_tx_queue_setup()
> > > > * rte_eth_rx_queue_setup()
> > > > * rte_eth_dev_start()
> > > >
> > > > Then, the network application can invoke, in any order, the functions
> > > > exported by the Ethernet API to get the MAC address of a given device, 
> > > > to
> > > > get the speed and the status of a device physical link, to
> > > > receive/transmit [burst of] packets, and so on.?
> > > >
> > > > So should I consider this as an application issue or whether the PMD is
> > > > expected to handle it? If PMD is to handle it, then should the PMD be:
> > > >
> > > > 1) Rejecting the Promisc config? OR
> > > > 2) Cache the config and apply when dev_start() is called at later point?
> >
> > Yes as I remember 2) is done.
> > dev_start() invokes rte_eth_dev_config_restore(), which restores
> > promisc mode, mac addresses, etc.
> >
> > > >
> > > > Thanks,
> > > > Harish
> > > >
> > > Good question. I think most/all of the Intel adapters, - for which the 
> > > app was
> > > originally written, way back in the day when there were only 2 PMDs in 
> > > DPDK :)
> > > - will handle the promiscuous mode call either before or after the dev 
> > > start.
> > > Assuming that's the case, and if it makes life easier for other driver 
> > > writers,
> > > we should indeed standardize on one supported way of doing things - the 
> > > way
> > > specified in the documentation being that one way, I would guess.
> > >
> > > So, e1000, ixgbe maintainers - do you see any issues with forcing the 
> > > promiscuous
> > > mode set API to be called after the call to dev_start()?
> >
> > Not sure, why do we need to enforce that restriction?
> > Is there any problem with current way?
> 
> It complicates things for driver writers is all,

Not sure how?
All this replay is done at rte_ethdev layer.
Honestly, so far I don't remember any complaint about promisc on/off.

> and conflicts slightly with
> what is stated in the docs.

Update the docs? :)

> 
> /Bruce

[dpdk-dev] [PATCH] mlx5: fix packet padding macro check

[Bruce Richardson]

On Wed, Mar 23, 2016 at 10:25:49AM +0100, Adrien Mazarguil wrote:
> All instances of HAVE_EXP_CREATE_WQ_FLAG_RX_END_PADDING were not replaced by
> HAVE_VERBS_RX_END_PADDING during a rework of the original patch, effectively
> preventing this feature from being used.
> 
> Fixes: 89ed2405447d ("mlx5: add support for HW packet padding")
> 
> Unfortunately I did not catch this earlier (one should avoid last minute
> changes).
> 
> Bruce, since the above commit is currently only present in your tree, can
> you merge this fix with it during your next rebase? I do not mind keeping
> a separate fix but the commit ID will have to be updated later. Thanks.
> 
Done.

Please check resultant commit on next-net tree:

http://dpdk.org/browse/next/dpdk-next-net/commit/?h=rel_16_04&id=62d20c4d1a463379c63584bee3f102699b59c036

thanks,
/Bruce

[dpdk-dev] [PATCH 0/6] make eth_dev_ops const

[Bruce Richardson]

On Mon, Mar 21, 2016 at 10:53:23AM -0700, Stephen Hemminger wrote:
> Newer driver seem not to have gotten the message that eth_dev_ops
> structure should be const.
> 
> Stephen Hemminger (6):
>   bonding: make eth_dev_ops const
>   cxgbe: make eth_dev_ops const
>   bnx2x: make eth_dev_ops const
>   nfp: make eth_dev_ops const
>   szedata: make eth_dev_ops const
>   mpipe: make eth_dev_ops const
>
Series Acked-by: Bruce Richardson 

Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH 2/2 v5] i40e: Add floating VEB support in i40e

[Zhe Tao]

This patch add the support for floating VEB in i40e.
All the VFs VSIs can decide whether to connect to the legacy VEB/VEPA or
the floating VEB. When connect to the floating VEB a new floating VEB is
created. Now all the VFs need to connect to floating VEB or legacy VEB,
cannot connect to both of them. The PF and VMDQ,FD VSIs still connect to
the old legacy VEB/VEPA.

All the VEB/VEPA concepts are not specific for FVL, they are defined in the
802.1Qbg spec.

Now the floating VEB feature is only avaiable in the specific version of FW.

Signed-off-by: Zhe Tao 
---
 doc/guides/rel_notes/release_16_04.rst |   2 +
 drivers/net/i40e/Makefile  |   2 +-
 drivers/net/i40e/i40e_ethdev.c | 116 +++--
 drivers/net/i40e/i40e_ethdev.h |   8 +++
 drivers/net/i40e/i40e_pf.c |  11 +++-
 5 files changed, 115 insertions(+), 24 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 9922bcb..1545872 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -248,6 +248,8 @@ This section should contain new features added in this 
release. Sample format:

   New application implementing an IPsec Security Gateway.

+* **Added floating VEB support for FVL.**
+

 Resolved Issues
 ---
diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile
index 6dd6eaa..8f7146f 100644
--- a/drivers/net/i40e/Makefile
+++ b/drivers/net/i40e/Makefile
@@ -39,7 +39,7 @@ LIB = librte_pmd_i40e.a
 CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS) -DPF_DRIVER -DVF_DRIVER -DINTEGRATED_VF
 CFLAGS += -DX722_SUPPORT -DX722_A0_SUPPORT
-
+CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common
 EXPORT_MAP := rte_pmd_i40e_version.map

 LIBABIVER := 1
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 6fdae57..00f2da8 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -829,6 +829,12 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 ((hw->nvm.version >> 4) & 0xff),
 (hw->nvm.version & 0xf), hw->nvm.eetrack);

+   /* Need the special FW version support floating VEB */
+   if (hw->aq.fw_maj_ver >= FLOATING_FW_MAJ) {
+   pf->floating = internal_config.floating;
+   } else {
+   pf->floating = false;
+   }
/* Clear PXE mode */
i40e_clear_pxe_mode(hw);

@@ -3690,21 +3696,27 @@ i40e_veb_release(struct i40e_veb *veb)
struct i40e_vsi *vsi;
struct i40e_hw *hw;

-   if (veb == NULL || veb->associate_vsi == NULL)
+   if (veb == NULL)
return -EINVAL;

if (!TAILQ_EMPTY(&veb->head)) {
PMD_DRV_LOG(ERR, "VEB still has VSI attached, can't remove");
return -EACCES;
}
+   /* associate_vsi field is NULL for floating VEB */
+   if (veb->associate_vsi != NULL) {
+   vsi = veb->associate_vsi;
+   hw = I40E_VSI_TO_HW(vsi);

-   vsi = veb->associate_vsi;
-   hw = I40E_VSI_TO_HW(vsi);
+   vsi->uplink_seid = veb->uplink_seid;
+   vsi->veb = NULL;
+   } else {
+   veb->associate_pf->main_vsi->floating_veb = NULL;
+   hw = I40E_VSI_TO_HW(veb->associate_pf->main_vsi);
+   }

-   vsi->uplink_seid = veb->uplink_seid;
i40e_aq_delete_element(hw, veb->seid, NULL);
rte_free(veb);
-   vsi->veb = NULL;
return I40E_SUCCESS;
 }

@@ -3716,9 +3728,9 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40e_vsi *vsi)
int ret;
struct i40e_hw *hw;

-   if (NULL == pf || vsi == NULL) {
+   if (NULL == pf) {
PMD_DRV_LOG(ERR, "veb setup failed, "
-   "associated VSI shouldn't null");
+   "associated PF shouldn't null");
return NULL;
}
hw = I40E_PF_TO_HW(pf);
@@ -3730,11 +3742,19 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40e_vsi *vsi)
}

veb->associate_vsi = vsi;
+   veb->associate_pf = pf;
TAILQ_INIT(&veb->head);
-   veb->uplink_seid = vsi->uplink_seid;
+   veb->uplink_seid = vsi ? vsi->uplink_seid : 0;

-   ret = i40e_aq_add_veb(hw, veb->uplink_seid, vsi->seid,
-   I40E_DEFAULT_TCMAP, false, &veb->seid, false, NULL);
+   /* create floating veb if vsi is NULL */
+   if (vsi != NULL) {
+   ret = i40e_aq_add_veb(hw, veb->uplink_seid, vsi->seid,
+ I40E_DEFAULT_TCMAP, false,
+ &veb->seid, false, NULL);
+   } else {
+   ret = i40e_aq_add_veb(hw, 0, 0, I40E_DEFAULT_TCMAP,
+ true, &veb->seid, false, NULL);
+   }

if (ret != I40E_SUCCESS) {
PMD_DRV_LOG(ERR, "Add veb failed, aq_err: %d",
@@ -3750,10 +3770,10 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40

[dpdk-dev] [PATCH 0/2 v5] i40e: Add floating VEB support for i40e

[Zhe Tao]

This patch-set add the support for floating VEB in i40e.
All the VFs VSIs can decide whether to connect to the legacy VEB/VEPA or
the floating VEB. When connect to the floating VEB a new floating VEB is
created. Now all the VFs need to connect to floating VEB or legacy VEB,
cannot connect to both of them. The PF and VMDQ,FD VSIs connect to
the old legacy VEB/VEPA.

All the VEB/VEPA concepts are not specific for FVL, they are defined in the
802.1Qbg spec.

This floating VEB only take effects on the specific version F/W.

Zhe Tao (2):
  support floating VEB config
  Add floating VEB support in i40e

 doc/guides/rel_notes/release_16_04.rst |   2 +
 doc/guides/testpmd_app_ug/run_app.rst  |   4 +
 drivers/net/i40e/Makefile  |   2 +-
 drivers/net/i40e/i40e_ethdev.c | 116 +++--
 drivers/net/i40e/i40e_ethdev.h |   8 ++
 drivers/net/i40e/i40e_pf.c |  11 ++-
 lib/librte_eal/common/eal_common_options.c |   4 +
 lib/librte_eal/common/eal_internal_cfg.h   |   1 +
 lib/librte_eal/common/eal_options.h|   2 +
 9 files changed, 126 insertions(+), 24 deletions(-)

V2: Added the release notes and changed commit log. 
V3: Changed the VSI release operation. 
V4: Added the FW version check otherwise it will cause the segment fault.
V5: Edited the code for new share code APIs
-- 
2.1.4

[dpdk-dev] [PATCH 1/2 v5] i40e: support floating VEB config

[Zhe Tao]

Add the new floating related argument option in the EAL.
Using this parameter, all the samples can decide whether to use legacy VEB/VEPA
or floating VEB.
Even the floating argument is provided in the EAL, but this floating
feature are only support for FVL so far.

Signed-off-by: Zhe Tao 
---
 doc/guides/testpmd_app_ug/run_app.rst  | 4 
 lib/librte_eal/common/eal_common_options.c | 4 
 lib/librte_eal/common/eal_internal_cfg.h   | 1 +
 lib/librte_eal/common/eal_options.h| 2 ++
 4 files changed, 11 insertions(+)

diff --git a/doc/guides/testpmd_app_ug/run_app.rst 
b/doc/guides/testpmd_app_ug/run_app.rst
index f605564..2f02f63 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -156,6 +156,10 @@ See the DPDK Getting Started Guides for more information 
on these options.

 Use malloc instead of hugetlbfs.

+*   ``--floating``
+
+Enable floating feature for virtual ethernet switch in the NIC.
+Now only Intel i40e NIC supports this feature.

 Testpmd Command-line Options
 
diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index 29942ea..29ed7bf 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -95,6 +95,7 @@ eal_long_options[] = {
{OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM},
{OPT_VMWARE_TSC_MAP,0, NULL, OPT_VMWARE_TSC_MAP_NUM   },
{OPT_XEN_DOM0,  0, NULL, OPT_XEN_DOM0_NUM },
+   {OPT_FLOATING,  0, NULL, OPT_FLOATING_NUM },
{0, 0, NULL, 0}
 };

@@ -896,6 +897,9 @@ eal_parse_common_option(int opt, const char *optarg,
return -1;
}
break;
+   case OPT_FLOATING_NUM:
+   conf->floating = 1;
+   break;

/* don't know what to do, leave this to caller */
default:
diff --git a/lib/librte_eal/common/eal_internal_cfg.h 
b/lib/librte_eal/common/eal_internal_cfg.h
index 5f1367e..19b321a 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -68,6 +68,7 @@ struct internal_config {
volatile unsigned xen_dom0_support; /**< support app running on Xen 
Dom0*/
volatile unsigned no_pci; /**< true to disable PCI */
volatile unsigned no_hpet;/**< true to disable HPET */
+   volatile unsigned floating;   /**< true to enable floating VEB */
volatile unsigned vmware_tsc_map; /**< true to use VMware TSC mapping

* instead of native TSC */
volatile unsigned no_shconf;  /**< true if there is no shared 
config */
diff --git a/lib/librte_eal/common/eal_options.h 
b/lib/librte_eal/common/eal_options.h
index a881c62..413c9e6 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -83,6 +83,8 @@ enum {
OPT_VMWARE_TSC_MAP_NUM,
 #define OPT_XEN_DOM0  "xen-dom0"
OPT_XEN_DOM0_NUM,
+#define OPT_FLOATING  "floating"
+   OPT_FLOATING_NUM,
OPT_LONG_MAX_NUM
 };

-- 
2.1.4

[dpdk-dev] [PATCH] mlx5: fix packet padding macro check

[Adrien Mazarguil]

On Wed, Mar 23, 2016 at 11:53:22AM +, Bruce Richardson wrote:
> On Wed, Mar 23, 2016 at 10:25:49AM +0100, Adrien Mazarguil wrote:
> > All instances of HAVE_EXP_CREATE_WQ_FLAG_RX_END_PADDING were not replaced by
> > HAVE_VERBS_RX_END_PADDING during a rework of the original patch, effectively
> > preventing this feature from being used.
> > 
> > Fixes: 89ed2405447d ("mlx5: add support for HW packet padding")
> > 
> > Unfortunately I did not catch this earlier (one should avoid last minute
> > changes).
> > 
> > Bruce, since the above commit is currently only present in your tree, can
> > you merge this fix with it during your next rebase? I do not mind keeping
> > a separate fix but the commit ID will have to be updated later. Thanks.
> > 
> Done.
> 
> Please check resultant commit on next-net tree:
> 
> http://dpdk.org/browse/next/dpdk-next-net/commit/?h=rel_16_04&id=62d20c4d1a463379c63584bee3f102699b59c036

Perfect, thanks!

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v2] i40e: fix ipv6 TSO issue for tx function

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhe Tao
> Sent: Wednesday, March 23, 2016 3:28 AM
> To: dev at dpdk.org
> Cc: Tao, Zhe; Wu, Jingjing
> Subject: [dpdk-dev] [PATCH v2] i40e: fix ipv6 TSO issue for tx function
> 
> Issue:
> when using the following CLI in testpmd to enable ipv6 TSO feature
> =
> set verbose 1
> csum set ip hw 0
> csum set udp hw 0
> csum set tcp hw 0
> csum set sctp hw 0
> csum set outer-ip hw 0
> csum parse_tunnel on 0
> tso set 800 0
> set fwd csum
> 
> start
> =
> 
> We will not get we want, the ipv6 packets sent out from IXIA can be received 
> by
> i40e, but cannot forward to another port.
> The root cause is when HW doing the TSO offload for packets, it not only 
> depends
> on the context descriptor to define the MSS and TSO payload size, it also
> need to know whether this packets is ipv4 or ipv6, ipv4 need the header csum,
> but ipv6 doesn't need the csum. We need to use the i40e_txd_enable_checksum to
> set the ipv6 type flag into the data descriptor when the packets are for
> ipv6 TSO.
> 
> Fixes: e3f0151f (i40e: enable Tx checksum only for offloaded packets)
> 
> Signed-off-by: Zhe Tao 
> ---
> v2: change condition check for ipv6 TSO checksum offload
> use a more clear check method which include both ipv4 & ipv6 TSO
> 
> 
>  drivers/net/i40e/i40e_rxtx.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index 1488f2f..3422ec2 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -73,9 +73,16 @@
> 
>  #define I40E_TXD_CMD (I40E_TX_DESC_CMD_EOP | I40E_TX_DESC_CMD_RS)
> 
> +/* need to add the TSO flag to the checksum offload mask
> + * even the packets like ipv6 doesn't need the checksum for ip header
> + * but the FW need to know whether this TCP packets is ipv4 or ipv6,
> + * so add this kind of information in the checksum offload field in the
> + * normal data descriptor.
> + */
>  #define I40E_TX_CKSUM_OFFLOAD_MASK (  \
>   PKT_TX_IP_CKSUM |\
>   PKT_TX_L4_MASK | \
> + PKT_TX_TCP_SEG | \
>   PKT_TX_OUTER_IP_CKSUM)
> 
>  static uint16_t i40e_xmit_pkts_simple(void *tx_queue,
> --

Acked-by: Konstantin Ananyev 

> 2.1.4

[dpdk-dev] [PATCH 1/2 v5] i40e: support floating VEB config

[Thomas Monjalon]

2016-03-23 20:27, Zhe Tao:
> Add the new floating related argument option in the EAL.
> Using this parameter, all the samples can decide whether to use legacy 
> VEB/VEPA
> or floating VEB.
> Even the floating argument is provided in the EAL, but this floating
> feature are only support for FVL so far.
> 
> Signed-off-by: Zhe Tao 
> ---
>  doc/guides/testpmd_app_ug/run_app.rst  | 4 
>  lib/librte_eal/common/eal_common_options.c | 4 
>  lib/librte_eal/common/eal_internal_cfg.h   | 1 +
>  lib/librte_eal/common/eal_options.h| 2 ++
>  4 files changed, 11 insertions(+)

The label of this patch is "i40e" but it doesn't touch i40e.
Actually it is an EAL change but there should not be related to EAL.
It seems to be a config option of the device.
Please check how ftag has been enabled in fm10k:
dpdk.org/browse/dpdk/commit/?id=7958b1310d5e

[dpdk-dev] [PATCH v6 7/9] i40e: fix VLAN bitmasks for input set

[Jingjing Wu]

From: Andrey Chilikin 

This patch adds missing VLAN bitmask for inner frame in case of
tunneling and fixes VLAN tags bitmasks for single or outer frame
in case of tunneling.

Fixes: 98f055707685 ("i40e: configure input fields for RSS or flow director")

Signed-off-by: Andrey Chilikin 
Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index ff0ee2e..493db14 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -198,10 +198,12 @@
 #define I40E_REG_INSET_L2_DMAC   0xE000ULL
 /* Source MAC address */
 #define I40E_REG_INSET_L2_SMAC   0x1C00ULL
-/* VLAN tag in the outer L2 header */
-#define I40E_REG_INSET_L2_OUTER_VLAN 0x0080ULL
-/* VLAN tag in the inner L2 header */
-#define I40E_REG_INSET_L2_INNER_VLAN 0x0100ULL
+/* Outer (S-Tag) VLAN tag in the outer L2 header */
+#define I40E_REG_INSET_L2_OUTER_VLAN 0x0200ULL
+/* Inner (C-Tag) or single VLAN tag in the outer L2 header */
+#define I40E_REG_INSET_L2_INNER_VLAN 0x0080ULL
+/* Single VLAN tag in the inner L2 header */
+#define I40E_REG_INSET_TUNNEL_VLAN   0x0100ULL
 /* Source IPv4 address */
 #define I40E_REG_INSET_L3_SRC_IP40x00018000ULL
 /* Destination IPv4 address */
@@ -7018,7 +7020,7 @@ i40e_translate_input_set_reg(uint64_t input)
I40E_REG_INSET_TUNNEL_L4_UDP_SRC_PORT},
{I40E_INSET_TUNNEL_DST_PORT,
I40E_REG_INSET_TUNNEL_L4_UDP_DST_PORT},
-   {I40E_INSET_TUNNEL_ID, I40E_REG_INSET_TUNNEL_ID},
+   {I40E_INSET_VLAN_TUNNEL, I40E_REG_INSET_TUNNEL_VLAN},
{I40E_INSET_FLEX_PAYLOAD_W1, I40E_REG_INSET_FLEX_PAYLOAD_WORD1},
{I40E_INSET_FLEX_PAYLOAD_W2, I40E_REG_INSET_FLEX_PAYLOAD_WORD2},
{I40E_INSET_FLEX_PAYLOAD_W3, I40E_REG_INSET_FLEX_PAYLOAD_WORD3},
-- 
2.4.0

[dpdk-dev] [PATCH v6 5/9] i40e: allow filtering on more IP Header fields

[Jingjing Wu]

This patch extends flow director to select more IP Header fields
as filter input set.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 69 ++
 drivers/net/i40e/i40e_fdir.c   | 26 +++-
 2 files changed, 75 insertions(+), 20 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 32249f9..ff0ee2e 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -210,6 +210,8 @@
 #define I40E_REG_INSET_L3_IP4_TOS0x0040ULL
 /* IPv4 Protocol */
 #define I40E_REG_INSET_L3_IP4_PROTO  0x0004ULL
+/* IPv4 Time to Live */
+#define I40E_REG_INSET_L3_IP4_TTL0x0004ULL
 /* Source IPv6 address */
 #define I40E_REG_INSET_L3_SRC_IP60x0007F800ULL
 /* Destination IPv6 address */
@@ -218,6 +220,8 @@
 #define I40E_REG_INSET_L3_IP6_TC 0x0040ULL
 /* IPv6 Next Header */
 #define I40E_REG_INSET_L3_IP6_NEXT_HDR   0x0008ULL
+/* IPv6 Hop Limit */
+#define I40E_REG_INSET_L3_IP6_HOP_LIMIT  0x0008ULL
 /* Source L4 port */
 #define I40E_REG_INSET_L4_SRC_PORT   0x0004ULL
 /* Destination L4 port */
@@ -261,10 +265,12 @@
 #define I40E_TRANSLATE_INSET 0
 #define I40E_TRANSLATE_REG   1

-#define I40E_INSET_IPV4_TOS_MASK  0x0009FF00UL
-#define I40E_INSET_IPV4_PROTO_MASK0x000DFF00UL
-#define I40E_INSET_IPV6_TC_MASK   0x0009F00FUL
-#define I40E_INSET_IPV6_NEXT_HDR_MASK 0x000C00FFUL
+#define I40E_INSET_IPV4_TOS_MASK0x0009FF00UL
+#define I40E_INSET_IPv4_TTL_MASK0x000D00FFUL
+#define I40E_INSET_IPV4_PROTO_MASK  0x000DFF00UL
+#define I40E_INSET_IPV6_TC_MASK 0x0009F00FUL
+#define I40E_INSET_IPV6_HOP_LIMIT_MASK  0x000CFF00UL
+#define I40E_INSET_IPV6_NEXT_HDR_MASK   0x000C00FFUL

 #define I40E_GL_SWT_L2TAGCTRL(_i) (0x001C0A70 + ((_i) * 4))
 #define I40E_GL_SWT_L2TAGCTRL_ETHERTYPE_SHIFT 16
@@ -6760,30 +6766,47 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
 */
static const uint64_t valid_fdir_inset_table[] = {
[I40E_FILTER_PCTYPE_FRAG_IPV4] =
-   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
+   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+   I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_PROTO |
+   I40E_INSET_IPV4_TTL,
[I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+   I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
-   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
+   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+   I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
+   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+   I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
-   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
+   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
+   I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_PROTO |
+   I40E_INSET_IPV4_TTL,
[I40E_FILTER_PCTYPE_FRAG_IPV6] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+   I40E_INSET_IPV6_TC | I40E_INSET_IPV6_NEXT_HDR |
+   I40E_INSET_IPV6_HOP_LIMIT,
[I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+   I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
+   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+   I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
+   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+   I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
+   I40E_INSET_IPV6_TC | I40E_INSET_IPV6_NEXT_HDR |
+   I40E_INSET_IPV6_HOP_LIMIT,
[I40E_

[dpdk-dev] [PATCH v6 0/9] extend flow director fields in i40e driver

[Jingjing Wu]

v6 changes:
 - remove ABI announce on rte_eth_ipv4_flow and rte_eth_ipv6_flow in 
deprecation.
 - reword commit logs. 

v5 changes:
 - remove the reorganizing of struct rte_eth_fdir_flow
 - remove fdir supporting on Tunnel Id
 - rebase to latest dpdk/master

v4 changes:
 - rebase to latest dpdk-next-net/rel_16_04.
 - comments on new fields in API structure.

v3 changes:
 - rebase to latest dpdk-next-net/rel_16_04(commit: 0f9564a0e4f2)
 - use AQ rx control register read/write for some registers
 - remove few useless lines
 - patch title rewording

v2 changes:
 - rebase on dpdk-next-net/rel_16_04
 - comments rewording.
 - redefine the value of RTE_ETH_INPUT_SET_L3_IP4_TTL to
   avoid ABI breaking.
 - remove ABI announce in Deprecation.
 - fix the ethertype setting when program filter in v1 patch set.

This patch set extends flow director to support filtering by
additional fields below in i40e driver:
 - TOS, Protocol and TTL in IP header
 - single vlan or inner vlan


Andrey Chilikin (1):
  i40e: fix VLAN bitmasks for input set

Jingjing Wu (8):
  ethdev: extend flow director for input selection
  i40e: split function for hash and fdir input
  i40e: remove flex payload from input selection
  i40e: restore default setting on input set
  i40e: extend flow director to filter by IP Header
  testpmd: extend input set related commands
  i40e: extend flow director to filter by vlan id
  testpmd: extend flow director commands

 app/test-pmd/cmdline.c  | 100 +--
 doc/guides/rel_notes/deprecation.rst|   8 -
 doc/guides/rel_notes/release_16_04.rst  |   5 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  42 +--
 drivers/net/i40e/i40e_ethdev.c  | 393 
 drivers/net/i40e/i40e_ethdev.h  |  11 +-
 drivers/net/i40e/i40e_fdir.c| 100 ---
 lib/librte_ether/rte_eth_ctrl.h |   8 +
 8 files changed, 417 insertions(+), 250 deletions(-)

-- 
2.4.0

[dpdk-dev] [PATCH v6 8/9] i40e: extend flow director to filter by vlan id

[Jingjing Wu]

This patch extends flow director to select vlan id as part of
filter's input set and program the filter rule with vlan id.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 doc/guides/rel_notes/release_16_04.rst |  2 +
 drivers/net/i40e/i40e_ethdev.c | 11 ++
 drivers/net/i40e/i40e_fdir.c   | 69 +-
 3 files changed, 55 insertions(+), 27 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 6e368f7..58a53fb 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -172,6 +172,8 @@ This section should contain new features added in this 
release. Sample format:

 * **Added i40e VEB switching support.**

+* **Added Flow director enhancements in i40e.**
+
 * **Added fm10k Rx interrupt support.**

 * **Optimized fm10k Tx.**
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 493db14..44042aa 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -6768,48 +6768,59 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
 */
static const uint64_t valid_fdir_inset_table[] = {
[I40E_FILTER_PCTYPE_FRAG_IPV4] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_PROTO |
I40E_INSET_IPV4_TTL,
[I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_PROTO |
I40E_INSET_IPV4_TTL,
[I40E_FILTER_PCTYPE_FRAG_IPV6] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_NEXT_HDR |
I40E_INSET_IPV6_HOP_LIMIT,
[I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_NEXT_HDR |
I40E_INSET_IPV6_HOP_LIMIT,
[I40E_FILTER_PCTYPE_L2_PAYLOAD] =
+   I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_LAST_ETHER_TYPE,
};

diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c
index ebbe612..f15a080 100644
--- a/drivers/net/i40e/i40e_fdir.c
+++ b/drivers/net/i40e/i40e_fdir.c
@@ -687,11 +687,14 @@ i40e_fdir_configure(struct rte_eth_dev *dev)
return ret;
 }

-static inline void
+static inline int
 i40e_fdir_fill_eth_ip_head(const struct rte_eth_fdir_input *fdir_input,
-  unsigned char *raw_pkt)
+  unsigned char *raw_pkt,
+  bool vlan)
 {
-   struct ether_hdr *ether = (struct ether_hdr *)raw_pkt;
+   static uint8_t vlan_frame[] = {

[dpdk-dev] [PATCH v6 1/9] ethdev: extend flow director for input selection

[Jingjing Wu]

This patch adds RTE_ETH_INPUT_SET_L3_IP4_TTL,
RTE_ETH_INPUT_SET_L3_IP6_HOP_LIMITS input field types and extends
struct rte_eth_ipv4_flow and rte_eth_ipv6_flow to support filtering
by tos, protocol and ttl.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 doc/guides/rel_notes/deprecation.rst   | 8 
 doc/guides/rel_notes/release_16_04.rst | 3 +++
 lib/librte_ether/rte_eth_ctrl.h| 8 
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 252a096..bdbac15 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -22,14 +22,6 @@ Deprecation Notices
 * The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
   must be updated to support 100G link and to have a cleaner link speed API.

-* ABI changes are planned for struct rte_eth_fdir_flow in order to support
-  extend flow director's input set. The release 2.2 does not contain these ABI
-  changes, but release 2.3 will, and no backwards compatibility is planned.
-
-* ABI changes are planned for rte_eth_ipv4_flow and rte_eth_ipv6_flow to
-  include more fields to be matched against. The release 2.2 does not
-  contain these ABI changes, but release 2.3 will.
-
 * ABI changes are planned for adding four new flow types. This impacts
   RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
   but release 2.3 will.
diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 9922bcb..6e368f7 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -437,6 +437,9 @@ ABI Changes
 * The RETA entry size in ``rte_eth_rss_reta_entry64`` has been increased
   from 8-bit to 16-bit.

+* The ethdev flow director structure ``rte_eth_fdir_flow`` structure was
+  changed. New fields were added to extend flow director's input set.
+
 * The cmdline buffer size has been increase from 256 to 512.


diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 6e2f617..aabd724 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -343,6 +343,8 @@ enum rte_eth_input_set_field {
RTE_ETH_INPUT_SET_L3_IP4_PROTO,
RTE_ETH_INPUT_SET_L3_IP6_TC,
RTE_ETH_INPUT_SET_L3_IP6_NEXT_HEADER,
+   RTE_ETH_INPUT_SET_L3_IP4_TTL,
+   RTE_ETH_INPUT_SET_L3_IP6_HOP_LIMITS,

/* L4 */
RTE_ETH_INPUT_SET_L4_UDP_SRC_PORT = 257,
@@ -410,6 +412,9 @@ struct rte_eth_l2_flow {
 struct rte_eth_ipv4_flow {
uint32_t src_ip;  /**< IPv4 source address to match. */
uint32_t dst_ip;  /**< IPv4 destination address to match. */
+   uint8_t  tos; /**< Type of service to match. */
+   uint8_t  ttl; /**< Time to live to match. */
+   uint8_t  proto;   /**< Protocol, next header to match. */
 };

 /**
@@ -446,6 +451,9 @@ struct rte_eth_sctpv4_flow {
 struct rte_eth_ipv6_flow {
uint32_t src_ip[4];  /**< IPv6 source address to match. */
uint32_t dst_ip[4];  /**< IPv6 destination address to match. */
+   uint8_t  tc; /**< Traffic class to match. */
+   uint8_t  proto;  /**< Protocol, next header to match. */
+   uint8_t  hop_limits; /**< Hop limits to match. */
 };

 /**
-- 
2.4.0

[dpdk-dev] [PATCH v6 4/9] i40e: use default filter input set on init

[Jingjing Wu]

This patch adds a new function to set the input set to default
when initialization.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 57 ++
 1 file changed, 57 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 5c549f7..32249f9 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -384,6 +384,7 @@ static int i40e_dev_udp_tunnel_port_add(struct rte_eth_dev 
*dev,
struct rte_eth_udp_tunnel *udp_tunnel);
 static int i40e_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
struct rte_eth_udp_tunnel *udp_tunnel);
+static void i40e_filter_input_set_init(struct i40e_pf *pf);
 static int i40e_ethertype_filter_set(struct i40e_pf *pf,
struct rte_eth_ethertype_filter *filter,
bool add);
@@ -816,6 +817,9 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 */
i40e_flex_payload_reg_init(hw);

+   /* Initialize the input set for filters (hash and fd) to default value 
*/
+   i40e_filter_input_set_init(pf);
+
/* Initialize the parameters for adminq */
i40e_init_adminq_parameter(hw);
ret = i40e_init_adminq(hw);
@@ -7054,6 +7058,59 @@ i40e_check_write_reg(struct i40e_hw *hw, uint32_t addr, 
uint32_t val)
(uint32_t)i40e_read_rx_ctl(hw, addr));
 }

+static void
+i40e_filter_input_set_init(struct i40e_pf *pf)
+{
+   struct i40e_hw *hw = I40E_PF_TO_HW(pf);
+   enum i40e_filter_pctype pctype;
+   uint64_t input_set, inset_reg;
+   uint32_t mask_reg[I40E_INSET_MASK_NUM_REG] = {0};
+   int num, i;
+
+   for (pctype = I40E_FILTER_PCTYPE_NONF_IPV4_UDP;
+pctype <= I40E_FILTER_PCTYPE_L2_PAYLOAD; pctype++) {
+   if (!I40E_VALID_PCTYPE(pctype))
+   continue;
+   input_set = i40e_get_default_input_set(pctype);
+
+   num = i40e_generate_inset_mask_reg(input_set, mask_reg,
+  I40E_INSET_MASK_NUM_REG);
+   if (num < 0)
+   return;
+   inset_reg = i40e_translate_input_set_reg(input_set);
+
+   i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 0),
+ (uint32_t)(inset_reg & UINT32_MAX));
+   i40e_check_write_reg(hw, I40E_PRTQF_FD_INSET(pctype, 1),
+(uint32_t)((inset_reg >>
+I40E_32_BIT_WIDTH) & UINT32_MAX));
+   i40e_check_write_reg(hw, I40E_GLQF_HASH_INSET(0, pctype),
+ (uint32_t)(inset_reg & UINT32_MAX));
+   i40e_check_write_reg(hw, I40E_GLQF_HASH_INSET(1, pctype),
+(uint32_t)((inset_reg >>
+I40E_32_BIT_WIDTH) & UINT32_MAX));
+
+   for (i = 0; i < num; i++) {
+   i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+mask_reg[i]);
+   i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+mask_reg[i]);
+   }
+   /*clear unused mask registers of the pctype */
+   for (i = num; i < I40E_INSET_MASK_NUM_REG; i++) {
+   i40e_check_write_reg(hw, I40E_GLQF_FD_MSK(i, pctype),
+0);
+   i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
+0);
+   }
+   I40E_WRITE_FLUSH(hw);
+
+   /* store the default input set */
+   pf->hash_input_set[pctype] = input_set;
+   pf->fdir.input_set[pctype] = input_set;
+   }
+}
+
 int
 i40e_hash_filter_inset_select(struct i40e_hw *hw,
 struct rte_eth_input_set_conf *conf)
-- 
2.4.0

[dpdk-dev] [PATCH v6 2/9] i40e: split function for hash and fdir input

[Jingjing Wu]

For the input set selection, Hash filter and Flow director shared
the same function, i.e. i40e_filter_inset_select.
For code readability, this patch replaces i40e_filter_inset_select
with two new functions: i40e_hash_filter_inset_select and
i40e_fdir_filter_inset_select for Hash filter and Flow director
respectively.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 235 +
 drivers/net/i40e/i40e_ethdev.h |  11 +-
 drivers/net/i40e/i40e_fdir.c   |   5 +-
 3 files changed, 107 insertions(+), 144 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 6fdae57..2867e60 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -7055,25 +7055,6 @@ i40e_generate_inset_mask_reg(uint64_t inset, uint32_t 
*mask, uint8_t nb_elem)
return idx;
 }

-static uint64_t
-i40e_get_reg_inset(struct i40e_hw *hw, enum rte_filter_type filter,
-   enum i40e_filter_pctype pctype)
-{
-   uint64_t reg = 0;
-
-   if (filter == RTE_ETH_FILTER_HASH) {
-   reg = i40e_read_rx_ctl(hw, I40E_GLQF_HASH_INSET(1, pctype));
-   reg <<= I40E_32_BIT_WIDTH;
-   reg |= i40e_read_rx_ctl(hw, I40E_GLQF_HASH_INSET(0, pctype));
-   } else if (filter == RTE_ETH_FILTER_FDIR) {
-   reg = i40e_read_rx_ctl(hw, I40E_PRTQF_FD_INSET(pctype, 1));
-   reg <<= I40E_32_BIT_WIDTH;
-   reg |= i40e_read_rx_ctl(hw, I40E_PRTQF_FD_INSET(pctype, 0));
-   }
-
-   return reg;
-}
-
 static void
 i40e_check_write_reg(struct i40e_hw *hw, uint32_t addr, uint32_t val)
 {
@@ -7086,105 +7067,96 @@ i40e_check_write_reg(struct i40e_hw *hw, uint32_t 
addr, uint32_t val)
(uint32_t)i40e_read_rx_ctl(hw, addr));
 }

-static int
-i40e_set_hash_inset_mask(struct i40e_hw *hw,
-enum i40e_filter_pctype pctype,
-enum rte_filter_input_set_op op,
-uint32_t *mask_reg,
-uint8_t num)
+int
+i40e_hash_filter_inset_select(struct i40e_hw *hw,
+struct rte_eth_input_set_conf *conf)
 {
-   uint32_t reg;
-   uint8_t i;
+   struct i40e_pf *pf = &((struct i40e_adapter *)hw->back)->pf;
+   enum i40e_filter_pctype pctype;
+   uint64_t input_set, inset_reg = 0;
+   uint32_t mask_reg[I40E_INSET_MASK_NUM_REG] = {0};
+   int ret, i, num;

-   if (!mask_reg || num > RTE_ETH_INPUT_SET_SELECT)
+   if (!conf) {
+   PMD_DRV_LOG(ERR, "Invalid pointer");
+   return -EFAULT;
+   }
+   if (conf->op != RTE_ETH_INPUT_SET_SELECT &&
+   conf->op != RTE_ETH_INPUT_SET_ADD) {
+   PMD_DRV_LOG(ERR, "Unsupported input set operation");
return -EINVAL;
-
-   if (op == RTE_ETH_INPUT_SET_SELECT) {
-   for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
-   i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
-0);
-   if (i >= num)
-   continue;
-   i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
-mask_reg[i]);
-   }
-   } else if (op == RTE_ETH_INPUT_SET_ADD) {
-   uint8_t j, count = 0;
-
-   for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++) {
-   reg = i40e_read_rx_ctl(hw,
-  I40E_GLQF_HASH_MSK(i, pctype));
-   if (reg & I40E_GLQF_HASH_MSK_MASK_MASK)
-   count++;
-   }
-   if (count + num > I40E_INSET_MASK_NUM_REG)
-   return -EINVAL;
-
-   for (i = count, j = 0; i < I40E_INSET_MASK_NUM_REG; i++, j++)
-   i40e_check_write_reg(hw, I40E_GLQF_HASH_MSK(i, pctype),
-mask_reg[j]);
}

-   return 0;
-}
-
-static int
-i40e_set_fd_inset_mask(struct i40e_hw *hw,
-  enum i40e_filter_pctype pctype,
-  enum rte_filter_input_set_op op,
-  uint32_t *mask_reg,
-  uint8_t num)
-{
-   uint32_t reg;
-   uint8_t i;
+   pctype = i40e_flowtype_to_pctype(conf->flow_type);
+   if (pctype == 0 || pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD) {
+   PMD_DRV_LOG(ERR, "Not supported flow type (%u)",
+   conf->flow_type);
+   return -EINVAL;
+   }

-   if (!mask_reg || num > RTE_ETH_INPUT_SET_SELECT)
+   ret = i40e_parse_input_set(&input_set, pctype, conf->field,
+  conf->inset_size);
+   if (ret) {
+   PMD_DRV_LOG(ERR, "Failed to parse input set");
+   return -EINVAL;
+   }
+   

[dpdk-dev] [PATCH v6 3/9] i40e: remove flex payload from input selection

[Jingjing Wu]

In this patch, flex payload is removed from valid fdir input set
values. It is because all flex payload configuration can be set
in struct rte_fdir_conf during device configure phase, which is
a more flexible way of setting this up.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 59 +++---
 1 file changed, 26 insertions(+), 33 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 2867e60..5c549f7 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -254,7 +254,8 @@
 #define I40E_REG_INSET_FLEX_PAYLOAD_WORD70x0080ULL
 /* 8th word of flex payload */
 #define I40E_REG_INSET_FLEX_PAYLOAD_WORD80x0040ULL
-
+/* all 8 words flex payload */
+#define I40E_REG_INSET_FLEX_PAYLOAD_WORDS0x3FC0ULL
 #define I40E_REG_INSET_MASK_DEFAULT  0xULL

 #define I40E_TRANSLATE_INSET 0
@@ -6755,43 +6756,32 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
 */
static const uint64_t valid_fdir_inset_table[] = {
[I40E_FILTER_PCTYPE_FRAG_IPV4] =
-   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
[I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
-   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
-   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
-   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
[I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
-   I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
-   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST,
[I40E_FILTER_PCTYPE_FRAG_IPV6] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
[I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
-   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
-   I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
[I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
-   I40E_INSET_SCTP_VT | I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_SCTP_VT,
[I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
-   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
-   I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST,
[I40E_FILTER_PCTYPE_L2_PAYLOAD] =
-   I40E_INSET_LAST_ETHER_TYPE | I40E_INSET_FLEX_PAYLOAD,
+   I40E_INSET_LAST_ETHER_TYPE,
};

if (pctype > I40E_FILTER_PCTYPE_L2_PAYLOAD)
@@ -7019,7 +7009,7 @@ i40e_translate_input_set_reg(uint64_t input)
return val;
 }

-static uint8_t
+static int
 i40e_generate_inset_mask_reg(uint64_t inset, uint32_t *mask, uint8_t nb_elem)
 {
uint8_t i, idx = 0;
@@ -7037,16 +7027,13 @@ i40e_generate_inset_mask_reg(uint64_t inset, uint32_t 
*mask, uint8_t nb_elem)
if (!inset || !mask || !nb_elem)
return 0;

-   if (!inset && nb_elem >= I40E_INSET_MASK_NUM_REG) {
-   for (i = 0; i < I40E_INSET_MASK_NUM_REG; i++)
-   mask[i] = 0;
-   return I40E_INSET_MASK_NUM_REG;
-   }

for (i = 0, idx = 0; i < RTE_DIM(inset_mask_map); i++) {
-   if (idx >= nb_elem)
-   break;
-   if (inset & inset_mask_map[i].inset) {
+   if ((inset & inset_mask_map[i].inset) == 
inset_mask_map[i].inset) {
+   if (idx >= nb_elem) {
+   PMD_DRV_LOG(ERR, "exceed maximal number of 
bitmasks");
+   return -EINVAL;
+   }
mask

[dpdk-dev] [PATCH v6 6/9] testpmd: extend input set related commands

[Jingjing Wu]

This patch extends commands for changing a flow director filter's input
set. It adds tos, protocol and ttl as filter's input fields, and removes
the words selection from flex payloads.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 app/test-pmd/cmdline.c  | 100 ++--
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  42 +++-
 2 files changed, 104 insertions(+), 38 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index c34d4c1..95350de 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -669,6 +669,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"flow_director_filter (port_id) mode IP 
(add|del|update)"
" flow (ipv4-other|ipv4-frag|ipv6-other|ipv6-frag)"
" src (src_ip_address) dst (dst_ip_address)"
+   " tos (tos_value) proto (proto_value) ttl (ttl_value)"
" vlan (vlan_value) flexbytes (flexbytes_value)"
" (drop|fwd) pf|vf(vf_id) queue (queue_id)"
" fd_id (fd_id_value)\n"
@@ -678,6 +679,7 @@ static void cmd_help_long_parsed(void *parsed_result,
" flow (ipv4-tcp|ipv4-udp|ipv6-tcp|ipv6-udp)"
" src (src_ip_address) (src_port)"
" dst (dst_ip_address) (dst_port)"
+   " tos (tos_value) ttl (ttl_value)"
" vlan (vlan_value) flexbytes (flexbytes_value)"
" (drop|fwd) pf|vf(vf_id) queue (queue_id)"
" fd_id (fd_id_value)\n"
@@ -687,7 +689,9 @@ static void cmd_help_long_parsed(void *parsed_result,
" flow (ipv4-sctp|ipv6-sctp)"
" src (src_ip_address) (src_port)"
" dst (dst_ip_address) (dst_port)"
-   " tag (verification_tag) vlan (vlan_value)"
+   " tag (verification_tag) "
+   " tos (tos_value) ttl (ttl_value)"
+   " vlan (vlan_value)"
" flexbytes (flexbytes_value) (drop|fwd)"
" pf|vf(vf_id) queue (queue_id) fd_id (fd_id_value)\n"
"Add/Del a SCTP type flow director filter.\n\n"
@@ -767,14 +771,15 @@ static void cmd_help_long_parsed(void *parsed_result,
"fld-8th|none) (select|add)\n"
"Set the input set for hash.\n\n"

-   "set_fdir_input_set (port_id) (ipv4|ipv4-frag|"
-   "ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|ipv6|"
+   "set_fdir_input_set (port_id) "
+   "(ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|"
"ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|"
-   "l2_payload) (src-ipv4|dst-ipv4|src-ipv6|dst-ipv6|"
-   "udp-src-port|udp-dst-port|tcp-src-port|tcp-dst-port|"
-   "sctp-src-port|sctp-dst-port|sctp-veri-tag|fld-1st|"
-   "fld-2nd|fld-3rd|fld-4th|fld-5th|fld-6th|fld-7th|"
-   "fld-8th|none) (select|add)\n"
+   "l2_payload) (ethertype|src-ipv4|dst-ipv4|src-ipv6|"
+   "dst-ipv6|ipv4-tos|ipv4-proto|ipv4-ttl|ipv6-tc|"
+   "ipv6-next-header|ipv6-hop-limits|udp-src-port|"
+   "udp-dst-port|tcp-src-port|tcp-dst-port|"
+   "sctp-src-port|sctp-dst-port|sctp-veri-tag|none)"
+   " (select|add)\n"
"Set the input set for FDir.\n\n"
);
}
@@ -8027,6 +8032,12 @@ struct cmd_flow_director_result {
uint16_t port_dst;
cmdline_fixed_string_t verify_tag;
uint32_t verify_tag_value;
+   cmdline_ipaddr_t tos;
+   uint8_t tos_value;
+   cmdline_ipaddr_t proto;
+   uint8_t proto_value;
+   cmdline_ipaddr_t ttl;
+   uint8_t ttl_value;
cmdline_fixed_string_t vlan;
uint16_t vlan_value;
cmdline_fixed_string_t flexbytes;
@@ -8206,12 +8217,15 @@ cmd_flow_director_filter_parsed(void *parsed_result,
switch (entry.input.flow_type) {
case RTE_ETH_FLOW_FRAG_IPV4:
case RTE_ETH_FLOW_NONFRAG_IPV4_OTHER:
+   entry.input.flow.ip4_flow.proto = res->proto_value;
case RTE_ETH_FLOW_NONFRAG_IPV4_UDP:
case RTE_ETH_FLOW_NONFRAG_IPV4_TCP:
IPV4_ADDR_TO_UINT(res->ip_dst,
entry.input.flow.ip4_flow.dst_ip);
IPV4_ADDR_TO_UINT(res->ip_src,
entry.input.flow.ip4_flow.src_ip);
+   entry.input.flow.ip4_flow.tos = res->tos_value;
+   entry.input.flow.ip4_flow.ttl = res->ttl_value;
/* need convert to big endian. */
entry.input.flow.udp4_flow.

[dpdk-dev] [PATCH v6 9/9] testpmd: allow vlan as part of fdir input set

[Jingjing Wu]

This patch extends the commands for changing filter's input set.
It adds vlan as filter's possobile input fields.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 app/test-pmd/cmdline.c  | 6 +++---
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 95350de..25b87ca 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -774,7 +774,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"set_fdir_input_set (port_id) "
"(ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|"
"ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|"
-   "l2_payload) (ethertype|src-ipv4|dst-ipv4|src-ipv6|"
+   "l2_payload) 
(ivlan|ethertype|src-ipv4|dst-ipv4|src-ipv6|"
"dst-ipv6|ipv4-tos|ipv4-proto|ipv4-ttl|ipv6-tc|"
"ipv6-next-header|ipv6-hop-limits|udp-src-port|"
"udp-dst-port|tcp-src-port|tcp-dst-port|"
@@ -9651,7 +9651,7 @@ cmdline_parse_token_string_t 
cmd_set_fdir_input_set_flow_type =
 cmdline_parse_token_string_t cmd_set_fdir_input_set_field =
TOKEN_STRING_INITIALIZER(struct cmd_set_fdir_input_set_result,
inset_field,
-   "ethertype#src-ipv4#dst-ipv4#src-ipv6#dst-ipv6#"
+   "ivlan#ethertype#src-ipv4#dst-ipv4#src-ipv6#dst-ipv6#"
"ipv4-tos#ipv4-proto#ipv4-ttl#ipv6-tc#ipv6-next-header#"
"ipv6-hop-limits#udp-src-port#udp-dst-port#"
"tcp-src-port#tcp-dst-port#sctp-src-port#sctp-dst-port#"
@@ -9666,7 +9666,7 @@ cmdline_parse_inst_t cmd_set_fdir_input_set = {
.help_str = "set_fdir_input_set  "
"ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|"
"ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|l2_payload "
-   "ethertype|src-ipv4|dst-ipv4|src-ipv6|dst-ipv6|"
+   "ivlan|ethertype|src-ipv4|dst-ipv4|src-ipv6|dst-ipv6|"
"ipv4-tos|ipv4-proto|ipv4-ttl|ipv6-tc|ipv6-next-header|"
"ipv6-hop-limits|udp-src-port|udp-dst-port|"
"tcp-src-port|tcp-dst-port|sctp-src-port|sctp-dst-port|"
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 52a4f11..94fba6a 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1929,7 +1929,7 @@ Set the input set for flow director::

set_fdir_input_set (port_id) (ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp| \
ipv4-other|ipv6|ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other| \
-   l2_payload) (ethertype|src-ipv4|dst-ipv4|src-ipv6|dst-ipv6|ipv4-tos| \
+   l2_payload) (ivlan|ethertype|src-ipv4|dst-ipv4|src-ipv6|dst-ipv6|ipv4-tos| \
ipv4-proto|ipv4-ttl|ipv6-tc|ipv6-next-header|ipv6-hop-limits| \
tudp-src-port|udp-dst-port|cp-src-port|tcp-dst-port|sctp-src-port| \
sctp-dst-port|sctp-veri-tag|none) (select|add)
-- 
2.4.0

[dpdk-dev] [PATCH] fm10k: conditionally disable RSS during device initialization

[Michael Frasca]

Hi Jing,

I ran into this issue while trying to run experiments with different RSS
configurations (no RSS being one cases). It is not clear to me that setting this
register to zero is the best way to disable RSS.

After digging further, I have a theory that I'm having this issues because I've
only attached my DPDK application to SR-IOV ports. In
fm10k_dev_dglort_map_configure(), I see that 'RSS Length' is set for the DGLORT
decoder. However, it appears that this is only invoked for physical functions.

Could this be my problem? Is it required that I bind to the physical function
if I want to properly manipulate RSS? 

Thanks,
Mike



> On Mar 22, 2016, at 11:14 PM, Chen, Jing D  wrote:
> 
> Hi,
> 
>> -Original Message-
>> From: Michael Frasca [mailto:michael.frasca at oracle.com]
>> Sent: Wednesday, March 23, 2016 12:58 AM
>> To: Chen, Jing D
>> Cc: dev at dpdk.org; Michael Frasca
>> Subject: [PATCH] fm10k: conditionally disable RSS during device 
>> initialization
>> 
>> If the provided configuration does not call for RSS, then RSS is
>> explicitly disabled. Without this change, the device continues to
>> operate under the previous RSS configuration.
>> 
>> Fixes: 57033cdf8fdc ("fm10k: add PF RSS")
>> 
>> Signed-off-by: Michael Frasca 
> Acked-by : Jing Chen 
> 

[dpdk-dev] [PATCH v2] virtio: fix rx ring descriptor starvation

[Huawei Xie]

Acked-by: Huawei Xie 

[dpdk-dev] [PATCH v6 1/9] ethdev: extend flow director for input selection

[Thomas Monjalon]

2016-03-23 21:07, Jingjing Wu:
> This patch adds RTE_ETH_INPUT_SET_L3_IP4_TTL,
> RTE_ETH_INPUT_SET_L3_IP6_HOP_LIMITS input field types and extends
> struct rte_eth_ipv4_flow and rte_eth_ipv6_flow to support filtering
> by tos, protocol and ttl.
> 
> Signed-off-by: Jingjing Wu 
> Acked-by: Helin Zhang 

Acked-by: Thomas Monjalon 

[dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of compiler ones.

[Xie, Huawei]

On 3/18/2016 8:24 PM, Ilya Maximets wrote:
> Since commit 4c02e453cc62 ("eal: introduce SMP memory barriers") virtio
> uses architecture dependent SMP barriers. vHost should use them too.
>
> Fixes: 4c02e453cc62 ("eal: introduce SMP memory barriers")
>
> Signed-off-by: Ilya Maximets 

Acked-by: Huawei Xie 

It fixes the issue for other archs. Will recheck in future.

[dpdk-dev] [PATCH v2] virtio: fix rx ring descriptor starvation

[Bruce Richardson]

On Wed, Mar 23, 2016 at 06:07:33AM +0800, Huawei Xie wrote:
> Acked-by: Huawei Xie 

Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH v6 0/9] extend flow director fields in i40e driver

[Bruce Richardson]

On Wed, Mar 23, 2016 at 09:07:03PM +0800, Jingjing Wu wrote:
> v6 changes:
>  - remove ABI announce on rte_eth_ipv4_flow and rte_eth_ipv6_flow in 
> deprecation.
>  - reword commit logs. 
> 
> v5 changes:
>  - remove the reorganizing of struct rte_eth_fdir_flow
>  - remove fdir supporting on Tunnel Id
>  - rebase to latest dpdk/master
> 
> v4 changes:
>  - rebase to latest dpdk-next-net/rel_16_04.
>  - comments on new fields in API structure.
> 
> v3 changes:
>  - rebase to latest dpdk-next-net/rel_16_04(commit: 0f9564a0e4f2)
>  - use AQ rx control register read/write for some registers
>  - remove few useless lines
>  - patch title rewording
> 
> v2 changes:
>  - rebase on dpdk-next-net/rel_16_04
>  - comments rewording.
>  - redefine the value of RTE_ETH_INPUT_SET_L3_IP4_TTL to
>avoid ABI breaking.
>  - remove ABI announce in Deprecation.
>  - fix the ethertype setting when program filter in v1 patch set.
> 
> This patch set extends flow director to support filtering by
> additional fields below in i40e driver:
>  - TOS, Protocol and TTL in IP header
>  - single vlan or inner vlan
> 
> 
> Andrey Chilikin (1):
>   i40e: fix VLAN bitmasks for input set
> 
> Jingjing Wu (8):
>   ethdev: extend flow director for input selection
>   i40e: split function for hash and fdir input
>   i40e: remove flex payload from input selection
>   i40e: restore default setting on input set
>   i40e: extend flow director to filter by IP Header
>   testpmd: extend input set related commands
>   i40e: extend flow director to filter by vlan id
>   testpmd: extend flow director commands
>
Patchset applied to dpdk-next-net/rel_16_04.

Thanks,
/Bruce

[dpdk-dev] [PATCH v2] testpmd: fix build on FreeBSD

[Thomas Monjalon]

2016-03-23 02:17, Wu, Jingjing:
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marvin Liu
> > Build log:
> > /root/dpdk/app/test-pmd/cmdline.c:6687:45: error: no member named
> > 's6_addr32' in 'struct in6_addr'
> > rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
> > 
> > This is caused by macro "s6_addr32" not defined on FreeBSD and testpmd
> > swap big endian parameter to host endian. Move the swap action to i40e
> > ethdev will fix this issue.
> > 
> > Fixes: 7b1312891b69 ("ethdev: add IP in GRE tunnel")
> > 
> > Signed-off-by: Marvin Liu 
> Acked-by: Jingjing Wu 

It looks good but something is missing to decide that it is the right fix:
the API do not state wether these fields (and others) are big endian or
something else.

Please Jingjing, fix the ethdev comments for these fields and others
rte_eth_ipv*_flow in a separate patch.

[dpdk-dev] [PATCH v2] ixgbe: add check for tx queue number

[Pablo de Lara]

IXGBE supports 128 TX queues. However, the full 128 queues
are only available in VT and DCB mode.
In normal default "none" mode (VT/DCB off) the maximum number
of available queues is only 64.
IXGBE doesn't check the mode when reporting the available
number of queues. If a queue larger than 64 is used in default mode,
the TX packets will be dropped silently.

This change adds a check to forbid using a queue number larger than 64
during device configuration (in default mode), so that the problem is
reported as early as possible.
It also changes the order of where the dev_conf parameters are copied
into the dev structure so that the correct maximum number of queues
is reported for the correct mode.

Signed-off-by: Wenzhuo Lu 
Signed-off-by: Pablo de Lara 
---

Changes in v2:

- Reorder memcpy of device configuration in rte_eth_dev_configure(),
  so function gets the correct maximum number of queues
  (depending on the operation mode), before checking the
  requested number of queues.
- Renamed new macro
- Reworded/wrapped commit message

 drivers/net/ixgbe/ixgbe_ethdev.c | 17 -
 drivers/net/ixgbe/ixgbe_ethdev.h |  1 +
 lib/librte_ether/rte_ethdev.c|  6 +++---
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index d4d883a..c799b47 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1862,7 +1862,7 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
 {
struct rte_eth_conf *dev_conf = &dev->data->dev_conf;
uint16_t nb_rx_q = dev->data->nb_rx_queues;
-   uint16_t nb_tx_q = dev->data->nb_rx_queues;
+   uint16_t nb_tx_q = dev->data->nb_tx_queues;

if (RTE_ETH_DEV_SRIOV(dev).active != 0) {
/* check multi-queue mode */
@@ -2002,6 +2002,16 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
return -EINVAL;
}
}
+
+   if (dev_conf->txmode.mq_mode == ETH_MQ_TX_NONE) {
+   if (nb_tx_q > IXGBE_NONE_MODE_TX_NB_QUEUES) {
+   PMD_INIT_LOG(ERR,
+"Neither VT nor DCB are enabled, "
+"nb_tx_q > %d.",
+IXGBE_NONE_MODE_TX_NB_QUEUES);
+   return -EINVAL;
+   }
+   }
}
return 0;
 }
@@ -2856,9 +2866,14 @@ static void
 ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 {
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct rte_eth_conf *dev_conf = &dev->data->dev_conf;

dev_info->max_rx_queues = (uint16_t)hw->mac.max_rx_queues;
dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
+   if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
+   if (dev_conf->txmode.mq_mode == ETH_MQ_TX_NONE)
+   dev_info->max_tx_queues = IXGBE_NONE_MODE_TX_NB_QUEUES;
+   }
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL register */
dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS register */
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index 5c3aa16..691c62f 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -61,6 +61,7 @@
 #define IXGBE_MAX_RX_QUEUE_NUM 128
 #define IXGBE_VMDQ_DCB_NB_QUEUES IXGBE_MAX_RX_QUEUE_NUM
 #define IXGBE_DCB_NB_QUEUES  IXGBE_MAX_RX_QUEUE_NUM
+#define IXGBE_NONE_MODE_TX_NB_QUEUES 64

 #ifndef NBBY
 #define NBBY   8   /* number of bits in a byte */
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 8721a6b..b941b0d 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -901,6 +901,9 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, 
uint16_t nb_tx_q,
return -EBUSY;
}

+   /* Copy the dev_conf parameter into the dev structure */
+   memcpy(&dev->data->dev_conf, dev_conf, sizeof(dev->data->dev_conf));
+
/*
 * Check that the numbers of RX and TX queues are not greater
 * than the maximum number of RX and TX queues supported by the
@@ -925,9 +928,6 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, 
uint16_t nb_tx_q,
return -EINVAL;
}

-   /* Copy the dev_conf parameter into the dev structure */
-   memcpy(&dev->data->dev_conf, dev_conf, sizeof(dev->data->dev_conf));
-
/*
 * If link state interrupt is enabled, check that the
 * device supports it.
-- 
2.5.5

[dpdk-dev] DPDK's vhost-user logging capability

[shesha Sreenivasamurthy (shesha)]

Hi All,

I was going over vhost-user migration capability in DPDK in lieu of a Cisco's 
multi-q DPDK vhost-user application. I see that log_base address is implemented 
as per virtio_net device. However, desc, addr and used is per vhost_virtqueue. 
Additionally, QEMU sends one VHOST_USER_SET_LOG_BASE per queue-pair (QEMU - 
hw/virtio/vhost.c::vhost_dev_set_log).

Does it mean we need to log dirty pages of all rings to same location ? If that 
is the case then why does QEMU sends separate VHOST_USER_SET_LOG_BASE per queue 
pair ?

--
- Thanks
char * (*shesha) (uint64_t cache, uint8_t F00D)
{ return 0xC0DE; }

[dpdk-dev] [PATCH] nfp: copy pci info from pci to ethdev

[Stephen Hemminger]

The NFP driver (unlike other PCI devices) was not copying the pci info
from the pci_dev to the eth_dev.  This would make the driver_name be
null (and other unset fields) when application uses dev_info_get.

This was found by code review; do not have the hardware.

Signed-off-by: Stephen Hemminger 
---
 drivers/net/nfp/nfp_net.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 8810704..10ba0ec 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2319,6 +2319,8 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
return 0;

pci_dev = eth_dev->pci_dev;
+   rte_eth_copy_pci_info(eth_dev, pci_dev);
+
hw->device_id = pci_dev->id.device_id;
hw->vendor_id = pci_dev->id.vendor_id;
hw->subsystem_device_id = pci_dev->id.subsystem_device_id;
-- 
2.1.4

[dpdk-dev] testpmd could not start up with vmxnet3 port

[Thomas Monjalon]

2016-03-23 05:57, Yong Wang:
> From: Ding, HengX
> > Testpmd will fail to start up with vmxnet3 port.
[...]
> Currently vmxnet3?s default_txconf.txq_flags is set to the following, which 
> is used by testpmd
> as there is no explicit txconf passed when initializing tx queue:
> 
> dev_info->default_txconf.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
> ETH_TXQ_FLAGS_NOOFFLOADS;

In vmxnet3_dev_tx_queue_setup:
if ((tx_conf->txq_flags & ETH_TXQ_FLAGS_NOXSUMS) !=
ETH_TXQ_FLAGS_NOXSUMSCTP) {
PMD_INIT_LOG(ERR, "SCTP checksum offload not supported");
return -EINVAL;
}
It means we cannot disable TCP or UDP checksum offload.
ETH_TXQ_FLAGS_NOXSUMS = NOXSUMSCTP + NOXSUMUDP + NOXSUMTCP

I think it should be:
if ((tx_conf->txq_flags & ETH_TXQ_FLAGS_NOXSUMSCTP) !=
ETH_TXQ_FLAGS_NOXSUMSCTP) {

> With the referred patch that introduced l4 cksum offload, we should update 
> the default txq
> flags check accordingly.  Heng, can you post the error logs to confirm this 
> is indeed the cause
> of the error you reported?

The default conf is ETH_TXQ_FLAGS_NOOFFLOADS (= NOVLANOFFL + NOXSUMS).
Yes you can update the default conf, *and* fix the check above.

> Related to this, I saw that the check for NOMULTISEGS has been removed and 
> the check for
> NOVLANOFF was never implemented.  Should we just remove the offload flags 
> check as well
> as I don?t see much value of this check.  Basically we know that the device 
> does not support
> certain offload and we have to set those flags to let the device initialize. 
> But doing this does
> nothing to prevent users to request these non-supported offload.  I also saw 
> another thread
> discussing better device capability APIs and hopefully this will not be 
> needed then

These checks are important to throw an error if an offload is requested
but not supported.

[dpdk-dev] [PATCH] ethdev: fix rte_eth_dev_xstats_get with NULL

[Stephen Hemminger]

On Wed, 23 Mar 2016 11:19:12 +0100
Thomas Monjalon  wrote:

> 2016-03-23 09:51, Olivier Matz:
> > On 03/22/2016 11:09 PM, Stephen Hemminger wrote:
> > > Normal usage of rte_eth_dev_xstats_get is to call twice. The
> > > first time the function is called with portid, xstats = NULL
> > > and n = 0; this returns the number of entries in the statistics
> > > table that need to be allocated.
> > > 
> > > The problem is that the routine adds a count value to NULL (0)
> > > and assumes that this is a valid pointer (it isn't). Device drivers
> > > all have a check for NULL, and this no longer matches.
> 
> This check for NULL should be done after the check (n == 0).
> 
> > > Bug was introduced by commit d4fef8b0d5e5
> > > ("ethdev: expose generic and driver specific stats in xstats")
> > > 
> > > Signed-off-by: Stephen Hemminger 
> [...]
> > > --- a/lib/librte_ether/rte_ethdev.c
> > > +++ b/lib/librte_ether/rte_ethdev.c
> > > @@ -1495,8 +1495,9 @@ rte_eth_xstats_get(uint8_t port_id, struct 
> > > rte_eth_xstats *xstats,
> > >   /* Retrieve the xstats from the driver at the end of the
> > >* xstats struct.
> > >*/
> > > - xcount = (*dev->dev_ops->xstats_get)(dev, &xstats[count],
> > > -  (n > count) ? n - count : 0);
> > > + xcount = (*dev->dev_ops->xstats_get)(dev,
> > > +  xstats ? xstats + count : NULL,
> > > +  (n > count) ? n - count : 0);
> > >  
> > >   if (xcount < 0)
> > >   return xcount;
> > 
> > Acked-by: Olivier Matz 
> > 
> > Just one comment: I think the driver should not rely on the pointer
> > value, but on the count. From the documentation of rte_eth_xstats_get(),
> > the function returns a:
> > 
> >   "positive value higher than n: error, the given statistics table
> >is too small. The return value corresponds to the size that should
> >be given to succeed. The entries in the table are not valid and
> >shall not be used by the caller."
> > 
> > So maybe it should be also fixed in the driver you are talking about.
> 
> In all known drivers, n is checked before xstats pointer.
> So there is no issue but the patch is still valid for unknown drivers.
> 
> Applied, thanks

Thanks, yes I was testing with a still not yet upstreamed driver.

[dpdk-dev] testpmd could not start up with vmxnet3 port

[Vincent Li]

> Currently vmxnet3?s default_txconf.txq_flags is set to the following, which 
> is used by testpmd
> as there is no explicit txconf passed when initializing tx queue:
>
> dev_info->default_txconf.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
> ETH_TXQ_FLAGS_NOOFFLOADS;
>
> With the referred patch that introduced l4 cksum offload, we should update 
> the default txq
> flags check accordingly.  Heng, can you post the error logs to confirm this 
> is indeed the cause
> of the error you reported?
>
> Related to this, I saw that the check for NOMULTISEGS has been removed and 
> the check for
> NOVLANOFF was never implemented.  Should we just remove the offload flags 
> check as well
> as I don?t see much value of this check.  Basically we know that the device 
> does not support
> certain offload and we have to set those flags to let the device initialize. 
> But doing this does
> nothing to prevent users to request these non-supported offload.  I also saw 
> another thread
> discussing better device capability APIs and hopefully this will not be 
> needed then.

somehow hijack this thread, in my company  ESXi environment, we are
using tagged vlan in ESXi (select "network label" in vsphpere client
when adding VM network adapter. I found the DPDK application packet
running on one ESXi VM can't reach to other ESXi VM, is this because
VLAN offload not implemented in vmxnet3 PMD ? any clue can I address
the tagged vlan in ESXi environment?

Thanks!

Vincent

[dpdk-dev] [PATCH] bonding: fix initialisation of current_primary_port

[Bernard Iremonger]

The current_primary_port is initialised to an invalid value
during bonded device creation.
It should be set to a valid value later.
This fix sets it to a valid value when the first slave port
is added to the bonding device.

Fixes: 2efb58cbab6e ("bond: new link bonding library")

Signed-off-by: Bernard Iremonger 
---
 drivers/net/bonding/rte_eth_bond_api.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/bonding/rte_eth_bond_api.c 
b/drivers/net/bonding/rte_eth_bond_api.c
index 3fca764..d473ac2 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -352,6 +352,7 @@ __eth_bond_slave_add_lock_free(uint8_t bonded_port_id, 
uint8_t slave_port_id)

/* Make primary slave */
internals->primary_port = slave_port_id;
+   internals->current_primary_port = slave_port_id;

/* Inherit queues settings from first slave */
internals->nb_rx_queues = slave_eth_dev->data->nb_rx_queues;
-- 
2.6.3

[dpdk-dev] [PATCH v2] i40e: fix build issue for RX set function

[Bruce Richardson]

On Wed, Mar 16, 2016 at 06:19:10PM +0800, Zhe Tao wrote:
> Issue:
> When define CONFIG_RTE_LIBTRE_I40E_RX_ALLOW_BULK_ALLOC as n in config file,
> there will be a build error:
> 'i40e_recv_pkts_bulk_alloc' undeclared 
> 
> Now DPDK i40e PMD use the Macro variable to choose whether to define the
> related bulk recv functions, but for selection of the RX function,PMD only
> depends on a C variable, which will cause the inconsistency and lead to the
> build error which will tell us the bulk recv function is not defined.
>  
> Fixes: 8e109464 (i40e: allow vector Rx and Tx usage)
> 
> Signed-off-by: Zhe Tao 
Acked-by: Bruce Richardson 

Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH] ixgbe: fix icc compile error

[Ferruh Yigit]

Fixes: 06554d381d97 ("ixgbe: speed up non-vector Tx")

icc (icc (ICC) 16.0.1 20151021) is generating following compile error:
"
  CC ixgbe_rxtx.o
  .../drivers/net/ixgbe/ixgbe_rxtx.c(153): error #3656: variable
  "free" may be used before its value is set
  (nb_free > 0 && m->pool != free[0]->pool)) {
 ^
"

Indeed this is a false positive and code is correct.
"nb_free" check prevents the free[] access before its value set.

But the patch is just for compiler to remove compiler error.

Signed-off-by: Ferruh Yigit 
---
 drivers/net/ixgbe/ixgbe_rxtx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index ff6ddb8..ef1a26f 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -128,7 +128,8 @@ ixgbe_tx_free_bufs(struct ixgbe_tx_queue *txq)
struct ixgbe_tx_entry *txep;
uint32_t status;
int i, nb_free = 0;
-   struct rte_mbuf *m, *free[RTE_IXGBE_TX_MAX_FREE_BUF_SZ];
+   struct rte_mbuf *m;
+   struct rte_mbuf *free[RTE_IXGBE_TX_MAX_FREE_BUF_SZ] = {0};

/* check DD bit on threshold descriptor */
status = txq->tx_ring[txq->tx_next_dd].wb.status;
-- 
2.5.0

[dpdk-dev] [PATCH] vhost PMD: Fix wrong handling of maximum value of rx/tx queues

[Bruce Richardson]

On Tue, Mar 22, 2016 at 05:17:42PM +, Loftus, Ciara wrote:
> > 
> > Currently, the maximum value of rx/tx queueus are kept by EAL. But,
> > the value are used like below different meanings in vhost PMD.
> >  - The maximum value of current enabled queues.
> >  - The maximum value of current supported queues.
> > 
> > This wrong double meaning will cause an issue like below steps.
> > 
> > * Invoke application with below option.
> >   --vdev 'eth_vhost0,iface=,queues=4'
> > * Configure queues like below.
> >   rte_eth_dev_configure(portid, 2, 2, ...);
> > * Configure queues again like below.
> >   rte_eth_dev_configure(portid, 4, 4, ...);
> > 
> > The second rte_eth_dev_configure() will be failed because both
> > the maximum value of current enabled queues and supported queues
> > will be '2' after calling first rte_eth_dev_configure().
> > 
> > To fix the issue, the patch prepare one more variable to keep the
> > number of maximum supported queues in vhost PMD.
> > 
> > Signed-off-by: Tetsuya Mukawa 
> > ---
 
> Acked-by: Ciara Loftus 
> 
Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH v2 0/5] virtio support for container

[Neil Horman]

On Fri, Feb 05, 2016 at 07:20:23PM +0800, Jianfeng Tan wrote:
> v1->v2:
>  - Rebase on the patchset of virtio 1.0 support.
>  - Fix cannot create non-hugepage memory.
>  - Fix wrong size of memory region when "single-file" is used.
>  - Fix setting of offset in virtqueue to use virtual address.
>  - Fix setting TUNSETVNETHDRSZ in vhost-user's branch.
>  - Add mac option to specify the mac address of this virtual device.
>  - Update doc.
> 
> This patchset is to provide high performance networking interface (virtio)
> for container-based DPDK applications. The way of starting DPDK apps in
> containers with ownership of NIC devices exclusively is beyond the scope.
> The basic idea here is to present a new virtual device (named eth_cvio),
> which can be discovered and initialized in container-based DPDK apps using
> rte_eal_init(). To minimize the change, we reuse already-existing virtio
> frontend driver code (driver/net/virtio/).
>  
> Compared to QEMU/VM case, virtio device framework (translates I/O port r/w
> operations into unix socket/cuse protocol, which is originally provided in
> QEMU), is integrated in virtio frontend driver. So this converged driver
> actually plays the role of original frontend driver and the role of QEMU
> device framework.
>  
> The major difference lies in how to calculate relative address for vhost.
> The principle of virtio is that: based on one or multiple shared memory
> segments, vhost maintains a reference system with the base addresses and
> length for each segment so that an address from VM comes (usually GPA,
> Guest Physical Address) can be translated into vhost-recognizable address
> (named VVA, Vhost Virtual Address). To decrease the overhead of address
> translation, we should maintain as few segments as possible. In VM's case,
> GPA is always locally continuous. In container's case, CVA (Container
> Virtual Address) can be used. Specifically:
> a. when set_base_addr, CVA address is used;
> b. when preparing RX's descriptors, CVA address is used;
> c. when transmitting packets, CVA is filled in TX's descriptors;
> d. in TX and CQ's header, CVA is used.
>  
> How to share memory? In VM's case, qemu always shares all physical layout
> to backend. But it's not feasible for a container, as a process, to share
> all virtual memory regions to backend. So only specified virtual memory
> regions (with type of shared) are sent to backend. It's a limitation that
> only addresses in these areas can be used to transmit or receive packets.
> 
> Known issues
> 
> a. When used with vhost-net, root privilege is required to create tap
> device inside.
> b. Control queue and multi-queue are not supported yet.
> c. When --single-file option is used, socket_id of the memory may be
> wrong. (Use "numactl -N x -m x" to work around this for now)
>  
> How to use?
> 
> a. Apply this patchset.
> 
> b. To compile container apps:
> $: make config RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
> $: make install RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
> $: make -C examples/l2fwd RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
> $: make -C examples/vhost RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
> 
> c. To build a docker image using Dockerfile below.
> $: cat ./Dockerfile
> FROM ubuntu:latest
> WORKDIR /usr/src/dpdk
> COPY . /usr/src/dpdk
> ENV PATH "$PATH:/usr/src/dpdk/examples/l2fwd/build/"
> $: docker build -t dpdk-app-l2fwd .
> 
> d. Used with vhost-user
> $: ./examples/vhost/build/vhost-switch -c 3 -n 4 \
>   --socket-mem 1024,1024 -- -p 0x1 --stats 1
> $: docker run -i -t -v :/var/run/usvhost \
>   -v /dev/hugepages:/dev/hugepages \
>   dpdk-app-l2fwd l2fwd -c 0x4 -n 4 -m 1024 --no-pci \
>   --vdev=eth_cvio0,path=/var/run/usvhost -- -p 0x1
> 
> f. Used with vhost-net
> $: modprobe vhost
> $: modprobe vhost-net
> $: docker run -i -t --privileged \
>   -v /dev/vhost-net:/dev/vhost-net \
>   -v /dev/net/tun:/dev/net/tun \
>   -v /dev/hugepages:/dev/hugepages \
>   dpdk-app-l2fwd l2fwd -c 0x4 -n 4 -m 1024 --no-pci \
>   --vdev=eth_cvio0,path=/dev/vhost-net -- -p 0x1
> 
> By the way, it's not necessary to run in a container.
> 
> Signed-off-by: Huawei Xie 
> Signed-off-by: Jianfeng Tan 
> 
> Jianfeng Tan (5):
>   mem: add --single-file to create single mem-backed file
>   mem: add API to obtain memory-backed file info
>   virtio/vdev: add embeded device emulation
>   virtio/vdev: add a new vdev named eth_cvio
>   docs: add release note for virtio for container
> 
>  config/common_linuxapp |   5 +
>  doc/guides/rel_notes/release_2_3.rst   |   4 +
>  drivers/net/virtio/Makefile|   4 +
>  drivers/net/virtio/vhost.h | 194 +++
>  drivers/net/virtio/vhost_embedded.c| 809 
> +
>  drivers/net/virtio/virtio_ethdev.c | 329 +---
>  drivers/net/virtio/virtio_ethdev.h |   6 +-
>  drivers/net/virtio/virtio_pci.h|  15 +-
>  drivers/net/virtio/virti

[dpdk-dev] [PATCH] ixgbe: fix icc compile error

[Stephen Hemminger]

On Wed, 23 Mar 2016 17:45:58 +
Ferruh Yigit  wrote:

> Fixes: 06554d381d97 ("ixgbe: speed up non-vector Tx")
> 
> icc (icc (ICC) 16.0.1 20151021) is generating following compile error:
> "
>   CC ixgbe_rxtx.o
>   .../drivers/net/ixgbe/ixgbe_rxtx.c(153): error #3656: variable
>   "free" may be used before its value is set
>   (nb_free > 0 && m->pool != free[0]->pool)) {
>^
> "
> 
> Indeed this is a false positive and code is correct.
> "nb_free" check prevents the free[] access before its value set.
> 
> But the patch is just for compiler to remove compiler error.
> 
> Signed-off-by: Ferruh Yigit 
> ---
>  drivers/net/ixgbe/ixgbe_rxtx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index ff6ddb8..ef1a26f 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -128,7 +128,8 @@ ixgbe_tx_free_bufs(struct ixgbe_tx_queue *txq)
>   struct ixgbe_tx_entry *txep;
>   uint32_t status;
>   int i, nb_free = 0;
> - struct rte_mbuf *m, *free[RTE_IXGBE_TX_MAX_FREE_BUF_SZ];
> + struct rte_mbuf *m;
> + struct rte_mbuf *free[RTE_IXGBE_TX_MAX_FREE_BUF_SZ] = {0};
>  
>   /* check DD bit on threshold descriptor */
>   status = txq->tx_ring[txq->tx_next_dd].wb.status;

Although this fixes a compiler bug, it also introduces a performance hit.
The initialization will generate a string instruct (rep; stosz) and this
stalls the multi-execution unit on many Intel CPU's.

Better to add a override to the Makefile (for icc only and with big comment).

[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring

[Marc]

Qian,

On 23 March 2016 at 02:18, Xu, Qian Q  wrote:

> We have tested with intel nic and found port can't be started for all
> nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please
> check and fix it.
>
>
> Thanks
> Qian
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, March 23, 2016 3:59 AM
> To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin
> Cc: marcdevel at gmail.com; Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API
> refactoring
>
> 2016-03-17 19:08, Thomas Monjalon:
> > There are still too few tests and reviews, especially for
> > autonegotiation with Intel devices (patch #6).
> > I would not be surprised to see some bugs in this rework.
>
> Any feedback about autoneg in e1000/ixgbe/i40e?
> Has it been tested before its integration in RC2?
>
> > The capabilities must be adapted per device. It can be improved in a
> > separate patch.
> >
> > It will be integrated in 16.04-rc2.
> > Please test and review shortly, thanks!
>
>
>
> -- Forwarded message --
> From: "Xu, Qian Q" 
> To: "Cao, Waterman" , "Glynn, Michael J" <
> michael.j.glynn at intel.com>
> Cc: "Richardson, Bruce" , "Zhu, Heqing" <
> heqing.zhu at intel.com>, "O'Driscoll, Tim" ,
> "Mcnamara, John" , "Xu, HuilongX" <
> huilongx.xu at intel.com>, "Fu, JingguoX" , "Xu, 
> Qian
> Q" , "Zhang, Helin" 
> Date: Tue, 22 Mar 2016 06:41:37 +
> Subject: RE: DPDK link speed with Intel devices
> Hi, all
> We have worked out the basic test cases for the patchset.
> 1. Test the link speed on major Intel NICs to see if the speed is right.
> 2. Test the auto-negoation on major Intel NICs to ensure it's working.
> Nic covered: ixgbe, igb, i40e, fm10k, bonding(SW), virtio(SW)
>
> When we run the Test#1 for all major NICs. We found that all these NIC
> port(igb, ixgbe, i40e, fm10k) can't be started. Pls check, if the patch is
> applied, all INTEL port can't be start, terrible things!
>
> Interactive-mode selected
> Configuring Port 0 (socket 0)
> PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f13e99e3440
> hw_ring=0x7f13e99e5480 dma_addr=0x8299e5480
> PMD: ixgbe_set_tx_function(): Using simple tx code path
> PMD: ixgbe_set_tx_function(): Vector tx enabled.
> PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f13ffcb8080
> sw_sc_ring=0x7f13ffcbaac0 hw_ring=0x7f13e99d3380 dma_addr=0x8299d3380
> PMD: ixgbe_dev_start(): Invalid link_speeds for port 0; autonegotiation
> disabled
> Fail to start port 0
> Configuring Port 1 (socket 0)
> PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq.
> PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are
> satisfied. Rx Burst Bulk Alloc function will be used on port=1, queue=0.
> PMD: i40e_dev_start(): Invalid link_speeds for port 1; autonegotiation
> disabled
>


Just to double-check; is the test#1 adapted to the _new_ API that ethdev
has to set link speeds? For the output it seems autoneg is disabled =>
fixed speed, hence the new bitmaps have to be used.

(I am not claiming patchset is bug free; there might be issues still)

Regards
marc

Fail to start port 1
> Please stop the ports first
> Done
>
> Thanks
> Qian
>
>
> -Original Message-
> From: Cao, Waterman
> Sent: Tuesday, March 22, 2016 11:06 AM
> To: Glynn, Michael J
> Cc: Richardson, Bruce; Zhu, Heqing; O'Driscoll, Tim; Mcnamara, John; Xu,
> Qian Q; Cao, Waterman
> Subject: RE: DPDK link speed with Intel devices
>
> Hi Mike,
>
> We just knew this patch set last week.
> Since this patch set is required to test with a lot of NIC,  we
> need more document from Dev about this patch.
> Currently, Qian is working on with Wenzhuo on it now.
>
> Waterman
>
>
> -Original Message-
> From: Glynn, Michael J
> Sent: Tuesday, March 22, 2016 1:31 AM
> To: Cao, Waterman 
> Cc: Richardson, Bruce ; Zhu, Heqing <
> heqing.zhu at intel.com>; O'Driscoll, Tim ;
> Mcnamara, John 
> Subject: FW: DPDK link speed with Intel devices
> Importance: High
>
> Hi Waterman, all
>
> See below - are you aware? And if so where are we with testing/resolution?
>
> Regards
> Mike
>
>
>
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, March 21, 2016 2:19 PM
> To: O'Driscoll, Tim ; Glynn, Michael J <
> michael.j.glynn at intel.com>; Zhu, Heqing 
> Cc: vincent.jardin at 6wind.com
> Subject: DPDK link speed with Intel devices
>
> Hi,
>
> We are still waiting for test feedbacks for this important patchset:
> ethdev: 100G and link speed API refactoring It is possible that it
> breaks the autonegotiation in e1000/ixgbe/i40e.
>
> Thanks for taking care.
>
>

[dpdk-dev] [PATCH] ixgbe: fix icc compile error

[Ferruh Yigit]

On 3/23/2016 7:35 PM, Stephen Hemminger wrote:
> On Wed, 23 Mar 2016 17:45:58 +
> Ferruh Yigit  wrote:
> 
>> Fixes: 06554d381d97 ("ixgbe: speed up non-vector Tx")
>>
>> icc (icc (ICC) 16.0.1 20151021) is generating following compile error:
>> "
>>   CC ixgbe_rxtx.o
>>   .../drivers/net/ixgbe/ixgbe_rxtx.c(153): error #3656: variable
>>   "free" may be used before its value is set
>>   (nb_free > 0 && m->pool != free[0]->pool)) {
>>   ^
>> "
>>
>> Indeed this is a false positive and code is correct.
>> "nb_free" check prevents the free[] access before its value set.
>>
>> But the patch is just for compiler to remove compiler error.
>>
>> Signed-off-by: Ferruh Yigit 
>> ---
>>  drivers/net/ixgbe/ixgbe_rxtx.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
>> index ff6ddb8..ef1a26f 100644
>> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
>> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
>> @@ -128,7 +128,8 @@ ixgbe_tx_free_bufs(struct ixgbe_tx_queue *txq)
>>  struct ixgbe_tx_entry *txep;
>>  uint32_t status;
>>  int i, nb_free = 0;
>> -struct rte_mbuf *m, *free[RTE_IXGBE_TX_MAX_FREE_BUF_SZ];
>> +struct rte_mbuf *m;
>> +struct rte_mbuf *free[RTE_IXGBE_TX_MAX_FREE_BUF_SZ] = {0};
>>  
>>  /* check DD bit on threshold descriptor */
>>  status = txq->tx_ring[txq->tx_next_dd].wb.status;
> 
> Although this fixes a compiler bug, it also introduces a performance hit.
> The initialization will generate a string instruct (rep; stosz) and this
> stalls the multi-execution unit on many Intel CPU's.
> 
> Better to add a override to the Makefile (for icc only and with big comment).
> 

Thank you for the comment. Konstantin also expressed similar performance
concern related this patch.

Nack for the patch, we will look for different solution.

Regards,
ferruh

[dpdk-dev] Bug in i40e PMD for flexible payload

[Michael Habibi]

We are using the i40 implementation to configure flow director with
flexible payload rules. When setting up rules, it allows you to set a value
to 63 to disable the rule (NONUSE_FLX_PIT_DEST_OFF). However, the macro in
question is always adding an offset value 50
(I40E_FLX_OFFSET_IN_FIELD_VECTOR). This doesn't work when you use it in
conjunction with NONUSE_FLX_PIT_DEST_OFF to disable it, because instead of
taking 63 as is, it does 63 + 50 and breaks the functionality.

We used the following fix and it appears to work. Just sharing with the
DPDK team in case they want to bring it in.

Index: i40e_fdir.c

===

--- i40e_fdir.c (revision 30006)

+++ i40e_fdir.c (working copy)

@@ -90,7 +90,8 @@

  I40E_PRTQF_FLX_PIT_SOURCE_OFF_MASK) | \

(((fsize) << I40E_PRTQF_FLX_PIT_FSIZE_SHIFT) & \

   I40E_PRTQF_FLX_PIT_FSIZE_MASK) | \

-dst_offset) + I40E_FLX_OFFSET_IN_FIELD_VECTOR) << \

+dst_offset) + ((dst_offset < NONUSE_FLX_PIT_DEST_OFF) ? \

+   I40E_FLX_OFFSET_IN_FIELD_VECTOR : 0)) << \

   I40E_PRTQF_FLX_PIT_DEST_OFF_SHIFT) & \

   I40E_PRTQF_FLX_PIT_DEST_OFF_MASK))