[dpdk-dev] [PATCH v2 1/2] ethdev: add tunnel and port RSS offload types

[Jerin Jacob]

On Tue, Mar 29, 2016 at 11:58:47AM +, De Lara Guarch, Pablo wrote:
> Hi Jerin,
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jerin Jacob
> > Sent: Tuesday, March 29, 2016 12:20 PM
> > To: dev at dpdk.org
> > Cc: thomas.monjalon at 6wind.com; Richardson, Bruce; Jerin Jacob
> > Subject: [dpdk-dev] [PATCH v2 1/2] ethdev: add tunnel and port RSS offload
> > types
> > 
> > - added VXLAN, GENEVE and NVGRE tunnel flow types
> > - added PORT flow type for accounting physical/virtual
> > port or channel number in flow creation
> > 
> > Signed-off-by: Jerin Jacob 
> > ---
> >  app/test-pmd/cmdline.c  | 18 +++---
> >  app/test-pmd/config.c   |  9 +
> >  lib/librte_ether/rte_eth_ctrl.h |  6 +-
> >  lib/librte_ether/rte_ethdev.h   | 16 +++-
> >  4 files changed, 44 insertions(+), 5 deletions(-)
> > 
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> > index 93203f4..5fe8239 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -565,7 +565,7 @@ static void cmd_help_long_parsed(void
> > *parsed_result,
> > "Set crc-strip/rx-checksum/hardware-
> > vlan/drop_en"
> > " for ports.\n\n"
> > 
> > -   "port config all rss
> > (all|ip|tcp|udp|sctp|ether|none)\n"
> > +   "port config all rss
> > (all|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none)\n"
> 
> Could you update the testpmd document and extend the options in the command 
> line help?
Hi John and Pablo,

I will send the V3 with testpmd document update. Command line help is
already part of V2

> 
> Thanks,
> Pablo
> 
> 

[dpdk-dev] [PATCH v3 0/2] New RSS offload flags

[Jerin Jacob]

v1..v2
- Added cover letter
- Corrected typo in RET_ETH_FLOW_VXLAN name
- Updated test-pmd application to access newly defined RSS offload flags

v2..v3
-testpmd document update(Suggested by John and Pablo)

Jerin Jacob (2):
  ethdev: add tunnel and port RSS offload types
  ethdev: add ETH_RSS_RETA_SIZE_256

 app/test-pmd/cmdline.c  | 18 +++---
 app/test-pmd/config.c   |  9 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  6 +-
 lib/librte_ether/rte_eth_ctrl.h |  6 +-
 lib/librte_ether/rte_ethdev.h   | 17 -
 5 files changed, 50 insertions(+), 6 deletions(-)

-- 
2.1.0

[dpdk-dev] [PATCH v3 1/2] ethdev: add tunnel and port RSS offload types

[Jerin Jacob]

- added VXLAN, GENEVE and NVGRE tunnel flow types
- added PORT flow type for accounting physical/virtual
port or channel number in flow creation

Signed-off-by: Jerin Jacob 
---
 app/test-pmd/cmdline.c  | 18 +++---
 app/test-pmd/config.c   |  9 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  6 +-
 lib/librte_ether/rte_eth_ctrl.h |  6 +-
 lib/librte_ether/rte_ethdev.h   | 16 +++-
 5 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 93203f4..5fe8239 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -565,7 +565,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"Set crc-strip/rx-checksum/hardware-vlan/drop_en"
" for ports.\n\n"

-   "port config all rss (all|ip|tcp|udp|sctp|ether|none)\n"
+   "port config all rss 
(all|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none)\n"
"Set the RSS mode.\n\n"

"port config port-id rss reta 
(hash,queue)[,(hash,queue)]\n"
@@ -1545,6 +1545,14 @@ cmd_config_rss_parsed(void *parsed_result,
rss_conf.rss_hf = ETH_RSS_SCTP;
else if (!strcmp(res->value, "ether"))
rss_conf.rss_hf = ETH_RSS_L2_PAYLOAD;
+   else if (!strcmp(res->value, "port"))
+   rss_conf.rss_hf = ETH_RSS_PORT;
+   else if (!strcmp(res->value, "vxlan"))
+   rss_conf.rss_hf = ETH_RSS_VXLAN;
+   else if (!strcmp(res->value, "geneve"))
+   rss_conf.rss_hf = ETH_RSS_GENEVE;
+   else if (!strcmp(res->value, "nvgre"))
+   rss_conf.rss_hf = ETH_RSS_NVGRE;
else if (!strcmp(res->value, "none"))
rss_conf.rss_hf = 0;
else {
@@ -1566,12 +1574,12 @@ cmdline_parse_token_string_t cmd_config_rss_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss, name, "rss");
 cmdline_parse_token_string_t cmd_config_rss_value =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss, value,
-   "all#ip#tcp#udp#sctp#ether#none");
+   "all#ip#tcp#udp#sctp#ether#port#vxlan#geneve#nvgre#none");

 cmdline_parse_inst_t cmd_config_rss = {
.f = cmd_config_rss_parsed,
.data = NULL,
-   .help_str = "port config all rss all|ip|tcp|udp|sctp|ether|none",
+   .help_str = "port config all rss 
all|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none",
.tokens = {
(void *)&cmd_config_rss_port,
(void *)&cmd_config_rss_keyword,
@@ -9304,6 +9312,10 @@ flowtype_to_str(uint16_t ftype)
{"ipv6-sctp", RTE_ETH_FLOW_NONFRAG_IPV6_SCTP},
{"ipv6-other", RTE_ETH_FLOW_NONFRAG_IPV6_OTHER},
{"l2_payload", RTE_ETH_FLOW_L2_PAYLOAD},
+   {"port", RTE_ETH_FLOW_PORT},
+   {"vxlan", RTE_ETH_FLOW_VXLAN},
+   {"geneve", RTE_ETH_FLOW_GENEVE},
+   {"nvgre", RTE_ETH_FLOW_NVGRE},
};

for (i = 0; i < RTE_DIM(ftype_table); i++) {
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index b1bbec6..0b3619d 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -137,6 +137,11 @@ static const struct rss_type_info rss_type_table[] = {
{ "ipv6-ex", ETH_RSS_IPV6_EX },
{ "ipv6-tcp-ex", ETH_RSS_IPV6_TCP_EX },
{ "ipv6-udp-ex", ETH_RSS_IPV6_UDP_EX },
+   { "port", ETH_RSS_PORT },
+   { "vxlan", ETH_RSS_VXLAN },
+   { "geneve", ETH_RSS_GENEVE },
+   { "nvgre", ETH_RSS_NVGRE },
+
 };

 static void
@@ -2028,6 +2033,10 @@ flowtype_to_str(uint16_t flow_type)
{"ipv6-sctp", RTE_ETH_FLOW_NONFRAG_IPV6_SCTP},
{"ipv6-other", RTE_ETH_FLOW_NONFRAG_IPV6_OTHER},
{"l2_payload", RTE_ETH_FLOW_L2_PAYLOAD},
+   {"port", RTE_ETH_FLOW_PORT},
+   {"vxlan", RTE_ETH_FLOW_VXLAN},
+   {"geneve", RTE_ETH_FLOW_GENEVE},
+   {"nvgre", RTE_ETH_FLOW_NVGRE},
};

for (i = 0; i < RTE_DIM(flowtype_str_table); i++) {
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 94fba6a..e8839c2 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -177,6 +177,10 @@ For example:
  ipv6-sctp
  ipv6-other
  l2_payload
+ port
+ vxlan
+ geneve
+ nvgre

 show port rss reta
 ~~
@@ -1258,7 +1262,7 @@ port config - RSS

 Set the RSS (Receive Side Scaling) mode on or off::

-   testpmd> port config all rss (all|ip|tcp|udp|sctp|ether|none)
+   testpmd> port config all rss 
(all|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none)

 RSS is on by default.

diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index b8c7be9..8afbd92 100644
--- a/

[dpdk-dev] [PATCH v3 2/2] ethdev: add ETH_RSS_RETA_SIZE_256

[Jerin Jacob]

Signed-off-by: Jerin Jacob 
---
 lib/librte_ether/rte_ethdev.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index a4eeeba..d93f85a 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -470,6 +470,7 @@ struct rte_eth_rss_conf {
  */
 #define ETH_RSS_RETA_SIZE_64  64
 #define ETH_RSS_RETA_SIZE_128 128
+#define ETH_RSS_RETA_SIZE_256 256
 #define ETH_RSS_RETA_SIZE_512 512
 #define RTE_RETA_GROUP_SIZE   64

-- 
2.1.0

[dpdk-dev] [PATCH] Fix KNI compilation under Wind River Linux 6.0 recent RCPLs.

[Vincent JARDIN]

Le 30/03/2016 23:50, Stephen Hemminger a ?crit :
> Do we want to require DPDK to work in the face of every weird vendor
> kernel backport. This is a road to nowhere...
+1 with Steve. No way! There is no rational.

[dpdk-dev] [PATCH v3 2/7] drivers/net/e1000: Suppress misleading indentation warning

[Lu, Wenzhuo]

Hi,

> -Original Message-
> From: Aaron Conole [mailto:aconole at redhat.com]
> Sent: Wednesday, March 30, 2016 10:07 PM
> To: Thomas Monjalon
> Cc: Panu Matilainen; Lu, Wenzhuo; dev at dpdk.org; Richardson, Bruce
> Subject: [PATCH v3 2/7] drivers/net/e1000: Suppress misleading indentation
> warning
> 
> The register read/write mphy functions have misleading whitespace around the
> `locked` check. This cleanup merely preserves the existing functionality and
> suppresses future gcc versions' "misleading indentation" warning.
> 
> Suggested-by: Panu Matilainen 
> Signed-off-by: Aaron Conole 
Acked-by: Wenzhuo Lu 

[dpdk-dev] [PATCH v13 6/8] ethdev: redesign link speed config

[Xing, Beilei]

Marc,

I?ve verified v13 + the modification, and it works.

Best Regards
Beilei Xing

From: marc.sune at gmail.com [mailto:marc.s...@gmail.com] On Behalf Of Marc
Sent: Wednesday, March 30, 2016 4:00 PM
To: Xing, Beilei 
Cc: Thomas Monjalon ; Xu, Qian Q ; dev at dpdk.org; Ananyev, Konstantin ; Lu, Wenzhuo ; Richardson, Bruce 
; Glynn, Michael J 
Subject: Re: [PATCH v13 6/8] ethdev: redesign link speed config



On 29 March 2016 at 08:18, Xing, Beilei mailto:beilei.xing at intel.com>> wrote:


> -Original Message-
> From: Marc Sune [mailto:marcdevel at gmail.com]
> Sent: Saturday, March 26, 2016 9:27 AM
> To: Thomas Monjalon mailto:thomas.monjalon at 
> 6wind.com>>; Xu, Qian Q
> mailto:qian.q.xu at intel.com>>; Xing, Beilei 
> mailto:beilei.xing at intel.com>>; dev at 
> dpdk.org;
> Ananyev, Konstantin  intel.com>; Lu, Wenzhuo
> mailto:wenzhuo.lu at intel.com>>; Richardson, Bruce 
> mailto:bruce.richardson at intel.com>>;
> Glynn, Michael J mailto:michael.j.glynn at 
> intel.com>>
> Cc: Marc Sune mailto:marcdevel at gmail.com>>
> Subject: [PATCH v13 6/8] ethdev: redesign link speed config
>

> a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
> index a98e8eb..6cc2da0 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -2193,32 +2195,21 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
>   if (err)
>   goto error;
>
> + speed = 0x0;
> + if (*link_speeds & ETH_LINK_SPEED_10G)
> + speed |= IXGBE_LINK_SPEED_10GB_FULL;
> + if (*link_speeds & ETH_LINK_SPEED_1G)
> + speed |= IXGBE_LINK_SPEED_1GB_FULL;
> + if (*link_speeds & ETH_LINK_SPEED_100M)
> + speed |= IXGBE_LINK_SPEED_100_FULL;
> +
>   err = ixgbe_setup_link(hw, speed, link_up);
>   if (err)
>   goto error;

Hi Marc,
According to ixgbe HW, link speed shouldn't be 0 when setting up,
Otherwise device will start fail. So we need to set speed if link_speed
is ETH_LINK_SPEED_AUTONEG. Following code is for reference.

speed = 0x0;
if ((*link_speeds & 0x1) == ETH_LINK_SPEED_AUTONEG)
speed = (hw->mac.type != ixgbe_mac_82598EB) ?
IXGBE_LINK_SPEED_82599_AUTONEG :
IXGBE_LINK_SPEED_82598_AUTONEG;
else {
if (*link_speeds & ETH_LINK_SPEED_10G)
speed |= IXGBE_LINK_SPEED_10GB_FULL;
if (*link_speeds & ETH_LINK_SPEED_1G)
speed |= IXGBE_LINK_SPEED_1GB_FULL;
if (*link_speeds & ETH_LINK_SPEED_100M)
speed |= IXGBE_LINK_SPEED_100_FULL;
}

Beilei,

OK, thanks.

Can you/someone please try v13 + this modification, so that we make sure this 
is the final version for ixgbe?

Regards
Marc


Beilei Xing
Thanks

[dpdk-dev] [PATCH 1/2] Fix CPU and memory parameters on IBM POWER8

[Chao Zhu]

Thomas,

Seems I didn't get the messages from David. Anyway, I sent out an updated
patch.
Thanks for reminder!

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: 2016?3?30? 18:53
To: Chao Zhu 
Cc: dev at dpdk.org; David Marchand ; Richardson,
Bruce ; Panu Matilainen 
Subject: Re: [dpdk-dev] [PATCH 1/2] Fix CPU and memory parameters on IBM
POWER8

2016-03-25 09:48, David Marchand:
> On Fri, Mar 25, 2016 at 9:11 AM, Chao Zhu 
wrote:
> > This patch fixes the max logic number and memory channel number 
> > settings on IBM POWER8 platform.
> > 1. The max number of logic cores of a POWER8 processor is 96. Normally,
> >there are two sockets on a server. So the max number of logic cores
> >are 192. So this parch set CONFIG_RTE_MAX_LCORE to 256.
> 
> This is a power8 configuration item, this should go to power8 config 
> file, not common_base.
> 
> > 2. Currently, the max number of memory channels are hardcoded to 4.
However,
> >on a POWER8 machine, the max number of memory channels are 8. To fix
this,
> >CONFIG_RTE_MAX_NCHANNELS is added to do the configuration.
> 
> I don't see any reason why we would need a max value for force_nchannel.
> We should just get rid of this check, this is an obscure parameter for 
> most people, so people playing with it know what they are doing 
> (hopefully ?).
> 
> On the other hand, if power8 has some specifics about it, maybe we 
> should introduce some default value in a arch eal header for other 
> dpdk components to use (like in mempool).
> Thoughts ?

Chao? We are running out of time for 16.04.

[dpdk-dev] [PATCH] igb: change default RX wthresh back

[Wenzhuo Lu]

A problem is found on i350 VF. TX will happen once per 4
packets. If only 1~3 packets are received, they will not be
forwarded.

The reason is the default RX write-back threshold is changed
to 4. This patch changes the value back to 0, so every packet
can be handled immediately.

Fixes: 4a41c17dba18 (igb: set default thresholds based on MAC type)
Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/igb_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index bd0ae26..34120ae 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -64,7 +64,7 @@

 #define IGB_DEFAULT_RX_PTHRESH  ((hw->mac.type == e1000_i354) ? 12 : 8)
 #define IGB_DEFAULT_RX_HTHRESH  8
-#define IGB_DEFAULT_RX_WTHRESH  ((hw->mac.type == e1000_82576) ? 1 : 4)
+#define IGB_DEFAULT_RX_WTHRESH  0

 #define IGB_DEFAULT_TX_PTHRESH  ((hw->mac.type == e1000_i354) ? 20 : 8)
 #define IGB_DEFAULT_TX_HTHRESH  1
-- 
1.9.3

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

[Lu, Wenzhuo]

Hi Thomas, Marc,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, March 30, 2016 5:23 PM
> To: dev at dpdk.org
> Cc: Marc Sune; Xu, Qian Q; Xing, Beilei; Ananyev, Konstantin; Lu, Wenzhuo;
> Richardson, Bruce; Glynn, Michael J
> Subject: Re: [PATCH v13 0/8] ethdev: 100G and link speed API refactoring
> 
> 2016-03-26 02:27, Marc Sune:
> > There are still too few tests and reviews, especially for
> > autonegotiation with Intel devices (patch #6).
> > I would not be surprised to see some bugs in this rework.
> >
> > The capabilities must be adapted per device. It can be improved in a
> > separate patch.
> >
> > It will be integrated in 16.04-rc3.
> > Please test and review shortly, thanks!
> 
> Still no feedback for e1000 and i40e devices.
> Should we consider it is working fine?
I've tried i350 with this patch set. At least the basic rx/tx function is 
working.
But it's a big patch, I still have some questions. I'll comment soon.

[dpdk-dev] [PATCH v4 05/10] qede: Add core driver

[Harish Patil]

>
>On Tue, 29 Mar 2016 22:28:20 -0700
>Rasesh Mody  wrote:
>
>> +static void
>> +qede_alloc_etherdev(struct qede_dev *qdev, struct qed_dev_eth_info
>>*info)
>> +{
>> +rte_memcpy(&qdev->dev_info, info, sizeof(*info));
>
>Why bother with rte_memcpy here? why not just assignment or memcpy()?

Basically, I have tried using rte_* equivalent macros if available.
Would it be a problem?
OR is it that rte_memcpy() is meant to be used only in data path?

>
>> +qdev->num_tc = qdev->dev_info.num_tc;
>> +qdev->ops = qed_ops;
>> +}
>

[dpdk-dev] [PATCH] igb: change default RX wthresh back

[Ananyev, Konstantin]

Hi Wenzhuo,
> 
> A problem is found on i350 VF. TX will happen once per 4
> packets. If only 1~3 packets are received, they will not be
> forwarded.
> 
> The reason is the default RX write-back threshold is changed
> to 4. This patch changes the value back to 0, so every packet
> can be handled immediately.
> 
> Fixes: 4a41c17dba18 (igb: set default thresholds based on MAC type)
> Signed-off-by: Wenzhuo Lu 
> ---
>  drivers/net/e1000/igb_ethdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
> index bd0ae26..34120ae 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -64,7 +64,7 @@
> 
>  #define IGB_DEFAULT_RX_PTHRESH  ((hw->mac.type == e1000_i354) ? 12 : 8)
>  #define IGB_DEFAULT_RX_HTHRESH  8
> -#define IGB_DEFAULT_RX_WTHRESH  ((hw->mac.type == e1000_82576) ? 1 : 4)
> +#define IGB_DEFAULT_RX_WTHRESH  0

But that still doesn't prevent user from setting wthresh to whatever he likes 
inside
rx_queue_setup(), so the problem persists right?
As a side notice, it seems really bad practice to use implicit variables inside 
macro definition. 
Konstantin

> 
>  #define IGB_DEFAULT_TX_PTHRESH  ((hw->mac.type == e1000_i354) ? 20 : 8)
>  #define IGB_DEFAULT_TX_HTHRESH  1
> --
> 1.9.3

[dpdk-dev] [PATCH 1/4] lpm: allocation of an existing object should fail

[Olivier Matz]

Hi Stephen,

On 03/30/2016 11:46 PM, Stephen Hemminger wrote:
> On Wed, 30 Mar 2016 17:30:24 +0200
> Olivier Matz  wrote:
> 
>> diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
>> index 4c44cd7..9877a30 100644
>> --- a/lib/librte_lpm/rte_lpm6.c
>> +++ b/lib/librte_lpm/rte_lpm6.c
>> @@ -182,8 +182,11 @@ rte_lpm6_create(const char *name, int socket_id,
>>  if (strncmp(name, lpm->name, RTE_LPM6_NAMESIZE) == 0)
>>  break;
>>  }
>> -if (te != NULL)
>> +if (te != NULL) {
>> +lpm = NULL;
>> +rte_errno = EEXIST;
>>  goto exit;
>> +}
>>  
>>  /* allocate tailq entry */
>>  
> 
> with older memzone model, objects in huge memory area were never freed.
> That means when application restarts it finds the old LPM and works.
> With your change it would break such an application.
> 

Could you be more precise about the use case you are
describing? Are you talking about a secondary process?

The API description of lpm and hash says since the first
release that EEXIST should be returned if a memzone with
the same name already exists:

 * @return
 *   Handle to LPM object on success, NULL otherwise with rte_errno set
 *   to an appropriate values. Possible rte_errno values include:
 *- E_RTE_NO_CONFIG - function could not get pointer to rte_config
structure
 *- E_RTE_SECONDARY - function was called from a secondary process
instance
 *- EINVAL - invalid parameter passed to function
 *- ENOSPC - the maximum number of memzones has already been allocated
 *- EEXIST - a memzone with the same name already exists
 *- ENOMEM - no appropriate memory area found in which to create memzone
 */
struct rte_lpm *
rte_lpm_create(const char *name, int socket_id,
const struct rte_lpm_config *config);

 * @return
 *   Pointer to hash table structure that is used in future hash table
 *   operations, or NULL on error, with error code set in rte_errno.
 *   Possible rte_errno errors include:
 *- E_RTE_NO_CONFIG - function could not get pointer to rte_config
structure
 *- E_RTE_SECONDARY - function was called from a secondary process
instance
 *- ENOENT - missing entry
 *- EINVAL - invalid parameter passed to function
 *- ENOSPC - the maximum number of memzones has already been allocated
 *- EEXIST - a memzone with the same name already exists
 *- ENOMEM - no appropriate memory area found in which to create memzone
 */
struct rte_hash *
rte_hash_create(const struct rte_hash_parameters *params);


>From my point of view, the behavior I'm fixing is more a bug
fix than an API change. But if required, I can send a deprecation
notice for 16.04 and have the fix integrated for 16.07.

[dpdk-dev] [PATCH 0/4] fix lpm and hash creation

[Olivier Matz]

On 03/30/2016 05:30 PM, Olivier Matz wrote:
> Seen while trying to fix the func_reentrancy autotest. The
> series addresses several issues:
> 
> 1/ Hash and lpm return a pointer to an existing object if the user requests 
> the
>creation with an already existing name. This look dangerous: when an object
>is returned, the user does not know if it should be freed or not.
> 
> 2/ There is a race condition in cuckoo_hash as the lock is not held in
>rte_hash_create(). We could find some cases where NULL is returned when the
>object already exists (ex: when rte_ring_create() fails).
> 
> 3/ There is a race condition func_reentrancy that can fail even if the tested
>API behaves correctly.
> 
> 
> Changes since RFC:
> 
> - split the patch in 4 patches
> - on error, set rte_errno to EEXIST when relevant
> - fix locking in cuckoo_hash creation
> 
> Olivier Matz (4):
>   lpm: allocation of an existing object should fail
>   hash: allocation of an existing object should fail
>   hash: keep the list locked at creation
>   autotest: fix func reentrancy
> 
>  app/test/test_func_reentrancy.c   | 31 +--
>  app/test/test_lpm6.c  |  2 +-
>  lib/librte_hash/rte_cuckoo_hash.c | 18 +-
>  lib/librte_hash/rte_fbk_hash.c|  5 -
>  lib/librte_lpm/rte_lpm.c  | 10 --
>  lib/librte_lpm/rte_lpm6.c |  5 -
>  6 files changed, 51 insertions(+), 20 deletions(-)
> 

Self-nack, there is a typo in rte_cuckoo_hash.c breaking the
compilation.

[dpdk-dev] 16.07 Roadmap

[O'Driscoll, Tim]

As we're nearing the completion of the 16.04 release, I'd like to let the 
community know our plans for 16.07. It would be good if others are also willing 
to share their plans so that we can build up a complete picture of what's 
targeted for 16.07.

These are the features that we're planning to submit:

Vhost/Virtio Performance Loopback Utility: A tool will be provided which will 
allow virtio/vhost performance testing without the need for NIC traffic.

Virtio Code Refactoring for Rx/TX Split: The Rx and Tx queues will be split as 
they have different information to maintain apart from the common vring. Other 
cleanups will be made to make the queues more friendly for optimization.

Virtio Descriptor Index Update: The virtio descriptor index will be optimized 
for cache2cache transfer in the virtio PMD. The performance increase is 
expected to be below 10%.

Virtio in Containers: Support will be added for virtio in containers (see 
http://dpdk.org/ml/archives/dev/2016-February/032786.html). Multi-queue support 
will also be added.

I40e NSH: This includes: 1. Recognize the Network Services Header packet type; 
2. Direct traffic to queues based on service path header and service index 
(dependent on firmware change so may not make 16.07); 3. Checksum offload.

I40e Floating VEB: Deferred from 16.04. See 
http://dpdk.org/ml/archives/dev/2016-March/036470.html for details.

Automatic VF Reset From PF (i40e/ixgbe): Currently, when a PF notifies a VF 
that a reset is required, DPDK just reports this event to the application, 
which then needs to restart the VF port. A more user-friendly mechanism will be 
implemented where DPDK will reset the VF port directly. The application will 
still be notified, but will not need to handle the reset of the VF port.

Software Implementation of the KASUMI Algorithm: Under the cryptodev API, a 
software implementation of the KASUMI algorithm will be supported. KASUMI is 
widely used in mobile communications systems.

Bit-Level Support for SNOW 3G: Support for the SNOW 3G algorithm is being added 
in the 16.04 release. In 16.07, this will be enhanced so that offsets and 
lengths can be specified in bits instead of bytes (so, you could encrypt 50 
bits of a stream starting from the 5th bit for example).

IPsec Sample App Enhancements: Support for IPv6 and Transport Mode will be 
added to the IPsec sample application that was submitted in 16.04.

XStats Enhancements: Improve the extended NIC stats API to use id value pairs 
instead of string value pairs. Remap stats registers to use standard interface 
MIB naming and sizing.

Keep-Alive Enhancements: Improve DPDK keep-alive to use the DPDK 
alarm/interrupt API instead of using callbacks.

Live Migration for SRIOV: Support for live migration for vhost-user is being 
added to 16.04. This will be further enhanced to support live migration for 
SR-IOV by using link bonding to bond an SRIOV interface with a virtio interface.

IP Pipeline Enhancements: This includes: 1. Configure the MAC address in the 
routing pipeline; 2. Enable RSS per network interface through the configuration 
file; 3. Streamline the CLI code of the IP pipeline application.

Packet Capture Framework: In 16.04, there was lots of discussion on 
requirements for tcpdump support in DPDK (see 
http://dpdk.org/ml/archives/dev/2016-March/035592.html). For 16.07, we plan to 
submit a packet capture framework which will support hooks for filtering 
capabilities such as BPF. Our specific use case for this is for low rate packet 
capture for debug purposes. It should be possible for others to extend the 
framework to support high rate packet capture if they require that capability.

External Mempool Manager: This was originally submitted for 16.04 but had to be 
deferred due to ABI changes. See 
http://dpdk.org/ml/archives/dev/2016-March/035107.html for details.


In addition, there are some features that we're working on now but which we 
know won't make 16.07, either because time is too tight or because of external 
dependencies. These include:

QEMU vHost Back-End Reconnect: Currently, if a vswitch is connected to VMs via 
vhost-user and the vswitch is restarted, then when it comes back up again it 
cannot reconnect to the existing VMs. To address this, both QEMU and vhost-user 
need to support client mode (currently only server mode is supported), which 
implements reconnection messages that allow the vswitch to reconnect to the 
VMs. Changes are required in QEMU as well as in DPDK, so this change will need 
to be coordinated with the QEMU community.

Delay Packet Copy in vHost-User Dequeue: It may be possible to increase 
vhost-user performance by delaying the packet copy until a point where we know 
for certain whether the copy is required or not. This would avoid copying the 
packet in cases where it is not definitely required. Further investigation is 
required to determine how much of a performance gain can be achieved.


Tim

[dpdk-dev] [PATCH 0/7] L2fwd-crypto fixes/enhancements

[Cao, Min]

Tested-by: Min Cao 

- Tested Commit: 6ac91f938cc88423885b757ce24c2a984da097d4
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc (GCC) 4.8.3
- CPU: Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz
- NIC: Niantic
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 44 cases, 44 passed, 0 failed

- test case 1: QAT Unit test 
Total 31 cases, 31 passed, 0 failed

- test case 2: AES_NI Unit test 
Total 10 cases, 10 passed, 0 failed

- test case 3: l2fwd-crypto AES-CBC 128/192/256
Total 3 cases, 3 passed, 0 failed



-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pablo de Lara
Sent: Wednesday, March 30, 2016 9:02 PM
To: dev at dpdk.org
Cc: Doherty, Declan; De Lara Guarch, Pablo
Subject: [dpdk-dev] [PATCH 0/7] L2fwd-crypto fixes/enhancements

This patches fixes some small issues in L2fwd-crypto app and also improves the 
app, making it more flexible (accepting different key sizes) and readable 
(information display improvement).

Pablo de Lara (7):
  l2fwd-crypto: add missing new line character in help
  l2fwd-crypto: rename period parameter
  l2fwd-crypto: add missing string initialization
  l2fwd-crypto: fix length of random IV/AAD
  l2fwd-crypto: fix ambiguous input key size
  l2fwd-crypto: use key-value list of supported algorithms
  l2fwd-crypto: extend crypto information

 examples/l2fwd-crypto/main.c  | 465 --
 lib/librte_cryptodev/rte_crypto_sym.h |   6 +-
 2 files changed, 398 insertions(+), 73 deletions(-)

--
2.5.5

[dpdk-dev] [PATCH] mlx5: fix RETA table size

[Adrien Mazarguil]

Yaacov,

On Wed, Mar 30, 2016 at 06:27:19PM +0300, Yaacov Hazan wrote:
> Change RETA table size to use 256 entries for better performance.
> 
> Fixes: ebb30ec64a68 ("mlx5: increase RETA table size")
> 
> Signed-off-by: Yaacov Hazan 
> ---
>  drivers/net/mlx5/mlx5_defs.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_defs.h b/drivers/net/mlx5/mlx5_defs.h
> index 195440c..09207d9 100644
> --- a/drivers/net/mlx5/mlx5_defs.h
> +++ b/drivers/net/mlx5/mlx5_defs.h
> @@ -52,7 +52,7 @@
>  #define MLX5_PMD_TX_PER_COMP_REQ 64
>  
>  /* RSS Indirection table size. */
> -#define RSS_INDIRECTION_TABLE_SIZE 512
> +#define RSS_INDIRECTION_TABLE_SIZE 256

Can you describe how using a smaller indirection table size improves
performance? Thanks.

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v2 0/8] L2fwd-crypto fixes/enhancements

[Pablo de Lara]

This patches fixes some small issues in L2fwd-crypto
app and also improves the app, making it more flexible
(accepting different key sizes)
and readable (information display improvement).

Changes in v2:

- Extended help information

Pablo de Lara (8):
  l2fwd-crypto: add missing new line character in help
  l2fwd-crypto: rename period parameter
  l2fwd-crypto: add missing string initialization
  l2fwd-crypto: fix length of random IV/AAD
  l2fwd-crypto: fix ambiguous input key size
  l2fwd-crypto: clarify key parsing in help
  l2fwd-crypto: use key-value list of supported algorithms
  l2fwd-crypto: extend crypto information

 examples/l2fwd-crypto/main.c  | 473 --
 lib/librte_cryptodev/rte_crypto_sym.h |   6 +-
 2 files changed, 402 insertions(+), 77 deletions(-)

-- 
2.5.5

[dpdk-dev] [PATCH v2 1/8] l2fwd-crypto: add missing new line character in help

[Pablo de Lara]

Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application)

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 5fd4ff1..0cb46c2 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -789,7 +789,7 @@ l2fwd_crypto_usage(const char *prgname)
printf("%s [EAL options] --\n"
"  -p PORTMASK: hexadecimal bitmask of ports to configure\n"
"  -q NQ: number of queue (=ports) per lcore (default is 1)\n"
-   "  -s manage all ports from single lcore"
+   "  -s manage all ports from single lcore\n"
"  -t PERIOD: statistics will be refreshed each PERIOD seconds"
" (0 to disable, 10 default, 86400 maximum)\n"

-- 
2.5.5

[dpdk-dev] [PATCH v2 2/8] l2fwd-crypto: rename period parameter

[Pablo de Lara]

L2fwd-crypto app is based on L2fwd app and it inherits
some of its parameters (such as portmask, queues per core...).

The parameter period (period of time between statistic updates)
is -T in L2fwd, but was -t in L2fwd-crypto, so for consistency,
it is changed back to -T

Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application)

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 0cb46c2..fd30826 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -790,7 +790,7 @@ l2fwd_crypto_usage(const char *prgname)
"  -p PORTMASK: hexadecimal bitmask of ports to configure\n"
"  -q NQ: number of queue (=ports) per lcore (default is 1)\n"
"  -s manage all ports from single lcore\n"
-   "  -t PERIOD: statistics will be refreshed each PERIOD seconds"
+   "  -T PERIOD: statistics will be refreshed each PERIOD seconds"
" (0 to disable, 10 default, 86400 maximum)\n"

"  --cdev_type HW / SW / ANY\n"
@@ -1220,7 +1220,7 @@ l2fwd_crypto_parse_args(struct l2fwd_crypto_options 
*options,
break;

/* timer period */
-   case 't':
+   case 'T':
retval = l2fwd_crypto_parse_timer_period(options,
optarg);
if (retval < 0) {
-- 
2.5.5

[dpdk-dev] [PATCH v2 3/8] l2fwd-crypto: add missing string initialization

[Pablo de Lara]

When passing the preferred crypto device type in the command line parameters,
the string (HW/SW/ANY) was not being saved, which is used
for error information to the user.

Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index fd30826..1b0c229 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -968,8 +968,12 @@ l2fwd_crypto_parse_args_long_options(struct 
l2fwd_crypto_options *options,
 {
int retval;

-   if (strcmp(lgopts[option_index].name, "cdev_type") == 0)
-   return parse_cryptodev_type(&options->type, optarg);
+   if (strcmp(lgopts[option_index].name, "cdev_type") == 0) {
+   retval = parse_cryptodev_type(&options->type, optarg);
+   if (retval == 0)
+   strcpy(options->string_type, optarg);
+   return retval;
+   }

else if (strcmp(lgopts[option_index].name, "chain") == 0)
return parse_crypto_opt_chain(options, optarg);
-- 
2.5.5

[dpdk-dev] [PATCH v2 4/8] l2fwd-crypto: fix length of random IV/AAD

[Pablo de Lara]

App was generating a random IV/AAD of only 4 bytes,
instead of the actual length, since it was using sizeof(length).

Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 1b0c229..c323b55 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -643,7 +643,7 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)
port_cparams[i].aad.phys_addr = 
options->aad.phys_addr;
if (!options->aad_param)

generate_random_key(port_cparams[i].aad.data,
-   
sizeof(port_cparams[i].aad.length));
+   port_cparams[i].aad.length);

}

@@ -661,7 +661,7 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)
port_cparams[i].iv.phys_addr = options->iv.phys_addr;
if (!options->iv_param)
generate_random_key(port_cparams[i].iv.data,
-   
sizeof(port_cparams[i].iv.length));
+   port_cparams[i].iv.length);

port_cparams[i].cipher_algo = 
options->cipher_xform.cipher.algo;
}
-- 
2.5.5

[dpdk-dev] [PATCH v2 5/8] l2fwd-crypto: fix ambiguous input key size

[Pablo de Lara]

Some crypto algorithms support more than one key size
(including cipher key, authentication key, IV and AAD),
but the app was using always the minimum size.

These changes allows the user to use an specific size,
either from the string provided with cipher_key, auth_key, iv and ADD 
parameters,
or from the values provided with cipher_key_random_size,
auth_key_random_size, iv_random_size and aad_random_size.

This also allows the user to specify the digest size.

Fixes: 1df9c0109f4c ("examples/l2fwd-crypto: parse key parameters")

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 257 +--
 1 file changed, 247 insertions(+), 10 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index c323b55..c561270 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -147,15 +147,21 @@ struct l2fwd_crypto_options {

struct rte_crypto_sym_xform cipher_xform;
unsigned ckey_param;
+   int ckey_random_size;

struct l2fwd_key iv;
unsigned iv_param;
+   int iv_random_size;

struct rte_crypto_sym_xform auth_xform;
uint8_t akey_param;
+   int akey_random_size;

struct l2fwd_key aad;
unsigned aad_param;
+   int aad_random_size;
+
+   int digest_size;

uint16_t block_size;
char string_auth_algo[MAX_STR_LEN];
@@ -799,12 +805,17 @@ l2fwd_crypto_usage(const char *prgname)
"  --cipher_algo ALGO\n"
"  --cipher_op ENCRYPT / DECRYPT\n"
"  --cipher_key KEY\n"
+   "  --cipher_key_random_size SIZE: size of cipher key when 
generated randomly\n"
"  --iv IV\n"
+   "  --iv_random_size SIZE: size of IV when generated randomly\n"

"  --auth_algo ALGO\n"
"  --auth_op GENERATE / VERIFY\n"
"  --auth_key KEY\n"
+   "  --auth_key_random_size SIZE: size of auth key when generated 
randomly\n"
"  --aad AAD\n"
+   "  --aad_random_size SIZE: size of AAD when generated 
randomly\n"
+   "  --digest_size SIZE: size of digest to be 
generated/verified\n"

"  --sessionless\n",
   prgname);
@@ -906,6 +917,27 @@ parse_key(uint8_t *data, char *input_arg)
data[byte_count++] = (uint8_t)number;
}

+   return byte_count;
+}
+
+/** Parse size param*/
+static int
+parse_size(int *size, const char *q_arg)
+{
+   char *end = NULL;
+   unsigned long n;
+
+   /* parse hexadecimal string */
+   n = strtoul(q_arg, &end, 10);
+   if ((q_arg[0] == '\0') || (end == NULL) || (*end != '\0'))
+   n = 0;
+
+   if (n == 0) {
+   printf("invalid size\n");
+   return -1;
+   }
+
+   *size = n;
return 0;
 }

@@ -993,14 +1025,30 @@ l2fwd_crypto_parse_args_long_options(struct 
l2fwd_crypto_options *options,

else if (strcmp(lgopts[option_index].name, "cipher_key") == 0) {
options->ckey_param = 1;
-   return parse_key(options->cipher_xform.cipher.key.data, optarg);
+   options->cipher_xform.cipher.key.length =
+   parse_key(options->cipher_xform.cipher.key.data, 
optarg);
+   if (options->cipher_xform.cipher.key.length > 0)
+   return 0;
+   else
+   return -1;
}

+   else if (strcmp(lgopts[option_index].name, "cipher_key_random_size") == 
0)
+   return parse_size(&options->ckey_random_size, optarg);
+
else if (strcmp(lgopts[option_index].name, "iv") == 0) {
options->iv_param = 1;
-   return parse_key(options->iv.data, optarg);
+   options->iv.length =
+   parse_key(options->iv.data, optarg);
+   if (options->iv.length > 0)
+   return 0;
+   else
+   return -1;
}

+   else if (strcmp(lgopts[option_index].name, "iv_random_size") == 0)
+   return parse_size(&options->iv_random_size, optarg);
+
/* Authentication options */
else if (strcmp(lgopts[option_index].name, "auth_algo") == 0) {
retval = parse_auth_algo(&options->auth_xform.auth.algo,
@@ -1016,12 +1064,34 @@ l2fwd_crypto_parse_args_long_options(struct 
l2fwd_crypto_options *options,

else if (strcmp(lgopts[option_index].name, "auth_key") == 0) {
options->akey_param = 1;
-   return parse_key(options->auth_xform.auth.key.data, optarg);
+   options->auth_xform.auth.key.length =
+   parse_key(options->auth_xform.auth.key.data, optarg);
+   if (options->auth_xform.auth.key.length > 0)
+   return 0;
+   else
+   return -1;
+   }
+
+   else

[dpdk-dev] [PATCH v2 6/8] l2fwd-crypto: clarify key parsing in help

[Pablo de Lara]

Cipher/Auth keys, AAD and IV must be passed from command line
with ":" between bytes, but help was not clarifying that.

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index c561270..6a28448 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -804,16 +804,16 @@ l2fwd_crypto_usage(const char *prgname)

"  --cipher_algo ALGO\n"
"  --cipher_op ENCRYPT / DECRYPT\n"
-   "  --cipher_key KEY\n"
+   "  --cipher_key KEY (bytes separated with \":\")\n"
"  --cipher_key_random_size SIZE: size of cipher key when 
generated randomly\n"
-   "  --iv IV\n"
+   "  --iv IV (bytes separated with \":\")\n"
"  --iv_random_size SIZE: size of IV when generated randomly\n"

"  --auth_algo ALGO\n"
"  --auth_op GENERATE / VERIFY\n"
-   "  --auth_key KEY\n"
+   "  --auth_key KEY (bytes separated with \":\")\n"
"  --auth_key_random_size SIZE: size of auth key when generated 
randomly\n"
-   "  --aad AAD\n"
+   "  --aad AAD (bytes separated with \":\")\n"
"  --aad_random_size SIZE: size of AAD when generated 
randomly\n"
"  --digest_size SIZE: size of digest to be 
generated/verified\n"

-- 
2.5.5

[dpdk-dev] [PATCH v2 7/8] l2fwd-crypto: use key-value list of supported algorithms

[Pablo de Lara]

In order to ease the parsing and display of supported algorithms
in the application, two new arrays are created, which contains
the strings of the different cipher and authentication algorithms,

These lists are used to parse the algorithms from the command line,
and will be used to display crypto information to the user.

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c  | 106 +-
 lib/librte_cryptodev/rte_crypto_sym.h |   6 +-
 2 files changed, 58 insertions(+), 54 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 6a28448..5fb33df 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -133,6 +133,9 @@ struct l2fwd_key {
phys_addr_t phys_addr;
 };

+char supported_auth_algo[RTE_CRYPTO_AUTH_LIST_END][MAX_STR_LEN];
+char supported_cipher_algo[RTE_CRYPTO_CIPHER_LIST_END][MAX_STR_LEN];
+
 /** l2fwd crypto application command line options */
 struct l2fwd_crypto_options {
unsigned portmask;
@@ -164,8 +167,6 @@ struct l2fwd_crypto_options {
int digest_size;

uint16_t block_size;
-   char string_auth_algo[MAX_STR_LEN];
-   char string_cipher_algo[MAX_STR_LEN];
char string_type[MAX_STR_LEN];
 };

@@ -328,6 +329,32 @@ print_stats(void)
printf("\n\n");
 }

+static void
+fill_supported_algorithm_tables(void)
+{
+   unsigned i;
+
+   for (i = 0; i < RTE_CRYPTO_AUTH_LIST_END; i++)
+   strcpy(supported_auth_algo[i], "NOT_SUPPORTED");
+
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_AES_GCM], "AES_GCM");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_MD5_HMAC], "MD5_HMAC");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_NULL], "NULL");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_SHA1_HMAC], "SHA1_HMAC");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_SHA224_HMAC], "SHA224_HMAC");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_SHA256_HMAC], "SHA256_HMAC");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_SHA384_HMAC], "SHA384_HMAC");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_SHA512_HMAC], "SHA512_HMAC");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_SNOW3G_UIA2], "SNOW3G_UIA2");
+
+   for (i = 0; i < RTE_CRYPTO_CIPHER_LIST_END; i++)
+   strcpy(supported_cipher_algo[i], "NOT_SUPPORTED");
+
+   strcpy(supported_cipher_algo[RTE_CRYPTO_CIPHER_AES_CBC], "AES_CBC");
+   strcpy(supported_cipher_algo[RTE_CRYPTO_CIPHER_AES_GCM], "AES_GCM");
+   strcpy(supported_cipher_algo[RTE_CRYPTO_CIPHER_NULL], "NULL");
+   strcpy(supported_cipher_algo[RTE_CRYPTO_CIPHER_SNOW3G_UEA2], 
"SNOW3G_UEA2");
+}


 static int
@@ -864,18 +891,13 @@ parse_crypto_opt_chain(struct l2fwd_crypto_options 
*options, char *optarg)
 static int
 parse_cipher_algo(enum rte_crypto_cipher_algorithm *algo, char *optarg)
 {
-   if (strcmp("AES_CBC", optarg) == 0) {
-   *algo = RTE_CRYPTO_CIPHER_AES_CBC;
-   return 0;
-   } else if (strcmp("AES_GCM", optarg) == 0) {
-   *algo = RTE_CRYPTO_CIPHER_AES_GCM;
-   return 0;
-   } else if (strcmp("NULL", optarg) == 0) {
-   *algo = RTE_CRYPTO_CIPHER_NULL;
-   return 0;
-   } else if (strcmp("SNOW3G_UEA2", optarg) == 0) {
-   *algo = RTE_CRYPTO_CIPHER_SNOW3G_UEA2;
-   return 0;
+   unsigned i;
+
+   for (i = 0; i < RTE_CRYPTO_CIPHER_LIST_END; i++) {
+   if (!strcmp(supported_cipher_algo[i], optarg)) {
+   *algo = i;
+   return 0;
+   }
}

printf("Cipher algorithm  not supported!\n");
@@ -945,33 +967,13 @@ parse_size(int *size, const char *q_arg)
 static int
 parse_auth_algo(enum rte_crypto_auth_algorithm *algo, char *optarg)
 {
-   if (strcmp("AES_GCM", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_AES_GCM;
-   return 0;
-   } else if (strcmp("MD5_HMAC", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_MD5_HMAC;
-   return 0;
-   } else if (strcmp("NULL", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_NULL;
-   return 0;
-   } else if (strcmp("SHA1_HMAC", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_SHA1_HMAC;
-   return 0;
-   } else if (strcmp("SHA224_HMAC", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_SHA224_HMAC;
-   return 0;
-   } else if (strcmp("SHA256_HMAC", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_SHA256_HMAC;
-   return 0;
-   }  else if (strcmp("SHA384_HMAC", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_SHA384_HMAC;
-   return 0;
-   } else if (strcmp("SHA512_HMAC", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_SHA512_HMAC;
-   return 0;
-   } else if (strcmp("SNOW3G_UIA2", optarg) == 0) 

[dpdk-dev] [PATCH v2 8/8] l2fwd-crypto: extend crypto information

[Pablo de Lara]

Display extra crypto information (algorithms, keys/IV/AAD used, chain...),
so user can know exactly what operations are being carried out.

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 84 ++--
 1 file changed, 82 insertions(+), 2 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 5fb33df..09a07d3 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -71,6 +71,7 @@
 #include 
 #include 
 #include 
+#include 

 enum cdev_type {
CDEV_TYPE_ANY,
@@ -634,8 +635,6 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)

RTE_LOG(INFO, L2FWD, "entering main loop on lcore %u\n", lcore_id);

-   l2fwd_crypto_options_print(options);
-
for (i = 0; i < qconf->nb_rx_ports; i++) {

portid = qconf->rx_port_list[i];
@@ -708,6 +707,14 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)
port_cparams[i].dev_id);
}

+   l2fwd_crypto_options_print(options);
+
+   /*
+* Initialize previous tsc timestamp before the loop,
+* to avoid showing the port statistics immediately,
+* so user can see the crypto information.
+*/
+   prev_tsc = rte_rdtsc();
while (1) {

cur_tsc = rte_rdtsc();
@@ -1213,8 +1220,45 @@ l2fwd_crypto_default_options(struct l2fwd_crypto_options 
*options)
 }

 static void
+display_cipher_info(struct l2fwd_crypto_options *options)
+{
+   printf("\n Cipher information ---\n");
+   printf("Algorithm: %s\n",
+   supported_cipher_algo[options->cipher_xform.cipher.algo]);
+   rte_hexdump(stdout, "Cipher key:",
+   options->cipher_xform.cipher.key.data,
+   options->cipher_xform.cipher.key.length);
+   rte_hexdump(stdout, "IV:", options->iv.data, options->iv.length);
+}
+
+static void
+display_auth_info(struct l2fwd_crypto_options *options)
+{
+   printf("\n Authentication information ---\n");
+   printf("Algorithm: %s\n",
+   supported_auth_algo[options->auth_xform.auth.algo]);
+   rte_hexdump(stdout, "Auth key:",
+   options->auth_xform.auth.key.data,
+   options->auth_xform.auth.key.length);
+   rte_hexdump(stdout, "AAD:", options->aad.data, options->aad.length);
+}
+
+static void
 l2fwd_crypto_options_print(struct l2fwd_crypto_options *options)
 {
+   char string_cipher_op[MAX_STR_LEN];
+   char string_auth_op[MAX_STR_LEN];
+
+   if (options->cipher_xform.cipher.op == RTE_CRYPTO_CIPHER_OP_ENCRYPT)
+   strcpy(string_cipher_op, "Encrypt");
+   else
+   strcpy(string_cipher_op, "Decrypt");
+
+   if (options->auth_xform.auth.op == RTE_CRYPTO_AUTH_OP_GENERATE)
+   strcpy(string_auth_op, "Auth generate");
+   else
+   strcpy(string_auth_op, "Auth verify");
+
printf("Options:-\nn");
printf("portmask: %x\n", options->portmask);
printf("ports per lcore: %u\n", options->nb_ports_per_lcore);
@@ -1226,6 +1270,42 @@ l2fwd_crypto_options_print(struct l2fwd_crypto_options 
*options)

printf("sessionless crypto: %s\n",
options->sessionless ? "enabled" : "disabled");
+
+   if (options->ckey_param && (options->ckey_random_size != -1))
+   printf("Cipher key already parsed, ignoring size of random 
key\n");
+
+   if (options->akey_param && (options->akey_random_size != -1))
+   printf("Auth key already parsed, ignoring size of random 
key\n");
+
+   if (options->iv_param && (options->iv_random_size != -1))
+   printf("IV already parsed, ignoring size of random IV\n");
+
+   if (options->aad_param && (options->aad_random_size != -1))
+   printf("AAD already parsed, ignoring size of random AAD\n");
+
+   printf("\nCrypto chain: ");
+   switch (options->xform_chain) {
+   case L2FWD_CRYPTO_CIPHER_HASH:
+   printf("Input --> %s --> %s --> Output\n",
+   string_cipher_op, string_auth_op);
+   display_cipher_info(options);
+   display_auth_info(options);
+   break;
+   case L2FWD_CRYPTO_HASH_CIPHER:
+   printf("Input --> %s --> %s --> Output\n",
+   string_auth_op, string_cipher_op);
+   display_cipher_info(options);
+   display_auth_info(options);
+   break;
+   case L2FWD_CRYPTO_HASH_ONLY:
+   printf("Input --> %s --> Output\n", string_auth_op);
+   display_auth_info(options);
+   break;
+   case L2FWD_CRYPTO_CIPHER_ONLY:
+   printf("Input --> %s --> Output\n", string_cipher_op);
+   display_cipher_info(options);
+   break;
+   }
 }

 /* Parse the argument given in the command line of the applicati

[dpdk-dev] [PATCH] examples/ipsec-secgw: Fix Missed Headers For FreeBSD

[Daniel Mrzyglod]

There were misssed typedef for u_char - 
There were missed network definitions - 

Failure #13: http://dpdk.org/ml/archives/test-report/2016-March/001896.html

Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample application")

Signed-off-by: Daniel Mrzyglod 
---
 examples/ipsec-secgw/esp.c   | 4 +++-
 examples/ipsec-secgw/ipsec.c | 2 +-
 examples/ipsec-secgw/rt.c| 1 +
 examples/ipsec-secgw/sa.c| 2 ++
 examples/ipsec-secgw/sp.c| 2 ++
 5 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
index ca0fc56..7b0e04c 100644
--- a/examples/ipsec-secgw/esp.c
+++ b/examples/ipsec-secgw/esp.c
@@ -33,8 +33,10 @@

 #include 
 #include 
-#include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index d385100..baf30d4 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -30,7 +30,7 @@
  *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
-
+#include 
 #include 
 #include 

diff --git a/examples/ipsec-secgw/rt.c b/examples/ipsec-secgw/rt.c
index c3bb4de..a6d0866 100644
--- a/examples/ipsec-secgw/rt.c
+++ b/examples/ipsec-secgw/rt.c
@@ -34,6 +34,7 @@
 /*
  * Routing Table (RT)
  */
+#include 
 #include 
 #include 

diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 91a5f6e..a5b8a63 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -34,6 +34,8 @@
 /*
  * Security Associations
  */
+#include 
+#include 
 #include 

 #include 
diff --git a/examples/ipsec-secgw/sp.c b/examples/ipsec-secgw/sp.c
index 7972f40..4f16730 100644
--- a/examples/ipsec-secgw/sp.c
+++ b/examples/ipsec-secgw/sp.c
@@ -34,6 +34,8 @@
 /*
  * Security Policies
  */
+#include 
+#include 
 #include 

 #include 
-- 
2.5.5

[dpdk-dev] [PATCH v2 0/8] L2fwd-crypto fixes/enhancements

[Thomas Monjalon]

2016-03-31 10:01, Pablo de Lara:
> This patches fixes some small issues in L2fwd-crypto
> app and also improves the app, making it more flexible
> (accepting different key sizes)
> and readable (information display improvement).
> 
> Changes in v2:
> 
> - Extended help information

The line "Tested-by: Min Cao " is missing.

[dpdk-dev] [PATCH v2] mlx5: fix RETA table size

[Yaacov Hazan]

When the number of RX queues is not a power of two,
the RETA table is configured to its maximum size for
better balancing.

Testing showed that limiting its size to 256 improves performance
noticeably with little to no  impact on balancing results.

Fixes: ebb30ec64a68 ("mlx5: increase RETA table size")

Signed-off-by: Yaacov Hazan 
---
 drivers/net/mlx5/mlx5_defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_defs.h b/drivers/net/mlx5/mlx5_defs.h
index 195440c..09207d9 100644
--- a/drivers/net/mlx5/mlx5_defs.h
+++ b/drivers/net/mlx5/mlx5_defs.h
@@ -52,7 +52,7 @@
 #define MLX5_PMD_TX_PER_COMP_REQ 64

 /* RSS Indirection table size. */
-#define RSS_INDIRECTION_TABLE_SIZE 512
+#define RSS_INDIRECTION_TABLE_SIZE 256

 /* Maximum number of Scatter/Gather Elements per Work Request. */
 #ifndef MLX5_PMD_SGE_WR_N
-- 
1.9.1

[dpdk-dev] [PATCH v3 0/8] L2fwd-crypto fixes/enhancements

[Pablo de Lara]

This patches fixes some small issues in L2fwd-crypto
app and also improves the app, making it more flexible
(accepting different key sizes)
and readable (information display improvement).

Series-tested-by: Min Cao 


Changes in v3:

- Added missing Tested-by line.

Changes in v2:

- Extended help information

Pablo de Lara (8):
  l2fwd-crypto: add missing new line character in help
  l2fwd-crypto: rename period parameter
  l2fwd-crypto: add missing string initialization
  l2fwd-crypto: fix length of random IV/AAD
  l2fwd-crypto: fix ambiguous input key size
  l2fwd-crypto: clarify key parsing in help
  l2fwd-crypto: use key-value list of supported algorithms
  l2fwd-crypto: extend crypto information

 examples/l2fwd-crypto/main.c  | 473 --
 lib/librte_cryptodev/rte_crypto_sym.h |   6 +-
 2 files changed, 402 insertions(+), 77 deletions(-)

-- 
2.5.5

[dpdk-dev] [PATCH v3 1/8] l2fwd-crypto: add missing new line character in help

[Pablo de Lara]

Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application)

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 5fd4ff1..0cb46c2 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -789,7 +789,7 @@ l2fwd_crypto_usage(const char *prgname)
printf("%s [EAL options] --\n"
"  -p PORTMASK: hexadecimal bitmask of ports to configure\n"
"  -q NQ: number of queue (=ports) per lcore (default is 1)\n"
-   "  -s manage all ports from single lcore"
+   "  -s manage all ports from single lcore\n"
"  -t PERIOD: statistics will be refreshed each PERIOD seconds"
" (0 to disable, 10 default, 86400 maximum)\n"

-- 
2.5.5

[dpdk-dev] [PATCH v3 2/8] l2fwd-crypto: rename period parameter

[Pablo de Lara]

L2fwd-crypto app is based on L2fwd app and it inherits
some of its parameters (such as portmask, queues per core...).

The parameter period (period of time between statistic updates)
is -T in L2fwd, but was -t in L2fwd-crypto, so for consistency,
it is changed back to -T

Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application)

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 0cb46c2..fd30826 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -790,7 +790,7 @@ l2fwd_crypto_usage(const char *prgname)
"  -p PORTMASK: hexadecimal bitmask of ports to configure\n"
"  -q NQ: number of queue (=ports) per lcore (default is 1)\n"
"  -s manage all ports from single lcore\n"
-   "  -t PERIOD: statistics will be refreshed each PERIOD seconds"
+   "  -T PERIOD: statistics will be refreshed each PERIOD seconds"
" (0 to disable, 10 default, 86400 maximum)\n"

"  --cdev_type HW / SW / ANY\n"
@@ -1220,7 +1220,7 @@ l2fwd_crypto_parse_args(struct l2fwd_crypto_options 
*options,
break;

/* timer period */
-   case 't':
+   case 'T':
retval = l2fwd_crypto_parse_timer_period(options,
optarg);
if (retval < 0) {
-- 
2.5.5

[dpdk-dev] [PATCH v3 3/8] l2fwd-crypto: add missing string initialization

[Pablo de Lara]

When passing the preferred crypto device type in the command line parameters,
the string (HW/SW/ANY) was not being saved, which is used
for error information to the user.

Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index fd30826..1b0c229 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -968,8 +968,12 @@ l2fwd_crypto_parse_args_long_options(struct 
l2fwd_crypto_options *options,
 {
int retval;

-   if (strcmp(lgopts[option_index].name, "cdev_type") == 0)
-   return parse_cryptodev_type(&options->type, optarg);
+   if (strcmp(lgopts[option_index].name, "cdev_type") == 0) {
+   retval = parse_cryptodev_type(&options->type, optarg);
+   if (retval == 0)
+   strcpy(options->string_type, optarg);
+   return retval;
+   }

else if (strcmp(lgopts[option_index].name, "chain") == 0)
return parse_crypto_opt_chain(options, optarg);
-- 
2.5.5

[dpdk-dev] [PATCH v3 4/8] l2fwd-crypto: fix length of random IV/AAD

[Pablo de Lara]

App was generating a random IV/AAD of only 4 bytes,
instead of the actual length, since it was using sizeof(length).

Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 1b0c229..c323b55 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -643,7 +643,7 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)
port_cparams[i].aad.phys_addr = 
options->aad.phys_addr;
if (!options->aad_param)

generate_random_key(port_cparams[i].aad.data,
-   
sizeof(port_cparams[i].aad.length));
+   port_cparams[i].aad.length);

}

@@ -661,7 +661,7 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)
port_cparams[i].iv.phys_addr = options->iv.phys_addr;
if (!options->iv_param)
generate_random_key(port_cparams[i].iv.data,
-   
sizeof(port_cparams[i].iv.length));
+   port_cparams[i].iv.length);

port_cparams[i].cipher_algo = 
options->cipher_xform.cipher.algo;
}
-- 
2.5.5

[dpdk-dev] [PATCH v3 5/8] l2fwd-crypto: fix ambiguous input key size

[Pablo de Lara]

Some crypto algorithms support more than one key size
(including cipher key, authentication key, IV and AAD),
but the app was using always the minimum size.

These changes allows the user to use an specific size,
either from the string provided with cipher_key, auth_key, iv and ADD 
parameters,
or from the values provided with cipher_key_random_size,
auth_key_random_size, iv_random_size and aad_random_size.

This also allows the user to specify the digest size.

Fixes: 1df9c0109f4c ("examples/l2fwd-crypto: parse key parameters")

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 257 +--
 1 file changed, 247 insertions(+), 10 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index c323b55..c561270 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -147,15 +147,21 @@ struct l2fwd_crypto_options {

struct rte_crypto_sym_xform cipher_xform;
unsigned ckey_param;
+   int ckey_random_size;

struct l2fwd_key iv;
unsigned iv_param;
+   int iv_random_size;

struct rte_crypto_sym_xform auth_xform;
uint8_t akey_param;
+   int akey_random_size;

struct l2fwd_key aad;
unsigned aad_param;
+   int aad_random_size;
+
+   int digest_size;

uint16_t block_size;
char string_auth_algo[MAX_STR_LEN];
@@ -799,12 +805,17 @@ l2fwd_crypto_usage(const char *prgname)
"  --cipher_algo ALGO\n"
"  --cipher_op ENCRYPT / DECRYPT\n"
"  --cipher_key KEY\n"
+   "  --cipher_key_random_size SIZE: size of cipher key when 
generated randomly\n"
"  --iv IV\n"
+   "  --iv_random_size SIZE: size of IV when generated randomly\n"

"  --auth_algo ALGO\n"
"  --auth_op GENERATE / VERIFY\n"
"  --auth_key KEY\n"
+   "  --auth_key_random_size SIZE: size of auth key when generated 
randomly\n"
"  --aad AAD\n"
+   "  --aad_random_size SIZE: size of AAD when generated 
randomly\n"
+   "  --digest_size SIZE: size of digest to be 
generated/verified\n"

"  --sessionless\n",
   prgname);
@@ -906,6 +917,27 @@ parse_key(uint8_t *data, char *input_arg)
data[byte_count++] = (uint8_t)number;
}

+   return byte_count;
+}
+
+/** Parse size param*/
+static int
+parse_size(int *size, const char *q_arg)
+{
+   char *end = NULL;
+   unsigned long n;
+
+   /* parse hexadecimal string */
+   n = strtoul(q_arg, &end, 10);
+   if ((q_arg[0] == '\0') || (end == NULL) || (*end != '\0'))
+   n = 0;
+
+   if (n == 0) {
+   printf("invalid size\n");
+   return -1;
+   }
+
+   *size = n;
return 0;
 }

@@ -993,14 +1025,30 @@ l2fwd_crypto_parse_args_long_options(struct 
l2fwd_crypto_options *options,

else if (strcmp(lgopts[option_index].name, "cipher_key") == 0) {
options->ckey_param = 1;
-   return parse_key(options->cipher_xform.cipher.key.data, optarg);
+   options->cipher_xform.cipher.key.length =
+   parse_key(options->cipher_xform.cipher.key.data, 
optarg);
+   if (options->cipher_xform.cipher.key.length > 0)
+   return 0;
+   else
+   return -1;
}

+   else if (strcmp(lgopts[option_index].name, "cipher_key_random_size") == 
0)
+   return parse_size(&options->ckey_random_size, optarg);
+
else if (strcmp(lgopts[option_index].name, "iv") == 0) {
options->iv_param = 1;
-   return parse_key(options->iv.data, optarg);
+   options->iv.length =
+   parse_key(options->iv.data, optarg);
+   if (options->iv.length > 0)
+   return 0;
+   else
+   return -1;
}

+   else if (strcmp(lgopts[option_index].name, "iv_random_size") == 0)
+   return parse_size(&options->iv_random_size, optarg);
+
/* Authentication options */
else if (strcmp(lgopts[option_index].name, "auth_algo") == 0) {
retval = parse_auth_algo(&options->auth_xform.auth.algo,
@@ -1016,12 +1064,34 @@ l2fwd_crypto_parse_args_long_options(struct 
l2fwd_crypto_options *options,

else if (strcmp(lgopts[option_index].name, "auth_key") == 0) {
options->akey_param = 1;
-   return parse_key(options->auth_xform.auth.key.data, optarg);
+   options->auth_xform.auth.key.length =
+   parse_key(options->auth_xform.auth.key.data, optarg);
+   if (options->auth_xform.auth.key.length > 0)
+   return 0;
+   else
+   return -1;
+   }
+
+   else

[dpdk-dev] [PATCH v3 6/8] l2fwd-crypto: clarify key parsing in help

[Pablo de Lara]

Cipher/Auth keys, AAD and IV must be passed from command line
with ":" between bytes, but help was not clarifying that.

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index c561270..6a28448 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -804,16 +804,16 @@ l2fwd_crypto_usage(const char *prgname)

"  --cipher_algo ALGO\n"
"  --cipher_op ENCRYPT / DECRYPT\n"
-   "  --cipher_key KEY\n"
+   "  --cipher_key KEY (bytes separated with \":\")\n"
"  --cipher_key_random_size SIZE: size of cipher key when 
generated randomly\n"
-   "  --iv IV\n"
+   "  --iv IV (bytes separated with \":\")\n"
"  --iv_random_size SIZE: size of IV when generated randomly\n"

"  --auth_algo ALGO\n"
"  --auth_op GENERATE / VERIFY\n"
-   "  --auth_key KEY\n"
+   "  --auth_key KEY (bytes separated with \":\")\n"
"  --auth_key_random_size SIZE: size of auth key when generated 
randomly\n"
-   "  --aad AAD\n"
+   "  --aad AAD (bytes separated with \":\")\n"
"  --aad_random_size SIZE: size of AAD when generated 
randomly\n"
"  --digest_size SIZE: size of digest to be 
generated/verified\n"

-- 
2.5.5

[dpdk-dev] [PATCH v3 7/8] l2fwd-crypto: use key-value list of supported algorithms

[Pablo de Lara]

In order to ease the parsing and display of supported algorithms
in the application, two new arrays are created, which contains
the strings of the different cipher and authentication algorithms,

These lists are used to parse the algorithms from the command line,
and will be used to display crypto information to the user.

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c  | 106 +-
 lib/librte_cryptodev/rte_crypto_sym.h |   6 +-
 2 files changed, 58 insertions(+), 54 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 6a28448..5fb33df 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -133,6 +133,9 @@ struct l2fwd_key {
phys_addr_t phys_addr;
 };

+char supported_auth_algo[RTE_CRYPTO_AUTH_LIST_END][MAX_STR_LEN];
+char supported_cipher_algo[RTE_CRYPTO_CIPHER_LIST_END][MAX_STR_LEN];
+
 /** l2fwd crypto application command line options */
 struct l2fwd_crypto_options {
unsigned portmask;
@@ -164,8 +167,6 @@ struct l2fwd_crypto_options {
int digest_size;

uint16_t block_size;
-   char string_auth_algo[MAX_STR_LEN];
-   char string_cipher_algo[MAX_STR_LEN];
char string_type[MAX_STR_LEN];
 };

@@ -328,6 +329,32 @@ print_stats(void)
printf("\n\n");
 }

+static void
+fill_supported_algorithm_tables(void)
+{
+   unsigned i;
+
+   for (i = 0; i < RTE_CRYPTO_AUTH_LIST_END; i++)
+   strcpy(supported_auth_algo[i], "NOT_SUPPORTED");
+
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_AES_GCM], "AES_GCM");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_MD5_HMAC], "MD5_HMAC");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_NULL], "NULL");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_SHA1_HMAC], "SHA1_HMAC");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_SHA224_HMAC], "SHA224_HMAC");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_SHA256_HMAC], "SHA256_HMAC");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_SHA384_HMAC], "SHA384_HMAC");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_SHA512_HMAC], "SHA512_HMAC");
+   strcpy(supported_auth_algo[RTE_CRYPTO_AUTH_SNOW3G_UIA2], "SNOW3G_UIA2");
+
+   for (i = 0; i < RTE_CRYPTO_CIPHER_LIST_END; i++)
+   strcpy(supported_cipher_algo[i], "NOT_SUPPORTED");
+
+   strcpy(supported_cipher_algo[RTE_CRYPTO_CIPHER_AES_CBC], "AES_CBC");
+   strcpy(supported_cipher_algo[RTE_CRYPTO_CIPHER_AES_GCM], "AES_GCM");
+   strcpy(supported_cipher_algo[RTE_CRYPTO_CIPHER_NULL], "NULL");
+   strcpy(supported_cipher_algo[RTE_CRYPTO_CIPHER_SNOW3G_UEA2], 
"SNOW3G_UEA2");
+}


 static int
@@ -864,18 +891,13 @@ parse_crypto_opt_chain(struct l2fwd_crypto_options 
*options, char *optarg)
 static int
 parse_cipher_algo(enum rte_crypto_cipher_algorithm *algo, char *optarg)
 {
-   if (strcmp("AES_CBC", optarg) == 0) {
-   *algo = RTE_CRYPTO_CIPHER_AES_CBC;
-   return 0;
-   } else if (strcmp("AES_GCM", optarg) == 0) {
-   *algo = RTE_CRYPTO_CIPHER_AES_GCM;
-   return 0;
-   } else if (strcmp("NULL", optarg) == 0) {
-   *algo = RTE_CRYPTO_CIPHER_NULL;
-   return 0;
-   } else if (strcmp("SNOW3G_UEA2", optarg) == 0) {
-   *algo = RTE_CRYPTO_CIPHER_SNOW3G_UEA2;
-   return 0;
+   unsigned i;
+
+   for (i = 0; i < RTE_CRYPTO_CIPHER_LIST_END; i++) {
+   if (!strcmp(supported_cipher_algo[i], optarg)) {
+   *algo = i;
+   return 0;
+   }
}

printf("Cipher algorithm  not supported!\n");
@@ -945,33 +967,13 @@ parse_size(int *size, const char *q_arg)
 static int
 parse_auth_algo(enum rte_crypto_auth_algorithm *algo, char *optarg)
 {
-   if (strcmp("AES_GCM", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_AES_GCM;
-   return 0;
-   } else if (strcmp("MD5_HMAC", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_MD5_HMAC;
-   return 0;
-   } else if (strcmp("NULL", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_NULL;
-   return 0;
-   } else if (strcmp("SHA1_HMAC", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_SHA1_HMAC;
-   return 0;
-   } else if (strcmp("SHA224_HMAC", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_SHA224_HMAC;
-   return 0;
-   } else if (strcmp("SHA256_HMAC", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_SHA256_HMAC;
-   return 0;
-   }  else if (strcmp("SHA384_HMAC", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_SHA384_HMAC;
-   return 0;
-   } else if (strcmp("SHA512_HMAC", optarg) == 0) {
-   *algo = RTE_CRYPTO_AUTH_SHA512_HMAC;
-   return 0;
-   } else if (strcmp("SNOW3G_UIA2", optarg) == 0) 

[dpdk-dev] [PATCH v3 8/8] l2fwd-crypto: extend crypto information

[Pablo de Lara]

Display extra crypto information (algorithms, keys/IV/AAD used, chain...),
so user can know exactly what operations are being carried out.

Signed-off-by: Pablo de Lara 
---
 examples/l2fwd-crypto/main.c | 84 ++--
 1 file changed, 82 insertions(+), 2 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 5fb33df..09a07d3 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -71,6 +71,7 @@
 #include 
 #include 
 #include 
+#include 

 enum cdev_type {
CDEV_TYPE_ANY,
@@ -634,8 +635,6 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)

RTE_LOG(INFO, L2FWD, "entering main loop on lcore %u\n", lcore_id);

-   l2fwd_crypto_options_print(options);
-
for (i = 0; i < qconf->nb_rx_ports; i++) {

portid = qconf->rx_port_list[i];
@@ -708,6 +707,14 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)
port_cparams[i].dev_id);
}

+   l2fwd_crypto_options_print(options);
+
+   /*
+* Initialize previous tsc timestamp before the loop,
+* to avoid showing the port statistics immediately,
+* so user can see the crypto information.
+*/
+   prev_tsc = rte_rdtsc();
while (1) {

cur_tsc = rte_rdtsc();
@@ -1213,8 +1220,45 @@ l2fwd_crypto_default_options(struct l2fwd_crypto_options 
*options)
 }

 static void
+display_cipher_info(struct l2fwd_crypto_options *options)
+{
+   printf("\n Cipher information ---\n");
+   printf("Algorithm: %s\n",
+   supported_cipher_algo[options->cipher_xform.cipher.algo]);
+   rte_hexdump(stdout, "Cipher key:",
+   options->cipher_xform.cipher.key.data,
+   options->cipher_xform.cipher.key.length);
+   rte_hexdump(stdout, "IV:", options->iv.data, options->iv.length);
+}
+
+static void
+display_auth_info(struct l2fwd_crypto_options *options)
+{
+   printf("\n Authentication information ---\n");
+   printf("Algorithm: %s\n",
+   supported_auth_algo[options->auth_xform.auth.algo]);
+   rte_hexdump(stdout, "Auth key:",
+   options->auth_xform.auth.key.data,
+   options->auth_xform.auth.key.length);
+   rte_hexdump(stdout, "AAD:", options->aad.data, options->aad.length);
+}
+
+static void
 l2fwd_crypto_options_print(struct l2fwd_crypto_options *options)
 {
+   char string_cipher_op[MAX_STR_LEN];
+   char string_auth_op[MAX_STR_LEN];
+
+   if (options->cipher_xform.cipher.op == RTE_CRYPTO_CIPHER_OP_ENCRYPT)
+   strcpy(string_cipher_op, "Encrypt");
+   else
+   strcpy(string_cipher_op, "Decrypt");
+
+   if (options->auth_xform.auth.op == RTE_CRYPTO_AUTH_OP_GENERATE)
+   strcpy(string_auth_op, "Auth generate");
+   else
+   strcpy(string_auth_op, "Auth verify");
+
printf("Options:-\nn");
printf("portmask: %x\n", options->portmask);
printf("ports per lcore: %u\n", options->nb_ports_per_lcore);
@@ -1226,6 +1270,42 @@ l2fwd_crypto_options_print(struct l2fwd_crypto_options 
*options)

printf("sessionless crypto: %s\n",
options->sessionless ? "enabled" : "disabled");
+
+   if (options->ckey_param && (options->ckey_random_size != -1))
+   printf("Cipher key already parsed, ignoring size of random 
key\n");
+
+   if (options->akey_param && (options->akey_random_size != -1))
+   printf("Auth key already parsed, ignoring size of random 
key\n");
+
+   if (options->iv_param && (options->iv_random_size != -1))
+   printf("IV already parsed, ignoring size of random IV\n");
+
+   if (options->aad_param && (options->aad_random_size != -1))
+   printf("AAD already parsed, ignoring size of random AAD\n");
+
+   printf("\nCrypto chain: ");
+   switch (options->xform_chain) {
+   case L2FWD_CRYPTO_CIPHER_HASH:
+   printf("Input --> %s --> %s --> Output\n",
+   string_cipher_op, string_auth_op);
+   display_cipher_info(options);
+   display_auth_info(options);
+   break;
+   case L2FWD_CRYPTO_HASH_CIPHER:
+   printf("Input --> %s --> %s --> Output\n",
+   string_auth_op, string_cipher_op);
+   display_cipher_info(options);
+   display_auth_info(options);
+   break;
+   case L2FWD_CRYPTO_HASH_ONLY:
+   printf("Input --> %s --> Output\n", string_auth_op);
+   display_auth_info(options);
+   break;
+   case L2FWD_CRYPTO_CIPHER_ONLY:
+   printf("Input --> %s --> Output\n", string_cipher_op);
+   display_cipher_info(options);
+   break;
+   }
 }

 /* Parse the argument given in the command line of the applicati

[dpdk-dev] [PATCH v2 0/8] L2fwd-crypto fixes/enhancements

[De Lara Guarch, Pablo]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, March 31, 2016 10:20 AM
> To: De Lara Guarch, Pablo
> Cc: dev at dpdk.org; Doherty, Declan
> Subject: Re: [dpdk-dev] [PATCH v2 0/8] L2fwd-crypto fixes/enhancements
> 
> 2016-03-31 10:01, Pablo de Lara:
> > This patches fixes some small issues in L2fwd-crypto
> > app and also improves the app, making it more flexible
> > (accepting different key sizes)
> > and readable (information display improvement).
> >
> > Changes in v2:
> >
> > - Extended help information
> 
> The line "Tested-by: Min Cao " is missing.

Thanks for pointing that out. V3 sent with that line.

Pablo

[dpdk-dev] [PATCH v2] mlx5: fix RETA table size

[Adrien Mazarguil]

On Thu, Mar 31, 2016 at 12:21:08PM +0300, Yaacov Hazan wrote:
> When the number of RX queues is not a power of two,
> the RETA table is configured to its maximum size for
> better balancing.
> 
> Testing showed that limiting its size to 256 improves performance
> noticeably with little to no  impact on balancing results.
> 
> Fixes: ebb30ec64a68 ("mlx5: increase RETA table size")
> 
> Signed-off-by: Yaacov Hazan 

Acked-by: Adrien Mazarguil 

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH] mlx: fix double mbuf free in TX queue clean up function

[Adrien Mazarguil]

Once freed, completed mbufs pointers are not set to NULL in the TX queue.
Clean up function must take this into account.

Fixes: 2e22920b85d9 ("mlx5: support non-scattered Tx and Rx")
Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")

Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx4/mlx4.c  | 25 -
 drivers/net/mlx5/mlx5_rxtx.c |  4 
 drivers/net/mlx5/mlx5_txq.c  | 21 -
 3 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index f946f08..5cc995f 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -1047,14 +1047,20 @@ error:
 static void
 txq_free_elts(struct txq *txq)
 {
-   unsigned int i;
unsigned int elts_n = txq->elts_n;
+   unsigned int elts_head = txq->elts_head;
+   unsigned int elts_tail = txq->elts_tail;
struct txq_elt (*elts)[elts_n] = txq->elts;
linear_t (*elts_linear)[elts_n] = txq->elts_linear;
struct ibv_mr *mr_linear = txq->mr_linear;

DEBUG("%p: freeing WRs", (void *)txq);
txq->elts_n = 0;
+   txq->elts_head = 0;
+   txq->elts_tail = 0;
+   txq->elts_comp = 0;
+   txq->elts_comp_cd = 0;
+   txq->elts_comp_cd_init = 0;
txq->elts = NULL;
txq->elts_linear = NULL;
txq->mr_linear = NULL;
@@ -1064,12 +1070,17 @@ txq_free_elts(struct txq *txq)
rte_free(elts_linear);
if (elts == NULL)
return;
-   for (i = 0; (i != elemof(*elts)); ++i) {
-   struct txq_elt *elt = &(*elts)[i];
+   while (elts_tail != elts_head) {
+   struct txq_elt *elt = &(*elts)[elts_tail];

-   if (elt->buf == NULL)
-   continue;
+   assert(elt->buf != NULL);
rte_pktmbuf_free(elt->buf);
+#ifndef NDEBUG
+   /* Poisoning. */
+   memset(elt, 0x77, sizeof(*elt));
+#endif
+   if (++elts_tail == elts_n)
+   elts_tail = 0;
}
rte_free(elts);
 }
@@ -1588,6 +1599,10 @@ mlx4_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, 
uint16_t pkts_n)
if (likely(elt->buf != NULL)) {
struct rte_mbuf *tmp = elt->buf;

+#ifndef NDEBUG
+   /* Poisoning. */
+   memset(elt, 0x66, sizeof(*elt));
+#endif
/* Faster than rte_pktmbuf_free(). */
do {
struct rte_mbuf *next = NEXT(tmp);
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index edf64aa..9d1380a 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -120,6 +120,10 @@ txq_complete(struct txq *txq)
struct rte_mbuf *tmp = elt->buf;
struct txq_elt *elt_next = &(*txq->elts)[elts_free_next];

+#ifndef NDEBUG
+   /* Poisoning. */
+   memset(elt, 0x66, sizeof(*elt));
+#endif
RTE_MBUF_PREFETCH_TO_FREE(elt_next->buf);
/* Faster than rte_pktmbuf_free(). */
do {
diff --git a/drivers/net/mlx5/mlx5_txq.c b/drivers/net/mlx5/mlx5_txq.c
index ce2bb42..31ce53a 100644
--- a/drivers/net/mlx5/mlx5_txq.c
+++ b/drivers/net/mlx5/mlx5_txq.c
@@ -144,14 +144,20 @@ error:
 static void
 txq_free_elts(struct txq *txq)
 {
-   unsigned int i;
unsigned int elts_n = txq->elts_n;
+   unsigned int elts_head = txq->elts_head;
+   unsigned int elts_tail = txq->elts_tail;
struct txq_elt (*elts)[elts_n] = txq->elts;
linear_t (*elts_linear)[elts_n] = txq->elts_linear;
struct ibv_mr *mr_linear = txq->mr_linear;

DEBUG("%p: freeing WRs", (void *)txq);
txq->elts_n = 0;
+   txq->elts_head = 0;
+   txq->elts_tail = 0;
+   txq->elts_comp = 0;
+   txq->elts_comp_cd = 0;
+   txq->elts_comp_cd_init = 0;
txq->elts = NULL;
txq->elts_linear = NULL;
txq->mr_linear = NULL;
@@ -161,12 +167,17 @@ txq_free_elts(struct txq *txq)
rte_free(elts_linear);
if (elts == NULL)
return;
-   for (i = 0; (i != RTE_DIM(*elts)); ++i) {
-   struct txq_elt *elt = &(*elts)[i];
+   while (elts_tail != elts_head) {
+   struct txq_elt *elt = &(*elts)[elts_tail];

-   if (elt->buf == NULL)
-   continue;
+   assert(elt->buf != NULL);
rte_pktmbuf_free(elt->buf);
+#ifndef NDEBUG
+   /* Poisoning. */
+   memset(elt, 0x77, sizeof(*elt));
+#endif
+   if (++elts_tail == elts_n)
+   elts_tail = 0;
}
rte_free(elts);
 }
-- 
2.1.4

[dpdk-dev] Must kni be associated with a dpdk port?

[Ferruh Yigit]

On 3/30/2016 6:20 PM, ALeX Wang wrote:
> Hi,
> 
> I want to use 'rte_kni_alloc()' to create a kernel iface and
> use it to test application rx.  From the api and example in
> 'examples/kni/main.c', i saw the 'conf' argument is assigned
> with pci info of a dpdk port.
> 
> Want to ask if this is compulsory...  Must kni always be
> used together with a dpdk port?
> 
> Thanks,
> 

Hi Alex,

You don't have to associate kni with dpdk port.

pci info is required for ethtool support, if you are only interested in
data transfer, you don't have to provide pci information.

Regards,
ferruh

[dpdk-dev] [PATCH] doc: fill nics features matrix for mlx4 & mlx5

[Adrien Mazarguil]

Signed-off-by: Adrien Mazarguil 
---
 doc/guides/nics/overview.rst | 56 ++--
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index 542479a..5238088 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -86,63 +86,63 @@ Most of these differences are summarized below.
   e   e   e   e   e
 e
   c   c   c   c   c
 c
 = = = = = = = = = = = = = = = = = = = = = = = = = = = 
= = = = = =
-   link status  X   X X   
X X
-   link status eventX X
 X
+   link status  X   X X X X   
X X
+   link status eventX X X X
 X
queue status event  
 X
Rx interrupt X X X X
-   queue start/stop X   X   X X X X   X
-   MTU update   X   X
-   jumbo frame  X   X   X X X X
-   scattered Rx X   X   X X X X   X
+   queue start/stop X   X   X X X X X X   X
+   MTU update   X   X   X X
+   jumbo frame  X   X   X X X X X X
+   scattered Rx X   X   X X X X X X   X
LRO
TSO  X   X   X X X X
-   promiscuous mode X   X X X X   X
-   allmulticast modeX   X X X X   X
+   promiscuous mode X   X X X X X X   X
+   allmulticast modeX   X X X X X X   X
unicast MAC filter   X X X X
multicast MAC filter X X X X
-   RSS hash X   X   X X X X
-   RSS key update   X   X X X X
-   RSS reta update  X   X X X X
+   RSS hash X   X   X X X X X X
+   RSS key update   X   X X X X   X
+   RSS reta update  X   X X X X   X
VMDq X X
-   SR-IOV   X   X X
+   SR-IOV   X   X X X X
DCB  X X
-   VLAN filter  X X X X
+   VLAN filter  X X X X X X
ethertype filter X X
n-tuple filter
SYN filter
tunnel filterX X
flexible filter
hash filter  X X X X
-   flow directorX X
+   flow directorX X   X
flow control X   X X
rate limitation
traffic mirroringX X
-   CRC offload  X   X   X   X
-   VLAN offload X   X   X   X
+   CRC offload  X   X   X   X X
+   VLAN offload X   X   X   X X
QinQ offload X   X
-   L3 checksum offload  X   X   X   X
-   L4 checksum offload  X   X   X   X
-   inner L3 checksumX   X   X
-   inner L4 checksumX   X   X
-   packet type parsing  X   X   X
+   L3 checksum offload  X   X   X   X   X X
+   L4 checksum offload  X   X   X   X   X X
+   inner L3 checksumX   X   X   X
+   inner L4 checksumX   X   X   X
+   packet type parsing  X   X   X   X X
timesync X X
-   basic stats  X   X   X X X X   
X X
+   basic stats  X   X   X X X X X X   
X X
extended stats   X   X X X X
-   stats per queue  X X
+   stats per queue  X   X X   X
EEPROM dump
registers dump
-   multiprocess aware   X X X X
+   multiprocess aware   X X X X X X
BSD nic_uio  X   X X X X
Linux UIOX   X   X X X X
Linux VFIO   X   X X X X
other kdrv X
ARMv7
ARMv8
-   Power8
+   Power8 

[dpdk-dev] Reg: promiscuous mode on VF

[bharath paulraj]

Hi Michael and All,

 I am unable to set the rule to receive the packet on the VF.
Below is my setup.

1. Creating one virtual function with one queue, in one of my port, p2p1.
*modprobe ixgbe MQ=1 max_vfs=1 RSS=1 allow_unsupported_sfp=1 *
2. Below is the interface status after creating one virtual function.
[root at  sriov]# ifconfig p2p1
p2p1  Link encap:Ethernet  HWaddr A0:36:9F:86:C2:74
  inet6 addr: fe80::a236:9fff:fe86:c274/64 Scope:Link
  UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500 Metric:1
  RX packets:2540 errors:0 dropped:0 overruns:0 frame:0
  TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:157456 (153.7 KiB)  TX bytes:258 (258.0 b)

[root at  sriov]# ifconfig p2p1_0
p2p1_0Link encap:Ethernet  HWaddr DA:61:95:CD:AF:35
  inet6 addr: fe80::d861:95ff:fecd:af35/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:12 errors:0 dropped:0 overruns:0 frame:0
  TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:360 (360.0 b)  TX bytes:740 (740.0 b)
3. Next I am enable ntuple
*ethtool -K p2p1  ntuple on *
4. Now I am adding below rule

*ethtool -N p2p1   flow-type udp4 dst-port 4789 action 0x1 --> VF
0, queue 0 ethtool -N p2p1   flow-type udp4 dst-port 4790 action
0x0 --> PF queue 0 *
5. [root at XXX sriov]# ethtool -n p2p1
1 RX rings available
Total 2 rules

Filter: 2044
Rule Type: UDP over IPv4
Src IP addr: 0.0.0.0 mask: 255.255.255.255
Dest IP addr: 0.0.0.0 mask: 255.255.255.255
TOS: 0x0 mask: 0xff
Src port: 0 mask: 0x
Dest port: 4790 mask: 0x0
VLAN EtherType: 0x0 mask: 0x
VLAN: 0x0 mask: 0x
User-defined: 0x0 mask: 0x
Action: Direct to queue 0

Filter: 2045
Rule Type: UDP over IPv4
Src IP addr: 0.0.0.0 mask: 255.255.255.255
Dest IP addr: 0.0.0.0 mask: 255.255.255.255
TOS: 0x0 mask: 0xff
Src port: 0 mask: 0x
Dest port: 4789 mask: 0x0
VLAN EtherType: 0x0 mask: 0x
VLAN: 0x0 mask: 0x
User-defined: 0x0 mask: 0x
Action: Direct to queue 0
*>> Won't it show the VF queue numbers here?*

6. Start the VM over p2p1_0
7. Below is the Packet I am sending
a) Dest MAC - VF Mac, Src MAC - any untagged, src ip - 1.1.1.1 dest ip -
2.2.2.2 src port - 100 dest port - 4789
b) Dest MAC - VF Mac, Src MAC - any, untagged, src ip - 1.1.1.1 dest ip -
2.2.2.2 src port - 100 dest port - 4790
c) Dest MAC - VF Mac, untagged, src ip - 1.1.1.1 dest ip - 2.2.2.2 src port
- 100 dest port - 4791

All the above testing is done on centOs-6.7 with ixgbe version - 4.3.13
with patch you mentioned on 82599 Ethernet controller
Linux XXX 2.6.32-573.22.1.el6.x86_64 #1 SMP Wed Mar 23 03:35:39 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux


*Observation: *
If the packet matches the rule, I am not able to see the packet in the VF,
instead I am able to see the packet in PF.
for the packets a) and b), I am able to see te packet only in PF. Even if
the packet destination MAC is VF's MAC,
I am able to see only in PF.
If the packet is not matching the rule, then I am able to see the packet in
VF, provided packet destination MAC is VF's MAC.
*Question: *
1) Am I mapping the queues wrongly while adding the rules?
2) How to Identify which VF using which Queues?

Request you to provide some help on it.


On Tue, Mar 22, 2016 at 1:03 PM, bharath paulraj 
wrote:

> Thanks a lot Michael.  Finally i am able to see some light. I will try the
> same in our setup and will post you the results.
>
> Thanks,
> Bharath
>
> On Tue, Mar 22, 2016 at 12:09 PM, Qiu, Michael 
> wrote:
>
>> Yes, we could let ovs using 82599 VF to do rx/tx. I don't know what's
>> your l2 bridge, but since ovs could work I think your bridge also could
>> work. But I only tested with one VF.
>>
>> Make sure below two patches (bifurcate driver) are included in your
>> kernel:
>>
>> _https://patchwork.ozlabs.org/patch/476511/_
>> _https://patchwork.ozlabs.org/patch/476516/_
>>
>> Mostly, if your kernel version in 4.2 or newer, it should be included.
>>
>> After you create VF, before you passthrough the VF to guest:
>>
>> (vf +1) << 32 + queue-index,
>>
>>
>>  1. where vf is the VF index starting from 0
>>  2. the queue-index is 0 if multi-queue support is not turned on, and
>> this value is [0,1] if multiple-queue is turned on
>>
>>
>> echo 1 > /sys/bus/pci/devices/\:05\:00.0/sriov_numvfs
>> ifconfig $(PF_INTF) up
>> ifconfig $(VF0_INFT) up
>> ip link set $(PF_INTF) promisc on
>> ethtool -K $(PF_INTF) ntuple on
>> ethtool -N $(PF_INTF) flow-type udp4 dst-port 4789 action 0x1
>> (VF0 queue 0)
>>
>> Here we using flow director to all let packets according to the rules to
>> the VF, But I don't know if it could le

[dpdk-dev] [PATCH 1/4] lpm: allocation of an existing object should fail

[Bruce Richardson]

On Wed, Mar 30, 2016 at 02:46:49PM -0700, Stephen Hemminger wrote:
> On Wed, 30 Mar 2016 17:30:24 +0200
> Olivier Matz  wrote:
> 
> > diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
> > index 4c44cd7..9877a30 100644
> > --- a/lib/librte_lpm/rte_lpm6.c
> > +++ b/lib/librte_lpm/rte_lpm6.c
> > @@ -182,8 +182,11 @@ rte_lpm6_create(const char *name, int socket_id,
> > if (strncmp(name, lpm->name, RTE_LPM6_NAMESIZE) == 0)
> > break;
> > }
> > -   if (te != NULL)
> > +   if (te != NULL) {
> > +   lpm = NULL;
> > +   rte_errno = EEXIST;
> > goto exit;
> > +   }
> >  
> > /* allocate tailq entry */
> >  
> 
> with older memzone model, objects in huge memory area were never freed.
> That means when application restarts it finds the old LPM and works.
> With your change it would break such an application.

Is all the memory not zeroed on initialization?

/Bruce

[dpdk-dev] [PATCH] doc: fill nics features matrix for mlx4 & mlx5

[Tan, Jianfeng]

Hi,

On 3/31/2016 6:22 PM, Adrien Mazarguil wrote:
> Signed-off-by: Adrien Mazarguil 
> ---
>   doc/guides/nics/overview.rst | 56 
> ++--
>   1 file changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
> index 542479a..5238088 100644
> --- a/doc/guides/nics/overview.rst
> +++ b/doc/guides/nics/overview.rst
> @@ -86,63 +86,63 @@ Most of these differences are summarized below.
> e   e   e   e   e 
> e
> c   c   c   c   c 
> c
>   = = = = = = = = = = = = = = = = = = = = = = = = = = 
> = = = = = = =
> -   link status  X   X X  
>  X X
> -   link status eventX X  
>X
> +   link status  X   X X X X  
>  X X
> +   link status eventX X X X  
>X
>  queue status event   
> X
>  Rx interrupt X X X X
> -   queue start/stop X   X   X X X X  
>  X
> -   MTU update   X   X
> -   jumbo frame  X   X   X X X X
> -   scattered Rx X   X   X X X X  
>  X
> +   queue start/stop X   X   X X X X X X  
>  X
> +   MTU update   X   X   X X
> +   jumbo frame  X   X   X X X X X X
> +   scattered Rx X   X   X X X X X X  
>  X
>  LRO
>  TSO  X   X   X X X X
> -   promiscuous mode X   X X X X  
>  X
> -   allmulticast modeX   X X X X  
>  X
> +   promiscuous mode X   X X X X X X  
>  X
> +   allmulticast modeX   X X X X X X  
>  X
>  unicast MAC filter   X X X X
>  multicast MAC filter X X X X
> -   RSS hash X   X   X X X X
> -   RSS key update   X   X X X X
> -   RSS reta update  X   X X X X
> +   RSS hash X   X   X X X X X X
> +   RSS key update   X   X X X X   X
> +   RSS reta update  X   X X X X   X
>  VMDq X X
> -   SR-IOV   X   X X
> +   SR-IOV   X   X X X X
>  DCB  X X
> -   VLAN filter  X X X X
> +   VLAN filter  X X X X X X
>  ethertype filter X X
>  n-tuple filter
>  SYN filter
>  tunnel filterX X
>  flexible filter
>  hash filter  X X X X
> -   flow directorX X
> +   flow directorX X   X
>  flow control X   X X
>  rate limitation
>  traffic mirroringX X
> -   CRC offload  X   X   X   X
> -   VLAN offload X   X   X   X
> +   CRC offload  X   X   X   X X
> +   VLAN offload X   X   X   X X
>  QinQ offload X   X
> -   L3 checksum offload  X   X   X   X
> -   L4 checksum offload  X   X   X   X
> -   inner L3 checksumX   X   X
> -   inner L4 checksumX   X   X
> -   packet type parsing  X   X   X
> +   L3 checksum offload  X   X   X   X   X X
> +   L4 checksum offload  X   X   X   X   X X
> +   inner L3 checksumX   X   X   X
> +   inner L4 checksumX   X   X   X
> +   packet type parsing  X   X   X   X X
>  timesync X X
> -   basic stats  X   X   X X X X  
>  X X
> +   basic stats  X   X   X X X X X X  
>  X X
>  extended stats   X   X X X X
> -   stats per queue  X
>  X
> +   stats per queue  X   X X  
>  X
>  EEPROM dump
>  registers dump
> -   multiprocess aware   X X X X
> +   multiprocess aware   X X X X X X
> 

[dpdk-dev] [PATCH] doc: fill nics features matrix for mlx4 & mlx5

[Adrien Mazarguil]

On Thu, Mar 31, 2016 at 06:55:41PM +0800, Tan, Jianfeng wrote:
> Hi,
> 
> On 3/31/2016 6:22 PM, Adrien Mazarguil wrote:
> >Signed-off-by: Adrien Mazarguil 
> >---
> >  doc/guides/nics/overview.rst | 56 
> > ++--
> >  1 file changed, 28 insertions(+), 28 deletions(-)
> >
> >diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
> >index 542479a..5238088 100644
> >--- a/doc/guides/nics/overview.rst
> >+++ b/doc/guides/nics/overview.rst
> >@@ -86,63 +86,63 @@ Most of these differences are summarized below.
> >e   e   e   e   e
> >  e
> >c   c   c   c   c
> >  c
> >  = = = = = = = = = = = = = = = = = = = = = = = = = 
> > = = = = = = = =
> >-   link status  X   X X 
> >  X X
> >-   link status eventX X 
> >X
> >+   link status  X   X X X X 
> >  X X
> >+   link status eventX X X X 
> >X
> > queue status event  
> >  X
> > Rx interrupt X X X X
> >-   queue start/stop X   X   X X X X 
> >  X
> >-   MTU update   X   X
> >-   jumbo frame  X   X   X X X X
> >-   scattered Rx X   X   X X X X 
> >  X
> >+   queue start/stop X   X   X X X X X X 
> >  X
> >+   MTU update   X   X   X X
> >+   jumbo frame  X   X   X X X X X X
> >+   scattered Rx X   X   X X X X X X 
> >  X
> > LRO
> > TSO  X   X   X X X X
> >-   promiscuous mode X   X X X X 
> >  X
> >-   allmulticast modeX   X X X X 
> >  X
> >+   promiscuous mode X   X X X X X X 
> >  X
> >+   allmulticast modeX   X X X X X X 
> >  X
> > unicast MAC filter   X X X X
> > multicast MAC filter X X X X
> >-   RSS hash X   X   X X X X
> >-   RSS key update   X   X X X X
> >-   RSS reta update  X   X X X X
> >+   RSS hash X   X   X X X X X X
> >+   RSS key update   X   X X X X   X
> >+   RSS reta update  X   X X X X   X
> > VMDq X X
> >-   SR-IOV   X   X X
> >+   SR-IOV   X   X X X X
> > DCB  X X
> >-   VLAN filter  X X X X
> >+   VLAN filter  X X X X X X
> > ethertype filter X X
> > n-tuple filter
> > SYN filter
> > tunnel filterX X
> > flexible filter
> > hash filter  X X X X
> >-   flow directorX X
> >+   flow directorX X   X
> > flow control X   X X
> > rate limitation
> > traffic mirroringX X
> >-   CRC offload  X   X   X   X
> >-   VLAN offload X   X   X   X
> >+   CRC offload  X   X   X   X X
> >+   VLAN offload X   X   X   X X
> > QinQ offload X   X
> >-   L3 checksum offload  X   X   X   X
> >-   L4 checksum offload  X   X   X   X
> >-   inner L3 checksumX   X   X
> >-   inner L4 checksumX   X   X
> >-   packet type parsing  X   X   X
> >+   L3 checksum offload  X   X   X   X   X X
> >+   L4 checksum offload  X   X   X   X   X X
> >+   inner L3 checksumX   X   X   X
> >+   inner L4 checksumX   X   X   X
> >+   packet type parsing  X   X   X   X X
> > timesync X X
> >-   basic stats  X   X   X X X X 
> >  X X
> >+   basic stats  X   X   X X X X X X 
> >  X X
> > extended stats   X   X X X X
> >-   stats per queue  X   
> >  X
> >+   stats per queue  X   X X   

[dpdk-dev] [PATCH 2/4] port: fix ring writer buffer overflow

[Dumitrescu, Cristian]

> -Original Message-
> From: Robert Sanford [mailto:rsanford2 at gmail.com]
> Sent: Monday, March 28, 2016 9:52 PM
> To: dev at dpdk.org; Dumitrescu, Cristian 
> Subject: [PATCH 2/4] port: fix ring writer buffer overflow
> 
> Ring writer tx_bulk functions may write past the end of tx_buf[].
> Solution is to double the size of tx_buf[].
> 
> Signed-off-by: Robert Sanford 
> ---
>  lib/librte_port/rte_port_ring.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_port/rte_port_ring.c b/lib/librte_port/rte_port_ring.c
> index b847fea..765ecc5 100644
> --- a/lib/librte_port/rte_port_ring.c
> +++ b/lib/librte_port/rte_port_ring.c
> @@ -179,7 +179,7 @@ rte_port_ring_reader_stats_read(void *port,
>  struct rte_port_ring_writer {
>   struct rte_port_out_stats stats;
> 
> - struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX];
> + struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX];
>   struct rte_ring *ring;
>   uint32_t tx_burst_sz;
>   uint32_t tx_buf_count;
> @@ -447,7 +447,7 @@ rte_port_ring_writer_stats_read(void *port,
>  struct rte_port_ring_writer_nodrop {
>   struct rte_port_out_stats stats;
> 
> - struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX];
> + struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX];
>   struct rte_ring *ring;
>   uint32_t tx_burst_sz;
>   uint32_t tx_buf_count;
> --
> 1.7.1

Hi Robert,

How is the buffer overflow taking place?

After looking long and hard, I spotted that buffer overflow can potentially 
take place when the following conditions are met:
1. The input packet burst does not meet the conditions of (a) being contiguous 
(first n bits set in pkts_mask, all the other bits cleared) and (b) containing 
a full burst, i.e. at least tx_burst_sz packets (n >= tx_burst_size). This is 
the slow(er) code path taken when local variable expr != 0.
2. There are some packets already in the buffer.
3. The number of packets in the incoming burst (i.e. popcount(pkts_mask)) plus 
the number of packets already in the buffer exceeds the buffer size 
(RTE_PORT_IN_BURST_SIZE_MAX, i.e. 64).

Is this the buffer overflow scenario that you detected?

Thanks,
Cristian

[dpdk-dev] [PATCH] examples/ipsec-secgw: Fix Missed Headers For FreeBSD

[Sergio Gonzalez Monroy]

Commit title shouldn't contain capital letters.

On 31/03/2016 10:12, Daniel Mrzyglod wrote:
> There were misssed typedef for u_char - 
> There were missed network definitions - 

Something a bit more descriptive along the lines of:
 In FreeBSD, sys/types.h and netinet/in.h need to be included before 
netinet/ip.h.
> Failure #13: http://dpdk.org/ml/archives/test-report/2016-March/001896.html
>
> Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample application")
>
> Signed-off-by: Daniel Mrzyglod 
> ---
>   examples/ipsec-secgw/esp.c   | 4 +++-
>   examples/ipsec-secgw/ipsec.c | 2 +-
>   examples/ipsec-secgw/rt.c| 1 +
>   examples/ipsec-secgw/sa.c| 2 ++
>   examples/ipsec-secgw/sp.c| 2 ++
>   5 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
> index ca0fc56..7b0e04c 100644
> --- a/examples/ipsec-secgw/esp.c
> +++ b/examples/ipsec-secgw/esp.c
> @@ -33,8 +33,10 @@
>   
>   #include 
>   #include 
> -#include 
>   #include 
> +#include 

Do we need sys/socket.h?

Sergio

[dpdk-dev] [PATCH] examples/ip_pipeline: fix flow classification pipeline

[Fan Zhang]

Fixes: examples/ip_pipeline: config parser clean-up

This patch fixes the initialization error in flow classification
pipeline. Originally, when there is no key_mask specified in the
CFG file, all '0' mask is utilized.

Signed-off-by: Fan Zhang 
Acked-by: Cristian Dumitrescu 
---
 .../pipeline/pipeline_flow_classification_be.c  | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/examples/ip_pipeline/pipeline/pipeline_flow_classification_be.c 
b/examples/ip_pipeline/pipeline/pipeline_flow_classification_be.c
index 60e9c39..3da46b0 100644
--- a/examples/ip_pipeline/pipeline/pipeline_flow_classification_be.c
+++ b/examples/ip_pipeline/pipeline/pipeline_flow_classification_be.c
@@ -55,6 +55,7 @@ struct pipeline_flow_classification {
uint32_t key_offset;
uint32_t hash_offset;
uint8_t key_mask[PIPELINE_FC_FLOW_KEY_MAX_SIZE];
+   uint32_t key_mask_present;
uint32_t flow_id_offset;

 } __rte_cache_aligned;
@@ -308,7 +309,7 @@ pipeline_fc_parse_args(struct pipeline_flow_classification 
*p,
"\"%s\" is too long", params->name,
arg_name);

-   snprintf(key_mask_str, mask_str_len, "%s",
+   snprintf(key_mask_str, sizeof(key_mask_str), "%s",
arg_value);

continue;
@@ -370,11 +371,21 @@ pipeline_fc_parse_args(struct 
pipeline_flow_classification *p,
uint32_t key_size = p->key_size;
int status;

+   PIPELINE_ARG_CHECK(((key_size == 8) || (key_size == 16)),
+   "Parse error in section \"%s\": entry key_mask "
+   "only allowed for key_size of 8 or 16 bytes",
+   params->name);
+
PIPELINE_ARG_CHECK((strlen(key_mask_str) ==
(key_size * 2)), "Parse error in section "
"\"%s\": key_mask should have exactly %u hex "
"digits", params->name, (key_size * 2));

+   PIPELINE_ARG_CHECK((hash_offset_present == 0), "Parse "
+   "error in section \"%s\": entry hash_offset only "
+   "allowed when key_mask is not present",
+   params->name);
+
status = parse_hex_string(key_mask_str, p->key_mask,
&p->key_size);

@@ -383,6 +394,8 @@ pipeline_fc_parse_args(struct pipeline_flow_classification 
*p,
"key_mask", key_mask_str);
}

+   p->key_mask_present = key_mask_present;
+
return 0;
 }

@@ -486,7 +499,8 @@ static void *pipeline_fc_init(struct pipeline_params 
*params,
.signature_offset = p_fc->hash_offset,
.key_offset = p_fc->key_offset,
.f_hash = hash_func[(p_fc->key_size / 8) - 1],
-   .key_mask = p_fc->key_mask,
+   .key_mask = (p_fc->key_mask_present) ?
+   p_fc->key_mask : NULL,
.seed = 0,
};

@@ -497,7 +511,8 @@ static void *pipeline_fc_init(struct pipeline_params 
*params,
.signature_offset = p_fc->hash_offset,
.key_offset = p_fc->key_offset,
.f_hash = hash_func[(p_fc->key_size / 8) - 1],
-   .key_mask = p_fc->key_mask,
+   .key_mask = (p_fc->key_mask_present) ?
+   p_fc->key_mask : NULL,
.seed = 0,
};

-- 
2.5.0

[dpdk-dev] DPDK: receive single packet at a time

[Mohan Prasad]

Could not get it working by disabling the vector PMD, Do you have any
example where it works?

Thanks,
Mohan

On Wed, Mar 30, 2016 at 11:06 AM, Mohan Prasad 
wrote:

> Hi Bruce,
>
> Could not get it working by disabling the vector PMD, Do you have any
> example where it works?
>
> Thanks,
> Mohan
>
> On Tue, Mar 29, 2016 at 6:46 PM, Bruce Richardson <
> bruce.richardson at intel.com> wrote:
>
>> On Tue, Mar 29, 2016 at 06:31:58PM +0530, Mohan Prasad wrote:
>> > Hi,
>> >
>> > I have tried this and it does not work
>> >
>>
>> What type of NIC are you using. If you are using ixgbe or i40e, try
>> disabling
>> the vector PMD in your build-time configuration to see if it makes a
>> difference.
>>
>> However, why do you want to receive just a single packet at a time. Why
>> not just
>> receive a burst of packets and then process them one at a time? It's much
>> more
>> efficient that way, and you should get better performance from your
>> application.
>>
>> /Bruce
>>
>>
>> > Thanks,
>> > Mohan
>> > On Mar 29, 2016 6:26 PM, "Wiles, Keith"  wrote:
>> >
>> > > >Hi,
>> > > >
>> > > >Is there any option to receive single packet at a time with dpdk?
>> > >
>> > > Not sure if this is the answer you are looking for, but if you just
>> > > request a single packet with
>> > >
>> > > struct rte_mbuf *mbuf;
>> > > rte_eth_rx_burst(port_id, queue_id, &mbuf, 1);
>> > >
>> > > will return only one packet as a time.
>> > > >
>> > > >Thanks,
>> > > >Mohan
>> > > >
>> > >
>> > >
>> > > Regards,
>> > > Keith
>> > >
>> > >
>> > >
>> > >
>> > >
>>
>
>

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

[Zhe Tao]

On Thu, Mar 24, 2016 at 03:00:14PM +, Bruce Richardson wrote:
> On Wed, Mar 23, 2016 at 11:27:50AM +0800, Zhe Tao wrote:
> > Issue:
> > when using the following CLI in testpmd to enable ipv6 TSO feature
> > =
> > set verbose 1
> > csum set ip hw 0
> > csum set udp hw 0
> > csum set tcp hw 0
> > csum set sctp hw 0
> > csum set outer-ip hw 0
> > csum parse_tunnel on 0
> > tso set 800 0
> > set fwd csum
> > 
> > start
> > =
> 
> The "===" lines in the message are confusing patchwork. For a new version of
> this patch can you indent the commands rather than putting the "===" above 
> and 
> below. E.g.
> 
>  Issue:
>  when using the following CLI in testpmd to enable ipv6 TSO feature
> 
>   set verbose 1
>   csum set ip hw 0
>   csum set udp hw 0
>   
> 
> Thanks,
> /Bruce
very good advise, will send the new patch, thanks!
Zhe Tao

[dpdk-dev] [PATCH v3 0/8] L2fwd-crypto fixes/enhancements

[Bruce Richardson]

On Thu, Mar 31, 2016 at 10:32:06AM +0100, Pablo de Lara wrote:
> This patches fixes some small issues in L2fwd-crypto
> app and also improves the app, making it more flexible
> (accepting different key sizes)
> and readable (information display improvement).
> 
> Series-tested-by: Min Cao 
> 

Hi,

Just some general advice:

When someone is acking/resporting a tested-by for a patch series it's ok to 
reply to the patch 0.

However, for subsequent versions of the patchset itself, the acks and tested-bys
should be placed on (all) the patches themselves, not in the cover letter. If
it's in the cover letter, you're forcing the applier of the patch to modify each
one individually to stick on the extra information.

Thanks,
/Bruce

> 
> Changes in v3:
> 
> - Added missing Tested-by line.
> 
> Changes in v2:
> 
> - Extended help information
> 
> Pablo de Lara (8):
>   l2fwd-crypto: add missing new line character in help
>   l2fwd-crypto: rename period parameter
>   l2fwd-crypto: add missing string initialization
>   l2fwd-crypto: fix length of random IV/AAD
>   l2fwd-crypto: fix ambiguous input key size
>   l2fwd-crypto: clarify key parsing in help
>   l2fwd-crypto: use key-value list of supported algorithms
>   l2fwd-crypto: extend crypto information
> 
>  examples/l2fwd-crypto/main.c  | 473 
> --
>  lib/librte_cryptodev/rte_crypto_sym.h |   6 +-
>  2 files changed, 402 insertions(+), 77 deletions(-)
> 
> -- 
> 2.5.5
> 

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

[Zhe Tao]

Issue:

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

We will not get what we want, the ipv6 packets sent out from IXIA can be 
received by i40e, but cannot forward to another port.
The root cause is when HW doing the TSO offload for packets, it does not only
depends on the context descriptor to define the MSS and TSO payload size, it
also need to know whether this packets is ipv4 or ipv6, we use 
i40e_txd_enable_checksum to generate the related fields for data descriptor.
But PMD will not call i40e_txd_enable_checksum if only the TSO offload flag is
set. The reason why ipv4 works fine for TSO in testpmd csum mode is csum engine
will set the ip csum flag when the packet is ipv4 and TSO is enabled but 
will not set the flag for ipv6 and this flag will cause the
i40e_txd_enable_checksum to be invoked. For both the cases the TSO flag will be
set, so we need to use TSO flag to trigger the i40e_txd_enable_checksum.
The right logic here is we enable csum offload for both ipv4 and ipv6 when TSO
flag is set.

Fixes: e3f0151f (i40e: enable Tx checksum only for offloaded packets)
---
 drivers/net/i40e/i40e_rxtx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 81cde6c..6e3fd25 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -76,6 +76,7 @@
 #define I40E_TX_CKSUM_OFFLOAD_MASK (\
PKT_TX_IP_CKSUM |\
PKT_TX_L4_MASK | \
+   PKT_TX_TCP_SEG | \
PKT_TX_OUTER_IP_CKSUM)

 static uint16_t i40e_xmit_pkts_simple(void *tx_queue,
-- 
v2: changed condition check for ipv6 TSO checksum offload
use a more clear check method which include both ipv4 & ipv6 TSO
v3: edited the commit log and title because this problem exists for both
ipv4 and ipv6
2.1.4

[dpdk-dev] [PATCH] i40e: Fix a typo in fdir.

[Thomas Monjalon]

2016-03-27 13:58, Rami Rosen:
> Signed-off-by: Rami Rosen 

Applied, thanks

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

[Bruce Richardson]

On Thu, Mar 31, 2016 at 08:15:58PM +0800, Zhe Tao wrote:
> Issue:
> 
> when using the following CLI in testpmd to enable ipv6 TSO feature
> (set --txqflags=0 in the testpmd command)
>   set verbose 1
>   csum set ip hw 0
>   csum set udp hw 0
>   csum set tcp hw 0
>   csum set sctp hw 0
>   csum set outer-ip hw 0
>   csum parse_tunnel on 0
>   tso set 800 0
>   set fwd csum
>   start
> 
> We will not get what we want, the ipv6 packets sent out from IXIA can be 
> received by i40e, but cannot forward to another port.
> The root cause is when HW doing the TSO offload for packets, it does not only
> depends on the context descriptor to define the MSS and TSO payload size, it
> also need to know whether this packets is ipv4 or ipv6, we use 
> i40e_txd_enable_checksum to generate the related fields for data descriptor.
> But PMD will not call i40e_txd_enable_checksum if only the TSO offload flag is
> set. The reason why ipv4 works fine for TSO in testpmd csum mode is csum 
> engine
> will set the ip csum flag when the packet is ipv4 and TSO is enabled but 
> will not set the flag for ipv6 and this flag will cause the
> i40e_txd_enable_checksum to be invoked. For both the cases the TSO flag will 
> be
> set, so we need to use TSO flag to trigger the i40e_txd_enable_checksum.
> The right logic here is we enable csum offload for both ipv4 and ipv6 when TSO
> flag is set.
>  
> Fixes: e3f0151f (i40e: enable Tx checksum only for offloaded packets)

Missing sign-off in this version.

> ---
>  drivers/net/i40e/i40e_rxtx.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index 81cde6c..6e3fd25 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -76,6 +76,7 @@
>  #define I40E_TX_CKSUM_OFFLOAD_MASK (  \
>   PKT_TX_IP_CKSUM |\
>   PKT_TX_L4_MASK | \
> + PKT_TX_TCP_SEG | \
>   PKT_TX_OUTER_IP_CKSUM)
>  
>  static uint16_t i40e_xmit_pkts_simple(void *tx_queue,
> -- 
> v2: changed condition check for ipv6 TSO checksum offload
> use a more clear check method which include both ipv4 & ipv6 TSO
> v3: edited the commit log and title because this problem exists for both
> ipv4 and ipv6
> 2.1.4
> 

This version history is clearer when placed immediately below the commit 
description.
You also need to use a 3-character cut-line, rather than 2-char, in that case.

/Bruce

[dpdk-dev] [PATCH v3 0/8] L2fwd-crypto fixes/enhancements

[Thomas Monjalon]

2016-03-31 13:14, Bruce Richardson:
> On Thu, Mar 31, 2016 at 10:32:06AM +0100, Pablo de Lara wrote:
> > This patches fixes some small issues in L2fwd-crypto
> > app and also improves the app, making it more flexible
> > (accepting different key sizes)
> > and readable (information display improvement).
> > 
> > Series-tested-by: Min Cao 
> > 
> 
> Hi,
> 
> Just some general advice:
> 
> When someone is acking/resporting a tested-by for a patch series it's ok to 
> reply to the patch 0.
> 
> However, for subsequent versions of the patchset itself, the acks and 
> tested-bys
> should be placed on (all) the patches themselves, not in the cover letter. If
> it's in the cover letter, you're forcing the applier of the patch to modify 
> each
> one individually to stick on the extra information.

Yes
More information about Tested-by:
In general it doesn't apply to each patch. Example, here, I doubt
it has to be added to the patch "add missing new line character in help".

Thanks for adding the tag where relevant (by reading the test report).

[...]
> > Pablo de Lara (8):
> >   l2fwd-crypto: add missing new line character in help
> >   l2fwd-crypto: rename period parameter
> >   l2fwd-crypto: add missing string initialization
> >   l2fwd-crypto: fix length of random IV/AAD
> >   l2fwd-crypto: fix ambiguous input key size
> >   l2fwd-crypto: clarify key parsing in help
> >   l2fwd-crypto: use key-value list of supported algorithms
> >   l2fwd-crypto: extend crypto information

[dpdk-dev] [PATCH v3 0/8] L2fwd-crypto fixes/enhancements

[Declan Doherty]

On 31/03/16 10:32, Pablo de Lara wrote:
> This patches fixes some small issues in L2fwd-crypto
> app and also improves the app, making it more flexible
> (accepting different key sizes)
> and readable (information display improvement).
>
> Series-tested-by: Min Cao 
>
>
> Changes in v3:
>
> - Added missing Tested-by line.
>
> Changes in v2:
>
> - Extended help information
>
> Pablo de Lara (8):
>l2fwd-crypto: add missing new line character in help
>l2fwd-crypto: rename period parameter
>l2fwd-crypto: add missing string initialization
>l2fwd-crypto: fix length of random IV/AAD
>l2fwd-crypto: fix ambiguous input key size
>l2fwd-crypto: clarify key parsing in help
>l2fwd-crypto: use key-value list of supported algorithms
>l2fwd-crypto: extend crypto information
>
>   examples/l2fwd-crypto/main.c  | 473 
> --
>   lib/librte_cryptodev/rte_crypto_sym.h |   6 +-
>   2 files changed, 402 insertions(+), 77 deletions(-)
>

Series-Acked-by: Declan Doherty 

[dpdk-dev] [PATCH v13 6/8] ethdev: redesign link speed config

[Thomas Monjalon]

2016-03-31 00:57, Xing, Beilei:
> I?ve verified v13 + the modification, and it works.

Please, what have you tested? Which drivers? Which configurations?

It is important to test several uses of rte_eth_conf.link_speeds:
- ETH_LINK_SPEED_AUTONEG (all speeds)
- ETH_LINK_SPEED_FIXED (only one speed)
- a subset of speeds to advertise and negotiate

[dpdk-dev] DPDK: receive single packet at a time

[Wiles, Keith]

From:  Mohan Prasad 
Date:  Thursday, March 31, 2016 at 6:42 AM
To:  Bruce Richardson 
Cc:  Keith Wiles , "dev at dpdk.org" 
Subject:  Re: [dpdk-dev] DPDK: receive single packet at a time


>Could not get it working by disabling the vector PMD, Do you have any example 
>where it works?
>
>
>

I would expect the examples like l2fwd or l2fwd work in this way if the PMD is 
not enabled. The pktgen-dpdk I know will work with a single packet send and 
received. The code is on the dpdk.org/download directory.

>
>Thanks,
>Mohan
>
>
>On Wed, Mar 30, 2016 at 11:06 AM, Mohan Prasad 
> wrote:
>
>Hi Bruce,
>
>Could not get it working by disabling the vector PMD, Do you have any example 
>where it works?
>
>Thanks,
>Mohan
>
>
>On Tue, Mar 29, 2016 at 6:46 PM, Bruce Richardson 
> wrote:
>
>On Tue, Mar 29, 2016 at 06:31:58PM +0530, Mohan Prasad wrote:
>> Hi,
>>
>> I have tried this and it does not work
>>
>
>What type of NIC are you using. If you are using ixgbe or i40e, try disabling
>the vector PMD in your build-time configuration to see if it makes a 
>difference.
>
>However, why do you want to receive just a single packet at a time. Why not 
>just
>receive a burst of packets and then process them one at a time? It's much more
>efficient that way, and you should get better performance from your 
>application.
>
>/Bruce
>
>
>> Thanks,
>> Mohan
>> On Mar 29, 2016 6:26 PM, "Wiles, Keith"  wrote:
>>
>> > >Hi,
>> > >
>> > >Is there any option to receive single packet at a time with dpdk?
>> >
>> > Not sure if this is the answer you are looking for, but if you just
>> > request a single packet with
>> >
>> > struct rte_mbuf *mbuf;
>> > rte_eth_rx_burst(port_id, queue_id, &mbuf, 1);
>> >
>> > will return only one packet as a time.
>> > >
>> > >Thanks,
>> > >Mohan
>> > >
>> >
>> >
>> > Regards,
>> > Keith
>> >
>> >
>> >
>> >
>> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>


Regards,
Keith

[dpdk-dev] [PATCH v2] examples/ipsec-secgw: fix missed headers for FreeBSD

[Daniel Mrzyglod]

In FreeBSD, sys/types.h and netinet/in.h need to be included before
netinet/ip.h

There were misssed typedef for u_char - 
There were missed network definitions - 

Failure #13: http://dpdk.org/ml/archives/test-report/2016-March/001896.html

Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample application")

Signed-off-by: Daniel Mrzyglod 
---
 examples/ipsec-secgw/esp.c | 3 ++-
 examples/ipsec-secgw/ipsec-secgw.c | 2 ++
 examples/ipsec-secgw/ipsec.c   | 2 +-
 examples/ipsec-secgw/ipsec.h   | 2 --
 examples/ipsec-secgw/rt.c  | 1 +
 examples/ipsec-secgw/sa.c  | 2 ++
 examples/ipsec-secgw/sp.c  | 2 ++
 7 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
index ca0fc56..1927380 100644
--- a/examples/ipsec-secgw/esp.c
+++ b/examples/ipsec-secgw/esp.c
@@ -33,9 +33,10 @@

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

diff --git a/examples/ipsec-secgw/ipsec-secgw.c 
b/examples/ipsec-secgw/ipsec-secgw.c
index d6c9a5d..1d6c81b 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -36,6 +36,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index d385100..baf30d4 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -30,7 +30,7 @@
  *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
-
+#include 
 #include 
 #include 

diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index 8eb4e76..a13fdef 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -35,8 +35,6 @@
 #define __IPSEC_H__

 #include 
-#include 
-#include 

 #include 
 #include 
diff --git a/examples/ipsec-secgw/rt.c b/examples/ipsec-secgw/rt.c
index c3bb4de..a6d0866 100644
--- a/examples/ipsec-secgw/rt.c
+++ b/examples/ipsec-secgw/rt.c
@@ -34,6 +34,7 @@
 /*
  * Routing Table (RT)
  */
+#include 
 #include 
 #include 

diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 91a5f6e..a5b8a63 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -34,6 +34,8 @@
 /*
  * Security Associations
  */
+#include 
+#include 
 #include 

 #include 
diff --git a/examples/ipsec-secgw/sp.c b/examples/ipsec-secgw/sp.c
index 7972f40..4f16730 100644
--- a/examples/ipsec-secgw/sp.c
+++ b/examples/ipsec-secgw/sp.c
@@ -34,6 +34,8 @@
 /*
  * Security Policies
  */
+#include 
+#include 
 #include 

 #include 
-- 
2.5.5

[dpdk-dev] DPDK: receive single packet at a time

[Wiles, Keith]

>
>From:  Mohan Prasad 
>Date:  Thursday, March 31, 2016 at 6:42 AM
>To:  Bruce Richardson 
>Cc:  Keith Wiles , "dev at dpdk.org" dpdk.org>
>Subject:  Re: [dpdk-dev] DPDK: receive single packet at a time
>
>
>>Could not get it working by disabling the vector PMD, Do you have any example 
>>where it works?
>>
>>
>>
>
>I would expect the examples like l2fwd or l2fwd work in this way if the PMD is 
>not enabled. The pktgen-dpdk I know will work with a single packet send and 
>received. The code is on the dpdk.org/download directory.

Another possible debug is to run one of the l2fwd, l3fwd or pktgen and verify 
they work or not.
>
>>
>>Thanks,
>>Mohan
>>
>>
>>On Wed, Mar 30, 2016 at 11:06 AM, Mohan Prasad 
>> wrote:
>>
>>Hi Bruce,
>>
>>Could not get it working by disabling the vector PMD, Do you have any example 
>>where it works?
>>
>>Thanks,
>>Mohan
>>
>>
>>On Tue, Mar 29, 2016 at 6:46 PM, Bruce Richardson 
>> wrote:
>>
>>On Tue, Mar 29, 2016 at 06:31:58PM +0530, Mohan Prasad wrote:
>>> Hi,
>>>
>>> I have tried this and it does not work
>>>
>>
>>What type of NIC are you using. If you are using ixgbe or i40e, try disabling
>>the vector PMD in your build-time configuration to see if it makes a 
>>difference.
>>
>>However, why do you want to receive just a single packet at a time. Why not 
>>just
>>receive a burst of packets and then process them one at a time? It's much more
>>efficient that way, and you should get better performance from your 
>>application.
>>
>>/Bruce
>>
>>
>>> Thanks,
>>> Mohan
>>> On Mar 29, 2016 6:26 PM, "Wiles, Keith"  wrote:
>>>
>>> > >Hi,
>>> > >
>>> > >Is there any option to receive single packet at a time with dpdk?
>>> >
>>> > Not sure if this is the answer you are looking for, but if you just
>>> > request a single packet with
>>> >
>>> > struct rte_mbuf *mbuf;
>>> > rte_eth_rx_burst(port_id, queue_id, &mbuf, 1);
>>> >
>>> > will return only one packet as a time.
>>> > >
>>> > >Thanks,
>>> > >Mohan
>>> > >
>>> >
>>> >
>>> > Regards,
>>> > Keith
>>> >
>>> >
>>> >
>>> >
>>> >
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>Regards,
>Keith
>
>
>


Regards,
Keith

[dpdk-dev] [PATCH] i40e: fix crash when dcb query

[Thomas Monjalon]

2016-03-28 15:37, Jingjing Wu:
> Calling rte_eth_dev_get_dcb_info to get dcb info from i40e
> driver if VMDQ is disabled, results in a segmentation fault.
> This patch fixes it by treating VMDQ and No-VMDQ respectively
> when querying dcb information.
> 
> Fixes: 5135f3ca49a7 ("i40e: enable DCB in VMDQ VSIs")
> 
> Signed-off-by: Jingjing Wu 

Applied, thanks

[dpdk-dev] [PATCH] doc: fill nics features matrix for mlx4 & mlx5

[Tan, Jianfeng]

Hi,

On 3/31/2016 7:00 PM, Adrien Mazarguil wrote:
> On Thu, Mar 31, 2016 at 06:55:41PM +0800, Tan, Jianfeng wrote:
>> Hi,
>>
>> On 3/31/2016 6:22 PM, Adrien Mazarguil wrote:
>>> Signed-off-by: Adrien Mazarguil 
>>> ---
>>>   doc/guides/nics/overview.rst | 56 
>>> ++--
>>>   1 file changed, 28 insertions(+), 28 deletions(-)
>>>
>>> diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
>>> index 542479a..5238088 100644
>>> --- a/doc/guides/nics/overview.rst
>>> +++ b/doc/guides/nics/overview.rst
>>> @@ -86,63 +86,63 @@ Most of these differences are summarized below.
>>> e   e   e   e   e   
>>>   e
>>> c   c   c   c   c   
>>>   c
>>>   = = = = = = = = = = = = = = = = = = = = = = = = = 
>>> = = = = = = = =
>>> -   link status  X   X X
>>>X X
>>> -   link status eventX X
>>>  X
>>> +   link status  X   X X X X
>>>X X
>>> +   link status eventX X X X
>>>  X
>>>  queue status event 
>>>   X
>>>  Rx interrupt X X X X
>>> -   queue start/stop X   X   X X X X
>>>X
>>> -   MTU update   X   X
>>> -   jumbo frame  X   X   X X X X
>>> -   scattered Rx X   X   X X X X
>>>X
>>> +   queue start/stop X   X   X X X X X X
>>>X
>>> +   MTU update   X   X   X X
>>> +   jumbo frame  X   X   X X X X X X
>>> +   scattered Rx X   X   X X X X X X
>>>X
>>>  LRO
>>>  TSO  X   X   X X X X
>>> -   promiscuous mode X   X X X X
>>>X
>>> -   allmulticast modeX   X X X X
>>>X
>>> +   promiscuous mode X   X X X X X X
>>>X
>>> +   allmulticast modeX   X X X X X X
>>>X
>>>  unicast MAC filter   X X X X
>>>  multicast MAC filter X X X X
>>> -   RSS hash X   X   X X X X
>>> -   RSS key update   X   X X X X
>>> -   RSS reta update  X   X X X X
>>> +   RSS hash X   X   X X X X X X
>>> +   RSS key update   X   X X X X   X
>>> +   RSS reta update  X   X X X X   X
>>>  VMDq X X
>>> -   SR-IOV   X   X X
>>> +   SR-IOV   X   X X X X
>>>  DCB  X X
>>> -   VLAN filter  X X X X
>>> +   VLAN filter  X X X X X X
>>>  ethertype filter X X
>>>  n-tuple filter
>>>  SYN filter
>>>  tunnel filterX X
>>>  flexible filter
>>>  hash filter  X X X X
>>> -   flow directorX X
>>> +   flow directorX X   X
>>>  flow control X   X X
>>>  rate limitation
>>>  traffic mirroringX X
>>> -   CRC offload  X   X   X   X
>>> -   VLAN offload X   X   X   X
>>> +   CRC offload  X   X   X   X X
>>> +   VLAN offload X   X   X   X X
>>>  QinQ offload X   X
>>> -   L3 checksum offload  X   X   X   X
>>> -   L4 checksum offload  X   X   X   X
>>> -   inner L3 checksumX   X   X
>>> -   inner L4 checksumX   X   X
>>> -   packet type parsing  X   X   X
>>> +   L3 checksum offload  X   X   X   X   X X
>>> +   L4 checksum offload  X   X   X   X   X X
>>> +   inner L3 checksumX   X   X   X
>>> +   inner L4 checksumX   X   X   X
>>> +   packet type parsing  X   X   X   X X
>>>  timesync X X
>>> -   basic stats  X   X   X X X X
>>>X X
>>> +   basic stats  X   X   X X X X X X
>>>X X
>>>  extended stats   X   X X X X
>>> -   stats per que

[dpdk-dev] [PATCH] mlx: fix double mbuf free in TX queue clean up function

[Thomas Monjalon]

2016-03-31 11:43, Adrien Mazarguil:
> Once freed, completed mbufs pointers are not set to NULL in the TX queue.
> Clean up function must take this into account.
> 
> Fixes: 2e22920b85d9 ("mlx5: support non-scattered Tx and Rx")
> Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")
> 
> Signed-off-by: Adrien Mazarguil 

Applied, thanks

[dpdk-dev] [PATCH] doc: fill nics features matrix for mlx4 & mlx5

[Thomas Monjalon]

2016-03-31 20:50, Tan, Jianfeng:
> Thanks for explanation. I was wrongly treating "X" as "not supported" 
> previously. I was looking at "TSO", and it indicates by the table that 
> ixgbe does not support TSO, which does not make sense to me. Or this doc 
> is not updated efficiently?

According to the table, ixgbe supports nothing.
Does it mean this driver is useless? If so we could remove it ;)
Or you can talk to the maintainers of the driver to ask an update.
Thanks for pointing it

[dpdk-dev] [PATCH v2] mlx5: fix RETA table size

[Thomas Monjalon]

2016-03-31 11:36, Adrien Mazarguil:
> On Thu, Mar 31, 2016 at 12:21:08PM +0300, Yaacov Hazan wrote:
> > When the number of RX queues is not a power of two,
> > the RETA table is configured to its maximum size for
> > better balancing.
> > 
> > Testing showed that limiting its size to 256 improves performance
> > noticeably with little to no  impact on balancing results.
> > 
> > Fixes: ebb30ec64a68 ("mlx5: increase RETA table size")
> > 
> > Signed-off-by: Yaacov Hazan 
> 
> Acked-by: Adrien Mazarguil 

Applied, thanks

[dpdk-dev] [PATCH v2] examples/ipsec-secgw: fix missed headers for FreeBSD

[Sergio Gonzalez Monroy]

On 31/03/2016 13:43, Daniel Mrzyglod wrote:
> In FreeBSD, sys/types.h and netinet/in.h need to be included before
> netinet/ip.h
>
> There were misssed typedef for u_char - 
> There were missed network definitions - 
>
> Failure #13: http://dpdk.org/ml/archives/test-report/2016-March/001896.html
>
> Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample application")
>
> Signed-off-by: Daniel Mrzyglod 
> ---
>

Other than typo in commit message: "misssed"

Acked-by: Sergio Gonzalez Monroy 

[dpdk-dev] [PATCH] l3fwd: fix incorrect size for destination port values

[Konstantin Ananyev]

Fixes: dc81ebbacaeb ("lpm: extend IPv4 next hop field")

Originally l3fwd used 16-bit value to store dest_port value.
To accommodate 24-bit nexthop dest_port was increased to 32-bit,
though some further packet processing code remained unchanged and
still expects dest_port to be 16-bit.
That is not correct and can cause l3fwd invalid behaviour or even
process crash/hang on some input packet patterns.
For the fix, I choose the simplest approach and restored dest_port
as 16-bit value, plus necessary conversions from 32 to 16 bit values
after lpm_lookupx4.

Signed-off-by: Konstantin Ananyev 
---
 examples/l3fwd/l3fwd_em_hlm_sse.h |  6 +++---
 examples/l3fwd/l3fwd_em_sse.h |  2 +-
 examples/l3fwd/l3fwd_lpm.h|  4 ++--
 examples/l3fwd/l3fwd_lpm_sse.h| 12 
 examples/l3fwd/l3fwd_sse.h|  8 
 5 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/examples/l3fwd/l3fwd_em_hlm_sse.h 
b/examples/l3fwd/l3fwd_em_hlm_sse.h
index ee0211f..5001c72 100644
--- a/examples/l3fwd/l3fwd_em_hlm_sse.h
+++ b/examples/l3fwd/l3fwd_em_hlm_sse.h
@@ -38,7 +38,7 @@

 static inline __attribute__((always_inline)) void
 em_get_dst_port_ipv4x8(struct lcore_conf *qconf, struct rte_mbuf *m[8],
-   uint8_t portid, uint32_t dst_port[8])
+   uint8_t portid, uint16_t dst_port[8])
 {
int32_t ret[8];
union ipv4_5tuple_host key[8];
@@ -162,7 +162,7 @@ get_ipv6_5tuple(struct rte_mbuf *m0, __m128i mask0,

 static inline __attribute__((always_inline)) void
 em_get_dst_port_ipv6x8(struct lcore_conf *qconf, struct rte_mbuf *m[8],
-   uint8_t portid, uint32_t dst_port[8])
+   uint8_t portid, uint16_t dst_port[8])
 {
int32_t ret[8];
union ipv6_5tuple_host key[8];
@@ -289,7 +289,7 @@ l3fwd_em_send_packets(int nb_rx, struct rte_mbuf 
**pkts_burst,
uint8_t portid, struct lcore_conf *qconf)
 {
int32_t j;
-   uint32_t dst_port[MAX_PKT_BURST];
+   uint16_t dst_port[MAX_PKT_BURST];

/*
 * Send nb_rx - nb_rx%8 packets
diff --git a/examples/l3fwd/l3fwd_em_sse.h b/examples/l3fwd/l3fwd_em_sse.h
index e2fe932..c0a9725 100644
--- a/examples/l3fwd/l3fwd_em_sse.h
+++ b/examples/l3fwd/l3fwd_em_sse.h
@@ -102,7 +102,7 @@ l3fwd_em_send_packets(int nb_rx, struct rte_mbuf 
**pkts_burst,
uint8_t portid, struct lcore_conf *qconf)
 {
int32_t j;
-   uint32_t dst_port[MAX_PKT_BURST];
+   uint16_t dst_port[MAX_PKT_BURST];

for (j = 0; j < nb_rx; j++)
dst_port[j] = em_get_dst_port(qconf, pkts_burst[j], portid);
diff --git a/examples/l3fwd/l3fwd_lpm.h b/examples/l3fwd/l3fwd_lpm.h
index fc10235..a43c507 100644
--- a/examples/l3fwd/l3fwd_lpm.h
+++ b/examples/l3fwd/l3fwd_lpm.h
@@ -34,14 +34,14 @@
 #ifndef __L3FWD_LPM_H__
 #define __L3FWD_LPM_H__

-static inline uint32_t
+static inline uint8_t
 lpm_get_ipv4_dst_port(void *ipv4_hdr,  uint8_t portid, void *lookup_struct)
 {
uint32_t next_hop;
struct rte_lpm *ipv4_l3fwd_lookup_struct =
(struct rte_lpm *)lookup_struct;

-   return (uint32_t) ((rte_lpm_lookup(ipv4_l3fwd_lookup_struct,
+   return (uint8_t) ((rte_lpm_lookup(ipv4_l3fwd_lookup_struct,
rte_be_to_cpu_32(((struct ipv4_hdr *)ipv4_hdr)->dst_addr),
&next_hop) == 0) ? next_hop : portid);
 }
diff --git a/examples/l3fwd/l3fwd_lpm_sse.h b/examples/l3fwd/l3fwd_lpm_sse.h
index d64d6d2..538fe3d 100644
--- a/examples/l3fwd/l3fwd_lpm_sse.h
+++ b/examples/l3fwd/l3fwd_lpm_sse.h
@@ -145,9 +145,9 @@ static inline void
 processx4_step2(const struct lcore_conf *qconf,
__m128i dip,
uint32_t ipv4_flag,
-   uint32_t portid,
+   uint8_t portid,
struct rte_mbuf *pkt[FWDSTEP],
-   uint32_t dprt[FWDSTEP])
+   uint16_t dprt[FWDSTEP])
 {
rte_xmm_t dst;
const  __m128i bswap_mask = _mm_set_epi8(12, 13, 14, 15, 8, 9, 10, 11,
@@ -158,7 +158,11 @@ processx4_step2(const struct lcore_conf *qconf,

/* if all 4 packets are IPV4. */
if (likely(ipv4_flag)) {
-   rte_lpm_lookupx4(qconf->ipv4_lookup_struct, dip, dprt, portid);
+   rte_lpm_lookupx4(qconf->ipv4_lookup_struct, dip, dst.u32,
+   portid);
+   /* get rid of unused upper 16 bit for each dport. */
+   dst.x = _mm_packs_epi32(dst.x, dst.x);
+   *(uint64_t *)dprt = dst.u64[0];
} else {
dst.x = dip;
dprt[0] = lpm_get_dst_port_with_ipv4(qconf, pkt[0], dst.u32[0], 
portid);
@@ -177,7 +181,7 @@ l3fwd_lpm_send_packets(int nb_rx, struct rte_mbuf 
**pkts_burst,
uint8_t portid, struct lcore_conf *qconf)
 {
int32_t j;
-   uint32_t dst_port[MAX_PKT_BURST];
+   uint16_t dst_port[MAX_PKT_BURST];
__m128i dip[MAX_PKT_BURST / FWDSTEP];
uint32_t ipv4_flag[MAX_PKT_BURST / FWDS

[dpdk-dev] [PATCH 4/4] port: fix ethdev writer burst too big

[Dumitrescu, Cristian]

> -Original Message-
> From: Robert Sanford [mailto:rsanford2 at gmail.com]
> Sent: Monday, March 28, 2016 9:52 PM
> To: dev at dpdk.org; Dumitrescu, Cristian 
> Subject: [PATCH 4/4] port: fix ethdev writer burst too big
> 
> For f_tx_bulk functions in rte_port_ethdev.c, we may unintentionally
> send bursts larger than tx_burst_sz to the underlying ethdev.
> Some PMDs (e.g., ixgbe) may truncate this request to their maximum
> burst size, resulting in unnecessary enqueuing failures or ethdev
> writer retries.

Sending bursts larger than tx_burst_sz is actually intentional. The assumption 
is that NIC performance benefits from larger burst size. So the tx_burst_sz is 
used as a minimal burst size requirement, not as a maximal or fixed burst size 
requirement.

I agree with you that a while ago the vector version of IXGBE driver used to 
work the way you describe it, but I don't think this is the case anymore. As an 
example, if TX burst size is set to 32 and 48 packets are transmitted, than the 
PMD will TX all the 48 packets (internally it can work in batches of 4, 8, 32, 
etc, should not matter) rather than TXing just 32 packets out of 48 and user 
having to either discard or retry with the remaining 16 packets. I am CC-ing 
Steve Liang for confirming this.

Is there any PMD that people can name that currently behaves the opposite, i.e. 
given a burst of 48 pkts for TX, accept 32 pkts and discard the other 16?

> 
> We propose to fix this by moving the tx buffer flushing logic from
> *after* the loop that puts all packets into the tx buffer, to *inside*
> the loop, testing for a full burst when adding each packet.
> 

The issue I have with this approach is the introduction of a branch that has to 
be tested for each iteration of the loop rather than once for the entire loop.

The code branch where you add this is actually the slow(er) code path (where 
local variable expr != 0), which is used for non-contiguous or bursts smaller 
than tx_burst_sz. Is there a particular reason you are only interested of 
enabling this strategy (of using tx_burst_sz as a fixed burst size requirement) 
only on this code path? The reason I am asking is the other fast(er) code path 
(where expr == 0) also uses tx_burst_sz as a minimal requirement and therefore 
it can send burst sizes bigger than tx_burst_sz.


> Signed-off-by: Robert Sanford 
> ---
>  lib/librte_port/rte_port_ethdev.c |   20 ++--
>  1 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/lib/librte_port/rte_port_ethdev.c
> b/lib/librte_port/rte_port_ethdev.c
> index 3fb4947..1283338 100644
> --- a/lib/librte_port/rte_port_ethdev.c
> +++ b/lib/librte_port/rte_port_ethdev.c
> @@ -151,7 +151,7 @@ static int rte_port_ethdev_reader_stats_read(void
> *port,
>  struct rte_port_ethdev_writer {
>   struct rte_port_out_stats stats;
> 
> - struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX];
> + struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX];
>   uint32_t tx_burst_sz;
>   uint16_t tx_buf_count;
>   uint64_t bsz_mask;
> @@ -257,11 +257,11 @@ rte_port_ethdev_writer_tx_bulk(void *port,
>   p->tx_buf[tx_buf_count++] = pkt;
> 
>   RTE_PORT_ETHDEV_WRITER_STATS_PKTS_IN_ADD(p, 1);
>   pkts_mask &= ~pkt_mask;
> - }
> 
> - p->tx_buf_count = tx_buf_count;
> - if (tx_buf_count >= p->tx_burst_sz)
> - send_burst(p);
> + p->tx_buf_count = tx_buf_count;
> + if (tx_buf_count >= p->tx_burst_sz)
> + send_burst(p);
> + }
>   }

One observation here: if we enable this proposal (which I have an issue with 
due to the executing the branch per loop iteration rather than once per entire 
loop), it also eliminates the buffer overflow issue flagged by you in the other 
email :), so no need to e.g. doble the size of the port internal buffer 
(tx_buf).

> 
>   return 0;
> @@ -328,7 +328,7 @@ static int rte_port_ethdev_writer_stats_read(void
> *port,
>  struct rte_port_ethdev_writer_nodrop {
>   struct rte_port_out_stats stats;
> 
> - struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX];
> + struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX];
>   uint32_t tx_burst_sz;
>   uint16_t tx_buf_count;
>   uint64_t bsz_mask;
> @@ -466,11 +466,11 @@ rte_port_ethdev_writer_nodrop_tx_bulk(void
> *port,
>   p->tx_buf[tx_buf_count++] = pkt;
> 
>   RTE_PORT_ETHDEV_WRITER_NODROP_STATS_PKTS_IN_ADD(p, 1);
>   pkts_mask &= ~pkt_mask;
> - }
> 
> - p->tx_buf_count = tx_buf_count;
> - if (tx_buf_count >= p->tx_burst_sz)
> - send_burst_nodrop(p);
> + p->tx_buf_count = tx_buf_count;
> + if (tx_buf_count >= p->tx_burst_sz)
> + send_burst_nodrop(p);
> + }
>   }

[dpdk-dev] [PATCH] doc: announce ABI change for rte_port_source_params structure

[Fan Zhang]

Several new fields will be added to structure rte_port_source_params for
source port enhancement with pcap file reading support.

Signed-off-by: Fan Zhang 
Acked-by: Cristian Dumitrescu 

---
 doc/guides/rel_notes/deprecation.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 179e30f..9b4fc9d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -25,3 +25,8 @@ Deprecation Notices
 * ABI changes are planned for adding four new flow types. This impacts
   RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
   but release 2.3 will. [postponed]
+
+* ABI changes are planned for struct rte_port_source_params in order to
+  support PCAP file reading feature. The release 16.04 contains this ABI
+  change wrapped by RTE_NEXT_ABI macro. Release 16.07 will contain this
+  change, and no backwards compatibility is planned.
-- 
2.5.0

[dpdk-dev] [PATCH] doc: announce ABI change for rte_port_source_params structure

[Fan Zhang]

Several new fields will be added to structure rte_port_source_params for
source port enhancement with pcap file reading support.

Signed-off-by: Fan Zhang 
Acked-by: Cristian Dumitrescu 

---
 doc/guides/rel_notes/deprecation.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 179e30f..9b4fc9d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -25,3 +25,8 @@ Deprecation Notices
 * ABI changes are planned for adding four new flow types. This impacts
   RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
   but release 2.3 will. [postponed]
+
+* ABI changes are planned for struct rte_port_source_params in order to
+  support PCAP file reading feature. The release 16.04 contains this ABI
+  change wrapped by RTE_NEXT_ABI macro. Release 16.07 will contain this
+  change, and no backwards compatibility is planned.
-- 
2.5.0

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

[Thomas Monjalon]

2016-03-29 08:16, Alejandro Lucero:
> Hi guys,
> 
> Sorry for the delay but I was on a Easter break.
> 
> That patch is OK for me. In fact, I had one patch ready for upstreaming
> with this change needed for supporting hotplug. I was waiting for some
> feedback from one internal project needing this hotplug functionality
> before submitting.
[...]
> > On Wed, Mar 23, 2016 at 08:51:36AM -0700, Stephen Hemminger wrote:
> > > The NFP driver (unlike other PCI devices) was not copying the pci info
> > > from the pci_dev to the eth_dev.  This would make the driver_name be
> > > null (and other unset fields) when application uses dev_info_get.
> > >
> > > This was found by code review; do not have the hardware.
> > >
> > > Signed-off-by: Stephen Hemminger 

Applied, thanks

[dpdk-dev] [PATCH] examples/l3fwd: fix some packets lost when stops receiving

[Tomasz Kulasek]

Not all tx ports was included in tx_port_id array, used to periodically
drain only available ports. This caused that some packets remain in buffer
when application stops to receiving packets.

Fixes: 52c97adc1f0f ("examples/l3fwd: fix exact match performance")

Signed-off-by: Tomasz Kulasek 
---
 examples/l3fwd/main.c |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index e10dab9..92fda3b 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -836,7 +836,6 @@ main(int argc, char **argv)
unsigned lcore_id;
uint32_t n_tx_queue, nb_lcores;
uint8_t portid, nb_rx_queue, queue, socketid;
-   uint8_t nb_tx_port;

/* init EAL */
ret = rte_eal_init(argc, argv);
@@ -876,7 +875,6 @@ main(int argc, char **argv)
rte_exit(EXIT_FAILURE, "check_port_config failed\n");

nb_lcores = rte_lcore_count();
-   nb_tx_port = 0;

/* Setup function pointers for lookup method. */
setup_l3fwd_lookup_tables();
@@ -954,12 +952,10 @@ main(int argc, char **argv)
qconf->tx_queue_id[portid] = queueid;
queueid++;

-   qconf->n_tx_port = nb_tx_port;
qconf->tx_port_id[qconf->n_tx_port] = portid;
+   qconf->n_tx_port++;
}
printf("\n");
-
-   nb_tx_port++;
}

for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
-- 
1.7.9.5

[dpdk-dev] [PATCH] bonding: fix bond link detect in non-interrupt mode

[Thomas Monjalon]

2016-03-25 17:44, John Daley:
> From: Nelson Escobar 
> 
> Stopping then re-starting a bond interface containing slaves that
> used polling for link detection caused the bond to think all slave
> links were down and inactive.
> 
> Move the start of the polling for link from slave_add() to
> bond_ethdev_start() and in bond_ethdev_stop() make sure we clear
> the last_link_status of the slaves.
> 
> Signed-off-by: Nelson Escobar 
> Signed-off-by: John Daley 

A "Fixes:" line would be appreciated to know the origin of the bug.
Thanks

[dpdk-dev] [PATCH] vmxnet3: fix txq flags check

[Thomas Monjalon]

2016-03-28 15:35, Yong Wang:
> Now that vmxnet3 supports TCP/UDP checksum offload, let's update
> the default txq flags to allow such offloads.  Also fixed the tx
> queue setup check to allow TCP/UDP checksum and only error out
> if SCTP checksum is requested.
> 
> Fixes: f598fd063bb1 ("vmxnet3: add Tx L4 checksum offload")
> 
> Reported-by: Heng Ding 
> Signed-off-by: Yong Wang 

Applied, thanks

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

[Thomas Monjalon]

2016-03-23 14:07, Xie, Huawei:
> On 3/18/2016 8:24 PM, Ilya Maximets wrote:
> > Since commit 4c02e453cc62 ("eal: introduce SMP memory barriers") virtio
> > uses architecture dependent SMP barriers. vHost should use them too.
> >
> > Fixes: 4c02e453cc62 ("eal: introduce SMP memory barriers")
> >
> > Signed-off-by: Ilya Maximets 
> 
> Acked-by: Huawei Xie 
> 
> It fixes the issue for other archs. Will recheck in future.

Applied, thanks

[dpdk-dev] [PATCH] examples/l3fwd: fix some packets lost when stops receiving

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz Kulasek
> Sent: Thursday, March 31, 2016 2:38 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] examples/l3fwd: fix some packets lost when stops 
> receiving
> 
> Not all tx ports was included in tx_port_id array, used to periodically
> drain only available ports. This caused that some packets remain in buffer
> when application stops to receiving packets.
> 
> Fixes: 52c97adc1f0f ("examples/l3fwd: fix exact match performance")
> 
> Signed-off-by: Tomasz Kulasek 
> ---
>  examples/l3fwd/main.c |6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
> index e10dab9..92fda3b 100644
> --- a/examples/l3fwd/main.c
> +++ b/examples/l3fwd/main.c
> @@ -836,7 +836,6 @@ main(int argc, char **argv)
>   unsigned lcore_id;
>   uint32_t n_tx_queue, nb_lcores;
>   uint8_t portid, nb_rx_queue, queue, socketid;
> - uint8_t nb_tx_port;
> 
>   /* init EAL */
>   ret = rte_eal_init(argc, argv);
> @@ -876,7 +875,6 @@ main(int argc, char **argv)
>   rte_exit(EXIT_FAILURE, "check_port_config failed\n");
> 
>   nb_lcores = rte_lcore_count();
> - nb_tx_port = 0;
> 
>   /* Setup function pointers for lookup method. */
>   setup_l3fwd_lookup_tables();
> @@ -954,12 +952,10 @@ main(int argc, char **argv)
>   qconf->tx_queue_id[portid] = queueid;
>   queueid++;
> 
> - qconf->n_tx_port = nb_tx_port;
>   qconf->tx_port_id[qconf->n_tx_port] = portid;
> + qconf->n_tx_port++;
>   }
>   printf("\n");
> -
> - nb_tx_port++;
>   }
> 
>   for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
> --

Acked-by: Konstantin Ananyev 

> 1.7.9.5

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

[Thomas Monjalon]

Please, anyone to confirm that the patch is valid and must be applied?
This discussion shows some doubts.


2016-03-24 13:35, Michael Frasca:
> Jing,
> 
> Thanks for your assistance. The experiment that you have built should allow 
> you
> to observe the bug. In [5], I would expect that queue 0 receives roughly 1/4 
> of
> the packets that you sending, assuming the input packets have varied IP
> addresses. Can you measure what % of packets are actually being received in 
> this
> single queue setup (after first running a 4-queue setup)?
> 
> When trying to running with only one RX queue, the fm10k retains the same RSS
> hash function and redirection table that was configured from a previous run. 
> As
> a result, some packets are still being directed to other receive queues. I 
> have
> confirmed this by polling the queue specific stats, which I retrieved via
> rte_eth_xstats_get().
> 
> Looking at fm10k_dev_rss_configure(), one should see that there is no
> modification of fm10k registers when nb_rx_queues == 1. As far as I can tell,
> this is the reason that only a certain partition of packets are being receive 
> in
> a single queue setup (after first running a multi-queue configuration).
> 
> I am unable to access my development environment today, but if you need, I can
> later craft a patch to l3fwd that shows the measurement of packets received at
> each queue.
> 
> Thanks,
> Mike
> 
> 
> > On Mar 24, 2016, at 2:40 AM, Chen, Jing D  wrote:
> > 
> > Hi, Frasca,
> > 
> > 
> > 
> >> -Original Message-
> >> From: Michael Frasca [mailto:michael.frasca at oracle.com 
> >> ]
> >> Sent: Wednesday, March 23, 2016 9:43 PM
> >> To: Chen, Jing D
> >> Cc: dev at dpdk.org 
> >> Subject: Re: [PATCH] fm10k: conditionally disable RSS during device
> >> initialization
> >> 
> >> Hi Jing,
> >> 
> >> I ran into this issue while trying to run experiments with different RSS
> >> configurations (no RSS being one cases). It is not clear to me that 
> >> setting this
> >> register to zero is the best way to disable RSS.
> >> 
> >> After digging further, I have a theory that I'm having this issues because 
> >> I've
> >> only attached my DPDK application to SR-IOV ports. In
> >> fm10k_dev_dglort_map_configure(), I see that 'RSS Length' is set for the
> >> DGLORT
> >> decoder. However, it appears that this is only invoked for physical 
> >> functions.
> >> 
> >> Could this be my problem? Is it required that I bind to the physical 
> >> function
> >> if I want to properly manipulate RSS?
> >> 
> >> Thanks,
> >> Mike
> >> 
> > I don't know exactly what problem you ran into. I think we needn't worry 
> > about 
> > those DGLORT setting when using VF device.
> > 
> > I've followed steps to use SRIOV device with RSS enabled and disabled, both
> > are worked well from my side after applying your patch. Below is my setup.
> > 
> > 1. PF with Linux driver "fm10k-next_0.19.3".
> > 2. DPDK with latest code from master branch, apply your patch.
> > 3. Use 1 VF device created by kernel driver.
> > 4. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 
> > --config="(0,0,2),(0,1,2),(0,2,3),(0,3,3)""
> >with RSS enabled. After sending packets, I can see all 4 queues received 
> > packets.
> > 5. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 
> > --config="(0,0,2)""
> >with RSS disabled. After sending packets, I can see queue 0 received 
> > packets.
> > 
> > Can you explain what actual problem is?
> > We can talk offline.
> 

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

[Chen, Jing D]

Thomas,

We've agreed offline that the patch works without side effect.
Please kindly apply if possible.

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, March 31, 2016 9:57 PM
> To: dev at dpdk.org
> Cc: Michael Frasca ; Chen, Jing D
> 
> Subject: Re: [dpdk-dev] [PATCH] fm10k: conditionally disable RSS during
> device initialization
> 
> Please, anyone to confirm that the patch is valid and must be applied?
> This discussion shows some doubts.
> 
> 
> 2016-03-24 13:35, Michael Frasca:
> > Jing,
> >
> > Thanks for your assistance. The experiment that you have built should
> > allow you to observe the bug. In [5], I would expect that queue 0
> > receives roughly 1/4 of the packets that you sending, assuming the
> > input packets have varied IP addresses. Can you measure what % of
> > packets are actually being received in this single queue setup (after first
> running a 4-queue setup)?
> >
> > When trying to running with only one RX queue, the fm10k retains the
> > same RSS hash function and redirection table that was configured from
> > a previous run. As a result, some packets are still being directed to
> > other receive queues. I have confirmed this by polling the queue
> > specific stats, which I retrieved via rte_eth_xstats_get().
> >
> > Looking at fm10k_dev_rss_configure(), one should see that there is no
> > modification of fm10k registers when nb_rx_queues == 1. As far as I
> > can tell, this is the reason that only a certain partition of packets
> > are being receive in a single queue setup (after first running a multi-queue
> configuration).
> >
> > I am unable to access my development environment today, but if you
> > need, I can later craft a patch to l3fwd that shows the measurement of
> > packets received at each queue.
> >
> > Thanks,
> > Mike
> >
> >
> > > On Mar 24, 2016, at 2:40 AM, Chen, Jing D  
> > > wrote:
> > >
> > > Hi, Frasca,
> > >
> > >
> > >
> > >> -Original Message-
> > >> From: Michael Frasca [mailto:michael.frasca at oracle.com
> > >> ]
> > >> Sent: Wednesday, March 23, 2016 9:43 PM
> > >> To: Chen, Jing D
> > >> Cc: dev at dpdk.org 
> > >> Subject: Re: [PATCH] fm10k: conditionally disable RSS during device
> > >> initialization
> > >>
> > >> Hi Jing,
> > >>
> > >> I ran into this issue while trying to run experiments with
> > >> different RSS configurations (no RSS being one cases). It is not
> > >> clear to me that setting this register to zero is the best way to disable
> RSS.
> > >>
> > >> After digging further, I have a theory that I'm having this issues
> > >> because I've only attached my DPDK application to SR-IOV ports. In
> > >> fm10k_dev_dglort_map_configure(), I see that 'RSS Length' is set
> > >> for the DGLORT decoder. However, it appears that this is only
> > >> invoked for physical functions.
> > >>
> > >> Could this be my problem? Is it required that I bind to the
> > >> physical function if I want to properly manipulate RSS?
> > >>
> > >> Thanks,
> > >> Mike
> > >>
> > > I don't know exactly what problem you ran into. I think we needn't
> > > worry about those DGLORT setting when using VF device.
> > >
> > > I've followed steps to use SRIOV device with RSS enabled and
> > > disabled, both are worked well from my side after applying your patch.
> Below is my setup.
> > >
> > > 1. PF with Linux driver "fm10k-next_0.19.3".
> > > 2. DPDK with latest code from master branch, apply your patch.
> > > 3. Use 1 VF device created by kernel driver.
> > > 4. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 --
> config="(0,0,2),(0,1,2),(0,2,3),(0,3,3)""
> > >with RSS enabled. After sending packets, I can see all 4 queues 
> > > received
> packets.
> > > 5. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 --
> config="(0,0,2)""
> > >with RSS disabled. After sending packets, I can see queue 0 received
> packets.
> > >
> > > Can you explain what actual problem is?
> > > We can talk offline.
> >
> 

[dpdk-dev] [PATCH v2 0/7] Various fixes to compile with gcc6

[Thomas Monjalon]

2016-03-22 17:37, Aaron Conole:
> This series brings a number of code cleanups to allow building using gcc6,
> with various legitimate warnings being fixed.
> 
> Some of these fixes are to the drivers area, making this series a bit
> atypical. However, the fixes identified in patches 2 and 3 are actual
> bugs and should be fixed.
> 
> The first patch from the original series has been dropped. It is no
> longer needed, after commit 5ecdeba601d1 ("lpm: merge tbl24 and tbl8
> structures").
> 
> 
> Aaron Conole (7):
>   app/test/test: Fix missing brackets
>   drivers/net/e1000: Fix missing brackets
>   drivers/net/e1000: Fix missing lsc interrupt check brackets
>   drivers/net/ixgbe: Fix vlan filter missing brackets
>   drivers/net/e1000/igb: Signed left shift operator
>   drivers/net/ixgbe: Signed left shift operator
>   drivers/net/ixgbe: Fix uninitialized warning

Applied with v3 of patch 2, thanks

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

[Thomas Monjalon]

> > If the provided configuration does not call for RSS, then RSS is
> > explicitly disabled. Without this change, the device continues to
> > operate under the previous RSS configuration.
> > 
> > Fixes: 57033cdf8fdc ("fm10k: add PF RSS")
> > 
> > Signed-off-by: Michael Frasca 
> Acked-by : Jing Chen 

Applied, thanks

[dpdk-dev] Must kni be associated with a dpdk port?

[ALeX Wang]

Thx a lot, for the answer,!

Exactly what I'm looking for,~

On 31 March 2016 at 02:55, Ferruh Yigit  wrote:

> On 3/30/2016 6:20 PM, ALeX Wang wrote:
> > Hi,
> >
> > I want to use 'rte_kni_alloc()' to create a kernel iface and
> > use it to test application rx.  From the api and example in
> > 'examples/kni/main.c', i saw the 'conf' argument is assigned
> > with pci info of a dpdk port.
> >
> > Want to ask if this is compulsory...  Must kni always be
> > used together with a dpdk port?
> >
> > Thanks,
> >
>
> Hi Alex,
>
> You don't have to associate kni with dpdk port.
>
> pci info is required for ethtool support, if you are only interested in
> data transfer, you don't have to provide pci information.
>
> Regards,
> ferruh
>



-- 
Alex Wang,
Open vSwitch developer

[dpdk-dev] [PATCH 3/4] port: fix full burst checks in f_tx_bulk ops

[Dumitrescu, Cristian]

> -Original Message-
> From: Robert Sanford [mailto:rsanford2 at gmail.com]
> Sent: Monday, March 28, 2016 9:52 PM
> To: dev at dpdk.org; Dumitrescu, Cristian 
> Subject: [PATCH 3/4] port: fix full burst checks in f_tx_bulk ops
> 
> For several f_tx_bulk functions in rte_port_{ethdev,ring,sched}.c,
> it appears that the intent of the bsz_mask logic is to test whether
> pkts_mask contains a full burst (i.e., the  least
> significant bits are set).
> 
> There are two problems with the bsz_mask code: 1) It truncates
> by using the wrong size for local variable uint32_t bsz_mask, and

This is indeed a bug: although port->bsz_mask is always defined as uint64_t, 
there are several places where we cache it to a local variable which is defined 
as 32-bit by mistake: uint32_t bsz = p->bsz_mask. Thanks, Robert!

> 2) We may pass oversized bursts to the underlying ethdev/ring/sched,
> e.g., tx_burst_sz=16, bsz_mask=0x8000, and pkts_mask=0x1
> (17 packets), results in expr==0, and we send a burst larger than
> desired (and non-power-of-2) to the underlying tx burst interface.
> 

As stated in another related email, this is done by design, with the key 
assumption being that larger TX burst sizes will always be beneficial. So 
tx_burst_size is, by design, a requirement for the *minimal* value of the TX 
burst size rather than the *exact* value for the burst size.
As an example, when the TX burst size of 32 is set, then larger burst sizes of 
33, 34, ..., 40, 41, ..., 48, ..., 64 are welcomed and sent out as a single 
burst rather than breaking in into multiple fixed size 32-packet bursts. 
For PMDs, burst size (smaller than 64) is typically much lower than the TX ring 
size (typical value for IXGBE: 512). Same for rte_ring.

So what we are debating here is which of the following two approaches is better:
Approach 1: Consider tx_burst_sz as the minimal burst size, welcome larger 
bursts and send them as a single burst (i.e. do not break them into fixed 
tx_burst_sz bursts). This is the existing approach used consistently everywhere 
in librte_port.
Approach 2: Consider tx_burst_sz as an exact burst size requirement, any larger 
incoming burst is broken into fixed size bursts of exactly tx_burst_sz packets 
before send. This is the approach suggested by Robert.

I think we should go for the approach that gives the best performance. 
Personally, I think Approach 1 (existing) is doing this, but I would like to 
get more fact-based opinions from the people on this mail list (CC-ing a few 
key folks), especially PMD and ring maintainers. What is your experience, guys?

> We propose to effectively set bsz_mask = (1 << tx_burst_sz) - 1
> (while avoiding truncation for tx_burst_sz=64), to cache the mask
> value of a full burst, and then do a simple compare with pkts_mask
> in each f_tx_bulk.
> 
> Signed-off-by: Robert Sanford 
> ---
>  lib/librte_port/rte_port_ethdev.c |   15 ---
>  lib/librte_port/rte_port_ring.c   |   16 
>  lib/librte_port/rte_port_sched.c  |7 ++-
>  3 files changed, 10 insertions(+), 28 deletions(-)
> 
> diff --git a/lib/librte_port/rte_port_ethdev.c
> b/lib/librte_port/rte_port_ethdev.c
> index 1c34602..3fb4947 100644
> --- a/lib/librte_port/rte_port_ethdev.c
> +++ b/lib/librte_port/rte_port_ethdev.c
> @@ -188,7 +188,7 @@ rte_port_ethdev_writer_create(void *params, int
> socket_id)
>   port->queue_id = conf->queue_id;
>   port->tx_burst_sz = conf->tx_burst_sz;
>   port->tx_buf_count = 0;
> - port->bsz_mask = 1LLU << (conf->tx_burst_sz - 1);
> + port->bsz_mask = UINT64_MAX >> (64 - conf->tx_burst_sz);

Another way to write this is: port->bsz_mask = RTE_LEN2MASK(conf->tx_burst_sz, 
uint64_t);

> 
>   return port;
>  }
> @@ -229,12 +229,9 @@ rte_port_ethdev_writer_tx_bulk(void *port,
>  {
>   struct rte_port_ethdev_writer *p =
>   (struct rte_port_ethdev_writer *) port;
> - uint32_t bsz_mask = p->bsz_mask;
>   uint32_t tx_buf_count = p->tx_buf_count;
> - uint64_t expr = (pkts_mask & (pkts_mask + 1)) |
> - ((pkts_mask & bsz_mask) ^ bsz_mask);
> 
> - if (expr == 0) {
> + if (pkts_mask == p->bsz_mask) {
>   uint64_t n_pkts = __builtin_popcountll(pkts_mask);
>   uint32_t n_pkts_ok;
> 
> @@ -369,7 +366,7 @@ rte_port_ethdev_writer_nodrop_create(void
> *params, int socket_id)
>   port->queue_id = conf->queue_id;
>   port->tx_burst_sz = conf->tx_burst_sz;
>   port->tx_buf_count = 0;
> - port->bsz_mask = 1LLU << (conf->tx_burst_sz - 1);
> + port->bsz_mask = UINT64_MAX >> (64 - conf->tx_burst_sz);
> 
>   /*
>* When n_retries is 0 it means that we should wait for every packet
> to
> @@ -435,13 +432,9 @@ rte_port_ethdev_writer_nodrop_tx_bulk(void
> *port,
>  {
>   struct rte_port_ethdev_writer_nodrop *p =
>   (struct rte_port_ethdev_writer_nodrop *) port;
> -
> - uint32_t bsz_mask = p->bsz_mask;
>   uint32_t tx_buf

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

[Adrien Mazarguil]

On Sat, Mar 26, 2016 at 09:11:38AM +0100, Thomas Monjalon wrote:
> > v13:
> > - Fix startup regression; revert flip of ETH_LINK_SPEED_FIXED and
> >   ETH_LINK_SPEED_AUTONEG values. ETH_LINK_SPEED_AUTONEG is now 0.
> 
> As commented earlier, I would prefer avoiding this revert.
> Comments are welcome.

I've tested v13 using testpmd and ixgbe. Performed the following checks:

- Port start/stop - OK, link speed is displayed correctly.
- Forcing 1G / duplex auto - OK.
- Forcing 10G / duplex auto - OK.
- Forcing 10G / duplex half - half is not allowed (expected).
- Forcing 40G / duplex auto - unsupported, causes port start to fail
  (expected). 
- Forcing 1G / duplex full - OK.
- Forcing 100 / duplex half - unsupported, causes port start to fail
  (expected). 
- Forcing 100 / duplex full - OK.
- Traffic flows whenever link speed is supported/negotiated.

Tested-by: Adrien Mazarguil 

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH] bonding: fix bond link detect in non-interrupt mode

[Nelson Escobar]

Thomas,

Sorry, I should have included the following fixes line:

Fixes: a45b288ef21a("bond: support link status polling")

Please add it to the commit message when applying if there are no other
problems with the patch.

Nelson.
On 3/31/2016 6:40 AM, Thomas Monjalon wrote:
> 2016-03-25 17:44, John Daley:
>> From: Nelson Escobar 
>>
>> Stopping then re-starting a bond interface containing slaves that
>> used polling for link detection caused the bond to think all slave
>> links were down and inactive.
>>
>> Move the start of the polling for link from slave_add() to
>> bond_ethdev_start() and in bond_ethdev_stop() make sure we clear
>> the last_link_status of the slaves.
>>
>> Signed-off-by: Nelson Escobar 
>> Signed-off-by: John Daley 
> 
> A "Fixes:" line would be appreciated to know the origin of the bug.
> Thanks
> 

[dpdk-dev] [PATCH] vmxnet3: remove asserts that confuse coverity

[Yong Wang]

On 3/30/16, 2:38 PM, "Stephen Hemminger"  wrote:



>These asserts are only for debugging and never fired during
>any testing, but they confuse coverity's null tracking.
>
>Signed-off-by: Stephen Hemminger 
>---

Acked-by: Yong Wang 


> drivers/net/vmxnet3/vmxnet3_rxtx.c | 2 --
> 1 file changed, 2 deletions(-)
>
>diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c 
>b/drivers/net/vmxnet3/vmxnet3_rxtx.c
>index 66b0eed..f72156a 100644
>--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
>+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
>@@ -710,7 +710,6 @@ vmxnet3_recv_pkts(void *rx_queue, struct rte_mbuf 
>**rx_pkts, uint16_t nb_pkts)
>* the last mbuf of the current packet.
>*/
>   if (rcd->sop) {
>-  VMXNET3_ASSERT(rxq->start_seg != NULL);
>   VMXNET3_ASSERT(rxd->btype == VMXNET3_RXD_BTYPE_HEAD);
> 
>   if (unlikely(rcd->len == 0)) {
>@@ -729,7 +728,6 @@ vmxnet3_recv_pkts(void *rx_queue, struct rte_mbuf 
>**rx_pkts, uint16_t nb_pkts)
>   struct rte_mbuf *start = rxq->start_seg;
> 
>   VMXNET3_ASSERT(rxd->btype == VMXNET3_RXD_BTYPE_BODY);
>-  VMXNET3_ASSERT(start != NULL);
> 
>   start->pkt_len += rxm->data_len;
>   start->nb_segs++;
>-- 
>2.1.4
>

[dpdk-dev] [PATCH] vmxnet3: remove asserts that confuse coverity

[Thomas Monjalon]

> >These asserts are only for debugging and never fired during
> >any testing, but they confuse coverity's null tracking.
> >
> >Signed-off-by: Stephen Hemminger 
> 
> Acked-by: Yong Wang 

Applied, thanks

[dpdk-dev] [PATCH 0/2] Compile fixes in SUSE11 SP3 i686 platform

[Thomas Monjalon]

2016-03-25 15:20, Michael Qiu:
> In SUSE11 SP3 i686 platform with gcc version 4.5.1, there is
> some compile issues. This patch set is try to fix them.
> 
> Michael Qiu (2):
>   lib/librte_lpm: Fix anonymous union initialization issue
>   drivers/crypto: Fix anonymous union initialization in crypto

v2 of each patch applied, thanks

[dpdk-dev] [PATCH v4 05/10] qede: Add core driver

[Harish Patil]

>

>On Wed, 30 Mar 2016 22:16:51 +
>Harish Patil  wrote:
>
>> >
>> >On Tue, 29 Mar 2016 22:28:20 -0700
>> >Rasesh Mody  wrote:
>> >
>> >> +
>> >> +static void qede_print_adapter_info(struct qede_dev *qdev)
>> >> +{
>> >> + struct ecore_dev *edev = &qdev->edev;
>> >> + struct qed_dev_info *info = &qdev->dev_info.common;
>> >> + char ver_str[QED_DRV_VER_STR_SIZE] = { 0 };
>> >> +
>> >> + RTE_LOG(INFO, PMD,
>> >> +   " Chip details : %s%d\n",
>> >> +   ECORE_IS_BB(edev) ? "BB" : "AH",
>> >> +   CHIP_REV_IS_A0(edev) ? 0 : 1);
>> >> +
>> >> + sprintf(ver_str, "%s %s_%d.%d.%d.%d", QEDE_PMD_VER_PREFIX,
>> >> + edev->ver_str, QEDE_PMD_VERSION_MAJOR, QEDE_PMD_VERSION_MINOR,
>> >> + QEDE_PMD_VERSION_REVISION, QEDE_PMD_VERSION_PATCH);
>> >> + strcpy(qdev->drv_ver, ver_str);
>> >> + RTE_LOG(INFO, PMD, " Driver version : %s\n", ver_str);
>> >> +
>> >> + ver_str[0] = '\0';
>> >> + sprintf(ver_str, "%d.%d.%d.%d", info->fw_major, info->fw_minor,
>> >> + info->fw_rev, info->fw_eng);
>> >> + RTE_LOG(INFO, PMD, " Firmware version : %s\n", ver_str);
>> >> +
>> >> + ver_str[0] = '\0';
>> >> + sprintf(ver_str, "%d.%d.%d.%d",
>> >> + (info->mfw_rev >> 24) & 0xff,
>> >> + (info->mfw_rev >> 16) & 0xff,
>> >> + (info->mfw_rev >> 8) & 0xff, (info->mfw_rev) & 0xff);
>> >> + RTE_LOG(INFO, PMD, " Management firmware version : %s\n", ver_str);
>> >> +
>> >> + RTE_LOG(INFO, PMD, " Firmware file : %s\n", QEDE_FW_FILE_NAME);
>> >
>> >This means the driver is far too chatty in the logs.
>> >Can't this be made DEBUG level?
>> >
>> Not clear what is the issue here?
>> RTE_LOG is used here to display basic adapter info like firmware/driver
>> versions etc without the need to enable any debug flags.
>> The driver debug logging is under the control of appropriate debug
>>flags.
>> 
>
>The DPDK log messages end up being examined by tech support and customers.
>Too much code puts extra stuff in so it is hard to find the real problem.
>This is obviously debug info, so either:
>  1) make it conditionally compiled
>  2) change log level to DEBUG
>  3) remove it.
>

This is not really a debug msg per se. We want it to be printed on the
stdout unconditionally (displayed only once) so that we can readily know
what firmware/driver/hw versions we are dealing with. We don?t want to
depend on the apps to print those and many of the apps may not do so
including testpmd. Even the linux drivers prints basic stuff  under dmesg.
We have found this to be useful for triage and would like to retain it if
there is no objection.

[dpdk-dev] [PATCH v2 0/2] Out of place operations for symmetric crypto

[Thomas Monjalon]

2016-03-30 16:52, John Griffin:
> On 29/03/16 15:14, Fiona Trahe wrote:
> > From: Arek Kusztal 
> >
> > This patch adds out of place operations for qat symmetric crypto PMD,
> > i.e. the result of the operation can be written to the destination buffer
> > instead of overwriting the source buffer as done in "in-place" operation.
> >
> > v2:
> >   - updated commit message to clarify out-of-place meaning
> >
> >
> > Arek Kusztal (2):
> >driver/crypto: out-of-place symmetric operations
> >app/test: added test for out-of-place symmetric operations
> 
> Acked-by: John Griffin 

Applied, thanks

[dpdk-dev] [PATCH] qat: Fix for crash when nb_ops=0 on enqueue_burst

[Thomas Monjalon]

2016-03-29 18:10, Fiona Trahe:
> Crash seen in qat pmd when nb_ops=0 on rte_cryptodev_enqueue_burst() API
> 
> Signed-off-by: Fiona Trahe 

Applied, thanks

[dpdk-dev] [PATCH] dpdk_qat: fix error message in Makefile

[Thomas Monjalon]

2016-03-29 19:28, Pablo de Lara:
> When compiling dpdk_qat app with an i686 target on a x86_64 OS,
> an error message was shown, saying that it can only be built
> on a 32-bit OS, which should be i686 OS, as other 32-bit OS
> are not supported.
> 
> Fixes: commit 3460012bcce6 ("examples/qat: update")
> 
> Signed-off-by: Pablo de Lara 

Applied, thanks

[dpdk-dev] [PATCH] virtio: use zeroed memory for simple TX header

[Rich Lane]

For simple TX the virtio-net header must be zeroed, but it was using memory
that had been initialized with indirect descriptor tables. This resulted in
"unsupported gso type" errors from librte_vhost.

We can use the same memory for every descriptor to save cachelines in the
vswitch.

Signed-off-by: Rich Lane 
---
 drivers/net/virtio/virtio_rxtx.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 2b88efd..1df2df6 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -376,8 +376,7 @@ virtio_dev_vring_start(struct virtqueue *vq, int queue_type)
vq->vq_ring.avail->ring[i] = i + mid_idx;
vq->vq_ring.desc[i + mid_idx].next = i;
vq->vq_ring.desc[i + mid_idx].addr =
-   vq->virtio_net_hdr_mem +
-   i * vq->hw->vtnet_hdr_size;
+   vq->virtio_net_hdr_mem;
vq->vq_ring.desc[i + mid_idx].len =
vq->hw->vtnet_hdr_size;
vq->vq_ring.desc[i + mid_idx].flags =
-- 
1.9.1

[dpdk-dev] [PATCH v3 0/8] L2fwd-crypto fixes/enhancements

[Thomas Monjalon]

> > Pablo de Lara (8):
> >l2fwd-crypto: add missing new line character in help
> >l2fwd-crypto: rename period parameter
> >l2fwd-crypto: add missing string initialization
> >l2fwd-crypto: fix length of random IV/AAD
> >l2fwd-crypto: fix ambiguous input key size
> >l2fwd-crypto: clarify key parsing in help
> >l2fwd-crypto: use key-value list of supported algorithms
> >l2fwd-crypto: extend crypto information
> 
> Series-Acked-by: Declan Doherty 

Applied, thanks

[dpdk-dev] [PATCH v2] examples/ipsec-secgw: fix missed headers for FreeBSD

[Thomas Monjalon]

2016-03-31 14:02, Sergio Gonzalez Monroy:
> On 31/03/2016 13:43, Daniel Mrzyglod wrote:
> > In FreeBSD, sys/types.h and netinet/in.h need to be included before
> > netinet/ip.h
> >
> > There were misssed typedef for u_char - 
> > There were missed network definitions - 
> >
> > Failure #13: http://dpdk.org/ml/archives/test-report/2016-March/001896.html
> >
> > Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample application")
> >
> > Signed-off-by: Daniel Mrzyglod 
> 
> Other than typo in commit message: "misssed"
> 
> Acked-by: Sergio Gonzalez Monroy 

Applied, thanks

[dpdk-dev] [PATCH] examples/l3fwd: fix some packets lost when stops receiving

[Thomas Monjalon]

> > Not all tx ports was included in tx_port_id array, used to periodically
> > drain only available ports. This caused that some packets remain in buffer
> > when application stops to receiving packets.
> > 
> > Fixes: 52c97adc1f0f ("examples/l3fwd: fix exact match performance")
> > 
> > Signed-off-by: Tomasz Kulasek 
> 
> Acked-by: Konstantin Ananyev 

Applied, thanks

[dpdk-dev] [PATCH] l3fwd: fix incorrect size for destination port values

[Thomas Monjalon]

2016-03-31 14:07, Konstantin Ananyev:
> Fixes: dc81ebbacaeb ("lpm: extend IPv4 next hop field")
> 
> Originally l3fwd used 16-bit value to store dest_port value.
> To accommodate 24-bit nexthop dest_port was increased to 32-bit,
> though some further packet processing code remained unchanged and
> still expects dest_port to be 16-bit.
> That is not correct and can cause l3fwd invalid behaviour or even
> process crash/hang on some input packet patterns.
> For the fix, I choose the simplest approach and restored dest_port
> as 16-bit value, plus necessary conversions from 32 to 16 bit values
> after lpm_lookupx4.
> 
> Signed-off-by: Konstantin Ananyev 

Applied, thanks

[dpdk-dev] [PATCH] examples/ip_pipeline: fix SSE4.2 optimization branch

[Thomas Monjalon]

2016-03-30 20:06, Thomas Monjalon:
> The branch was disabled because of a typo in the SSE4.2 flag.
> Change also the x86_64 flag to use a DPDK one.
> 
> Fixes: 28377375c6c0 ("examples/ip_pipeline: fix build for x86_64 without 
> SSE4.2")
> 
> Signed-off-by: Thomas Monjalon 
> Acked-by: Cristian Dumitrescu 

Applied

[dpdk-dev] [PATCH] examples/ip_pipeline: fix flow classification pipeline

[Thomas Monjalon]

2016-03-31 12:29, Fan Zhang:
> Fixes: examples/ip_pipeline: config parser clean-up

Fixes: 1a33c5ea2f45 ("examples/ip_pipeline: clean config parser")

> This patch fixes the initialization error in flow classification
> pipeline. Originally, when there is no key_mask specified in the
> CFG file, all '0' mask is utilized.
> 
> Signed-off-by: Fan Zhang 
> Acked-by: Cristian Dumitrescu 

Applied, thanks