[dpdk-dev] [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK

[Jerin Jacob]

On Fri, Oct 14, 2016 at 03:00:57PM +, Eads, Gage wrote:
> Thanks Jerin, this looks good. I've put a few notes/questions inline.

Thanks Gage.

> 
> >  +
> >  +/**
> >  + * Get the device identifier for the named event device.
> >  + *
> >  + * @param name
> >  + *   Event device name to select the event device identifier.
> >  + *
> >  + * @return
> >  + *   Returns event device identifier on success.
> >  + *   - <0: Failure to find named event device.
> >  + */
> >  +extern uint8_t
> >  +rte_event_dev_get_dev_id(const char *name);
> 
> This return type should be int8_t, or some signed type, to support the 
> failure case.

Makes sense. I will change to int to make consistent with 
rte_cryptodev_get_dev_id()

> 
> >  +};
> >  +
> >  +/**
> >  + * Schedule one or more events in the event dev.
> >  + *
> >  + * An event dev implementation may define this is a NOOP, for instance if
> >  + * the event dev performs its scheduling in hardware.
> >  + *
> >  + * @param dev_id
> >  + *   The identifier of the device.
> >  + */
> >  +extern void
> >  +rte_event_schedule(uint8_t dev_id);
> 
> One idea: Have the function return the number of scheduled packets (or 0 for 
> implementations that do scheduling in hardware). This could be a helpful 
> diagnostic for the software scheduler.

How about returning an implementation specific value ?
Rather than defining certain function associated with returned value.
Just to  make sure it works with all HW/SW implementations. Something like 
below,

/**
 * Schedule one or more events in the event dev.
 *
 * An event dev implementation may define this is a NOOP, for instance if
 * the event dev performs its scheduling in hardware.
 *
 * @param dev_id
 *   The identifier of the device.
 * @return
 *   Implementation specific value from the event driver for diagnostic purpose
 */
extern int
rte_event_schedule(uint8_t dev_id);

[dpdk-dev] [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK

[Jerin Jacob]

On Fri, Oct 14, 2016 at 05:02:21PM +0100, Bruce Richardson wrote:
> On Wed, Oct 12, 2016 at 01:00:16AM +0530, Jerin Jacob wrote:
> > Thanks to Intel and NXP folks for the positive and constructive feedback
> > I've received so far. Here is the updated RFC(v2).
> > 
> > I've attempted to address as many comments as possible.
> > 
> > This series adds rte_eventdev.h to the DPDK tree with
> > adequate documentation in doxygen format.
> > 
> > Updates are also available online:
> > 
> > Related draft header file (this patch):
> > https://rawgit.com/jerinjacobk/libeventdev/master/rte_eventdev.h
> > 
> > PDF version(doxgen output):
> > https://rawgit.com/jerinjacobk/libeventdev/master/librte_eventdev_v2.pdf
> > 
> > Repo:
> > https://github.com/jerinjacobk/libeventdev
> > 
> 
> Thanks for all the work on this.

Thanks

> 
> 
> > +/* Event device configuration bitmap flags */
> > +#define RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT (1 << 0)
> > +/**< Override the global *dequeue_wait_ns* and use per dequeue wait in ns.
> > + *  \see rte_event_dequeue_wait_time(), rte_event_dequeue()
> > + */
> 
> Can you clarify why this is needed? If an app wants to use the same
> dequeue wait times for all dequeues can it not specify that itself via
> the wait time parameter, rather than having a global dequeue wait value?

The rational for choosing this scheme to have optimized
rte_event_dequeue() for some implementation without loosing application
portability and need.

We mostly have two different types of HW schemes to define the wait time

HW1) Have only global wait value for the eventdev across all the
dequeue
HW2) Per queue wait value

In-terms of applications,
APP1) Trivial application does not need different dequeue value for each
dequeue
APP2) Non trivial applications does need different dequeue values

This config option can take advantage if application demands only APP1
on HW1 without loosing application potablity.(i.e if application demand
for APP2 scheme then HW1 based implementation can have different function
pointer to implement dequeue function)

The overall theme of the proposal to have more configuration options(like
RTE_EVENT_QUEUE_CFG_SINGLE_CONSUMER) to have high performance SW/HW 
implementations

[dpdk-dev] [PATCH v2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV

[Lu, Wenzhuo]

Hi Bernard, Rahul,


> -Original Message-
> From: Iremonger, Bernard
> Sent: Friday, October 14, 2016 9:29 PM
> To: dev at dpdk.org; Shah, Rahul R; Lu, Wenzhuo
> Cc: Iremonger, Bernard
> Subject: [PATCH v2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
> 
> modify ixgbe_dcb_tx_hw_config function.
> modify ixgbe_dev_mq_rx_configure function.
> modify ixgbe_configure_dcb function.
Would you like to add more details about why we need to modify these functions 
and what has been done? Thanks.

> 
> Changes in v2:
> Rebased to DPDK v16.11-rc1
> 
> Signed-off-by: Rahul R Shah 
> Signed-off-by: Bernard Iremonger 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c |  9 -
>  drivers/net/ixgbe/ixgbe_rxtx.c   | 37 +
>  2 files changed, 25 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 4ca5747..114698d 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -1977,6 +1977,8 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
>   /* check multi-queue mode */
>   switch (dev_conf->rxmode.mq_mode) {
>   case ETH_MQ_RX_VMDQ_DCB:
Should we store the mq mode here?

> + PMD_INIT_LOG(INFO, "ETH_MQ_RX_VMDQ_DCB
> mode supported in SRIOV");
> + break;
>   case ETH_MQ_RX_VMDQ_DCB_RSS:
>   /* DCB/RSS VMDQ in SRIOV mode, not implement yet
> */
>   PMD_INIT_LOG(ERR, "SRIOV active,"
> @@ -2012,11 +2014,8 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
> 
>   switch (dev_conf->txmode.mq_mode) {
>   case ETH_MQ_TX_VMDQ_DCB:
> - /* DCB VMDQ in SRIOV mode, not implement yet */
> - PMD_INIT_LOG(ERR, "SRIOV is active,"
> - " unsupported VMDQ mq_mode
> tx %d.",
> - dev_conf->txmode.mq_mode);
> - return -EINVAL;
> + PMD_INIT_LOG(INFO, "ETH_MQ_TX_VMDQ_DCB mode
> supported in SRIOV");
> + break;
>   default: /* ETH_MQ_TX_VMDQ_ONLY or ETH_MQ_TX_NONE
> */
>   dev->data->dev_conf.txmode.mq_mode =
> ETH_MQ_TX_VMDQ_ONLY;
>   break;
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c 
> index
> 2ce8234..bb13889 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -1,7 +1,7 @@
>  /*-
>   *   BSD LICENSE
>   *
> - *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> + *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
>   *   Copyright 2014 6WIND S.A.
>   *   All rights reserved.
>   *
> @@ -3313,15 +3313,16 @@ ixgbe_vmdq_dcb_configure(struct rte_eth_dev
> *dev)
> 
>  /**
>   * ixgbe_dcb_config_tx_hw_config - Configure general DCB TX parameters
> - * @hw: pointer to hardware structure
> + * @dev: pointer to eth_dev structure
>   * @dcb_config: pointer to ixgbe_dcb_config structure
>   */
>  static void
> -ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
> +ixgbe_dcb_tx_hw_config(struct rte_eth_dev *dev,
>  struct ixgbe_dcb_config *dcb_config)  {
>   uint32_t reg;
>   uint32_t q;
> + struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data-
> >dev_private);
> 
>   PMD_INIT_FUNC_TRACE();
>   if (hw->mac.type != ixgbe_mac_82598EB) { @@ -3339,11 +3340,17 @@
> ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
>   if (dcb_config->vt_mode)
>   reg |= IXGBE_MTQC_VT_ENA;
>   IXGBE_WRITE_REG(hw, IXGBE_MTQC, reg);
> -
> - /* Disable drop for all queues */
> - for (q = 0; q < 128; q++)
> - IXGBE_WRITE_REG(hw, IXGBE_QDE,
> - (IXGBE_QDE_WRITE | (q <<
> IXGBE_QDE_IDX_SHIFT)));
> + if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
> + /* Disable drop for all queues in VMDQ mode*/
> + for (q = 0; q < 128; q++)
> + IXGBE_WRITE_REG(hw, IXGBE_QDE,
> + (IXGBE_QDE_WRITE | (q <<
> IXGBE_QDE_IDX_SHIFT) | IXGBE_QDE_ENABLE));
> + } else {
> + /* Enable drop for all queues in SRIOV mode */
> + for (q = 0; q < 128; q++)
> + IXGBE_WRITE_REG(hw, IXGBE_QDE,
> + (IXGBE_QDE_WRITE | (q <<
> IXGBE_QDE_IDX_SHIFT)));
> + }
I think it has nothing to do with mq mode. Do I miss something?

> 
>   /* Enable the Tx desc arbiter */
>   reg = IXGBE_READ_REG(hw, IXGBE_RTTDCS); @@ -3378,7
> +3385,7 @@ ixgbe_vmdq_dcb_hw_tx_config(struct rte_eth_dev *dev,
>   vmdq_tx_conf->nb_queue_pools == ETH_16_POOLS ?
> 0x : 0x);
> 
>   /

[dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile

[Guo, Jia]

hi, Konstantin
Thanks your constructive suggestion. I don't think your question is 
silly and we also think about the code style simply and effective, but 
may be i would interpret the reason why we do that.

1) Sure, user definitely can choose to define the macro or not when 
building dpdk i40e PMD, but i don't think it is
necessary to invoke a ret_config option to let up layer user freedom use 
it,  because only the older version i40e driver does not support X722, 
the newer version i40e driver will always support X722, so the macro 
will be default hard code in the makefile. and we will use mac.type to 
distinguish the difference register configure in run time. So we may 
consider the macro just like a flag that highlight the difference of the 
shared code between X710 and X722, that would benify the X710/X722 pmd 
development but hardly no use to exposure to the up layer user.

2)  i think the answer also could find from above. But i think if we 
develop go to a certain stage in the future, mute the macro or use 
script to remove them like the way from hw driver, for support all 
device types maybe not a bad idea, right?


On 10/16/2016 9:31 PM, Ananyev, Konstantin wrote:
> Hi Jeff,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jeff Guo
>> Sent: Sunday, October 16, 2016 2:40 AM
>> To: Zhang, Helin ; Wu, Jingjing > intel.com>
>> Cc: dev at dpdk.org; Guo, Jia 
>> Subject: [dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence 
>> result in compile
>>
>> Since some register only be supported by X722 but may not be supported
>> by other NICs, so add X722 macro to distinguish that to avoid compile error
>> when the X722 macro is undefined.
>
> Two probably silly questions:
> 1) So who will setup X722_SUPPORT macro?
> Is that a user responsibility when he is building dpdk i40e PMD?
> If so, why it is not a rte_config option?
> 2) Why this all has to be build  time decision?
> Why nor run-time?
> Why i40e driver can't support all devices (including x722)
> and invoke different config functions (write different registers)
> based on device type/id information?
> As it does for other device types/ids?
>
> Konstantin

[dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile

[Ananyev, Konstantin]

Hi Jeff,

> 
> hi, Konstantin
> Thanks your constructive suggestion. I don't think your question is
> silly and we also think about the code style simply and effective, but
> may be i would interpret the reason why we do that.
> 
> 1) Sure, user definitely can choose to define the macro or not when
> building dpdk i40e PMD, but i don't think it is
> necessary to invoke a ret_config option to let up layer user freedom use
> it,  because only the older version i40e driver does not support X722,
> the newer version i40e driver will always support X722, so the macro
> will be default hard code in the makefile. and we will use mac.type to
> distinguish the difference register configure in run time. So we may
> consider the macro just like a flag that highlight the difference of the
> shared code between X710 and X722, that would benify the X710/X722 pmd
> development but hardly no use to exposure to the up layer user.
> 
> 2)  i think the answer also could find from above. But i think if we
> develop go to a certain stage in the future, mute the macro or use
> script to remove them like the way from hw driver, for support all
> device types maybe not a bad idea, right?

Sorry, but I still didn't get it.
If i40e driver will always support X722 then why do we need that macro at all?
Why just not to remove it completely then?
Same about run-time vs build-time choice:
If let say i40e_get_rss_key() has to behave in a different way, why not to 
create
i40e_get_rss_key_x722() and use it when hw mactype is x7222?
Or at least inside i40e_get_rss_key() do something like:
if (hw->mac.type == I40E_MAC_X722) {...} else {...}
?
Why instead you have to pollute whole i40e code with all these #ifdef 
x7222/#else ...?
Obviously that looks pretty ugly and hard to maintain.
Konstantin



> 
> 
> On 10/16/2016 9:31 PM, Ananyev, Konstantin wrote:
> > Hi Jeff,
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jeff Guo
> >> Sent: Sunday, October 16, 2016 2:40 AM
> >> To: Zhang, Helin ; Wu, Jingjing  >> intel.com>
> >> Cc: dev at dpdk.org; Guo, Jia 
> >> Subject: [dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence 
> >> result in compile
> >>
> >> Since some register only be supported by X722 but may not be supported
> >> by other NICs, so add X722 macro to distinguish that to avoid compile error
> >> when the X722 macro is undefined.
> >
> > Two probably silly questions:
> > 1) So who will setup X722_SUPPORT macro?
> > Is that a user responsibility when he is building dpdk i40e PMD?
> > If so, why it is not a rte_config option?
> > 2) Why this all has to be build  time decision?
> > Why nor run-time?
> > Why i40e driver can't support all devices (including x722)
> > and invoke different config functions (write different registers)
> > based on device type/id information?
> > As it does for other device types/ids?
> >
> > Konstantin

[dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence result in compile

[Chilikin, Andrey]

In addition to Konstantin's point - some configuration settings, like RSS input 
set and PTYPEs, could be firmware dependent and change between fw versions for 
the same X710/X722 device. Moving mapping tables to the dev private data and 
initializing it on device start up will make code much cleaner.

Regards,
/Andrey

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Monday, October 17, 2016 10:55 AM
> To: Guo, Jia ; Zhang, Helin ; 
> Wu,
> Jingjing 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro absence
> result in compile
> 
> Hi Jeff,
> 
> >
> > hi, Konstantin
> > Thanks your constructive suggestion. I don't think your question is
> > silly and we also think about the code style simply and effective, but
> > may be i would interpret the reason why we do that.
> >
> > 1) Sure, user definitely can choose to define the macro or not when
> > building dpdk i40e PMD, but i don't think it is necessary to invoke a
> > ret_config option to let up layer user freedom use it,  because only
> > the older version i40e driver does not support X722, the newer version
> > i40e driver will always support X722, so the macro will be default
> > hard code in the makefile. and we will use mac.type to distinguish the
> > difference register configure in run time. So we may consider the
> > macro just like a flag that highlight the difference of the shared
> > code between X710 and X722, that would benify the X710/X722 pmd
> > development but hardly no use to exposure to the up layer user.
> >
> > 2)  i think the answer also could find from above. But i think if we
> > develop go to a certain stage in the future, mute the macro or use
> > script to remove them like the way from hw driver, for support all
> > device types maybe not a bad idea, right?
> 
> Sorry, but I still didn't get it.
> If i40e driver will always support X722 then why do we need that macro at all?
> Why just not to remove it completely then?
> Same about run-time vs build-time choice:
> If let say i40e_get_rss_key() has to behave in a different way, why not to 
> create
> i40e_get_rss_key_x722() and use it when hw mactype is x7222?
> Or at least inside i40e_get_rss_key() do something like:
> if (hw->mac.type == I40E_MAC_X722) {...} else {...} ?
> Why instead you have to pollute whole i40e code with all these #ifdef
> x7222/#else ...?
> Obviously that looks pretty ugly and hard to maintain.
> Konstantin
> 
> 
> 
> >
> >
> > On 10/16/2016 9:31 PM, Ananyev, Konstantin wrote:
> > > Hi Jeff,
> > >
> > >> -Original Message-
> > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jeff Guo
> > >> Sent: Sunday, October 16, 2016 2:40 AM
> > >> To: Zhang, Helin ; Wu, Jingjing
> > >> 
> > >> Cc: dev at dpdk.org; Guo, Jia 
> > >> Subject: [dpdk-dev] [PATCH v2 1/2] drivers/i40e: fix X722 macro
> > >> absence result in compile
> > >>
> > >> Since some register only be supported by X722 but may not be
> > >> supported by other NICs, so add X722 macro to distinguish that to
> > >> avoid compile error when the X722 macro is undefined.
> > >
> > > Two probably silly questions:
> > > 1) So who will setup X722_SUPPORT macro?
> > > Is that a user responsibility when he is building dpdk i40e PMD?
> > > If so, why it is not a rte_config option?
> > > 2) Why this all has to be build  time decision?
> > > Why nor run-time?
> > > Why i40e driver can't support all devices (including x722) and
> > > invoke different config functions (write different registers) based
> > > on device type/id information?
> > > As it does for other device types/ids?
> > >
> > > Konstantin

[dpdk-dev] [PATCH] kni: fix build with kernel 4.9

[Ferruh Yigit]

compile error:
  CC [M]  .../lib/librte_eal/linuxapp/kni/igb_main.o
.../lib/librte_eal/linuxapp/kni/igb_main.c:2317:21:
error: initialization from incompatible pointer type
[-Werror=incompatible-pointer-types]
  .ndo_set_vf_vlan = igb_ndo_set_vf_vlan,
 ^~~

Linux kernel 4.9 updates API for ndo_set_vf_vlan:
Linux: 79aab093a0b5 ("net: Update API for VF vlan protocol 802.1ad support")

Use new API for Linux kernels >= 4.9

Signed-off-by: Ferruh Yigit 
---
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c | 19 +++
 lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h  |  4 
 2 files changed, 23 insertions(+)

diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c 
b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
index 23e2d64..f4dca5a 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
@@ -195,7 +195,11 @@ static void igb_process_mdd_event(struct igb_adapter *);
 #ifdef IFLA_VF_MAX
 static int igb_ndo_set_vf_mac( struct net_device *netdev, int vf, u8 *mac);
 static int igb_ndo_set_vf_vlan(struct net_device *netdev,
+#ifdef HAVE_VF_VLAN_PROTO
+   int vf, u16 vlan, u8 qos, __be16 vlan_proto);
+#else
int vf, u16 vlan, u8 qos);
+#endif
 #ifdef HAVE_VF_SPOOFCHK_CONFIGURE
 static int igb_ndo_set_vf_spoofchk(struct net_device *netdev, int vf,
bool setting);
@@ -6412,7 +6416,11 @@ static void igb_set_vmvir(struct igb_adapter *adapter, 
u32 vid, u32 vf)
 }

 static int igb_ndo_set_vf_vlan(struct net_device *netdev,
+#ifdef HAVE_VF_VLAN_PROTO
+  int vf, u16 vlan, u8 qos, __be16 vlan_proto)
+#else
   int vf, u16 vlan, u8 qos)
+#endif
 {
int err = 0;
struct igb_adapter *adapter = netdev_priv(netdev);
@@ -6420,6 +6428,12 @@ static int igb_ndo_set_vf_vlan(struct net_device *netdev,
/* VLAN IDs accepted range 0-4094 */
if ((vf >= adapter->vfs_allocated_count) || (vlan > VLAN_VID_MASK-1) || 
(qos > 7))
return -EINVAL;
+
+#ifdef HAVE_VF_VLAN_PROTO
+   if (vlan_proto != htons(ETH_P_8021Q))
+   return -EPROTONOSUPPORT;
+#endif
+
if (vlan || qos) {
err = igb_vlvf_set(adapter, vlan, !!vlan, vf);
if (err)
@@ -6580,7 +6594,12 @@ static inline void igb_vf_reset(struct igb_adapter 
*adapter, u32 vf)
if (adapter->vf_data[vf].pf_vlan)
igb_ndo_set_vf_vlan(adapter->netdev, vf,
adapter->vf_data[vf].pf_vlan,
+#ifdef HAVE_VF_VLAN_PROTO
+   adapter->vf_data[vf].pf_qos,
+   htons(ETH_P_8021Q));
+#else
adapter->vf_data[vf].pf_qos);
+#endif
else
igb_clear_vf_vfta(adapter, vf);
 #endif
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h 
b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
index 69e0e7a..84826b2 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
@@ -3929,4 +3929,8 @@ skb_set_hash(struct sk_buff *skb, __u32 hash, 
__always_unused int type)
 #define vlan_tx_tag_present skb_vlan_tag_present
 #endif

+#if ( LINUX_VERSION_CODE >= KERNEL_VERSION(4,9,0) )
+#define HAVE_VF_VLAN_PROTO
+#endif /* >= 4.9.0 */
+
 #endif /* _KCOMPAT_H_ */
-- 
2.7.4

[dpdk-dev] Project Governance and Linux Foundation

[Hobywan Kenoby]

Hi Tim,


The Linux kernel community has a governance close to DPDK. It did allow
companies to grow largebusinesses and indivuals to take an
active and even influencial roles based on their technical expertise and
merits.

I don't really understand what can be gained by moving to Linux
Foundation, but I am almost sure that no individual expert will be able
to take any leaderhip role as those roles will be fulfilled by Platinum,
Gold or Silver members: right ?


VPP is a virtual switch that has its own event model that may compete with the 
new model proposed by Intel, Cavium and NXP. What would be the acceptability of 
such a proposal if DPDK would have been folded into FD.IO?


Intellectual property is probably properly handled in this community (I
don't really know a lot about this): are there things to be done on DPDK
to match was proved to be sufficient in Linux kernel?

The current DPDK version can run on virtually all processors (Intel, IBM
and ARM) and leverage all NICs: is there **really** anyone questionning
openness of the community?


- HK




From: dev  on behalf of O'Driscoll, Tim 

Sent: Monday, October 10, 2016 10:33 AM
To: dev at dpdk.org; users at dpdk.org
Subject: [dpdk-dev] Project Governance and Linux Foundation

This email is being sent on behalf of: Cavium, Cisco, Intel, NXP & Red Hat.


Since its creation as an open source project in 2013, DPDK has grown 
significantly. The number of DPDK users, contributors, commercial products that 
use DPDK and open source projects that depend on it have all increased 
consistently over that time. DPDK is now a key ingredient in networking and 
NFV, and we need to ensure that the project structure and governance are 
appropriate for such a critical project, and that they facilitate the project's 
continued growth.

For over a year now we've been discussing moving DPDK to the Linux Foundation. 
We believe it's now time to conclude that discussion and make the move. The 
benefits of doing this would include:
- The infrastructure for a project like DPDK should not be owned and controlled 
by any single company.
- Remove any remaining perception that DPDK is not truly open.
- Allow the project to avail of the infrastructure and services provided by the 
Linux Foundation. These include things like: Ability to host infrastructure for 
integration and testing (the FD.io CSIT lab is an example of this - see 
https://wiki.fd.io/view/CSIT/CSIT_LF_testbed); Support for legal issues 
including trademarks and branding, and the ability to sign agreements on behalf 
of the project; Ability to pool resources for events and brand promotion; Safe 
haven for community IP resources.
CSIT/CSIT LF testbed - fd.io
wiki.fd.io
FD.IO CSIT testbed - Server HW Configuration. CSIT testbed contains following 
three HW configuration types of UCS x86 servers, across total of ten servers 
provided:




We don't propose to debate the details here. Instead, an open discussion 
session on DPDK Project Growth has been included in the agenda for the DPDK 
Summit Userspace 2016 event in Dublin. We propose using that session to agree 
that the DPDK project will move to the Linux Foundation, and then to move on to 
discussing the specifics. Things that we'll need to consider include:
- Whether DPDK moves to the Linux Foundation as an independent project or as 
part of a larger project like FD.io.
- Creation of a project charter similar to those created for FD.io 
(https://fd.io/governance/technical-community-charter) and Open vSwitch (see 
http://openvswitch.org/pipermail/discuss/attachments/20160619/5a2df53e/attachment-0001.pdf).
[https://fd.io/sites/cpstandard/files/theme/backgrounds/bg.jpg]

Technical Community Charter | 
FD.io
fd.io
3.3.4 Project Reviews. For each review, there will be a publicly visible 
wiki/web template filled out containing relevant review information. The review 
document must ...



- Agreement on budget, membership levels etc. A draft budget was created by the 
LF during previous discussions 
(https://docs.google.com/spreadsheets/d/1-3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=302618256),
 but it is possible to adopt an even more lightweight model.

We could look at alternatives to the Linux Foundation, but a) we've been 
talking to the LF for over a year now, and b) the preponderance of networking 
projects in LF, like ODL, FD.io, and OVS, makes it a natural destination for 
DPDK.

As highlighted in previous discussions on this topic, it's important to stress 
that the intent is not to make significant changes to the technical governance 
and decision making of the project. The project has a strong set of maintainers 
and a Technical Board in place already. What's required is to supplement that 
with an open governance structure taking advantage of the services offered

[dpdk-dev] [PATCH] examples/ip_pipeline: fix gcc v6.2.1 build error

[Jasvinder Singh]

This patch fixes the misleading indentation error on compiling ip_pipeline
app with gcc v6.2.1.

Fixes: 3f2c9f3bb6c6 ("examples/ip_pipeline: add TAP port")

Signed-off-by: Jasvinder Singh 
---
 examples/ip_pipeline/app.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/examples/ip_pipeline/app.h b/examples/ip_pipeline/app.h
index 564996e..f8b84e0 100644
--- a/examples/ip_pipeline/app.h
+++ b/examples/ip_pipeline/app.h
@@ -1152,7 +1152,7 @@ app_tap_get_writer(struct app_params *app,
struct app_pktq_tap_params *tap,
uint32_t *pktq_out_id)
 {
-   struct app_pipeline_params *writer;
+   struct app_pipeline_params *writer = NULL;
uint32_t pos = tap - app->tap_params;
uint32_t n_pipelines = RTE_MIN(app->n_pipelines,
RTE_DIM(app->pipeline_params));
@@ -1168,10 +1168,11 @@ app_tap_get_writer(struct app_params *app,
struct app_pktq_out_params *pktq = &p->pktq_out[j];

if ((pktq->type == APP_PKTQ_OUT_TAP) &&
-   (pktq->id == pos))
+   (pktq->id == pos)) {
n_writers++;
writer = p;
id = j;
+   }
}
}

-- 
2.5.5

[dpdk-dev] [PATCH] net/mlx5: fix link status report

[Nelio Laranjeiro]

From: Olga Shern 

This commit fixes link status report on device start up when
lcs callback is configured.

Fixes: 62072098b54e ("mlx5: support setting link up or down")

Signed-off-by: Olga Shern 
---
 drivers/net/mlx5/mlx5.c| 1 +
 drivers/net/mlx5/mlx5.h| 1 +
 drivers/net/mlx5/mlx5_ethdev.c | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 2583a37..f066419 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -671,6 +671,7 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct 
rte_pci_device *pci_dev)
/* Bring Ethernet device up. */
DEBUG("forcing Ethernet interface up");
priv_set_flags(priv, ~IFF_UP, IFF_UP);
+   mlx5_link_update_unlocked(priv->dev, 1);
continue;

 port_error:
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index d24c4f4..000fb38 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -191,6 +191,7 @@ int priv_set_flags(struct priv *, unsigned int, unsigned 
int);
 int mlx5_dev_configure(struct rte_eth_dev *);
 void mlx5_dev_infos_get(struct rte_eth_dev *, struct rte_eth_dev_info *);
 const uint32_t *mlx5_dev_supported_ptypes_get(struct rte_eth_dev *dev);
+int mlx5_link_update_unlocked(struct rte_eth_dev *, int);
 int mlx5_link_update(struct rte_eth_dev *, int);
 int mlx5_dev_set_mtu(struct rte_eth_dev *, uint16_t);
 int mlx5_dev_get_flow_ctrl(struct rte_eth_dev *, struct rte_eth_fc_conf *);
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 7ee2006..b8b3ea9 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -642,7 +642,7 @@ mlx5_dev_supported_ptypes_get(struct rte_eth_dev *dev)
  * @param wait_to_complete
  *   Wait for request completion (ignored).
  */
-static int
+int
 mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
 {
struct priv *priv = mlx5_get_priv(dev);
-- 
2.1.4

[dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support to the TX path

[Maxime Coquelin]

On 10/14/2016 05:50 PM, Maxime Coquelin wrote:
>
>
> On 10/14/2016 09:24 AM, Wang, Zhihong wrote:
>>
>>
>>> -Original Message-
>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Maxime Coquelin
>>> Sent: Tuesday, September 27, 2016 4:43 PM
>>> To: yuanhan.liu at linux.intel.com; Xie, Huawei ;
>>> dev at dpdk.org
>>> Cc: vkaplans at redhat.com; mst at redhat.com;
>>> stephen at networkplumber.org; Maxime Coquelin
>>> 
>>> Subject: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors
>>> support to
>>> the TX path
>>>
>>> Indirect descriptors are usually supported by virtio-net devices,
>>> allowing to dispatch a larger number of requests.
>>>
>>> When the virtio device sends a packet using indirect descriptors,
>>> only one slot is used in the ring, even for large packets.
>>>
>>> The main effect is to improve the 0% packet loss benchmark.
>>> A PVP benchmark using Moongen (64 bytes) on the TE, and testpmd
>>> (fwd io for host, macswap for VM) on DUT shows a +50% gain for
>>> zero loss.
>>>
>>> On the downside, micro-benchmark using testpmd txonly in VM and
>>> rxonly on host shows a loss between 1 and 4%.i But depending on
>>> the needs, feature can be disabled at VM boot time by passing
>>> indirect_desc=off argument to vhost-user device in Qemu.
>>>
>>> Signed-off-by: Maxime Coquelin 
>>
>>
>> Hi Maxime,
>>
>> Seems this patch can't with Windows virtio guest in my test.
>> Have you done similar tests before?
>>
>> The way I test:
>>
>>  1. Make sure https://patchwork.codeaurora.org/patch/84339/ is applied
>>
>>  2. Start testpmd with iofwd between 2 vhost ports
>>
>>  3. Start 2 Windows guests connected to the 2 vhost ports
>>
>>  4. Disable firewall and assign IP to each guest using ipconfig
>>
>>  5. Use ping to test connectivity
>>
>> When I disable this patch by setting:
>>
>> 0ULL << VIRTIO_RING_F_INDIRECT_DESC,
>>
>> the connection is fine, but when I restore:
>>
>> 1ULL << VIRTIO_RING_F_INDIRECT_DESC,
>>
>> the connection is broken.
>
> Just noticed I didn't reply to all this morning.
> I sent a debug patch to Zhihong, which shows that indirect desc chaining
> looks OK.
>
> On my side, I just setup 2 Windows 2016 VMs, and confirm the issue.
> I'll continue the investigation early next week.

The root cause is identified.
When INDIRECT_DESC feature is negotiated, Windows guest uses indirect
for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD &
virtio-net kernel driver) use indirect only for Tx.

I'll implement indirect support for the Rx path in vhost lib, but the
change will be too big for -rc release.
I propose in the mean time to disable INDIRECT_DESC feature in vhost
lib, we can still enable it locally for testing.

Yuanhan, is it ok for you?

> Has anyone already tested Windows guest with vhost-net, which also has
> indirect descs support?

I tested and confirm it works with vhost-net.

Regards,
Maxime

[dpdk-dev] [PATCH 0/3] Improvements in packet timestamps support

[Nélio Laranjeiro]

On Thu, Oct 13, 2016 at 02:35:05PM +, Oleg Kuporosov wrote:
> 
> Hello DPDK Developers,
> 
> Financial Services Industry which is pretty eager for several DPDK
> features especially low latency while high throughput. The major issue
> so far for increasing DPDK adoption there is requirement for several
> applications (capturers, some trading algorithms) to support of accurate
> timestamping. The requirement mostly came from regulatory and customers
> need strictly follow it.
> 
> Current state of timestamping support in DPDK looks pretty good:
>  - there is API to enable/disable timestamping acquisition by 
>rte_eth_timesync_enable/disable
>  - get timestamps itself by timesync_read_rx/tx_timestamp
>  - and even implementation of NTP IEEE 1588 for time synchronization
>by rte_eth_timesync_adjust_read/write_time APIs.
>
> But it misses the most important feature there ? embedding timestamp
> in rte_mbuf aligning it with packet.
> 
> We would like to change this to increase DPDK adoption for several new
> DPDK-based applications for FSI segment. It also might be very
> applicable for several RT media and debugging purposes of network
> flows/streams in other segments like HPC.
> 
> There are several thoughts how to improve there:
>  - include uint64_t timestamp field into rte_mbuf with minimal impact
>to throughput/latency. Keep it just simple uint64_t in ns (more than
>580 years) would be enough for immediate needs while using full
>struct timespec with twice bigger size would have much stronger
>performance impact as missed cacheline0. It is possible as there is
>6-bytes gap in 1st cacheline (fast path) and moving uint16_t
>vlan_tci_outer field to 2nd cacheline. 
>  - such move will only impact for pretty rare usable VLAN RX stripping
>mode for outer TCI (it used only for one NIC i40e from the whole
>set and keep minimal performance impact for timestamps.  
>  - PMD can fill the field in their callback completion routines
>depending on enabling this feature in runtime.
> 
> We evaluated other possible options but looks it will have even worse
> performance impact.
> 
> 
> Oleg Kuporosov (3):
>   mbuf: embedding timestamp into the packet
>   app/testpmd: enabled control for packet timestamps
>   net/mlx5: implementation of Rx packet timestamping support
> 
>  app/test-pmd/cmdline.c  | 122 +++
>  app/test-pmd/parameters.c   |   4 +
>  app/test-pmd/testpmd.c  |   5 +
>  app/test-pmd/testpmd.h  |   1 +
>  doc/guides/testpmd_app_ug/run_app.rst   |   4 +
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst |   7 +
>  drivers/net/mlx5/mlx5.c |   7 +-
>  drivers/net/mlx5/mlx5.h |  10 +-
>  drivers/net/mlx5/mlx5_defs.h|   4 +
>  drivers/net/mlx5/mlx5_ethdev.c  | 222 
> +++-
>  drivers/net/mlx5/mlx5_rxq.c |   2 +
>  drivers/net/mlx5/mlx5_rxtx.c|  19 ++-
>  drivers/net/mlx5/mlx5_rxtx.h|   7 +-
>  drivers/net/mlx5/mlx5_time.h|  53 +++
>  drivers/net/mlx5/mlx5_trigger.c |   1 +
>  lib/librte_eal/common/include/rte_time.h|  45 ++
>  lib/librte_mbuf/rte_mbuf.h  |   6 +-
>  17 files changed, 507 insertions(+), 12 deletions(-)
>  create mode 100644 drivers/net/mlx5/mlx5_time.h
> 
> Thanks,
> Oleg.
> -- 
> 1.8.3.1

Reviewed-by: Nelio Laranjeiro 

-- 
N?lio Laranjeiro
6WIND

[dpdk-dev] Project Governance and Linux Foundation

[O'Driscoll, Tim]

Hi HK,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Hobywan Kenoby
> Sent: Monday, October 17, 2016 11:24 AM
> To: O'Driscoll, Tim ; dev at dpdk.org;
> users at dpdk.org
> Subject: Re: [dpdk-dev] Project Governance and Linux Foundation
> 
> Hi Tim,
> 
> 
> The Linux kernel community has a governance close to DPDK. It did allow
> companies to grow largebusinesses and indivuals to take an
> active and even influencial roles based on their technical expertise and
> merits.
> 
> I don't really understand what can be gained by moving to Linux
> Foundation, but I am almost sure that no individual expert will be able
> to take any leaderhip role as those roles will be fulfilled by Platinum,
> Gold or Silver members: right ?

No. If DPDK were to move to LF as an independent project, then as discussed at 
the Userspace event in Dublin last year, and as documented in the original post 
below, the intention would be not to make any significant changes to the 
technical governance.

If DPDK were to move to FD.io the situation would be the same. The FD.io 
Technical Community Charter 
(https://fd.io/governance/technical-community-charter) specifies how Project 
Technical Leaders and Committers are nominated and approved, but there's no 
requirement for people in those roles to come from Platinum, Gold or Silver 
FD.io members. Those decisions are based purely on technical merit.

> VPP is a virtual switch that has its own event model that may compete
> with the new model proposed by Intel, Cavium and NXP. What would be the
> acceptability of such a proposal if DPDK would have been folded into
> FD.IO?

Acceptance of the libeventdev proposal would be no different if DPDK were part 
of FD.io. It would be reviewed and accepted based on its technical merit.

FD.io is an umbrella project comprising a number of individual sub-projects. 
Those sub-projects are free to make their own technical decisions. This is 
documented in the Guiding Principles section of the FD.io Technical Community 
Charter (https://fd.io/governance/technical-community-charter):

4.Technical decisions (including release decisions) for a project should be 
made by consensus of that project's Committers.  If consensus cannot be 
reached, decisions are made by a majority vote of a project's Committers.  
Committers on a project may, by majority vote, delegate (or revoke delegation 
of) any portion of the project's decisions to an alternate open, documented, 
traceable decision making process.

> Intellectual property is probably properly handled in this community (I
> don't really know a lot about this): are there things to be done on DPDK
> to match was proved to be sufficient in Linux kernel?

I think Intellectual Property is already properly handled within DPDK. Being 
part of the Linux Foundation would provide a legal framework for dealing with 
any trademark or other legal issues that may occur in future.

> The current DPDK version can run on virtually all processors (Intel, IBM
> and ARM) and leverage all NICs: is there **really** anyone questionning
> openness of the community?

I still hear concerns on this, and based on discussions with others who put 
their names to the post below, they do too. I think it's a perception that we 
need to address.

> 
> - HK
> 
> 
> 
> 
> From: dev  on behalf of O'Driscoll, Tim
> 
> Sent: Monday, October 10, 2016 10:33 AM
> To: dev at dpdk.org; users at dpdk.org
> Subject: [dpdk-dev] Project Governance and Linux Foundation
> 
> This email is being sent on behalf of: Cavium, Cisco, Intel, NXP & Red
> Hat.
> 
> 
> Since its creation as an open source project in 2013, DPDK has grown
> significantly. The number of DPDK users, contributors, commercial
> products that use DPDK and open source projects that depend on it have
> all increased consistently over that time. DPDK is now a key ingredient
> in networking and NFV, and we need to ensure that the project structure
> and governance are appropriate for such a critical project, and that
> they facilitate the project's continued growth.
> 
> For over a year now we've been discussing moving DPDK to the Linux
> Foundation. We believe it's now time to conclude that discussion and
> make the move. The benefits of doing this would include:
> - The infrastructure for a project like DPDK should not be owned and
> controlled by any single company.
> - Remove any remaining perception that DPDK is not truly open.
> - Allow the project to avail of the infrastructure and services provided
> by the Linux Foundation. These include things like: Ability to host
> infrastructure for integration and testing (the FD.io CSIT lab is an
> example of this - see https://wiki.fd.io/view/CSIT/CSIT_LF_testbed);
> Support for legal issues including trademarks and branding, and the
> ability to sign agreements on behalf of the project; Ability to pool
> resources for events and brand promotion; Safe haven for community IP

[dpdk-dev] [PATCH] net/mlx5: fix init on secondary process

[Ferruh Yigit]

Hi Olivier,

On 10/11/2016 10:45 AM, Adrien Mazarguil wrote:
> Hi Olivier,
> 
> Secondary process support's got overlooked during this refactoring, thanks
> for the patch. However can you describe the issue you're addressing as part
> of the commit log?
> 
> I think problems started when txq got mistakenly converted to
> primary_txq_ctrl in 21c8bb4928c9 ("net/mlx5: split Tx queue structure"), you
> may add a Fixes line for that one as well.
> 
> Otherwise, this patch looks fine to me.
> 

Patch doesn't apply cleanly, can you please rebase the patch on top of
latest dpdk-next-net?

Thanks,
ferruh

[dpdk-dev] [PATCH] net/bnx2x: fix icc build error

[Ferruh Yigit]

On 9/30/2016 3:45 PM, Ferruh Yigit wrote:
> When bnx2x debug config enabled, icc (ICC) 17.0.0 20160721
> gives the following compilation error:
> 
> .../drivers/net/bnx2x/elink.c(6682):
> error #3656: variable "fw_ver1" may be used before its value is set
>   PMD_DRV_LOG(DEBUG,
>   ^
> 
> According logic in the code, this error is a false positive,
> but since this is not in the fast path, fixing compiler error by
> assigning initial value to variable.
> 
> Signed-off-by: Ferruh Yigit 
> ---
>  drivers/net/bnx2x/elink.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/bnx2x/elink.c b/drivers/net/bnx2x/elink.c
> index 149cc97..d9a72f0 100644
> --- a/drivers/net/bnx2x/elink.c
> +++ b/drivers/net/bnx2x/elink.c
> @@ -6645,7 +6645,7 @@ static elink_status_t 
> elink_8073_8727_external_rom_boot(struct bnx2x_softc *sc,
>   uint8_t port)
>  {
>   uint32_t count = 0;
> - uint16_t fw_ver1, fw_msgout;
> + uint16_t fw_ver1 = 0, fw_msgout;
>   elink_status_t rc = ELINK_STATUS_OK;
>  
>   /* Boot port from external ROM  */
> 

Since this is an compilation fix, I believe it is good to have this in
the release, can you please review the patch?

Thanks,
ferruh

[dpdk-dev] [PATCH] examples/ip_pipeline: fix gcc v6.2.1 build error

[Dumitrescu, Cristian]

> -Original Message-
> From: Singh, Jasvinder
> Sent: Monday, October 17, 2016 11:51 AM
> To: dev at dpdk.org
> Cc: Dumitrescu, Cristian 
> Subject: [PATCH] examples/ip_pipeline: fix gcc v6.2.1 build error
> 
> This patch fixes the misleading indentation error on compiling ip_pipeline
> app with gcc v6.2.1.
> 
> Fixes: 3f2c9f3bb6c6 ("examples/ip_pipeline: add TAP port")
> 
> Signed-off-by: Jasvinder Singh 
> ---
>  examples/ip_pipeline/app.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 

Acked-by: Cristian Dumitrescu 

[dpdk-dev] [dpdk-users] Project Governance and Linux Foundation

[Thomas Monjalon]

2016-10-17 11:52, O'Driscoll, Tim:
> From: Hobywan Kenoby
> > The current DPDK version can run on virtually all processors (Intel, IBM
> > and ARM) and leverage all NICs: is there **really** anyone questionning
> > openness of the community?
> 
> I still hear concerns on this, and based on discussions with others who
> put their names to the post below, they do too.
> I think it's a perception that we need to address.

It is simple to address this perception with fact checking.
The next releases will provide even more code for ARM and NPUs.
If someone submits some good code and is ignored, it is easy enough
to ping the mailing list and make it visible.
If someone sees any regression on his architecture, we care.
Please let's stop maintaining confusion on this topic.

DPDK *is* truly open.

[dpdk-dev] [PATCH v2] net/mlx5: fix init on secondary process

[Olivier Gournet]

Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
Fixes: 21c8bb4928c9 ("net/mlx5: split Tx queue structure")

Signed-off-by: Olivier Gournet 
---
 drivers/net/mlx5/mlx5_ethdev.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index c76e754..188ade9 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -1309,11 +1309,13 @@ mlx5_secondary_data_setup(struct priv *priv)
continue;
primary_txq_ctrl = container_of(primary_txq,
struct txq_ctrl, txq);
-   txq_ctrl = rte_calloc_socket("TXQ", 1, sizeof(*txq_ctrl), 0,
+   txq_ctrl = rte_calloc_socket("TXQ", 1, sizeof(*txq_ctrl) +
+(1 << primary_txq->elts_n) *
+sizeof(struct rte_mbuf *), 0,
 primary_txq_ctrl->socket);
if (txq_ctrl != NULL) {
if (txq_ctrl_setup(priv->dev,
-  primary_txq_ctrl,
+  txq_ctrl,
   1 << primary_txq->elts_n,
   primary_txq_ctrl->socket,
   NULL) == 0) {
-- 
2.1.4

[dpdk-dev] [PATCH 1/3] eal/drivers: prefix driver REGISTER macros with EAL

[Neil Horman]

On Sat, Oct 08, 2016 at 12:47:59PM +, Shreyansh Jain wrote:
> 
> 
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Friday, October 07, 2016 7:15 PM
> > To: Shreyansh Jain 
> > Cc: david.marchand at 6wind.com; dev at dpdk.org
> > Subject: Re: [PATCH 1/3] eal/drivers: prefix driver REGISTER macros with EAL
> > 
> > 2016-10-07 19:03, Shreyansh Jain:
> > > DRIVER_REGISTER_PCI -> EAL_REGISTER_PCI
> > > DRIVER_REGISTER_PCI_TABLE -> EAL_REGISTER_PCI_TABLE
> > 
> > Why not RTE_ prefix instead of EAL_?
> 
> Because while searching for similar naming pattern I came across other macros 
> like EAL_REGISTER_TAILQ which were within librte_eal/eal/* folders.
> 
This is why we were suggesting to make the regex in the makefile more specific,
to avoid matching on the TAILQ macro.

> > Why 3 patches? As there is no specific comment in each, I think you can
> > squash.
> 
> Because each of the patch are common and tightly related changes. The 
> replacement touches a large number of files, even though the change itself is 
> small. By splitting, it makes review (or minor misses) easier - at least for 
> me.
> Anyways, if as a maintainer you prefer having a single bulk, I have no issues.
> 
> I will send next version with RTE_* and the 'grep -E' suggestion from Neil.
> 
> -
> Shreyansh
> 

[dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support to the TX path

[Yuanhan Liu]

On Mon, Oct 17, 2016 at 01:23:23PM +0200, Maxime Coquelin wrote:
> >On my side, I just setup 2 Windows 2016 VMs, and confirm the issue.
> >I'll continue the investigation early next week.
> 
> The root cause is identified.
> When INDIRECT_DESC feature is negotiated, Windows guest uses indirect
> for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD &
> virtio-net kernel driver) use indirect only for Tx.
> 
> I'll implement indirect support for the Rx path in vhost lib, but the
> change will be too big for -rc release.
> I propose in the mean time to disable INDIRECT_DESC feature in vhost
> lib, we can still enable it locally for testing.
> 
> Yuanhan, is it ok for you?

That's okay.

> 
> >Has anyone already tested Windows guest with vhost-net, which also has
> >indirect descs support?
> 
> I tested and confirm it works with vhost-net.

I'm a bit confused then. IIRC, vhost-net also doesn't support indirect
for Rx path, right?

--yliu

[dpdk-dev] [RFC v3] latencystats: added new library for latency stats

[Reshma Pattan]

Library is designed to calculate latency stats and report them to the
application when queried. Library measures minimum, average, maximum
latencies and jitter in nano seconds.
Current implementation supports global latency stats, i.e. per application
stats.

Added new field to mbuf struct to mark the packet arrival time on Rx and
use the times tamp to measure the latency on Tx.

Modified dpdk-procinfo process to display the new stats.

APIs:

Added APIs to initialize and un initialize latency stats
calculation.
Added API to retrieve latency stats names and values.

Functionality:

*Library will register ethdev Rx/Tx callbacks for each active port,
queue combinations.
*Library will register latency stats names with new stats library, which is 
under
design for now.
*Rx packets will be marked with time stamp on each sampling interval.
*On Tx side, packets with time stamp will be considered for calculating
the minimum, maximum, average latencies and jitter.
*Average latency is calculated by summing all the latencies measured for each
time stamped packet and dividing that by total time stamped packets.
*Minimum and maximum latencies will be low and high latency values observed
so far.
*Jitter calculation is done based on inter packet delay variation.
*Measured stats can be retrieved via get API of the libray (or)
by calling generic get API of the new stats library, in this case
callback is provided to update the stats  into new stats library.

Signed-off-by: Reshma Pattan 
---
 MAINTAINERS|   4 +
 app/proc_info/main.c   |  60 
 app/test-pmd/testpmd.c |   9 +
 config/common_base |  10 +
 lib/Makefile   |   1 +
 lib/librte_latencystats/Makefile   |  57 
 lib/librte_latencystats/rte_latencystats.c | 378 +
 lib/librte_latencystats/rte_latencystats.h | 141 
 .../rte_latencystats_version.map   |  10 +
 lib/librte_mbuf/rte_mbuf.h |   3 +
 mk/rte.app.mk  |   1 +
 11 files changed, 674 insertions(+)
 create mode 100644 lib/librte_latencystats/Makefile
 create mode 100644 lib/librte_latencystats/rte_latencystats.c
 create mode 100644 lib/librte_latencystats/rte_latencystats.h
 create mode 100644 lib/librte_latencystats/rte_latencystats_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 8f5fa82..2db3365 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -698,3 +698,7 @@ F: examples/tep_termination/
 F: examples/vmdq/
 F: examples/vmdq_dcb/
 F: doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst
+
+Latency Stats
+M: Reshma Pattan 
+F: lib/librte_latencystats/
diff --git a/app/proc_info/main.c b/app/proc_info/main.c
index 2c56d10..56c9509 100644
--- a/app/proc_info/main.c
+++ b/app/proc_info/main.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 

 /* Maximum long option length for option parsing. */
 #define MAX_LONG_OPT_SZ 64
@@ -75,6 +76,8 @@ static uint32_t reset_xstats;
 /**< Enable memory info. */
 static uint32_t mem_info;

+static uint32_t enable_latnbit_stats = 1;
+
 /**< display usage */
 static void
 proc_info_usage(const char *prgname)
@@ -301,6 +304,60 @@ nic_xstats_clear(uint8_t port_id)
printf("\n  NIC extended statistics for port %d cleared\n", port_id);
 }

+static void
+latnbit_stats_display(void)
+{
+   struct rte_stat_value *lat_stats;
+   struct rte_stat_name *names;
+   int len, ret;
+   static const char *nic_stats_border = "";
+
+   memset(&lat_stats, 0, sizeof(struct rte_stat_value));
+   len = rte_stats_get_names(NULL, 0);
+   if (len < 0) {
+   printf("Cannot get latency and bitrate stats count\n");
+   return;
+   }
+
+   lat_stats = malloc(sizeof(struct rte_stat_value) * len);
+   if (lat_stats == NULL) {
+   printf("Cannot allocate memory for latency and bitrate 
stats\n");
+   return;
+   }
+
+   names =  malloc(sizeof(struct rte_stat_name) * len);
+   if (names == NULL) {
+   printf("Cannot allocate memory for latency and bitrate stats 
names\n");
+   free(lat_stats);
+   return;
+   }
+
+   if (len != rte_stats_get_names(names, len)) {
+   printf("Cannot get latency and bitrate stats names\n");
+   free(lat_stats);
+   free(names);
+   return;
+   }
+
+   printf("## Latency and bitrate statistics #\n");
+   printf("%s\n", nic_stats_border);
+   ret = rte_stats_get_values(RTE_STATS_NONPORT, lat_stats, len);
+   if (ret < 0 || ret > len) {
+   printf("Cannot get latency and bitrate stats\n");
+   free(lat_stats);
+   free(names);
+   return;
+   }

[dpdk-dev] [PATCH v11 00/24] Introducing rte_driver/rte_device generalization

[Ferruh Yigit]

On 10/5/2016 12:57 PM, Shreyansh Jain wrote:
> Hi Thomas,
> 
> On Tuesday 04 October 2016 01:12 PM, Thomas Monjalon wrote:
>> 2016-10-04 12:21, Shreyansh Jain:
>>> Hi Thomas,
>>>
>>> On Monday 03 October 2016 07:58 PM, Thomas Monjalon wrote:
 Applied, thanks everybody for the great (re)work!
>>>
>>> Thanks!
>>>
> [...]
> [...]
>>>
>>> It can be merged with changes for:
>>>   - drv_name
>>>   - EAL_ before _REGISTER_ macros
>>>   - eth_driver => rte_driver naming
>>
>> Good.
>> Could you make it this week, please?
>>
> 
> Certainly. At least some of those I can send within this week :)
> 


I caught while running ABI validation script today, I think this patch
should increase LIBABIVER of:
- lib/librte_cryptodev
- lib/librte_eal
- lib/librte_ether

Thanks,
ferruh

[dpdk-dev] [PATCH v2] net/mlx5: fix init on secondary process

[Ferruh Yigit]

Hi Adrien,

On 10/17/2016 1:56 PM, Olivier Gournet wrote:
> Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
> Fixes: 21c8bb4928c9 ("net/mlx5: split Tx queue structure")
> 
> Signed-off-by: Olivier Gournet 

According your comment on previous version of it, I think you have your
Ack on this patch, but can you please confirm?

Thanks,
ferruh

[dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support to the TX path

[Maxime Coquelin]

On 10/17/2016 03:21 PM, Yuanhan Liu wrote:
> On Mon, Oct 17, 2016 at 01:23:23PM +0200, Maxime Coquelin wrote:
>>> On my side, I just setup 2 Windows 2016 VMs, and confirm the issue.
>>> I'll continue the investigation early next week.
>>
>> The root cause is identified.
>> When INDIRECT_DESC feature is negotiated, Windows guest uses indirect
>> for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD &
>> virtio-net kernel driver) use indirect only for Tx.
>> I'll implement indirect support for the Rx path in vhost lib, but the
>> change will be too big for -rc release.
>> I propose in the mean time to disable INDIRECT_DESC feature in vhost
>> lib, we can still enable it locally for testing.
>>
>> Yuanhan, is it ok for you?
>
> That's okay.
I'll send a patch to disable it then.

>
>>
>>> Has anyone already tested Windows guest with vhost-net, which also has
>>> indirect descs support?
>>
>> I tested and confirm it works with vhost-net.
>
> I'm a bit confused then. IIRC, vhost-net also doesn't support indirect
> for Rx path, right?

No, it does support it actually.
I thought it didn't support too, I misread the Kernel implementation of
vhost-net and virtio-net. Acutally, virtio-net makes use of indirect
in Rx path when mergeable buffers is disabled.

The confusion certainly comes from me, sorry about that.

Maxime

[dpdk-dev] [PATCH v2] net/mlx5: fix init on secondary process

[Adrien Mazarguil]

On Mon, Oct 17, 2016 at 02:52:39PM +0100, Ferruh Yigit wrote:
> Hi Adrien,
> 
> On 10/17/2016 1:56 PM, Olivier Gournet wrote:
> > Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
> > Fixes: 21c8bb4928c9 ("net/mlx5: split Tx queue structure")
> > 
> > Signed-off-by: Olivier Gournet 
> 
> According your comment on previous version of it, I think you have your
> Ack on this patch, but can you please confirm?

Yes it's fine, thanks.

Acked-by: Adrien Mazarguil 

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [dpdk-users] Project Governance and Linux Foundation

[O'Driscoll, Tim]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, October 17, 2016 1:41 PM
> To: users at dpdk.org; dev at dpdk.org
> Cc: O'Driscoll, Tim ; Hobywan Kenoby
> 
> Subject: Re: [dpdk-users] Project Governance and Linux Foundation
> 
> 2016-10-17 11:52, O'Driscoll, Tim:
> > From: Hobywan Kenoby
> > > The current DPDK version can run on virtually all processors (Intel,
> IBM
> > > and ARM) and leverage all NICs: is there **really** anyone
> questionning
> > > openness of the community?
> >
> > I still hear concerns on this, and based on discussions with others
> who
> > put their names to the post below, they do too.
> > I think it's a perception that we need to address.
> 
> It is simple to address this perception with fact checking.
> The next releases will provide even more code for ARM and NPUs.
> If someone submits some good code and is ignored, it is easy enough
> to ping the mailing list and make it visible.
> If someone sees any regression on his architecture, we care.
> Please let's stop maintaining confusion on this topic.
> 
> DPDK *is* truly open.

Well, to be a little more specific, the concern I've heard on many occasions is 
that 6WIND control the infrastructure for the project and so effectively have a 
veto over what's accepted into DPDK. Your argument is that you've never 
exercised that veto, which is true, but you still have the ability to do so. 
That's not a characteristic of a truly open project. As stated in the original 
post on this:

> - The infrastructure for a project like DPDK should not be owned and 
> controlled by any single company.

[dpdk-dev] [PATCH v2 0/5] i40e: vector poll-mode driver on ARM64

[Bruce Richardson]

On Fri, Oct 14, 2016 at 09:29:59AM +0530, Jianbo Liu wrote:
> This patch set is to implement i40e vector PMD on ARM64.
> For x86, vPMD is only reorganized, there should be no performance loss.
> 
> v1 -> v2
> - rebase to dpdk-next-net/rel_16_11
> 
> Jianbo Liu (5):
>   i40e: extract non-x86 specific code from vector driver
>   i40e: implement vector PMD for ARM architecture
>   i40e: enable i40e vector PMD on ARMv8a platform
>   i40e: make vector driver filenames consistent
>   maintainers: claim i40e vector PMD on ARM
> 
While I haven't reviewed the ARM code, I have run a very quick sanity
check on an IA platform and saw no performance regression there.

Acked-by: Bruce Richardson 

[dpdk-dev] [PATCH] vhost: disable indirect descriptors feature

[Maxime Coquelin]

Commit 2304dd73d287 ("vhost: support indirect Tx descriptors")
adds support for indirect descriptors for Tx, but not for Rx.

The problem is that it does not work with windows guests, which
uses indirect descriptors for the Rx, and also with Linux guests
when using kernel driver with mergeable buffers feature disabled.

While indirect descriptors support is also added to the Rx path,
let's disable the feature.

Reported-by: Zhihong Wang 
Reported-by: Ciara Loftus 
Cc: Yuanhan Liu 
Signed-off-by: Maxime Coquelin 
---
 lib/librte_vhost/vhost.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
index 469117a..f5f8f92 100644
--- a/lib/librte_vhost/vhost.c
+++ b/lib/librte_vhost/vhost.c
@@ -65,8 +65,7 @@
(1ULL << VIRTIO_NET_F_CSUM)| \
(1ULL << VIRTIO_NET_F_GUEST_CSUM) | \
(1ULL << VIRTIO_NET_F_GUEST_TSO4) | \
-   (1ULL << VIRTIO_NET_F_GUEST_TSO6) | \
-   (1ULL << VIRTIO_RING_F_INDIRECT_DESC))
+   (1ULL << VIRTIO_NET_F_GUEST_TSO6))

 uint64_t VHOST_FEATURES = VHOST_SUPPORTED_FEATURES;

-- 
2.7.4

[dpdk-dev] [PATCH 0/3] net: fix out of order rx read issue

[Qi Zhang]

Volatile point has been cast to non-volatile
point when call _mm_loadu_si128, so add compile
barrier to prevent compiler reorder.

Qi Zhang (3):
  net/i40e: fix out of order rx read issue
  net/ixgbe: fix out of order rx read issue
  net/fm10k: fix out of order rx read issue

 drivers/net/fm10k/fm10k_rxtx_vec.c | 3 +++
 drivers/net/i40e/i40e_rxtx_vec.c   | 3 +++
 drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 3 +++
 3 files changed, 9 insertions(+)

-- 
2.7.4

[dpdk-dev] [PATCH 1/3] net/i40e: fix out of order rx read issue

[Qi Zhang]

Volatile point has been cast to non-volatile
point when call _mm_loadu_si128, so add compile
barrier to prevent compiler reorder.

Fixes: 9ed94e5bb04e ("i40e: add vector Rx")

Signed-off-by: Qi Zhang 
---
 drivers/net/i40e/i40e_rxtx_vec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/i40e/i40e_rxtx_vec.c b/drivers/net/i40e/i40e_rxtx_vec.c
index 0ee0241..ab63501 100644
--- a/drivers/net/i40e/i40e_rxtx_vec.c
+++ b/drivers/net/i40e/i40e_rxtx_vec.c
@@ -305,6 +305,7 @@ _recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct 
rte_mbuf **rx_pkts,
/* Read desc statuses backwards to avoid race condition */
/* A.1 load 4 pkts desc */
descs[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));
+   rte_compiler_barrier();

/* B.2 copy 2 mbuf point into rx_pkts  */
_mm_storeu_si128((__m128i *)&rx_pkts[pos], mbp1);
@@ -313,8 +314,10 @@ _recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct 
rte_mbuf **rx_pkts,
mbp2 = _mm_loadu_si128((__m128i *)&sw_ring[pos+2]);

descs[2] = _mm_loadu_si128((__m128i *)(rxdp + 2));
+   rte_compiler_barrier();
/* B.1 load 2 mbuf point */
descs[1] = _mm_loadu_si128((__m128i *)(rxdp + 1));
+   rte_compiler_barrier();
descs[0] = _mm_loadu_si128((__m128i *)(rxdp));

/* B.2 copy 2 mbuf point into rx_pkts  */
-- 
2.7.4

[dpdk-dev] [PATCH 2/3] net/ixgbe: fix out of order rx read issue

[Qi Zhang]

Volatile point has been cast to non-volatile
point when call _mm_loadu_si128, so add compile
barrier to prevent compiler reorder.

Fixes: c95584dc2b18 ("ixgbe: new vectorized functions for Rx/Tx")

Signed-off-by: Qi Zhang 
---
 drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c 
b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
index ad8a9ff..abbf284 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
@@ -343,6 +343,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct 
rte_mbuf **rx_pkts,
/* Read desc statuses backwards to avoid race condition */
/* A.1 load 4 pkts desc */
descs[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));
+   rte_compiler_barrier();

/* B.2 copy 2 mbuf point into rx_pkts  */
_mm_storeu_si128((__m128i *)&rx_pkts[pos], mbp1);
@@ -351,8 +352,10 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct 
rte_mbuf **rx_pkts,
mbp2 = _mm_loadu_si128((__m128i *)&sw_ring[pos+2]);

descs[2] = _mm_loadu_si128((__m128i *)(rxdp + 2));
+   rte_compiler_barrier();
/* B.1 load 2 mbuf point */
descs[1] = _mm_loadu_si128((__m128i *)(rxdp + 1));
+   rte_compiler_barrier();
descs[0] = _mm_loadu_si128((__m128i *)(rxdp));

/* B.2 copy 2 mbuf point into rx_pkts  */
-- 
2.7.4

[dpdk-dev] [PATCH 3/3] net/fm10k: fix out of order rx read issue

[Qi Zhang]

Volatile point has been cast to non-volatile
point when call _mm_loadu_si128, so add compile
barrier to prevent compiler reorder.

Fixes: 7092be8437bd ("fm10k: add vector RX")

Signed-off-by: Qi Zhang 
---
 drivers/net/fm10k/fm10k_rxtx_vec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c 
b/drivers/net/fm10k/fm10k_rxtx_vec.c
index b724486..27f3e43 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -478,6 +478,7 @@ fm10k_recv_raw_pkts_vec(void *rx_queue, struct rte_mbuf 
**rx_pkts,
/* Read desc statuses backwards to avoid race condition */
/* A.1 load 4 pkts desc */
descs0[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));
+   rte_compiler_barrier();

/* B.2 copy 2 mbuf point into rx_pkts  */
_mm_storeu_si128((__m128i *)&rx_pkts[pos], mbp1);
@@ -486,8 +487,10 @@ fm10k_recv_raw_pkts_vec(void *rx_queue, struct rte_mbuf 
**rx_pkts,
mbp2 = _mm_loadu_si128((__m128i *)&mbufp[pos+2]);

descs0[2] = _mm_loadu_si128((__m128i *)(rxdp + 2));
+   rte_compiler_barrier();
/* B.1 load 2 mbuf point */
descs0[1] = _mm_loadu_si128((__m128i *)(rxdp + 1));
+   rte_compiler_barrier();
descs0[0] = _mm_loadu_si128((__m128i *)(rxdp));

/* B.2 copy 2 mbuf point into rx_pkts  */
-- 
2.7.4

[dpdk-dev] [PATCH] examples/ip_pipeline: fix freeBSD build error

[Jasvinder Singh]

Error log:
 CC init.o
 examples/ip_pipeline/init.c:38:22: fatal error: linux/if.h: No such file or 
directory
 #include 
  ^
Fixes: 3f2c9f3bb6c6 ("examples/ip_pipeline: add TAP port")

Signed-off-by: Jasvinder Singh 
---
 examples/ip_pipeline/init.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/examples/ip_pipeline/init.c b/examples/ip_pipeline/init.c
index 4fed474..3b36b53 100644
--- a/examples/ip_pipeline/init.c
+++ b/examples/ip_pipeline/init.c
@@ -35,8 +35,10 @@
 #include 
 #include 
 #include 
+#ifdef RTE_EXEC_ENV_LINUXAPP
 #include 
 #include 
+#endif
 #include 
 #include 
 #include 
@@ -1160,6 +1162,15 @@ app_init_tm(struct app_params *app)
}
 }

+#ifndef RTE_EXEC_ENV_LINUXAPP
+static void
+app_init_tap(struct app_params *app) {
+   if (app->n_pktq_tap == 0)
+   return;
+
+   rte_panic("TAP device not supported.\n");
+}
+#else
 static void
 app_init_tap(struct app_params *app)
 {
@@ -1187,6 +1198,7 @@ app_init_tap(struct app_params *app)
app->tap[i] = fd;
}
 }
+#endif

 #ifdef RTE_LIBRTE_KNI
 static int
@@ -1404,6 +1416,7 @@ void app_pipeline_params_get(struct app_params *app,
out->burst_size = app->tm_params[in->id].burst_read;
break;
}
+#ifdef RTE_EXEC_ENV_LINUXAPP
case APP_PKTQ_IN_TAP:
{
struct app_pktq_tap_params *tap_params =
@@ -1420,6 +1433,7 @@ void app_pipeline_params_get(struct app_params *app,
out->burst_size = app->tap_params[in->id].burst_read;
break;
}
+#endif
 #ifdef RTE_LIBRTE_KNI
case APP_PKTQ_IN_KNI:
{
@@ -1564,6 +1578,7 @@ void app_pipeline_params_get(struct app_params *app,
app->tm_params[in->id].burst_write;
break;
}
+#ifdef RTE_EXEC_ENV_LINUXAPP
case APP_PKTQ_OUT_TAP:
{
struct rte_port_fd_writer_params *params =
@@ -1575,6 +1590,7 @@ void app_pipeline_params_get(struct app_params *app,
app->tap_params[in->id].burst_write;
break;
}
+#endif
 #ifdef RTE_LIBRTE_KNI
case APP_PKTQ_OUT_KNI:
{
-- 
2.5.5

[dpdk-dev] [PATCH 0/3] net: fix out of order rx read issue

[Chen, Jing D]

Hi,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qi Zhang
> Sent: Monday, October 17, 2016 1:24 AM
> To: Wu, Jingjing ; Zhang, Helin
> 
> Cc: dev at dpdk.org; Zhang, Qi Z 
> Subject: [dpdk-dev] [PATCH 0/3] net: fix out of order rx read issue
> 
> Volatile point has been cast to non-volatile point when call _mm_loadu_si128,
> so add compile barrier to prevent compiler reorder.
> 
> Qi Zhang (3):
>   net/i40e: fix out of order rx read issue
>   net/ixgbe: fix out of order rx read issue
>   net/fm10k: fix out of order rx read issue
> 
>  drivers/net/fm10k/fm10k_rxtx_vec.c | 3 +++
>  drivers/net/i40e/i40e_rxtx_vec.c   | 3 +++
>  drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 3 +++
>  3 files changed, 9 insertions(+)

I have an overall comment on the committed message. You'd better to describe
why we have out of order issue here and the requirement on the execution order
of the 4 loads. 

[dpdk-dev] [PATCH v3 0/2] net/ixgbe: VMDq DCB with SRIOV

[Bernard Iremonger]

Changes in v3:
rebase to latest master.
update commit message for ixgbe patch
add testpmd patch.

Changes in v2:
rebase to  latest master.

Bernard Iremonger (2):
  net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
  app/test_pmd: fix DCB configuration

 app/test-pmd/testpmd.c   |  4 ++--
 drivers/net/ixgbe/ixgbe_ethdev.c |  9 -
 drivers/net/ixgbe/ixgbe_rxtx.c   | 37 +
 3 files changed, 27 insertions(+), 23 deletions(-)

-- 
2.10.1

[dpdk-dev] [PATCH v3 1/2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV

[Bernard Iremonger]

Modify ixgbe_check_mq_mode function,
when SRIOV is enabled, enable mq_mode
ETH_MQ_RX_VMDQ_DCB and ETH_MQ_TX_VMDQ_DCB.

Modify ixgbe_dcb_tx_hw_config function,
replace the struct ixgbe_hw parameter with a
struct rte_eth_dev parameter and handle SRIOV enabled.

Modify ixgbe_dev_mq_rx_configure function,
when SRIOV is enabled, enable mq_mode ETH_MQ_RX_VMDQ_DCB.

Modify ixgbe_configure_dcb function,
drop check on dev->data->nb_rx_queues.

Signed-off-by: Rahul R Shah 
Signed-off-by: Bernard Iremonger 
---
 drivers/net/ixgbe/ixgbe_ethdev.c |  9 -
 drivers/net/ixgbe/ixgbe_rxtx.c   | 37 +
 2 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 4ca5747..114698d 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1977,6 +1977,8 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
/* check multi-queue mode */
switch (dev_conf->rxmode.mq_mode) {
case ETH_MQ_RX_VMDQ_DCB:
+   PMD_INIT_LOG(INFO, "ETH_MQ_RX_VMDQ_DCB mode supported 
in SRIOV");
+   break;
case ETH_MQ_RX_VMDQ_DCB_RSS:
/* DCB/RSS VMDQ in SRIOV mode, not implement yet */
PMD_INIT_LOG(ERR, "SRIOV active,"
@@ -2012,11 +2014,8 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)

switch (dev_conf->txmode.mq_mode) {
case ETH_MQ_TX_VMDQ_DCB:
-   /* DCB VMDQ in SRIOV mode, not implement yet */
-   PMD_INIT_LOG(ERR, "SRIOV is active,"
-   " unsupported VMDQ mq_mode tx %d.",
-   dev_conf->txmode.mq_mode);
-   return -EINVAL;
+   PMD_INIT_LOG(INFO, "ETH_MQ_TX_VMDQ_DCB mode supported 
in SRIOV");
+   break;
default: /* ETH_MQ_TX_VMDQ_ONLY or ETH_MQ_TX_NONE */
dev->data->dev_conf.txmode.mq_mode = 
ETH_MQ_TX_VMDQ_ONLY;
break;
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 2ce8234..bb13889 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
  *   Copyright 2014 6WIND S.A.
  *   All rights reserved.
  *
@@ -3313,15 +3313,16 @@ ixgbe_vmdq_dcb_configure(struct rte_eth_dev *dev)

 /**
  * ixgbe_dcb_config_tx_hw_config - Configure general DCB TX parameters
- * @hw: pointer to hardware structure
+ * @dev: pointer to eth_dev structure
  * @dcb_config: pointer to ixgbe_dcb_config structure
  */
 static void
-ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
+ixgbe_dcb_tx_hw_config(struct rte_eth_dev *dev,
   struct ixgbe_dcb_config *dcb_config)
 {
uint32_t reg;
uint32_t q;
+   struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);

PMD_INIT_FUNC_TRACE();
if (hw->mac.type != ixgbe_mac_82598EB) {
@@ -3339,11 +3340,17 @@ ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
if (dcb_config->vt_mode)
reg |= IXGBE_MTQC_VT_ENA;
IXGBE_WRITE_REG(hw, IXGBE_MTQC, reg);
-
-   /* Disable drop for all queues */
-   for (q = 0; q < 128; q++)
-   IXGBE_WRITE_REG(hw, IXGBE_QDE,
-   (IXGBE_QDE_WRITE | (q << IXGBE_QDE_IDX_SHIFT)));
+   if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
+   /* Disable drop for all queues in VMDQ mode*/
+   for (q = 0; q < 128; q++)
+   IXGBE_WRITE_REG(hw, IXGBE_QDE,
+   (IXGBE_QDE_WRITE | (q << 
IXGBE_QDE_IDX_SHIFT) | IXGBE_QDE_ENABLE));
+   } else {
+   /* Enable drop for all queues in SRIOV mode */
+   for (q = 0; q < 128; q++)
+   IXGBE_WRITE_REG(hw, IXGBE_QDE,
+   (IXGBE_QDE_WRITE | (q << 
IXGBE_QDE_IDX_SHIFT)));
+   }

/* Enable the Tx desc arbiter */
reg = IXGBE_READ_REG(hw, IXGBE_RTTDCS);
@@ -3378,7 +3385,7 @@ ixgbe_vmdq_dcb_hw_tx_config(struct rte_eth_dev *dev,
vmdq_tx_conf->nb_queue_pools == ETH_16_POOLS ? 0x : 
0x);

/*Configure general DCB TX parameters*/
-   ixgbe_dcb_tx_hw_config(hw, dcb_config);
+   ixgbe_dcb_tx_hw_config(dev, dcb_config);
 }

 static void
@@ -3661,7 +3668,7 @@ ixgbe_dcb_hw_configure(struct rte_eth_dev *dev,
/*get DCB TX configuration parameters from rte_eth_conf*/
ixgbe_dcb_tx_config(dev, 

[dpdk-dev] [PATCH v3 2/2] app/test_pmd: fix DCB configuration

[Bernard Iremonger]

when dcb mode is DCB_VT_ENABLED set nb_rxq and nb_txq to 1.

Fixes: 2a977b891f99 ("app/testpmd: fix DCB configuration")
Signed-off-by: Bernard Iremonger 
---
 app/test-pmd/testpmd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 6185be6..ee567c3 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2002,8 +2002,8 @@ init_port_dcb_config(portid_t pid,
 * and has the same number of rxq and txq in dcb mode
 */
if (dcb_mode == DCB_VT_ENABLED) {
-   nb_rxq = rte_port->dev_info.max_rx_queues;
-   nb_txq = rte_port->dev_info.max_tx_queues;
+   nb_rxq = 1;
+   nb_txq = 1;
} else {
/*if vt is disabled, use all pf queues */
if (rte_port->dev_info.vmdq_pool_base == 0) {
-- 
2.10.1

[dpdk-dev] [PATCH v5 1/6] ethdev: add Tx preparation

[Kulasek, TomaszX]

Hi Thomas,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, October 14, 2016 16:20
> To: Kulasek, TomaszX 
> Cc: dev at dpdk.org; Ananyev, Konstantin ;
> olivier.matz at 6wind.com
> Subject: Re: [dpdk-dev] [PATCH v5 1/6] ethdev: add Tx preparation
> 
> 2016-10-14 14:02, Kulasek, TomaszX:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > 2016-10-13 19:36, Tomasz Kulasek:
> > > > +/**
> > > > + * Fix pseudo header checksum for TSO and non-TSO tcp/udp packets
> > > before
> > > > + * hardware tx checksum.
> > > > + * For non-TSO tcp/udp packets full pseudo-header checksum is
> > > > + counted
> > > and set.
> > > > + * For TSO the IP payload length is not included.
> > > > + */
> > > > +static inline int
> > > > +rte_phdr_cksum_fix(struct rte_mbuf *m)
> > >
> > > You probably don't need this function since the recent improvements
> > > from Olivier.
> >
> > Do you mean this improvement: "net: add function to calculate a checksum
> in a mbuf"
> > http://dpdk.org/dev/patchwork/patch/16542/
> >
> > I see only full raw checksum computation on mbuf in Olivier patches,
> while this function counts only pseudo-header checksum to be used with tx
> offload.
> 
> OK. Please check what exists already in librte_net (especially rte_ip.h)
> and try to re-use code if possible. Thanks

I have already sent v6 with requested changes in Friday. There's no equivalent 
of rte_phdr_cksum_fix in librte_net. This function already uses 
rte_ipv4_phdr_cksum and rte_ipv6_phdr_cksum and there's nothing similar on the 
higher level to simplify it even more.

Tomasz

[dpdk-dev] [PATCH v2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV

[Iremonger, Bernard]

Hi Wenzhuo,



> > Subject: [PATCH v2] net/ixgbe: support multiqueue mode VMDq DCB with
> > SRIOV
> >
> > modify ixgbe_dcb_tx_hw_config function.
> > modify ixgbe_dev_mq_rx_configure function.
> > modify ixgbe_configure_dcb function.
> Would you like to add more details about why we need to modify these
> functions and what has been done? Thanks.

I have updated the commit message for this patch with more information.
I have also added a testpmd patch and sent a v3 patchset.


> > Changes in v2:
> > Rebased to DPDK v16.11-rc1
> >
> > Signed-off-by: Rahul R Shah 
> > Signed-off-by: Bernard Iremonger 
> > ---
> >  drivers/net/ixgbe/ixgbe_ethdev.c |  9 -
> >  drivers/net/ixgbe/ixgbe_rxtx.c   | 37 +
> 
> >  2 files changed, 25 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > index 4ca5747..114698d 100644
> > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > @@ -1977,6 +1977,8 @@ ixgbe_check_mq_mode(struct rte_eth_dev
> *dev)
> > /* check multi-queue mode */
> > switch (dev_conf->rxmode.mq_mode) {
> > case ETH_MQ_RX_VMDQ_DCB:
> Should we store the mq mode here?

Yes, it probably should be stored here.


> > +   PMD_INIT_LOG(INFO, "ETH_MQ_RX_VMDQ_DCB
> > mode supported in SRIOV");
> > +   break;
> > case ETH_MQ_RX_VMDQ_DCB_RSS:
> > /* DCB/RSS VMDQ in SRIOV mode, not implement
> yet */
> > PMD_INIT_LOG(ERR, "SRIOV active,"
> > @@ -2012,11 +2014,8 @@ ixgbe_check_mq_mode(struct rte_eth_dev
> *dev)
> >
> > switch (dev_conf->txmode.mq_mode) {
> > case ETH_MQ_TX_VMDQ_DCB:
> > -   /* DCB VMDQ in SRIOV mode, not implement yet */
> > -   PMD_INIT_LOG(ERR, "SRIOV is active,"
> > -   " unsupported VMDQ mq_mode
> > tx %d.",
> > -   dev_conf->txmode.mq_mode);
> > -   return -EINVAL;
> > +   PMD_INIT_LOG(INFO, "ETH_MQ_TX_VMDQ_DCB
> mode
> > supported in SRIOV");
> > +   break;
> > default: /* ETH_MQ_TX_VMDQ_ONLY or
> ETH_MQ_TX_NONE */
> > dev->data->dev_conf.txmode.mq_mode =
> ETH_MQ_TX_VMDQ_ONLY;
> > break;
> > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c
> > b/drivers/net/ixgbe/ixgbe_rxtx.c index
> > 2ce8234..bb13889 100644
> > --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> > +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> > @@ -1,7 +1,7 @@
> >  /*-
> >   *   BSD LICENSE
> >   *
> > - *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> > + *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> >   *   Copyright 2014 6WIND S.A.
> >   *   All rights reserved.
> >   *
> > @@ -3313,15 +3313,16 @@ ixgbe_vmdq_dcb_configure(struct
> rte_eth_dev
> > *dev)
> >
> >  /**
> >   * ixgbe_dcb_config_tx_hw_config - Configure general DCB TX
> > parameters
> > - * @hw: pointer to hardware structure
> > + * @dev: pointer to eth_dev structure
> >   * @dcb_config: pointer to ixgbe_dcb_config structure
> >   */
> >  static void
> > -ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
> > +ixgbe_dcb_tx_hw_config(struct rte_eth_dev *dev,
> >struct ixgbe_dcb_config *dcb_config)  {
> > uint32_t reg;
> > uint32_t q;
> > +   struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data-
> > >dev_private);
> >
> > PMD_INIT_FUNC_TRACE();
> > if (hw->mac.type != ixgbe_mac_82598EB) { @@ -3339,11 +3340,17
> @@
> > ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
> > if (dcb_config->vt_mode)
> > reg |= IXGBE_MTQC_VT_ENA;
> > IXGBE_WRITE_REG(hw, IXGBE_MTQC, reg);
> > -
> > -   /* Disable drop for all queues */
> > -   for (q = 0; q < 128; q++)
> > -   IXGBE_WRITE_REG(hw, IXGBE_QDE,
> > -   (IXGBE_QDE_WRITE | (q <<
> > IXGBE_QDE_IDX_SHIFT)));
> > +   if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
> > +   /* Disable drop for all queues in VMDQ mode*/
> > +   for (q = 0; q < 128; q++)
> > +   IXGBE_WRITE_REG(hw, IXGBE_QDE,
> > +   (IXGBE_QDE_WRITE | (q <<
> > IXGBE_QDE_IDX_SHIFT) | IXGBE_QDE_ENABLE));
> > +   } else {
> > +   /* Enable drop for all queues in SRIOV mode */
> > +   for (q = 0; q < 128; q++)
> > +   IXGBE_WRITE_REG(hw, IXGBE_QDE,
> > +   (IXGBE_QDE_WRITE | (q <<
> > IXGBE_QDE_IDX_SHIFT)));
> > +   }
> I think it has nothing to do with mq mode. Do I miss something?

Behavior is different when SRIOV is enabled.

> 
> >
> > /* Enable the Tx desc arbiter */
> > reg = IXGBE_READ_REG(hw, IXGBE_RTTDCS); @@ 

[dpdk-dev] [PATCH v3 02/32] qede/base: formatting changes

[Ferruh Yigit]

Hi Rasesh,

On 10/15/2016 9:07 PM, Rasesh Mody wrote:
> Fixes white spaces and tabs.
> 
> Signed-off-by: Rasesh Mody 
> ---

When testing patch by patch compilation, applying this patch gives
following build error, the build error disappears after patch 12/32.

It should successfully compile after each patch, can you please fix this?


Build error:

.../drivers/net/qede/base/ecore_sp_commands.c: In function
?ecore_sp_pf_update_tunn_cfg?:
.../drivers/net/qede/base/ecore_sp_commands.c:473:2: error: this ?if?
clause does not guard... [-Werror=misleading-indentation]
  if (p_tunn->update_geneve_udp_port)
  ^~
.../drivers/net/qede/base/ecore_sp_commands.c:477:3: note: ...this
statement, but the latter is misleadingly indented as if it is guarded
by the ?if?
   ecore_set_hw_tunn_mode(p_hwfn, p_hwfn->p_main_ptt,
   ^~
cc1: all warnings being treated as errors
make[10]: *** [base/ecore_sp_commands.o] Error 1
make[10]: *** Waiting for unfinished jobs
.../drivers/net/qede/base/ecore_spq.c: In function ?ecore_spq_add_entry?:
.../drivers/net/qede/base/ecore_spq.c:628:3: error: this ?if? clause
does not guard... [-Werror=misleading-indentation]
   if (p_ent->comp_cb.cookie == &p_ent->comp_done)
   ^~
.../drivers/net/qede/base/ecore_spq.c:631:4: note: ...this statement,
but the latter is misleadingly indented as if it is guarded by the ?if?
*p_en2 = *p_ent;
^
cc1: all warnings being treated as errors


Thanks,
ferruh

[dpdk-dev] [PATCH v4 0/2] net/ixgbe: VMDq DCB with SRIOV

[Bernard Iremonger]

Changes in v4:
changes to ixgbe patch following comments.

Changes in v3:
rebase to latest master.
update commit message for ixgbe patch
add testpmd patch.

Changes in v2:
rebase to  latest master.

Bernard Iremonger (2):
  net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
  app/test_pmd: fix DCB configuration

 app/test-pmd/testpmd.c   |  4 ++--
 drivers/net/ixgbe/ixgbe_ethdev.c | 11 ++-
 drivers/net/ixgbe/ixgbe_rxtx.c   | 36 ++--
 3 files changed, 30 insertions(+), 21 deletions(-)

-- 
2.10.1

[dpdk-dev] [PATCH v4 1/2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV

[Bernard Iremonger]

Modify ixgbe_check_mq_mode function,
when SRIOV is enabled, enable mq_mode
ETH_MQ_RX_VMDQ_DCB and ETH_MQ_TX_VMDQ_DCB.

Modify ixgbe_dcb_tx_hw_config function,
replace the struct ixgbe_hw parameter with a
struct rte_eth_dev parameter and handle SRIOV enabled.

Modify ixgbe_dev_mq_rx_configure function,
when SRIOV is enabled, enable mq_mode ETH_MQ_RX_VMDQ_DCB.

Modify ixgbe_configure_dcb function,
drop check on dev->data->nb_rx_queues.

Signed-off-by: Rahul R Shah 
Signed-off-by: Bernard Iremonger 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 11 ++-
 drivers/net/ixgbe/ixgbe_rxtx.c   | 36 ++--
 2 files changed, 28 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 4ca5747..4d5ce83 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1977,6 +1977,9 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
/* check multi-queue mode */
switch (dev_conf->rxmode.mq_mode) {
case ETH_MQ_RX_VMDQ_DCB:
+   PMD_INIT_LOG(INFO, "ETH_MQ_RX_VMDQ_DCB mode supported 
in SRIOV");
+   dev->data->dev_conf.rxmode.mq_mode = ETH_MQ_RX_VMDQ_DCB;
+   break;
case ETH_MQ_RX_VMDQ_DCB_RSS:
/* DCB/RSS VMDQ in SRIOV mode, not implement yet */
PMD_INIT_LOG(ERR, "SRIOV active,"
@@ -2012,11 +2015,9 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)

switch (dev_conf->txmode.mq_mode) {
case ETH_MQ_TX_VMDQ_DCB:
-   /* DCB VMDQ in SRIOV mode, not implement yet */
-   PMD_INIT_LOG(ERR, "SRIOV is active,"
-   " unsupported VMDQ mq_mode tx %d.",
-   dev_conf->txmode.mq_mode);
-   return -EINVAL;
+   PMD_INIT_LOG(INFO, "ETH_MQ_TX_VMDQ_DCB mode supported 
in SRIOV");
+   dev->data->dev_conf.txmode.mq_mode = ETH_MQ_TX_VMDQ_DCB;
+   break;
default: /* ETH_MQ_TX_VMDQ_ONLY or ETH_MQ_TX_NONE */
dev->data->dev_conf.txmode.mq_mode = 
ETH_MQ_TX_VMDQ_ONLY;
break;
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 2ce8234..4c13ed2 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
  *   Copyright 2014 6WIND S.A.
  *   All rights reserved.
  *
@@ -3313,15 +3313,16 @@ ixgbe_vmdq_dcb_configure(struct rte_eth_dev *dev)

 /**
  * ixgbe_dcb_config_tx_hw_config - Configure general DCB TX parameters
- * @hw: pointer to hardware structure
+ * @dev: pointer to eth_dev structure
  * @dcb_config: pointer to ixgbe_dcb_config structure
  */
 static void
-ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
+ixgbe_dcb_tx_hw_config(struct rte_eth_dev *dev,
   struct ixgbe_dcb_config *dcb_config)
 {
uint32_t reg;
uint32_t q;
+   struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);

PMD_INIT_FUNC_TRACE();
if (hw->mac.type != ixgbe_mac_82598EB) {
@@ -3339,11 +3340,17 @@ ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
if (dcb_config->vt_mode)
reg |= IXGBE_MTQC_VT_ENA;
IXGBE_WRITE_REG(hw, IXGBE_MTQC, reg);
-
-   /* Disable drop for all queues */
-   for (q = 0; q < 128; q++)
-   IXGBE_WRITE_REG(hw, IXGBE_QDE,
-   (IXGBE_QDE_WRITE | (q << IXGBE_QDE_IDX_SHIFT)));
+   if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
+   /* Disable drop for all queues in VMDQ mode*/
+   for (q = 0; q < 128; q++)
+   IXGBE_WRITE_REG(hw, IXGBE_QDE,
+   (IXGBE_QDE_WRITE | (q << 
IXGBE_QDE_IDX_SHIFT) | IXGBE_QDE_ENABLE));
+   } else {
+   /* Enable drop for all queues in SRIOV mode */
+   for (q = 0; q < 128; q++)
+   IXGBE_WRITE_REG(hw, IXGBE_QDE,
+   (IXGBE_QDE_WRITE | (q << 
IXGBE_QDE_IDX_SHIFT)));
+   }

/* Enable the Tx desc arbiter */
reg = IXGBE_READ_REG(hw, IXGBE_RTTDCS);
@@ -3378,7 +3385,7 @@ ixgbe_vmdq_dcb_hw_tx_config(struct rte_eth_dev *dev,
vmdq_tx_conf->nb_queue_pools == ETH_16_POOLS ? 0x : 
0x);

/*Configure general DCB TX parameters*/
-   ixgbe_dcb_tx_hw_config(hw, dcb_config);
+   ixgbe_dcb_tx_hw_config(dev, dcb_config);
 }

 static void
@@ -3661,7 +3668,7 @@ 

[dpdk-dev] [PATCH v4 2/2] app/test_pmd: fix DCB configuration

[Bernard Iremonger]

when dcb mode is DCB_VT_ENABLED set nb_rxq and nb_txq to 1.

Fixes: 2a977b891f99 ("app/testpmd: fix DCB configuration")
Signed-off-by: Bernard Iremonger 
---
 app/test-pmd/testpmd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 6185be6..ee567c3 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2002,8 +2002,8 @@ init_port_dcb_config(portid_t pid,
 * and has the same number of rxq and txq in dcb mode
 */
if (dcb_mode == DCB_VT_ENABLED) {
-   nb_rxq = rte_port->dev_info.max_rx_queues;
-   nb_txq = rte_port->dev_info.max_tx_queues;
+   nb_rxq = 1;
+   nb_txq = 1;
} else {
/*if vt is disabled, use all pf queues */
if (rte_port->dev_info.vmdq_pool_base == 0) {
-- 
2.10.1

[dpdk-dev] [PATCH] examples/ipsec-secgw: Update checksum while decrementing ttl

[De Lara Guarch, Pablo]

> -Original Message-
> From: Gonzalez Monroy, Sergio
> Sent: Monday, October 10, 2016 5:05 AM
> To: De Lara Guarch, Pablo; Akhil Goyal; dev at dpdk.org
> Subject: Re: [PATCH] examples/ipsec-secgw: Update checksum while
> decrementing ttl
> 
> On 07/10/2016 21:53, De Lara Guarch, Pablo wrote:
> >> -Original Message-
> >> From: Akhil Goyal [mailto:akhil.goyal at nxp.com]
> >> Sent: Tuesday, October 04, 2016 11:33 PM
> >> To: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio; dev at dpdk.org
> >> Subject: Re: [PATCH] examples/ipsec-secgw: Update checksum while
> >> decrementing ttl
> >>
> >> On 10/5/2016 6:04 AM, De Lara Guarch, Pablo wrote:
> >>>
>  -Original Message-
>  From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sergio
> Gonzalez
>  Monroy
>  Sent: Monday, September 26, 2016 6:28 AM
>  To: akhil.goyal at nxp.com; dev at dpdk.org
>  Subject: Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: Update
> checksum
>  while decrementing ttl
> 
>  Hi Akhil,
> 
>  This application relies on checksum offload in both outbound and
> >> inbound
>  paths (PKT_TX_IP_CKSUM flag).
> >> [Akhil]Agreed that the application relies on checksum offload, but here
> >> we are talking about the inner ip header. Inner IP checksum will be
> >> updated on the next end point after decryption. This would expect that
> >> the next end point must have checksum offload capability. What if we are
> >> capturing the encrypted packets on wireshark or say send it to some
> >> other machine which does not run DPDK and do not know about
> checksum
> >> offload, then wireshark/other machine will not be able to get the
> >> correct the checksum and will show error.
> 
> Understood, we need to have a valid inner checksum.
> RFC1624 states that the computation would be incorrect in
> corner/boundary case.
> I reckon you are basing your incremental update on RFC1141?
> 
> Also I think you should take care of endianess and increment the
> checksum with
> host_to_be(0x0100) instead of +1.
> 
>  Because we assume that we always forward the packet in both paths,
> we
>  decrement the ttl in both inbound and outbound.
>  You seem to only increment (recalculate) the checksum of the inner IP
>  header in the outbound path but not the inbound path.
> >> [Akhil]Correct I missed out the inbound path.
>  Also, in the inbound path you have to consider a possible ECN value
> >> update.
> >> [Akhil]If I take care of the ECN then it would mean I need to calculate
> >> the checksum completely, incremental checksum wont give correct results.
> >> This would surely impact performance. Any suggestion on how should we
> >> take care of ECN update. Should I recalculate the checksum and send the
> >> patch for ECN update? Or do we have a better solution.
> 
> If I am understanding the RFCs mentioned above correctly, you should be
> able to do
> incremental checksum update for any 16bit field/value of the IP header.
> I don't see no reason why you couldn't do something like that, except
> that you would
> have to follow the full equation instead of just adding 0x0100, which
> would be always
> the case when decrementing TTL.
> 
> What do you think?

Any comments, Akhil?

[dpdk-dev] [PATCH v3 00/32] qede: update qede pmd to 1.2.0.1 and enable by default

[Ferruh Yigit]

On 10/15/2016 9:07 PM, Rasesh Mody wrote:
> Hi,
> 
> This patch set includes changes to update the base driver, work with
> newer FW 8.10.9.0, adds new features, includes enhancements and code
> cleanup, provides bug fixes and updates documentation for the QEDE
> poll mode driver.
> 
> It enables QEDE PMD in the dpdk config by default. The dependency on
> external library libz has been addressed.
> 
> The patch set updates the QEDE PMD to 1.2.0.1.
> 
> Review comments recived for v2 series have been addressed.
> 
> Please apply to DPDK tree for v16.11 release.
> 
> Thanks!
> Rasesh
> 
> Harish Patil (14):
>   qede: change the API signature of ecore_mcp_cmd_and_union()
>   qede: serialize access to MFW mbox
>   qede: add APIs to support NIC selftests and query sensor info.
>   qede: fix port (re)configuration issue
>   qede/base: allow MTU change via vport-update
>   qede: add missing 100G link speed capability
>   qede: remove unused/dead code
>   qede: fixes for VLAN filters
>   qede: add enable/disable VLAN filtering
>   qede: fix RSS related issues
>   qede/base: add support to initiate PF FLR
>   qede: skip slowpath polling for 100G VF device
>   qede: fix driver version string
>   qede: fix status_blk index for VF queues
> 
> Rasesh Mody (16):
>   qede/base: add new init files and rearrange the code
>   qede/base: formatting changes
>   qede: use FW CONFIG defines as needed
>   qede/base: add HSI changes and register defines
>   qede/base: fix the attention formating string
>   qede/base: additional formatting/comment changes
>   qede: fix 32 bit compilation
>   qede/base: update base driver
>   qede/base: rename structure and defines
>   qede/base: comment enhancements
>   qede/base: add MFW crash dump support
>   qede/base: change rx tx queue start APIs
>   qede: add support for queue statistics
>   qede: remove zlib dependency and enable PMD by default
>   doc: update qede pmd documentation
>   qede: update driver version
> 
> Sony Chacko (2):
>   qede: enable support for unequal number of RX/TX queues
>   qede: add scatter gather support
> 

Hi Rasesh,

This version of the patchset received after RC1, and to be in this
release only remaining chance is to be merged in RC2.

And I would like to remind you that after RC2 you will have little time
to test your new driver, would you like to push the driver to next
release or stick with this one?

If you stick to release, can you please send new version -because of
patch by patch compile error- timely so that it gives some time to
reviewers before RC2?

Thanks,
ferruh

[dpdk-dev] [PATCH v11 00/24] Introducing rte_driver/rte_device generalization

[Shreyansh Jain]

Hi Ferruh,

> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yigit at intel.com]
> Sent: Monday, October 17, 2016 7:13 PM
> To: Shreyansh Jain ; Thomas Monjalon
> 
> Cc: dev at dpdk.org; viktorin at rehivetech.com; David Marchand
> ; Hemant Agrawal 
> Subject: Re: [dpdk-dev] [PATCH v11 00/24] Introducing rte_driver/rte_device
> generalization
> 
> On 10/5/2016 12:57 PM, Shreyansh Jain wrote:
> > Hi Thomas,
> >
> > On Tuesday 04 October 2016 01:12 PM, Thomas Monjalon wrote:
> >> 2016-10-04 12:21, Shreyansh Jain:
> >>> Hi Thomas,
> >>>
> >>> On Monday 03 October 2016 07:58 PM, Thomas Monjalon wrote:
>  Applied, thanks everybody for the great (re)work!
> >>>
> >>> Thanks!
> >>>
> > [...]
> > [...]
> >>>
> >>> It can be merged with changes for:
> >>>   - drv_name
> >>>   - EAL_ before _REGISTER_ macros
> >>>   - eth_driver => rte_driver naming
> >>
> >> Good.
> >> Could you make it this week, please?
> >>
> >
> > Certainly. At least some of those I can send within this week :)
> >
> 
> 
> I caught while running ABI validation script today, I think this patch
> should increase LIBABIVER of:
> - lib/librte_cryptodev
> - lib/librte_eal
> - lib/librte_ether

Should I be referring to [1] for understanding how/when to change the LIBABIVER?

[1] http://dpdk.org/doc/guides/contributing/versioning.html

> 
> Thanks,
> ferruh

[dpdk-dev] [PATCH] app/test: add tests with corrupted data for QAT test suite

[De Lara Guarch, Pablo]

> -Original Message-
> From: Jain, Deepak K
> Sent: Friday, October 14, 2016 1:14 AM
> To: Kusztal, ArkadiuszX; dev at dpdk.org
> Cc: Trahe, Fiona; De Lara Guarch, Pablo; Griffin, John
> Subject: RE: [PATCH] app/test: add tests with corrupted data for QAT test
> suite
> 
> 
> 
> > -Original Message-
> > From: Kusztal, ArkadiuszX
> > Sent: Thursday, October 13, 2016 11:04 AM
> > To: dev at dpdk.org
> > Cc: Trahe, Fiona ; Jain, Deepak K
> > ; De Lara Guarch, Pablo
> > ; Griffin, John  > intel.com>;
> > Kusztal, ArkadiuszX 
> > Subject: [PATCH] app/test: add tests with corrupted data for QAT test suite
> >
> > This commit adds tests with corrupted data to the Intel QuickAssist
> > Technology tests suite in test_cryptodev.c
> >
> > Signed-off-by: Arek Kusztal 
> > ---
> >  app/test/test_cryptodev.c | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> >  };
> > --
> > 2.1.0
> Acked-by: Deepak Kumar Jain 

Applied to dpdk-next-crypto.
Thanks,

Pablo

[dpdk-dev] [PATCH] app/test: add crypto continual tests

[De Lara Guarch, Pablo]

> -Original Message-
> From: Kusztal, ArkadiuszX
> Sent: Thursday, October 13, 2016 5:18 AM
> To: dev at dpdk.org
> Cc: Trahe, Fiona; De Lara Guarch, Pablo; Griffin, John; Jain, Deepak K; 
> Kusztal,
> ArkadiuszX
> Subject: [PATCH] app/test: add crypto continual tests
> 
> This commit adds continual performace tests to Intel(R) QuickAssist
> Technology tests suite. Performance tests are run continually with
> some number of repeating loops.
> 
> Signed-off-by: Arek Kusztal 

Applied to dpdk-next-crypto.
Thanks,

Pablo

[dpdk-dev] [PATCH] kni: fix build with kernel 4.9

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Monday, October 17, 2016 3:23 AM
> To: dev at dpdk.org
> Cc: Yigit, Ferruh
> Subject: [dpdk-dev] [PATCH] kni: fix build with kernel 4.9
> 
> compile error:
>   CC [M]  .../lib/librte_eal/linuxapp/kni/igb_main.o
> .../lib/librte_eal/linuxapp/kni/igb_main.c:2317:21:
> error: initialization from incompatible pointer type
>   [-Werror=incompatible-pointer-types]
>   .ndo_set_vf_vlan = igb_ndo_set_vf_vlan,
>  ^~~
> 
> Linux kernel 4.9 updates API for ndo_set_vf_vlan:
> Linux: 79aab093a0b5 ("net: Update API for VF vlan protocol 802.1ad
> support")
> 
> Use new API for Linux kernels >= 4.9
> 
> Signed-off-by: Ferruh Yigit 
Tested-by: Pablo de Lara 

[dpdk-dev] [PATCH] app/testpmd: fix pf/vf check of flow director

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Sunday, October 09, 2016 7:47 PM
> To: dev at dpdk.org
> Cc: Lu, Wenzhuo
> Subject: [dpdk-dev] [PATCH] app/testpmd: fix pf/vf check of flow director
> 
> Parameters pf & vf are added into most of flow director
> filter CLIs.
> But mac-valn and tunnel filters don't have these parameters,
> the parameters should not be checked for mac-vlan and tunnel
> filters.
> 
> Fixes: e6a68c013353 ("app/testpmd: extend commands for flow director in
> VF")
> Signed-off-by: Wenzhuo Lu 

Check-git-log script throws a couple of errors:

Wrong headline lowercase:
app/testpmd: fix pf/vf check of flow director -> PF/VF
Missing blank line after 'Fixes' tag:
Fixes: e6a68c013353 ("app/testpmd: extend commands for flow director in 
VF")

Apart from this:
Acked-by: Pablo de Lara 

[dpdk-dev] [PATCH v2 2/3] app/testpmd: fix wrong flow director mask

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, October 11, 2016 11:24 PM
> To: dev at dpdk.org
> Cc: Lu, Wenzhuo
> Subject: [dpdk-dev] [PATCH v2 2/3] app/testpmd: fix wrong flow director mask
> 
> In mac-vlan mode, MAC address mask is not supported by HW.
> The MAC address mask should not be set in mac-vlan mode.
> Remove this parameter from the CLI. Remove MAC address
> from mask print too.
> 
> Fixes: 53b2bb9b7ea7 ("app/testpmd: new flow director commands")
> Signed-off-by: Wenzhuo Lu 

Commit message should have a space between the Fixes and the Signed-off line.
Apart from that:

Acked-by: Pablo de Lara 

[dpdk-dev] [PATCH v2 3/3] app/testpmd: fix flow director endian issue

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, October 11, 2016 11:24 PM
> To: dev at dpdk.org
> Cc: Lu, Wenzhuo
> Subject: [dpdk-dev] [PATCH v2 3/3] app/testpmd: fix flow director endian
> issue
> 
> The vlan mask and tunnel id mask of flow director
> are defined as big endian. So they should be
> converted.
> When the mask is printed, the parameters are not
> converted either. This patch converts the mask
> parameters.
> Some lines of the mask print are too long, split
> them to more lines.
> 
> Fixes: 7c554b4f0484 ("app/testpmd: update display of flow director
> information")
> Fixes: 53b2bb9b7ea7 ("app/testpmd: new flow director commands")
> Signed-off-by: Wenzhuo Lu 

Commit message should have a space between the Fixes and the Signed-off line.
Apart from that:

Acked-by: Pablo de Lara 

[dpdk-dev] [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK

[Eads, Gage]

>  -Original Message-
>  From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
>  Sent: Sunday, October 16, 2016 11:18 PM
>  To: Eads, Gage 
>  Cc: dev at dpdk.org; thomas.monjalon at 6wind.com; Richardson, Bruce
>  ; Vangati, Narender
>  ; hemant.agrawal at nxp.com
>  Subject: Re: [dpdk-dev] [RFC] [PATCH v2] libeventdev: event driven
>  programming model framework for DPDK
>  
>  On Fri, Oct 14, 2016 at 03:00:57PM +, Eads, Gage wrote:
>  > Thanks Jerin, this looks good. I've put a few notes/questions inline.
>  
>  Thanks Gage.
>  
>  >
>  > >  +
>  > >  +/**
>  > >  + * Get the device identifier for the named event device.
>  > >  + *
>  > >  + * @param name
>  > >  + *   Event device name to select the event device identifier.
>  > >  + *
>  > >  + * @return
>  > >  + *   Returns event device identifier on success.
>  > >  + *   - <0: Failure to find named event device.
>  > >  + */
>  > >  +extern uint8_t
>  > >  +rte_event_dev_get_dev_id(const char *name);
>  >
>  > This return type should be int8_t, or some signed type, to support the 
> failure
>  case.
>  
>  Makes sense. I will change to int to make consistent with
>  rte_cryptodev_get_dev_id()
>  
>  >
>  > >  +};
>  > >  +
>  > >  +/**
>  > >  + * Schedule one or more events in the event dev.
>  > >  + *
>  > >  + * An event dev implementation may define this is a NOOP, for
>  > > instance if  + * the event dev performs its scheduling in hardware.
>  > >  + *
>  > >  + * @param dev_id
>  > >  + *   The identifier of the device.
>  > >  + */
>  > >  +extern void
>  > >  +rte_event_schedule(uint8_t dev_id);
>  >
>  > One idea: Have the function return the number of scheduled packets (or 0 
> for
>  implementations that do scheduling in hardware). This could be a helpful
>  diagnostic for the software scheduler.
>  
>  How about returning an implementation specific value ?
>  Rather than defining certain function associated with returned value.
>  Just to  make sure it works with all HW/SW implementations. Something like
>  below,
>  
>  /**
>   * Schedule one or more events in the event dev.
>   *
>   * An event dev implementation may define this is a NOOP, for instance if
>   * the event dev performs its scheduling in hardware.
>   *
>   * @param dev_id
>   *   The identifier of the device.
>   * @return
>   *   Implementation specific value from the event driver for diagnostic 
> purpose
>   */
>  extern int
>  rte_event_schedule(uint8_t dev_id);
>  
>  

That's fine by me.

I also had a comment on the return value of rte_event_dev_info_get() in my 
previous email: "I'm wondering if this return type should be int, so we can 
return an error if the dev_id is invalid."

What do you think?

Thanks,
Gage

>  
>  

[dpdk-dev] Project Governance and Linux Foundation

[Dave Neary]

Hi,

On 10/17/2016 07:52 AM, O'Driscoll, Tim wrote:
>> -Original Message-
>> I don't really understand what can be gained by moving to Linux
>> Foundation, but I am almost sure that no individual expert will be able
>> to take any leaderhip role as those roles will be fulfilled by Platinum,
>> Gold or Silver members: right ?
> 
> No. If DPDK were to move to LF as an independent project, then as discussed 
> at the Userspace event in Dublin last year, and as documented in the original 
> post below, the intention would be not to make any significant changes to the 
> technical governance.
> 
> If DPDK were to move to FD.io the situation would be the same. The FD.io 
> Technical Community Charter 
> (https://fd.io/governance/technical-community-charter) specifies how Project 
> Technical Leaders and Committers are nominated and approved, but there's no 
> requirement for people in those roles to come from Platinum, Gold or Silver 
> FD.io members. Those decisions are based purely on technical merit.

I just want to second what Tim said - it's important for Red Hat, at
least, that the technical governance of a project be kept separate from
any membership of an organization managing the budget for the project.

The technical management of the project can also be discussed, but it is
out of scope, IMHO, when talking about moving to fd.io or the Linux
Foundation.

>> The current DPDK version can run on virtually all processors (Intel, IBM
>> and ARM) and leverage all NICs: is there **really** anyone questionning
>> openness of the community?
> 
> I still hear concerns on this, and based on discussions with others who put 
> their names to the post below, they do too. I think it's a perception that we 
> need to address.

I would say that there is still a perception issue, for companies who
look at the active developers, the owners of the project's resources
(infra, domain name), and who have heard anecdotal evidence of issues in
the past. I think the project has made a lot of progress since I have
been following it, and I do not believe there are any major issues with
the independence of the project. However, there are still concerned
parties on this front, and the concerns can be easily addressed by a
move to the LF.

Regards,
Dave.

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

[dpdk-dev] [PATCH] net/enic: fix fdir UDP v4 source port mask

[John Daley]

This fixes issue found by Coverity where a typo caused the flow director
UDP IPv4 source port mask to be assigned the destination port mask
supplied by the caller.

Coverity issue: 137860

Fixes: dfbd6a9cb504 ("net/enic: extend flow director support for 1300 series")

Signed-off-by: John Daley 
---
 drivers/net/enic/enic_clsf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/enic/enic_clsf.c b/drivers/net/enic/enic_clsf.c
index d2413d7..53a7977 100644
--- a/drivers/net/enic/enic_clsf.c
+++ b/drivers/net/enic/enic_clsf.c
@@ -155,7 +155,7 @@ copy_fltr_v2(struct filter_v2 *fltr, struct 
rte_eth_fdir_input *input,
udp_val.src_port = input->flow.udp4_flow.src_port;
}
if (input->flow.udp4_flow.dst_port) {
-   udp_mask.src_port = masks->dst_port_mask;
+   udp_mask.dst_port = masks->dst_port_mask;
udp_val.dst_port = input->flow.udp4_flow.dst_port;
}

-- 
2.10.0

[dpdk-dev] [PATCH v3 02/32] qede/base: formatting changes

[Mody, Rasesh]

Hi Ferruh,

> From: Ferruh Yigit [mailto:ferruh.yigit at intel.com]
> Sent: Monday, October 17, 2016 9:28 AM
> 
> Hi Rasesh,
> 
> On 10/15/2016 9:07 PM, Rasesh Mody wrote:
> > Fixes white spaces and tabs.
> >
> > Signed-off-by: Rasesh Mody 
> > ---
> 
> When testing patch by patch compilation, applying this patch gives following
> build error, the build error disappears after patch 12/32.
> 
> It should successfully compile after each patch, can you please fix this?

We'll fix the build error and resubmit them today.

Thanks!
Rasesh

[dpdk-dev] [PATCH v3 00/32] qede: update qede pmd to 1.2.0.1 and enable by default

[Mody, Rasesh]

> From: Ferruh Yigit [mailto:ferruh.yigit at intel.com]
> Sent: Monday, October 17, 2016 10:06 AM
> 
> On 10/15/2016 9:07 PM, Rasesh Mody wrote:
> > Hi,
> >
> > This patch set includes changes to update the base driver, work with
> > newer FW 8.10.9.0, adds new features, includes enhancements and code
> > cleanup, provides bug fixes and updates documentation for the QEDE
> > poll mode driver.
> >
> > It enables QEDE PMD in the dpdk config by default. The dependency on
> > external library libz has been addressed.
> >
> > The patch set updates the QEDE PMD to 1.2.0.1.
> >
> > Review comments recived for v2 series have been addressed.
> >
> > Please apply to DPDK tree for v16.11 release.
> >
> > Thanks!
> > Rasesh
> >
> > Harish Patil (14):
> >   qede: change the API signature of ecore_mcp_cmd_and_union()
> >   qede: serialize access to MFW mbox
> >   qede: add APIs to support NIC selftests and query sensor info.
> >   qede: fix port (re)configuration issue
> >   qede/base: allow MTU change via vport-update
> >   qede: add missing 100G link speed capability
> >   qede: remove unused/dead code
> >   qede: fixes for VLAN filters
> >   qede: add enable/disable VLAN filtering
> >   qede: fix RSS related issues
> >   qede/base: add support to initiate PF FLR
> >   qede: skip slowpath polling for 100G VF device
> >   qede: fix driver version string
> >   qede: fix status_blk index for VF queues
> >
> > Rasesh Mody (16):
> >   qede/base: add new init files and rearrange the code
> >   qede/base: formatting changes
> >   qede: use FW CONFIG defines as needed
> >   qede/base: add HSI changes and register defines
> >   qede/base: fix the attention formating string
> >   qede/base: additional formatting/comment changes
> >   qede: fix 32 bit compilation
> >   qede/base: update base driver
> >   qede/base: rename structure and defines
> >   qede/base: comment enhancements
> >   qede/base: add MFW crash dump support
> >   qede/base: change rx tx queue start APIs
> >   qede: add support for queue statistics
> >   qede: remove zlib dependency and enable PMD by default
> >   doc: update qede pmd documentation
> >   qede: update driver version
> >
> > Sony Chacko (2):
> >   qede: enable support for unequal number of RX/TX queues
> >   qede: add scatter gather support
> >
> 
> Hi Rasesh,
> 
> This version of the patchset received after RC1, and to be in this release 
> only
> remaining chance is to be merged in RC2.
> 
> And I would like to remind you that after RC2 you will have little time to 
> test
> your new driver, would you like to push the driver to next release or stick
> with this one?
> 
> If you stick to release, can you please send new version -because of patch by
> patch compile error- timely so that it gives some time to reviewers before
> RC2?

Hi Ferruh,

We would like to include the driver changes in DPDK 16.11 release.

Please note that even though the driver patches are out for quite some time, we 
have thoroughly tested these changes.

Thanks!
-Rasesh 

> Thanks,
> ferruh
> 
> 
> 

[dpdk-dev] [PATCH] net/bnx2x: fix icc build error

[Mody, Rasesh]

> From: Ferruh Yigit [mailto:ferruh.yigit at intel.com]
> Sent: Monday, October 17, 2016 5:12 AM
> 
> On 9/30/2016 3:45 PM, Ferruh Yigit wrote:
> > When bnx2x debug config enabled, icc (ICC) 17.0.0 20160721 gives the
> > following compilation error:
> >
> > .../drivers/net/bnx2x/elink.c(6682):
> > error #3656: variable "fw_ver1" may be used before its value is set
> > PMD_DRV_LOG(DEBUG,
> > ^
> >
> > According logic in the code, this error is a false positive, but since
> > this is not in the fast path, fixing compiler error by assigning
> > initial value to variable.
> >
> > Signed-off-by: Ferruh Yigit 
> > ---
> >  drivers/net/bnx2x/elink.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/bnx2x/elink.c b/drivers/net/bnx2x/elink.c
> > index 149cc97..d9a72f0 100644
> > --- a/drivers/net/bnx2x/elink.c
> > +++ b/drivers/net/bnx2x/elink.c
> > @@ -6645,7 +6645,7 @@ static elink_status_t
> elink_8073_8727_external_rom_boot(struct bnx2x_softc *sc,
> > uint8_t port)
> >  {
> > uint32_t count = 0;
> > -   uint16_t fw_ver1, fw_msgout;
> > +   uint16_t fw_ver1 = 0, fw_msgout;
> > elink_status_t rc = ELINK_STATUS_OK;
> >
> > /* Boot port from external ROM  */
> >
> 
> Since this is an compilation fix, I believe it is good to have this in the 
> release,
> can you please review the patch?

Thanks!

Acked-by: Rasesh Mody 

> Thanks,
> ferruh