[dpdk-dev] [PATCH v2] examples: fix ip_pipeline to load PMD driver correctly

[Thomas Monjalon]

> > From: Gowrishankar Muthukrishnan 
> > 
> > v2: minor correction in patch to avoid space between -d option and driver
> > path
> 
> Acked-by: Cristian Dumitrescu 

Applied, thanks

[dpdk-dev] [PATCH 2/2] ip_pipeline: enable swap action in network layers configuration file

[Thomas Monjalon]

2016-08-26 22:21, Jasvinder Singh:
> The network_layers configuration file (config/network_layers.cfg)
> demonstrates the various network layer components such as TCP, UDP,
> ICMP etc, which can be easily integrated into ip pipeline
> infrastructure.
> 
> The loopback function (implemented using passthrough pipeline) is
> updated to perform swap operation on the IP source and destination
> address, and UDP source and destination ports.
> 
> Signed-off-by: Jasvinder Singh 
> Acked-by: Cristian Dumitrescu 

Series applied, thanks

[dpdk-dev] [PATCH v2 03/12] virtio: reinitialize the device in configure callback

[Yuanhan Liu]

On Mon, Oct 03, 2016 at 11:00:14AM +0200, Olivier Matz wrote:
> @@ -1344,6 +1347,7 @@ virtio_dev_configure(struct rte_eth_dev *dev)
>  {
>   const struct rte_eth_rxmode *rxmode = >data->dev_conf.rxmode;
>   struct virtio_hw *hw = dev->data->dev_private;
> + uint64_t req_features;
>   int ret;
>  
>   PMD_INIT_LOG(DEBUG, "configure");
> @@ -1353,6 +1357,14 @@ virtio_dev_configure(struct rte_eth_dev *dev)
>   return -EINVAL;
>   }
>  
> + req_features = VIRTIO_PMD_GUEST_FEATURES;
> + /* if request features changed, reinit the device */
> + if (req_features != hw->req_guest_features) {
> + ret = virtio_init_device(dev, req_features);
> + if (ret < 0)
> + return ret;
> + }

Why do you have to reset virtio here? This doesn't make too much sense
to me.

IIUC, you want to make sure those TSO related features being unset at
init time, and enable it (by doing reset) when it's asked to be enabled
(by rte_eth_dev_configure)?

Why not always setting those features? We could do the actual offloads
when:

- those features have been negoiated

- they are enabled through rte_eth_dev_configure

With that, I think we could avoid the reset here?

--yliu

[dpdk-dev] [PATCH v2 1/3] lib/librte_port: enable file descriptor port support

[Thomas Monjalon]

2016-09-04 15:38, Jasvinder Singh:
> +#define RTE_PORT_FD_READER_STATS_PKTS_IN_ADD(port, val) \
> +   do { port->stats.n_pkts_in += val } while (0)
> +#define RTE_PORT_FD_READER_STATS_PKTS_DROP_ADD(port, val) \
> +   do { port->stats.n_pkts_drop += val } while (0)
> +

It does not compile because of missing ;

> + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.

The years seem outdated.

This patchset was probably not tested as it does not compile.
And it could be useless if a TAP PMD is integrated.
I suggest to wait 17.02 cycle and see.

[dpdk-dev] [PATCH 2/2] examples/ip_pipeline: modify source port default parameter

[Thomas Monjalon]

> > The default value of ``file_name`` parameter of the source port structure is
> > changed from ``NULL`` to ``./config/packets.pcap``.
> > 
> > Signed-off-by: Jasvinder Singh 
> 
> Acked-by: Cristian Dumitrescu 

Series applied, thanks

[dpdk-dev] [PATCH 0/3] changes for enabling cuckoo hash into table library

[Thomas Monjalon]

> > From: Guruprasad Rao 
> 
> Acked-by: Cristian Dumitrescu 

Applied, thanks

[dpdk-dev] [PATCH v4] log: respect rte_openlog_stream calls before rte_eal_init

[Thomas Monjalon]

2016-10-12 12:38, John Ousterhout:
> @@ -127,6 +125,19 @@ rte_vlog(uint32_t level, uint32_t logtype, const char 
> *format, va_list ap)
>  {
>   int ret;
>   FILE *f = rte_logs.file;
> + if (f == NULL) {
> + f = default_log_stream;
> + if (f == NULL) {
> + /*
> +  * Grab the current value of stderr here, rather than
> +  * just initializing default_log_stream to stderr. This
> +  * ensures that we will always use the current value
> +  * of stderr, even if the application closes and
> +  * reopens it.
> +  */
> + f = stderr;
> + }
> + }

I don't understand this big comment.
What is the difference with initializing default_log_stream to stderr?
What do you mean by "if the application closes and reopens it"?

[dpdk-dev] [PATCH v2 09/12] virtio: add Rx checksum offload support

[Yuanhan Liu]

On Wed, Oct 05, 2016 at 03:27:47PM +0200, Maxime Coquelin wrote:
> >/* Update offload features */
> >-   if (virtio_rx_offload(rxm, hdr) < 0) {
> >+   if ((features & VIRTIO_NET_F_GUEST_CSUM) &&
> s/VIRTIO_NET_F_GUEST_CSUM/(1u << VIRTIO_NET_F_GUEST_CSUM)/

There is a helper function for that: vtpci_with_feature.

--yliu

[dpdk-dev] [PATCH v2 1/3] lib/librte_port: enable file descriptor port support

[Dumitrescu, Cristian]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, October 12, 2016 9:33 PM
> To: Singh, Jasvinder 
> Cc: dev at dpdk.org; Dumitrescu, Cristian 
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] lib/librte_port: enable file descriptor
> port support
> 
> 2016-09-04 15:38, Jasvinder Singh:
> > +#define RTE_PORT_FD_READER_STATS_PKTS_IN_ADD(port, val) \
> > +   do { port->stats.n_pkts_in += val } while (0)
> > +#define RTE_PORT_FD_READER_STATS_PKTS_DROP_ADD(port, val) \
> > +   do { port->stats.n_pkts_drop += val } while (0)
> > +
> 
> It does not compile because of missing ;
> 
> > + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> 
> The years seem outdated.

Will fix immediately.

> 
> This patchset was probably not tested as it does not compile.
> And it could be useless if a TAP PMD is integrated.
> I suggest to wait 17.02 cycle and see.

This patch was tested by me and Jasvinder as well and it works brilliantly.

We did not enable stats when testing, will sort out the missing semicolon issue 
in the stats macros and resend v3 asap. This is a trivial issue, no need to 
wait for 17.02.

This is not conflicting with TAP PMD, and as said the scope of this supersedes 
the TAP PMD.

[dpdk-dev] [PATCH v5] drivers/net:new PMD using tun/tap host interface

[Wiles, Keith]

Regards,
Keith

> On Oct 12, 2016, at 1:19 PM, Wiles, Keith  wrote:
> 
> 
> Regards,
> Keith
> 
>> On Oct 12, 2016, at 9:56 AM, Yigit, Ferruh  wrote:
>> 
>>> +
>>> +static void
>>> +tap_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *tap_stats)
>>> +{
>>> +   unsigned i, imax;
>> 
>> checkpatch complain about not using "unsigned int?
> 
> I ran checkpatch on the patch and saw no errors reported via the 
> scripts/checkpatch.sh. Which checkpatch are you using here?

OK, the scripts/checkpatch.sh does not seem to report any failures, but running 
checkpatch.pl does report problems. Is the scripts/checkpatch.sh script suppose 
to display the errors or what?

It seems odd for the script file not to display warnings and errors, unless it 
is just for validating patch. I would expect the script show the problems 
normally or at least with an option.

[dpdk-dev] [PATCH] ethdev: Support VFs on the different PCI domains

[Kamil Rytarowski]

W dniu 11.10.2016 o 18:52, David Marchand pisze:
> On Tue, Oct 11, 2016 at 3:49 PM, Kamil Rytarowski
>  wrote:
>> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
>> index 382c959..01d5fb0 100644
>> --- a/lib/librte_ether/rte_ethdev.c
>> +++ b/lib/librte_ether/rte_ethdev.c
>> @@ -225,7 +225,7 @@ rte_eth_dev_create_unique_device_name(char *name, size_t 
>> size,
>>   {
>>  int ret;
>>
>> -   ret = snprintf(name, size, "%d:%d.%d",
>> +   ret = snprintf(name, size, "%d:%d:%d.%d", pci_dev->addr.domain,
>>  pci_dev->addr.bus, pci_dev->addr.devid,
>>  pci_dev->addr.function);
>>  if (ret < 0)
> This patch is obsolete since this part has been moved to eal.
>
> Can you test with current master branch if there is still an issue ?
> Thanks.
>
>

I've tested DPDK master without this PCI domain patch and everything 
seems to work.

Thank you.

[dpdk-dev] [PATCH v9 2/2] app/test_pmd: add tests for new API's

[Bernard Iremonger]

add test for set vf vlan anti spoof
add test for set vf mac anti spoof
add test for set vf vlan stripq
add test for set vf vlan insert
add test for set tx loopback
add test for set all queues drop enable bit
add test for set vf split drop enable bit
add test for set vf mac address
add new API's to testpmd help command.

add new API's to the testpmd guide

modify Makefile, add library rte_pmd_ixgbe to _LDLIBS-y.

Signed-off-by: Bernard Iremonger 
---
 app/test-pmd/Makefile   |   2 +
 app/test-pmd/cmdline.c  | 699 +++-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  62 ++-
 3 files changed, 759 insertions(+), 4 deletions(-)

diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
index 2a0b5a5..891b85a 100644
--- a/app/test-pmd/Makefile
+++ b/app/test-pmd/Makefile
@@ -58,6 +58,8 @@ SRCS-y += csumonly.c
 SRCS-y += icmpecho.c
 SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c

+_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
+
 CFLAGS_cmdline.o := -D_GNU_SOURCE

 # this application needs libraries first
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index a1da8b8..41c7acf 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -87,7 +87,9 @@
 #ifdef RTE_LIBRTE_PMD_BOND
 #include 
 #endif
-
+#ifdef RTE_LIBRTE_IXGBE_PMD
+#include 
+#endif
 #include "testpmd.h"

 static struct cmdline *testpmd_cl;
@@ -260,12 +262,37 @@ static void cmd_help_long_parsed(void *parsed_result,
"set portlist (x[,y]*)\n"
"Set the list of forwarding ports.\n\n"

+#ifdef RTE_LIBRTE_IXGBE_PMD
+   "set tx loopback (port_id) (on|off)\n"
+   "Enable or disable tx loopback.\n\n"
+
+   "set all queues drop (port_id) (on|off)\n"
+   "Set drop enable bit for all queues.\n\n"
+
+   "set vf split drop (port_id) (vf_id) (on|off)\n"
+   "Set split drop enable bit for a VF from the 
PF.\n\n"
+
+   "set vf mac antispoof (port_id) (vf_id) (on|off).\n"
+   "Set MAC antispoof for a VF from the PF.\n\n"
+#endif
+
"vlan set strip (on|off) (port_id)\n"
"Set the VLAN strip on a port.\n\n"

"vlan set stripq (on|off) (port_id,queue_id)\n"
"Set the VLAN strip for a queue on a port.\n\n"

+#ifdef RTE_LIBRTE_IXGBE_PMD
+   "set vf vlan stripq (port_id) (vf_id) (on|off)\n"
+   "Set the VLAN strip for all queues in a pool for a 
VF from the PF.\n\n"
+
+   "set vf vlan insert (port_id) (vf_id) (on|off)\n"
+   "Set VLAN insert for a VF from the PF.\n\n"
+
+   "set vf vlan antispoof (port_id) (vf_id) (on|off)\n"
+   "Set VLAN antispoof for a VF from the PF.\n\n"
+#endif
+
"vlan set filter (on|off) (port_id)\n"
"Set the VLAN filter on a port.\n\n"

@@ -359,6 +386,11 @@ static void cmd_help_long_parsed(void *parsed_result,
"mac_addr add port (port_id) vf (vf_id) (mac_address)\n"
"Add a MAC address for a VF on the port.\n\n"

+#ifdef RTE_LIBRTE_IXGBE_PMD
+   "set vf mac addr (port_id) (vf_id) 
(XX:XX:XX:XX:XX:XX)\n"
+   "Set the MAC address for a VF from the PF.\n\n"
+#endif
+
"set port (port_id) uta (mac_address|all) (on|off)\n"
"Add/Remove a or all unicast hash filter(s)"
"from port X.\n\n"
@@ -10700,6 +10732,661 @@ cmdline_parse_inst_t cmd_config_e_tag_filter_del = {
NULL,
},
 };
+#ifdef RTE_LIBRTE_IXGBE_PMD
+
+/* vf vlan anti spoof configuration */
+
+/* Common result structure for vf vlan anti spoof */
+struct cmd_vf_vlan_anti_spoof_result {
+   cmdline_fixed_string_t set;
+   cmdline_fixed_string_t vf;
+   cmdline_fixed_string_t vlan;
+   cmdline_fixed_string_t antispoof;
+   uint8_t port_id;
+   uint32_t vf_id;
+   cmdline_fixed_string_t on_off;
+};
+
+/* Common CLI fields for vf vlan anti spoof enable disable */
+cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_set =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_vlan_anti_spoof_result,
+set, "set");
+cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_vf =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_vlan_anti_spoof_result,
+vf, "vf");
+cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_vlan =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_vlan_anti_spoof_result,
+vlan, "vlan");
+cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_antispoof =
+   TOKEN_STRING_INITIALIZER
+  

[dpdk-dev] [PATCH v9 1/2] net/ixgbe: add API's for VF management

[Bernard Iremonger]

Add API's to configure and manage VF's on an Intel 82559 NIC.

add rte_pmd_ixgbe_set_vf_vlan_anti_spoof function.
add rte_pmd_ixgbe_set_vf_mac_anti_spoof function.
add rte_pmd_ixgbe_set_vf_stripq function.

Signed-off-by: Alex Zelezniak 

add rte_pmd_ixgbe_set_vf_vlan_insert function.
add rte_pmd_ixgbe_set_tx_loopback function.
add rte_pmd_ixgbe_set_all_queues_drop function.
add rte_pmd_ixgbe_set_vf_split_drop_en function.
add rte_pmd_ixgbe_set_vf_mac_addr function.

Signed-off-by: Bernard Iremonger 
---
 drivers/net/ixgbe/Makefile  |   4 +-
 drivers/net/ixgbe/ixgbe_ethdev.c| 240 
 drivers/net/ixgbe/rte_pmd_ixgbe.h   | 182 +
 drivers/net/ixgbe/rte_pmd_ixgbe_version.map |  13 ++
 4 files changed, 438 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ixgbe/rte_pmd_ixgbe.h

diff --git a/drivers/net/ixgbe/Makefile b/drivers/net/ixgbe/Makefile
index a6c71f3..94ddc7b 100644
--- a/drivers/net/ixgbe/Makefile
+++ b/drivers/net/ixgbe/Makefile
@@ -1,6 +1,6 @@
 #   BSD LICENSE
 #
-#   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+#   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
 #   All rights reserved.
 #
 #   Redistribution and use in source and binary forms, with or without
@@ -119,6 +119,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_bypass.c
 SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_82599_bypass.c
 endif

+# install this header file
+SYMLINK-$(CONFIG_RTE_LIBRTE_IXGBE_PMD)-include := rte_pmd_ixgbe.h

 # this lib depends upon:
 DEPDIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += lib/librte_eal lib/librte_ether
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 6b3d4fa..35281f9 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -72,6 +72,8 @@
 #include "base/ixgbe_phy.h"
 #include "ixgbe_regs.h"

+#include "rte_pmd_ixgbe.h"
+
 /*
  * High threshold controlling when to start sending XOFF frames. Must be at
  * least 8 bytes less than receive packet buffer size. This value is in units
@@ -4046,6 +4048,35 @@ ixgbe_set_default_mac_addr(struct rte_eth_dev *dev, 
struct ether_addr *addr)
ixgbe_add_rar(dev, addr, 0, 0);
 }

+int
+rte_pmd_ixgbe_set_vf_mac_addr(uint8_t port, uint16_t vf, struct ether_addr 
*mac_addr)
+{
+   struct ixgbe_hw *hw;
+   struct ixgbe_vf_info *vfinfo;
+   int rar_entry;
+   uint8_t *new_mac = (uint8_t *)(mac_addr);
+   struct rte_eth_dev *dev;
+   struct rte_eth_dev_info dev_info;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+   dev = _eth_devices[port];
+   rte_eth_dev_info_get(port, _info);
+
+   if (vf >= dev_info.max_vfs)
+   return -EINVAL;
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   vfinfo = *(IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private));
+   rar_entry = hw->mac.num_rar_entries - (vf + 1);
+
+   if (is_valid_assigned_ether_addr((struct ether_addr *)new_mac)) {
+   rte_memcpy(vfinfo[vf].vf_mac_addresses, new_mac, 
ETHER_ADDR_LEN);
+   return hw->mac.ops.set_rar(hw, rar_entry, new_mac, vf, 
IXGBE_RAH_AV);
+   }
+   return -EINVAL;
+}
+
 static int
 ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
 {
@@ -4639,6 +4670,215 @@ ixgbe_set_pool_vlan_filter(struct rte_eth_dev *dev, 
uint16_t vlan,
return ret;
 }

+int
+rte_pmd_ixgbe_set_vf_vlan_anti_spoof(uint8_t port, uint16_t vf, uint8_t on)
+{
+   struct ixgbe_hw *hw;
+   struct ixgbe_mac_info *mac;
+   struct rte_eth_dev *dev;
+   struct rte_eth_dev_info dev_info;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+   dev = _eth_devices[port];
+   rte_eth_dev_info_get(port, _info);
+
+   if (vf >= dev_info.max_vfs)
+   return -EINVAL;
+
+   if (on > 1)
+   return -EINVAL;
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   mac = >mac;
+
+   mac->ops.set_vlan_anti_spoofing(hw, on, vf);
+
+   return 0;
+}
+
+int
+rte_pmd_ixgbe_set_vf_mac_anti_spoof(uint8_t port, uint16_t vf, uint8_t on)
+{
+   struct ixgbe_hw *hw;
+   struct ixgbe_mac_info *mac;
+   struct rte_eth_dev *dev;
+   struct rte_eth_dev_info dev_info;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+   dev = _eth_devices[port];
+   rte_eth_dev_info_get(port, _info);
+
+   if (vf >= dev_info.max_vfs)
+   return -EINVAL;
+
+   if (on > 1)
+   return -EINVAL;
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   mac = >mac;
+   mac->ops.set_mac_anti_spoofing(hw, on, vf);
+
+   return 0;
+}
+
+int
+rte_pmd_ixgbe_set_vf_vlan_insert(uint8_t port, uint16_t vf, uint8_t on)
+{
+   struct ixgbe_hw *hw;
+   uint32_t ctrl;
+   struct rte_eth_dev *dev;
+   struct rte_eth_dev_info dev_info;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port, 

[dpdk-dev] [PATCH v9 0/2] add API's for VF management

[Bernard Iremonger]

This patchset contains new DPDK API's for use
with the Virtual Function Daemon (VFD).

The need to configure and manage VF's on a NIC has grown to the
point where a DPDK based tool, VFD, has been developed to do this.

This patch set adds API extensions to DPDK for VF configuration.

Eight new API's have been added for the Intel 82559 NIC.

Changes have been made to testpmd to facilitate testing of the new API's.
The testpmd documentation has been updated to document the testpmd changes.

Changes in v8:
rebase to latest master branch.
fix testpmd Makefile.

Changes in v8:
rebase to latest master branch.
add new API's to testpmd help command.
modify testpmd  Makefile to build with and without ixgbe PMD,
in shared library mode and default mode.

Changes in v7:
rebase to latest master branch.
minor changes to ixgbe PMD following internal review.

Changes in v6:
rebase to latest master branch.
fix ixgbe makefile.
move set_vf_vlan_stripq function from ethdev to ixgbe PMD.
revise testpmd command for set_vf_vlan_stripq.

Changes in v5:
rebase to latest master branch.
remove new API's from eth_dev_ops structure.
add public API's to ixgbe PMD.
revise testpmd commands for new API's

Changes in v4:
The rte_eth_dev_vf_ping API has been dropped as it is a work around for a bug.
The rte_eth_dev_set_vf_vlan_strip API has been renamed to
rte_eth_dev_set_vf_vlan_stripq.

Changes in v3:
rebase to latest master branch.
drop patches for callback functions
revise VF id checks in new librte_ether functions
revise testpmd commands for new API's

Changes in V2:
rebase to latest master branch.
fix compile  error with clang.
Bernard Iremonger (2):
  net/ixgbe: add API's for VF management
  app/test_pmd: add tests for new API's

 app/test-pmd/Makefile   |   2 +
 app/test-pmd/cmdline.c  | 699 +++-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  62 ++-
 drivers/net/ixgbe/Makefile  |   4 +-
 drivers/net/ixgbe/ixgbe_ethdev.c| 240 ++
 drivers/net/ixgbe/rte_pmd_ixgbe.h   | 182 
 drivers/net/ixgbe/rte_pmd_ixgbe_version.map |  13 +
 7 files changed, 1197 insertions(+), 5 deletions(-)
 create mode 100644 drivers/net/ixgbe/rte_pmd_ixgbe.h

-- 
2.9.0

[dpdk-dev] [PATCH v6 0/8] Misc enhancements in testpmd

[Thomas Monjalon]

2016-10-12 17:39, Olivier Matz:
> This patchset introduces several enhancements or minor fixes
> in testpmd. It is targetted for v16.11, and applies on top of
> software ptype v2 patchset [1].
> 
> These patches are useful to validate the virtio offload
> patchset [2] (to be rebased).

Applied, thanks

[dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new API's

[Thomas Monjalon]

2016-10-12 16:21, Iremonger, Bernard:
> Hi Thomas,
> 
> 
> > > > > > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests
> > > > > > for new API's
> > > > > >
> > > > > > 2016-10-12 16:03, Bernard Iremonger:
> > > > > > > --- a/app/test-pmd/Makefile
> > > > > > > +++ b/app/test-pmd/Makefile
> > > > > > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c  SRCS-y += icmpecho.c
> > > > > > >  SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > > > > > >
> > > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > > > > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > > > endif
> > > > > > > +
> > > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > > > > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > > > > > +LDLIBS += -lrte_pmd_ixgbe
> > > > > > > +endif
> > > > > > > +endif
> > > > > >
> > > > > > Sorry if I miss something, but I thought it was enough to do:
> > > > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > > > >
> > > > > No unfortunately not, the above line does not work for all scenarios .
> > > > >
> > > > > There are 4 scenarios as follows:
> > > > >
> > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with
> > > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > >
> > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with
> > > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > > >
> > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with
> > > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > > >
> > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with
> > > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > >
> > > > > I have been doing quite a bit of building today to get it to work
> > > > > in all 4
> > > > scenarios.
> > > >
> > > > I have a doubt about the tests because LDLIBS-y does not exist.
> > > > There is _LDLIBS-y and LDLIBS.
> > > > But in the static case, you wrote:
> > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > endif
> > > > Please could you check?
> > >
> > > LDLIBS-y exists in some of the scenarios but not all.
> > 
> > I think I'm something obvious.
> > Please could you point the line where LDLIBS-y is used?
> 
> Line 62  of latest Makefile;
> LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe

No, I mean where do you find LDLIBS- (without underscore) before your patch?
git grep '\

[dpdk-dev] [PATCH v3] test_cryptodev_perf: IV and digest should be stored at a DMAeble address

[Trahe, Fiona]

> -Original Message-
> From: akhil.goyal at nxp.com [mailto:akhil.goyal at nxp.com]
> Sent: Wednesday, October 12, 2016 12:16 PM
> To: Kusztal, ArkadiuszX ; Doherty, Declan
> 
> Cc: Griffin, John ; Trahe, Fiona
> ; Jain, Deepak K ;
> dev at dpdk.org; Akhil Goyal 
> Subject: [PATCH v3] test_cryptodev_perf: IV and digest should be stored at a
> DMAeble address
> 
> From: Akhil Goyal 
> 
> For physical crypto devices, IV and digest are processed by the crypto device
> which need the contents to be written on some DMA able address.
> 
> So in order to do that, IV and digest are accomodated in the packet.
> 
> Signed-off-by: Akhil Goyal 
> v2: patch rebased
> v3: fix broken compilation
> ---
>  app/test/test_cryptodev_perf.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/app/test/test_cryptodev_perf.c b/app/test/test_cryptodev_perf.c
> index 4aee9af..d498195 100644
> --- a/app/test/test_cryptodev_perf.c
> +++ b/app/test/test_cryptodev_perf.c
> @@ -2722,9 +2722,12 @@ test_perf_set_crypto_op_aes(struct
> rte_crypto_op *op, struct rte_mbuf *m,
>   op->sym->auth.aad.length = AES_CIPHER_IV_LENGTH;
> 
>   /* Cipher Parameters */
> - op->sym->cipher.iv.data = aes_iv;
> + op->sym->cipher.iv.data = (uint8_t *)m->buf_addr + m->data_off;
> + op->sym->cipher.iv.phys_addr = rte_pktmbuf_mtophys(m);
>   op->sym->cipher.iv.length = AES_CIPHER_IV_LENGTH;
> 
> + rte_memcpy(op->sym->cipher.iv.data, aes_iv,
> AES_CIPHER_IV_LENGTH);
> +
>   /* Data lengths/offsets Parameters */
>   op->sym->auth.data.offset = 0;
>   op->sym->auth.data.length = data_len;
> @@ -2893,7 +2896,9 @@ test_perf_aes_sha(uint8_t dev_id, uint16_t
> queue_id,
>   rte_pktmbuf_free(mbufs[k]);
>   return -1;
>   }
> -
> + /* Make room for Digest and IV in mbuf */
> + rte_pktmbuf_append(mbufs[i], digest_length);
> + rte_pktmbuf_prepend(mbufs[i], AES_CIPHER_IV_LENGTH);
>   }
> 
> 
> --
> 2.9.3
Acked-by: Fiona Trahe 

[dpdk-dev] [PATCH v5] drivers/net:new PMD using tun/tap host interface

[Wiles, Keith]

Regards,
Keith

> On Oct 12, 2016, at 9:56 AM, Yigit, Ferruh  wrote:
> 
> On 10/11/2016 10:51 PM, Keith Wiles wrote:
>> The rte_eth_tap.c PMD creates a device using TUN/TAP interfaces
>> on the local host. The PMD allows for DPDK and the host to
>> communicate using a raw device interface on the host and in
>> the DPDK application. The device created is a Tap device with
>> a L2 packet header.
>> 
>> v5 - merge in changes from list review see related emails.
>> fixed checkpatch issues and many minor edits
>> v4 - merge with latest driver changes
>> v3 - fix includes by removing ifdef for other type besides Linux.
>> Fix the copyright notice in the Makefile
>> v2 - merge all of the patches into one patch.
>> Fix a typo on naming the tap device.
>> Update the maintainers list
>> 
>> Signed-off-by: Keith Wiles 
>> ---
> 
> <..>
> 
>> diff --git a/config/common_base b/config/common_base
>> index f5d2eff..356c631 100644
>> --- a/config/common_base
>> +++ b/config/common_base
>> @@ -592,3 +592,8 @@ CONFIG_RTE_APP_TEST_RESOURCE_TAR=n
>> CONFIG_RTE_TEST_PMD=y
>> CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
>> CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
>> +
>> +#
>> +# Set TAP PMD to 'n' as it is only supported in Linux for now.
> 
> This comments moved to final .config and creates confusion, can we
> remove it if you don't have a strong option to keep it?

What do you mean, the statement is confusing or causes problems?

> 
> <..>
> 
>> diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
>> new file mode 100644
>> index 000..eed81ec
>> --- /dev/null
>> +++ b/doc/guides/nics/tap.rst
> 
> <..>
> 
>> +.. code-block:: console
>> +
>> +   The interfaced name can be changed by adding the iface=foo0
>> +   e.g. --vdev=eth_tap,iface=foo0 --vdev=eth_tap,iface=foo1, ...
> 
> For all file:
> %s/eth_tap/net_tap/g, there are multiple lines with this usage

Missed that one.

> 
> 
> <..>
> 
>> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
>> new file mode 100644
>> index 000..c13aa1b
>> --- /dev/null
>> +++ b/drivers/net/tap/rte_eth_tap.c
> 
> <..>
> 
>> +
>> +struct tap_info {
>> +char name[RTE_ETH_NAME_MAX_LEN]; /* Interface name supplied/given */
>> +int speed;   /* Speed of interface */
>> +};
> 
> This struct can go away, it is not used, since with the updated code
> rte_pmd_tap_probe() used tap_name and speed as seperate variables
> instead of struct.
> 

OK.

> 
> <..>
> 
>> +
>> +/* If the name is different that new name as default */
>> +if (name && strcmp(name, ifr.ifr_name))
>> +snprintf(name, RTE_ETH_NAME_MAX_LEN-1, "%s", ifr.ifr_name);
> 
> syntax, space around "-"
> 
> <..>
> 
>> +
>> +static void
>> +tap_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *tap_stats)
>> +{
>> +unsigned i, imax;
> 
> checkpatch complain about not using "unsigned int?

I ran checkpatch on the patch and saw no errors reported via the 
scripts/checkpatch.sh. Which checkpatch are you using here?
> 
> 
> <..>
> 
>> +static int
>> +tap_setup_queue(struct rte_eth_dev *dev,
>> +struct pmd_internals *internals,
>> +uint16_t qid)
>> +{
>> +struct rx_queue *rx = >rxq[qid];
>> +struct tx_queue *tx = >txq[qid];
>> +int fd;
>> +
>> +if ((fd = rx->fd) < 0)
>> +if ((fd = tx->fd) < 0) {
>> +RTE_LOG(INFO, PMD, "Add queue to TAP %s for qid %d\n",
>> +dev->data->name, qid);
>> +if ((fd = tun_alloc(dev->data->name)) < 0) {
> 
> checkpatch complain about assignment in the if condition
> 
> 
> <..>
> 
>> +/* Now get the space available for data in the mbuf */
>> +buf_size = (uint16_t) (rte_pktmbuf_data_room_size(mp) -
> 
> syntax, no space after cast
> 
> 
> <..>
> 
>> +/* Create the first Tap device */
>> +if ((fd = tun_alloc(tap_name)) < 0) {
> 
> checkpatch complains about assignment in if condition
> 
>> +RTE_LOG(ERR, PMD, "tun_alloc(%s) failed\n", dev->data->name);
>> +rte_free(pmd);
> 
> rte_free(data) or goto error_exit; ?
> 
>> +rte_eth_dev_release_port(dev);
>> +return -EINVAL;
>> +}
>> +
>> +/* Presetup the fds to -1 as being not working */
>> +for(i = 0; i < RTE_PMD_TAP_MAX_QUEUES; i++) {
>> +pmd->fds[i] = -1;
>> +pmd->rxq[i].fd = -1;
>> +pmd->txq[i].fd = -1;
>> +}
>> +
>> +/* Take the TUN/TAP fd and place in the first location */
>> +pmd->rxq[0].fd = fd;
>> +pmd->txq[0].fd = fd;
>> +pmd->fds[0] = fd;
>> +
>> +if (pmd_mac_address(fd, dev, >eth_addr) < 0) {
>> +rte_free(pmd);
> 
> rte_free(data) or goto error_exit; ?
> 
> 
> <..>
> 
>> +static int
>> +set_interface_name(const char *key __rte_unused,
>> +   const char *value,
>> +   void *extra_args)
>> +{
>> +char *name = (char *)extra_args;
>> +
>> +if (value)
>> +

[dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new API's

[Thomas Monjalon]

2016-10-12 15:48, Iremonger, Bernard:
> Hi Thomas,
> 
> 
> 
> > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new
> > API's
> > 
> > 2016-10-12 15:27, Iremonger, Bernard:
> > > Hi Thomas,
> > >
> > > 
> > >
> > > > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for
> > > > new API's
> > > >
> > > > 2016-10-12 16:03, Bernard Iremonger:
> > > > > --- a/app/test-pmd/Makefile
> > > > > +++ b/app/test-pmd/Makefile
> > > > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c  SRCS-y += icmpecho.c
> > > > >  SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > > > >
> > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > endif
> > > > > +
> > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > > > +LDLIBS += -lrte_pmd_ixgbe
> > > > > +endif
> > > > > +endif
> > > >
> > > > Sorry if I miss something, but I thought it was enough to do:
> > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > >
> > > No unfortunately not, the above line does not work for all scenarios .
> > >
> > > There are 4 scenarios as follows:
> > >
> > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with
> > CONFIG_RTE_BUILD_SHARED_LIB=n
> > >
> > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with
> > CONFIG_RTE_BUILD_SHARED_LIB=y
> > >
> > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with
> > CONFIG_RTE_BUILD_SHARED_LIB=y
> > >
> > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with
> > CONFIG_RTE_BUILD_SHARED_LIB=n
> > >
> > > I have been doing quite a bit of building today to get it to work in all 4
> > scenarios.
> > 
> > I have a doubt about the tests because LDLIBS-y does not exist.
> > There is _LDLIBS-y and LDLIBS.
> > But in the static case, you wrote:
> > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > endif Please could you check?
> 
> LDLIBS-y exists in some of the scenarios but not all.

I think I'm something obvious.
Please could you point the line where LDLIBS-y is used?

> Do you want me to check the four scenarios  with just the line below.
> 
> LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe

Let's check the theory first :)

[dpdk-dev] [PATCH v2 03/12] virtio: reinitialize the device in configure callback

[Olivier MATZ]

Hello Yuanhan,

On 10/12/2016 04:41 PM, Yuanhan Liu wrote:
> On Mon, Oct 03, 2016 at 11:00:14AM +0200, Olivier Matz wrote:
>> @@ -1344,6 +1347,7 @@ virtio_dev_configure(struct rte_eth_dev *dev)
>>   {
>>  const struct rte_eth_rxmode *rxmode = >data->dev_conf.rxmode;
>>  struct virtio_hw *hw = dev->data->dev_private;
>> +uint64_t req_features;
>>  int ret;
>>
>>  PMD_INIT_LOG(DEBUG, "configure");
>> @@ -1353,6 +1357,14 @@ virtio_dev_configure(struct rte_eth_dev *dev)
>>  return -EINVAL;
>>  }
>>
>> +req_features = VIRTIO_PMD_GUEST_FEATURES;
>> +/* if request features changed, reinit the device */
>> +if (req_features != hw->req_guest_features) {
>> +ret = virtio_init_device(dev, req_features);
>> +if (ret < 0)
>> +return ret;
>> +}
>
> Why do you have to reset virtio here? This doesn't make too much sense
> to me.
>
> IIUC, you want to make sure those TSO related features being unset at
> init time, and enable it (by doing reset) when it's asked to be enabled
> (by rte_eth_dev_configure)?
>
> Why not always setting those features? We could do the actual offloads
> when:
>
> - those features have been negoiated
>
> - they are enabled through rte_eth_dev_configure
>
> With that, I think we could avoid the reset here?

It would work for TX, since you decide to use or not the feature. But I 
think this won't work for RX: if you negociate LRO at init, the host may 
send you large packets, even if LRO is disabled in dev_configure.

Regards,
Olivier

[dpdk-dev] [PATCH v2 09/12] virtio: add Rx checksum offload support

[Olivier MATZ]

On 10/12/2016 03:02 PM, Yuanhan Liu wrote:
> On Wed, Oct 05, 2016 at 03:27:47PM +0200, Maxime Coquelin wrote:
>>> /* Update offload features */
>>> -   if (virtio_rx_offload(rxm, hdr) < 0) {
>>> +   if ((features & VIRTIO_NET_F_GUEST_CSUM) &&
>> s/VIRTIO_NET_F_GUEST_CSUM/(1u << VIRTIO_NET_F_GUEST_CSUM)/
>
> There is a helper function for that: vtpci_with_feature.

Ok, will use it.

Thanks,
Olivier

[dpdk-dev] [PATCH v6 8/8] app/testpmd: hide segsize when unrelevant in csum engine

[Olivier Matz]

When TSO is not asked, hide the segment size.

Signed-off-by: Olivier Matz 
Acked-by: Pablo de Lara 
---
 app/test-pmd/csumonly.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index d51d85a..f9e65b6 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -843,10 +843,12 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
"m->outer_l3_len=%d\n",
m->outer_l2_len,
m->outer_l3_len);
-   if (info.tunnel_tso_segsz != 0)
+   if (info.tunnel_tso_segsz != 0 &&
+   (m->ol_flags & PKT_TX_TCP_SEG))
printf("tx: m->tso_segsz=%d\n",
m->tso_segsz);
-   } else if (info.tso_segsz != 0)
+   } else if (info.tso_segsz != 0 &&
+   (m->ol_flags & PKT_TX_TCP_SEG))
printf("tx: m->tso_segsz=%d\n", m->tso_segsz);
rte_get_tx_ol_flag_list(m->ol_flags, buf, sizeof(buf));
printf("tx: flags=%s", buf);
-- 
2.8.1

[dpdk-dev] [PATCH v6 7/8] app/testpmd: don't use tso if packet is too small

[Olivier Matz]

Asking for TSO (TCP Segmentation Offload) on packets that are already
smaller than (headers + MSS) does not work, for instance on ixgbe.

Fix the csumonly engine to only set the TSO flag when a segmentation
offload is really required, i.e. when packet is large enough.

Signed-off-by: Olivier Matz 
Acked-by: Pablo de Lara 
---
 app/test-pmd/csumonly.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index dbd8dc4..d51d85a 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -102,6 +102,7 @@ struct testpmd_offload_info {
uint8_t outer_l4_proto;
uint16_t tso_segsz;
uint16_t tunnel_tso_segsz;
+   uint32_t pkt_len;
 };

 /* simplified GRE header */
@@ -329,6 +330,21 @@ process_inner_cksums(void *l3_hdr, const struct 
testpmd_offload_info *info,
struct tcp_hdr *tcp_hdr;
struct sctp_hdr *sctp_hdr;
uint64_t ol_flags = 0;
+   uint32_t max_pkt_len, tso_segsz = 0;
+
+   /* ensure packet is large enough to require tso */
+   if (!info->is_tunnel) {
+   max_pkt_len = info->l2_len + info->l3_len + info->l4_len +
+   info->tso_segsz;
+   if (info->tunnel_tso_segsz != 0 && info->pkt_len > max_pkt_len)
+   tso_segsz = info->tso_segsz;
+   } else {
+   max_pkt_len = info->outer_l2_len + info->outer_l3_len +
+   info->l2_len + info->l3_len + info->l4_len +
+   info->tunnel_tso_segsz;
+   if (info->tunnel_tso_segsz != 0 && info->pkt_len > max_pkt_len)
+   tso_segsz = info->tunnel_tso_segsz;
+   }

if (info->ethertype == _htons(ETHER_TYPE_IPv4)) {
ipv4_hdr = l3_hdr;
@@ -369,8 +385,7 @@ process_inner_cksums(void *l3_hdr, const struct 
testpmd_offload_info *info,
} else if (info->l4_proto == IPPROTO_TCP) {
tcp_hdr = (struct tcp_hdr *)((char *)l3_hdr + info->l3_len);
tcp_hdr->cksum = 0;
-   if ((info->is_tunnel && info->tunnel_tso_segsz != 0) ||
-   (!info->is_tunnel && info->tso_segsz != 0)) {
+   if (tso_segsz) {
ol_flags |= PKT_TX_TCP_SEG;
tcp_hdr->cksum = get_psd_sum(l3_hdr, info->ethertype,
ol_flags);
@@ -679,6 +694,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)

m = pkts_burst[i];
info.is_tunnel = 0;
+   info.pkt_len = rte_pktmbuf_pkt_len(m);
tx_ol_flags = 0;
rx_ol_flags = m->ol_flags;

-- 
2.8.1

[dpdk-dev] [PATCH v6 6/8] app/testpmd: display Rx port in csum engine

[Olivier Matz]

This information is useful when debugging, especially with
bidirectional traffic.

Signed-off-by: Olivier Matz 
Acked-by: Pablo de Lara 
---
 app/test-pmd/csumonly.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 34d4b11..dbd8dc4 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -798,8 +798,8 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
char buf[256];

printf("-\n");
-   printf("mbuf=%p, pkt_len=%u, nb_segs=%hhu:\n",
-   m, m->pkt_len, m->nb_segs);
+   printf("port=%u, mbuf=%p, pkt_len=%u, nb_segs=%hhu:\n",
+   fs->rx_port, m, m->pkt_len, m->nb_segs);
/* dump rx parsed packet info */
rte_get_rx_ol_flag_list(rx_ol_flags, buf, sizeof(buf));
printf("rx: l2_len=%d ethertype=%x l3_len=%d "
-- 
2.8.1

[dpdk-dev] [PATCH v6 5/8] app/testpmd: do not change ip addrs in csum engine

[Olivier Matz]

The csum forward engine was updated to change the IP addresses in the
packet data in
commit 51f694dd40f5 ("app/testpmd: rework checksum forward engine")

This was done to ensure that the checksum is correctly reprocessed when
using hardware checksum offload. But the functions
process_inner_cksums() and process_outer_cksums() already reset the
checksum field to 0, so this is not necessary.

Moreover, this makes the engine more complex than needed, and prevents
to easily use it to forward traffic (like iperf) as it modifies the
packets.

This patch drops this behavior.

Signed-off-by: Olivier Matz 
Acked-by: Pablo de Lara 
---
 app/test-pmd/csumonly.c | 27 ++-
 1 file changed, 2 insertions(+), 25 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 42974d5..34d4b11 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -318,21 +318,6 @@ parse_encap_ip(void *encap_ip, struct testpmd_offload_info 
*info)
info->l2_len = 0;
 }

-/* modify the IPv4 or IPv4 source address of a packet */
-static void
-change_ip_addresses(void *l3_hdr, uint16_t ethertype)
-{
-   struct ipv4_hdr *ipv4_hdr = l3_hdr;
-   struct ipv6_hdr *ipv6_hdr = l3_hdr;
-
-   if (ethertype == _htons(ETHER_TYPE_IPv4)) {
-   ipv4_hdr->src_addr =
-   rte_cpu_to_be_32(rte_be_to_cpu_32(ipv4_hdr->src_addr) + 
1);
-   } else if (ethertype == _htons(ETHER_TYPE_IPv6)) {
-   ipv6_hdr->src_addr[15] = ipv6_hdr->src_addr[15] + 1;
-   }
-}
-
 /* if possible, calculate the checksum of a packet in hw or sw,
  * depending on the testpmd command line configuration */
 static uint64_t
@@ -620,7 +605,6 @@ pkt_copy_split(const struct rte_mbuf *pkt)
  * Receive a burst of packets, and for each packet:
  *  - parse packet, and try to recognize a supported packet type (1)
  *  - if it's not a supported packet type, don't touch the packet, else:
- *  - modify the IPs in inner headers and in outer headers if any
  *  - reprocess the checksum of all supported layers. This is done in SW
  *or HW, depending on testpmd command line configuration
  *  - if TSO is enabled in testpmd command line, also flag the mbuf for TCP
@@ -747,14 +731,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
l3_hdr = (char *)l3_hdr + info.outer_l3_len + 
info.l2_len;
}

-   /* step 2: change all source IPs (v4 or v6) so we need
-* to recompute the chksums even if they were correct */
-
-   change_ip_addresses(l3_hdr, info.ethertype);
-   if (info.is_tunnel == 1)
-   change_ip_addresses(outer_l3_hdr, info.outer_ethertype);
-
-   /* step 3: depending on user command line configuration,
+   /* step 2: depending on user command line configuration,
 * recompute checksum either in software or flag the
 * mbuf to offload the calculation to the NIC. If TSO
 * is configured, prepare the mbuf for TCP segmentation. */
@@ -772,7 +749,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
!!(tx_ol_flags & PKT_TX_TCP_SEG));
}

-   /* step 4: fill the mbuf meta data (flags and header lengths) */
+   /* step 3: fill the mbuf meta data (flags and header lengths) */

if (info.is_tunnel == 1) {
if (info.tunnel_tso_segsz ||
-- 
2.8.1

[dpdk-dev] [PATCH v6 4/8] app/testpmd: add option to enable lro

[Olivier Matz]

Introduce a new argument '--enable-lro' to ask testpmd to enable the LRO
feature on enabled ports, like it's done for '--enable-rx-cksum' for
instance.

Signed-off-by: Olivier Matz 
Acked-by: Pablo de Lara 
---
 app/test-pmd/parameters.c | 4 
 doc/guides/testpmd_app_ug/run_app.rst | 4 
 2 files changed, 8 insertions(+)

diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 6a6a07e..c45f78a 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -149,6 +149,7 @@ usage(char* progname)
   "If the drop-queue doesn't exist, the packet is dropped. "
   "By default drop-queue=127.\n");
printf("  --crc-strip: enable CRC stripping by hardware.\n");
+   printf("  --enable-lro: enable large receive offload.\n");
printf("  --enable-rx-cksum: enable rx hardware checksum offload.\n");
printf("  --disable-hw-vlan: disable hardware vlan.\n");
printf("  --disable-hw-vlan-filter: disable hardware vlan filter.\n");
@@ -524,6 +525,7 @@ launch_args_parse(int argc, char** argv)
{ "pkt-filter-size",1, 0, 0 },
{ "pkt-filter-drop-queue",  1, 0, 0 },
{ "crc-strip",  0, 0, 0 },
+   { "enable-lro", 0, 0, 0 },
{ "enable-rx-cksum",0, 0, 0 },
{ "enable-scatter", 0, 0, 0 },
{ "disable-hw-vlan",0, 0, 0 },
@@ -764,6 +766,8 @@ launch_args_parse(int argc, char** argv)
}
if (!strcmp(lgopts[opt_idx].name, "crc-strip"))
rx_mode.hw_strip_crc = 1;
+   if (!strcmp(lgopts[opt_idx].name, "enable-lro"))
+   rx_mode.enable_lro = 1;
if (!strcmp(lgopts[opt_idx].name, "enable-scatter"))
rx_mode.enable_scatter = 1;
if (!strcmp(lgopts[opt_idx].name, "enable-rx-cksum"))
diff --git a/doc/guides/testpmd_app_ug/run_app.rst 
b/doc/guides/testpmd_app_ug/run_app.rst
index 7712bd2..55c7ac0 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -285,6 +285,10 @@ The commandline options are:

 Enable hardware CRC stripping.

+*   ``--enable-lro``
+
+Enable large receive offload.
+
 *   ``--enable-rx-cksum``

 Enable hardware RX checksum offload.
-- 
2.8.1

[dpdk-dev] [PATCH v6 3/8] app/testpmd: dump Rx flags in csum engine

[Olivier Matz]

Signed-off-by: Olivier Matz 
Acked-by: Pablo de Lara 
---
 app/test-pmd/csumonly.c | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 2ecd6b8..42974d5 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -652,7 +652,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
uint16_t nb_rx;
uint16_t nb_tx;
uint16_t i;
-   uint64_t ol_flags;
+   uint64_t rx_ol_flags, tx_ol_flags;
uint16_t testpmd_ol_flags;
uint32_t retry;
uint32_t rx_bad_ip_csum;
@@ -693,13 +693,14 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
rte_prefetch0(rte_pktmbuf_mtod(pkts_burst[i + 1],
   void *));

-   ol_flags = 0;
-   info.is_tunnel = 0;
m = pkts_burst[i];
+   info.is_tunnel = 0;
+   tx_ol_flags = 0;
+   rx_ol_flags = m->ol_flags;

/* Update the L3/L4 checksum error packet statistics */
-   rx_bad_ip_csum += ((m->ol_flags & PKT_RX_IP_CKSUM_BAD) != 0);
-   rx_bad_l4_csum += ((m->ol_flags & PKT_RX_L4_CKSUM_BAD) != 0);
+   rx_bad_ip_csum += ((rx_ol_flags & PKT_RX_IP_CKSUM_BAD) != 0);
+   rx_bad_l4_csum += ((rx_ol_flags & PKT_RX_L4_CKSUM_BAD) != 0);

/* step 1: dissect packet, parsing optional vlan, ip4/ip6, vxlan
 * and inner headers */
@@ -721,7 +722,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
info.l3_len);
parse_vxlan(udp_hdr, , m->packet_type);
if (info.is_tunnel)
-   ol_flags |= PKT_TX_TUNNEL_VXLAN;
+   tx_ol_flags |= PKT_TX_TUNNEL_VXLAN;
} else if (info.l4_proto == IPPROTO_GRE) {
struct simple_gre_hdr *gre_hdr;

@@ -729,14 +730,14 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
((char *)l3_hdr + info.l3_len);
parse_gre(gre_hdr, );
if (info.is_tunnel)
-   ol_flags |= PKT_TX_TUNNEL_GRE;
+   tx_ol_flags |= PKT_TX_TUNNEL_GRE;
} else if (info.l4_proto == IPPROTO_IPIP) {
void *encap_ip_hdr;

encap_ip_hdr = (char *)l3_hdr + info.l3_len;
parse_encap_ip(encap_ip_hdr, );
if (info.is_tunnel)
-   ol_flags |= PKT_TX_TUNNEL_IPIP;
+   tx_ol_flags |= PKT_TX_TUNNEL_IPIP;
}
}

@@ -759,15 +760,16 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
 * is configured, prepare the mbuf for TCP segmentation. */

/* process checksums of inner headers first */
-   ol_flags |= process_inner_cksums(l3_hdr, , 
testpmd_ol_flags);
+   tx_ol_flags |= process_inner_cksums(l3_hdr, ,
+   testpmd_ol_flags);

/* Then process outer headers if any. Note that the software
 * checksum will be wrong if one of the inner checksums is
 * processed in hardware. */
if (info.is_tunnel == 1) {
-   ol_flags |= process_outer_cksums(outer_l3_hdr, ,
+   tx_ol_flags |= process_outer_cksums(outer_l3_hdr, ,
testpmd_ol_flags,
-   !!(ol_flags & PKT_TX_TCP_SEG));
+   !!(tx_ol_flags & PKT_TX_TCP_SEG));
}

/* step 4: fill the mbuf meta data (flags and header lengths) */
@@ -802,7 +804,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
m->l4_len = info.l4_len;
m->tso_segsz = info.tso_segsz;
}
-   m->ol_flags = ol_flags;
+   m->ol_flags = tx_ol_flags;

/* Do split & copy for the packet. */
if (tx_pkt_split != TX_PKT_SPLIT_OFF) {
@@ -822,10 +824,11 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
printf("mbuf=%p, pkt_len=%u, nb_segs=%hhu:\n",
m, m->pkt_len, m->nb_segs);
/* dump rx parsed packet info */
+   rte_get_rx_ol_flag_list(rx_ol_flags, buf, sizeof(buf));
printf("rx: l2_len=%d ethertype=%x l3_len=%d "
-   "l4_proto=%d l4_len=%d\n",
+   "l4_proto=%d l4_len=%d 

[dpdk-dev] [PATCH v6 2/8] app/testpmd: use new function to dump offload flags

[Olivier Matz]

Use the functions introduced in the previous commit to dump the offload
flags.

Signed-off-by: Olivier Matz 
Acked-by: Pablo de Lara 
---
 app/test-pmd/csumonly.c | 31 +++
 app/test-pmd/rxonly.c   | 15 ++-
 2 files changed, 5 insertions(+), 41 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 4fe038d..2ecd6b8 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -816,27 +816,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)

/* if verbose mode is enabled, dump debug info */
if (verbose_level > 0) {
-   struct {
-   uint64_t flag;
-   uint64_t mask;
-   } tx_flags[] = {
-   { PKT_TX_IP_CKSUM, PKT_TX_IP_CKSUM },
-   { PKT_TX_UDP_CKSUM, PKT_TX_L4_MASK },
-   { PKT_TX_TCP_CKSUM, PKT_TX_L4_MASK },
-   { PKT_TX_SCTP_CKSUM, PKT_TX_L4_MASK },
-   { PKT_TX_IPV4, PKT_TX_IPV4 },
-   { PKT_TX_IPV6, PKT_TX_IPV6 },
-   { PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IP_CKSUM 
},
-   { PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV4 },
-   { PKT_TX_OUTER_IPV6, PKT_TX_OUTER_IPV6 },
-   { PKT_TX_TCP_SEG, PKT_TX_TCP_SEG },
-   { PKT_TX_TUNNEL_VXLAN, PKT_TX_TUNNEL_MASK },
-   { PKT_TX_TUNNEL_GRE, PKT_TX_TUNNEL_MASK },
-   { PKT_TX_TUNNEL_IPIP, PKT_TX_TUNNEL_MASK },
-   { PKT_TX_TUNNEL_GENEVE, PKT_TX_TUNNEL_MASK },
-   };
-   unsigned j;
-   const char *name;
+   char buf[256];

printf("-\n");
printf("mbuf=%p, pkt_len=%u, nb_segs=%hhu:\n",
@@ -872,13 +852,8 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
m->tso_segsz);
} else if (info.tso_segsz != 0)
printf("tx: m->tso_segsz=%d\n", m->tso_segsz);
-   printf("tx: flags=");
-   for (j = 0; j < sizeof(tx_flags)/sizeof(*tx_flags); 
j++) {
-   name = 
rte_get_tx_ol_flag_name(tx_flags[j].flag);
-   if ((m->ol_flags & tx_flags[j].mask) ==
-   tx_flags[j].flag)
-   printf("%s ", name);
-   }
+   rte_get_tx_ol_flag_list(m->ol_flags, buf, sizeof(buf));
+   printf("tx: flags=%s", buf);
printf("\n");
}
}
diff --git a/app/test-pmd/rxonly.c b/app/test-pmd/rxonly.c
index 9acc4c6..fff815c 100644
--- a/app/test-pmd/rxonly.c
+++ b/app/test-pmd/rxonly.c
@@ -229,19 +229,8 @@ pkt_burst_receive(struct fwd_stream *fs)
}
printf(" - Receive queue=0x%x", (unsigned) fs->rx_queue);
printf("\n");
-   if (ol_flags != 0) {
-   unsigned rxf;
-   const char *name;
-
-   for (rxf = 0; rxf < sizeof(mb->ol_flags) * 8; rxf++) {
-   if ((ol_flags & (1ULL << rxf)) == 0)
-   continue;
-   name = rte_get_rx_ol_flag_name(1ULL << rxf);
-   if (name == NULL)
-   continue;
-   printf("  %s\n", name);
-   }
-   }
+   rte_get_rx_ol_flag_list(mb->ol_flags, buf, sizeof(buf));
+   printf("  ol_flags: %s\n", buf);
rte_pktmbuf_free(mb);
}

-- 
2.8.1

[dpdk-dev] [PATCH v6 1/8] mbuf: add function to dump ol flag list

[Olivier Matz]

The functions rte_get_rx_ol_flag_name() and rte_get_tx_ol_flag_name()
can dump one flag, or set of flag that are part of the same mask (ex:
PKT_TX_UDP_CKSUM, part of PKT_TX_L4_MASK). But they are not designed to
dump the list of flags contained in mbuf->ol_flags.

This commit introduce new functions to do that. Similarly to the packet
type dump functions, the goal is to factorize the code that could be
used in several applications and reduce the risk of desynchronization
between the flags and the dump functions.

Signed-off-by: Olivier Matz 
Acked-by: Pablo de Lara 
---
 doc/guides/rel_notes/release_16_11.rst |   5 ++
 lib/librte_mbuf/rte_mbuf.c | 101 +
 lib/librte_mbuf/rte_mbuf.h |  28 +
 lib/librte_mbuf/rte_mbuf_version.map   |   2 +
 4 files changed, 136 insertions(+)

diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
index 25c447d..0f04a39 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -99,6 +99,11 @@ New Features
   * AES GCM/CTR mode


+* **Added functions to dump the offload flags as a string.**
+
+  Added two new functions ``rte_get_rx_ol_flag_list()`` and
+  ``rte_get_tx_ol_flag_list()`` to dump offload flags as a string.
+
 Resolved Issues
 ---

diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 04f9ed3..4e1fdd1 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -319,6 +319,54 @@ const char *rte_get_rx_ol_flag_name(uint64_t mask)
}
 }

+struct flag_mask {
+   uint64_t flag;
+   uint64_t mask;
+   const char *default_name;
+};
+
+/* write the list of rx ol flags in buffer buf */
+int
+rte_get_rx_ol_flag_list(uint64_t mask, char *buf, size_t buflen)
+{
+   const struct flag_mask rx_flags[] = {
+   { PKT_RX_VLAN_PKT, PKT_RX_VLAN_PKT, NULL },
+   { PKT_RX_RSS_HASH, PKT_RX_RSS_HASH, NULL },
+   { PKT_RX_FDIR, PKT_RX_FDIR, NULL },
+   { PKT_RX_L4_CKSUM_BAD, PKT_RX_L4_CKSUM_BAD, NULL },
+   { PKT_RX_IP_CKSUM_BAD, PKT_RX_IP_CKSUM_BAD, NULL },
+   { PKT_RX_EIP_CKSUM_BAD, PKT_RX_EIP_CKSUM_BAD, NULL },
+   { PKT_RX_VLAN_STRIPPED, PKT_RX_VLAN_STRIPPED, NULL },
+   { PKT_RX_IEEE1588_PTP, PKT_RX_IEEE1588_PTP, NULL },
+   { PKT_RX_IEEE1588_TMST, PKT_RX_IEEE1588_TMST, NULL },
+   { PKT_RX_QINQ_STRIPPED, PKT_RX_QINQ_STRIPPED, NULL },
+   };
+   const char *name;
+   unsigned int i;
+   int ret;
+
+   if (buflen == 0)
+   return -1;
+
+   buf[0] = '\0';
+   for (i = 0; i < RTE_DIM(rx_flags); i++) {
+   if ((mask & rx_flags[i].mask) != rx_flags[i].flag)
+   continue;
+   name = rte_get_rx_ol_flag_name(rx_flags[i].flag);
+   if (name == NULL)
+   name = rx_flags[i].default_name;
+   ret = snprintf(buf, buflen, "%s ", name);
+   if (ret < 0)
+   return -1;
+   if ((size_t)ret >= buflen)
+   return -1;
+   buf += ret;
+   buflen -= ret;
+   }
+
+   return 0;
+}
+
 /*
  * Get the name of a TX offload flag. Must be kept synchronized with flag
  * definitions in rte_mbuf.h.
@@ -345,3 +393,56 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask)
default: return NULL;
}
 }
+
+/* write the list of tx ol flags in buffer buf */
+int
+rte_get_tx_ol_flag_list(uint64_t mask, char *buf, size_t buflen)
+{
+   const struct flag_mask tx_flags[] = {
+   { PKT_TX_VLAN_PKT, PKT_TX_VLAN_PKT, NULL },
+   { PKT_TX_IP_CKSUM, PKT_TX_IP_CKSUM, NULL },
+   { PKT_TX_TCP_CKSUM, PKT_TX_L4_MASK, NULL },
+   { PKT_TX_SCTP_CKSUM, PKT_TX_L4_MASK, NULL },
+   { PKT_TX_UDP_CKSUM, PKT_TX_L4_MASK, NULL },
+   { PKT_TX_L4_NO_CKSUM, PKT_TX_L4_MASK, "PKT_TX_L4_NO_CKSUM" },
+   { PKT_TX_IEEE1588_TMST, PKT_TX_IEEE1588_TMST, NULL },
+   { PKT_TX_TCP_SEG, PKT_TX_TCP_SEG, NULL },
+   { PKT_TX_IPV4, PKT_TX_IPV4, NULL },
+   { PKT_TX_IPV6, PKT_TX_IPV6, NULL },
+   { PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IP_CKSUM, NULL },
+   { PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV4, NULL },
+   { PKT_TX_OUTER_IPV6, PKT_TX_OUTER_IPV6, NULL },
+   { PKT_TX_TUNNEL_VXLAN, PKT_TX_TUNNEL_MASK,
+ "PKT_TX_TUNNEL_NONE" },
+   { PKT_TX_TUNNEL_GRE, PKT_TX_TUNNEL_MASK,
+ "PKT_TX_TUNNEL_NONE" },
+   { PKT_TX_TUNNEL_IPIP, PKT_TX_TUNNEL_MASK,
+ "PKT_TX_TUNNEL_NONE" },
+   { PKT_TX_TUNNEL_GENEVE, PKT_TX_TUNNEL_MASK,
+ "PKT_TX_TUNNEL_NONE" },
+   };
+   const char *name;
+   unsigned int i;
+   int ret;
+
+   if 

[dpdk-dev] [PATCH v6 0/8] Misc enhancements in testpmd

[Olivier Matz]

This patchset introduces several enhancements or minor fixes
in testpmd. It is targetted for v16.11, and applies on top of
software ptype v2 patchset [1].

These patches are useful to validate the virtio offload
patchset [2] (to be rebased).

[1] http://dpdk.org/ml/archives/dev/2016-August/045876.html
[2] http://dpdk.org/ml/archives/dev/2016-July/044404.html

v5 -> v6:
- rebase against head

v4 -> v5:
- fix headline lowercase for "Rx"
- fix typo in API comment: "ouput" -> "output"

v3 -> v4:
- fix typo in documentation

v2 -> v3:
- move return type on a separate line in function definitions
- add documentation for the new --enable-lro option

v1 -> v2:
- rebase on top of sw ptype v2 patch

Olivier Matz (8):
  mbuf: add function to dump ol flag list
  app/testpmd: use new function to dump offload flags
  app/testpmd: dump Rx flags in csum engine
  app/testpmd: add option to enable lro
  app/testpmd: do not change ip addrs in csum engine
  app/testpmd: display Rx port in csum engine
  app/testpmd: don't use tso if packet is too small
  app/testpmd: hide segsize when unrelevant in csum engine

 app/test-pmd/csumonly.c| 119 +
 app/test-pmd/parameters.c  |   4 ++
 app/test-pmd/rxonly.c  |  15 +
 doc/guides/rel_notes/release_16_11.rst |   5 ++
 doc/guides/testpmd_app_ug/run_app.rst  |   4 ++
 lib/librte_mbuf/rte_mbuf.c | 101 
 lib/librte_mbuf/rte_mbuf.h |  28 
 lib/librte_mbuf/rte_mbuf_version.map   |   2 +
 8 files changed, 192 insertions(+), 86 deletions(-)

-- 
2.8.1

[dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new API's

[Thomas Monjalon]

2016-10-12 15:27, Iremonger, Bernard:
> Hi Thomas,
> 
> 
> 
> > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new
> > API's
> > 
> > 2016-10-12 16:03, Bernard Iremonger:
> > > --- a/app/test-pmd/Makefile
> > > +++ b/app/test-pmd/Makefile
> > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c  SRCS-y += icmpecho.c
> > >  SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > >
> > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe endif
> > > +
> > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > +LDLIBS += -lrte_pmd_ixgbe
> > > +endif
> > > +endif
> > 
> > Sorry if I miss something, but I thought it was enough to do:
> > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> 
> No unfortunately not, the above line does not work for all scenarios .
> 
> There are 4 scenarios as follows:
> 
> CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with CONFIG_RTE_BUILD_SHARED_LIB=n
> 
> CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with CONFIG_RTE_BUILD_SHARED_LIB=y
> 
> CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with CONFIG_RTE_BUILD_SHARED_LIB=y
> 
> CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with CONFIG_RTE_BUILD_SHARED_LIB=n
> 
> I have been doing quite a bit of building today to get it to work in all 4 
> scenarios.

I have a doubt about the tests because LDLIBS-y does not exist.
There is _LDLIBS-y and LDLIBS.
But in the static case, you wrote:
LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe endif
Please could you check?

[dpdk-dev] [PATCH 1/2] bnx2x: fix maximum PF queues

[Bruce Richardson]

On Wed, Oct 05, 2016 at 10:36:36PM -0700, Rasesh Mody wrote:
> Fix the max number of PF rx/tx queues. Set the value based
> on BNX2X_MAX_RSS_COUNT() rather than hard coding it to 128.
> 
> Fixes: 540a211 ("bnx2x: driver core")
> 
> Signed-off-by: Rasesh Mody 
> ---

Series applied to dpdk-next-net/rel_16_11

/Bruce

[dpdk-dev] [PATCH v3 0/5] vhost: optimize enqueue

[Thomas Monjalon]

Sorry guys, you lost me in the discussion.

Is there some regression only on ARM?
Does it need some work specifically on memcpy for ARM,
or vhost for ARM?
Who can work on ARM optimization?

More comments below.

2016-10-12 12:22, Wang, Zhihong:
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> > > It's an ARM server.
> > >
> > > >> >  3. How many percentage of drop are you seeing?
> > > The testing result:
> > > size (bytes) improvement (%)
> > > 64   3.92
> > > 128 11.51
> > > 256  24.16
> > > 512  -13.79
> > > 1024-22.51
> > > 1500-12.22
> > > A correction is that performance is dropping if byte size is larger than 
> > > 512.
> > 
> > I have thought of this twice. Unfortunately, I think I may need NACK this
> > series.
> > 
> > Merging two code path into one is really good: as you stated, it improves
> > the maintainability. But only if we see no performance regression on both
> > path after the refactor. Unfortunately, that's not the case here: it hurts
> > the performance for one code path (non-mrg Rx).

+1

> > That makes me think we may should not do the code path merge at all. I think
> > that also aligns with what you have said before (internally): we could do 
> > the
> > merge if it gives comparable performance before and after that.
> > 
> > Besides that, I don't quite like the way you did in patch 2 (rewrite 
> > enqueue):
> > you made a lot of changes in one patch. That means if something wrong
> > happened,
> > it is hard to narrow down which change introduces that regression. Badly,
> > that's exactly what we met here. Weeks have been passed, I see no progress.

+1, it is important to have simple patches making changes step by step.

> > That's the reason we like the idea of "one patch only does one thing, an
> > atomic thing".
> 
> 
> Yuanhan, folks,
> 
> Thanks for the analysis. I disagree here though.
> 
> I analyze, develop, benchmark on x86 platforms, where this patch
> works great.
> 
> I've been trying to analyze on ARM too but it takes time and I've
> had a schedule. Also since the ARM perf issue comes when it's
> v6 already, I might not be able to make it in time. However
> that's what I have to do for this patch to be merged in this
> or the next release.
> 
> In the meantime, may I suggest we consider the possibility to
> have dedicated codes for **perf critical paths** for different
> kinds of architecture?

Yes that's what we do in several parts of DPDK.

> It can be hard for a person to have both the knowledge and the
> development environment for multiple archs at the same time.

Yes we do not expect you work on ARM.
So if nobody work on the ARM issue, you could make 2 code paths
in order to allow your optimization for x86 only.
But that's not the preferred way.
And you must split your rework to better identify which part is
a regression on ARM.

> Moreover, different optimization techniques might be required for
> different archs, so it's hard and unnecessary to make a function
> works for all archs, sometimes it's just not the right thing to do.

Yes sometimes. Please help us to be convinced for this case.

> > So I will apply the first patch (it's a bug fixing patch) and ask you to
> > refactor the rest, without the code path merge.
> > 
> > I think we could still have a good maintainability code base if we introduce
> > more common helper functions that can be used on both Rx path, or even on
> > Tx path (such as update_used_ring, or shadow_used_ring).

Yes it is a good step.
And the code path merge could be reconsidered later.

> > It's a bit late for too many changes for v16.11. I think you could just
> > grab patch 6 (vhost: optimize cache access) to the old mrg-Rx code path,
> > if that also helps the performance? Let us handle the left in next release,
> > such as shadow used ring.

Thank you

[dpdk-dev] [dpdk-stable] [PATCH v2 1/4] net/ena: improve safety of string handling in ena_config_host_info

[Ferruh Yigit]

On 9/29/2016 6:39 PM, John W. Linville wrote:
> Use sizeof dest rather than sizeof src for limiting copy length,
> and replace strncpy with snprintf to ensure NULL termination.
> 
> Coverity issue: 127795
> Fixes: 372c1af5ed8f ("net/ena: add dedicated memory area for extra device 
> info")
> 
> Signed-off-by: John W. Linville 
> ---

Acked-by: Ferruh Yigit 

[dpdk-dev] [PATCH 4/4] net/enic: extend fdir support for 1300 series adapters

[Bruce Richardson]

On Tue, Oct 11, 2016 at 09:25:45AM +, John Daley (johndale) wrote:
> 
> 
> > -Original Message-
> > From: Ferruh Yigit [mailto:ferruh.yigit at intel.com]
> > Sent: Tuesday, October 11, 2016 2:22 AM
> > To: John Daley (johndale) ;
> > bruce.richardson at intel.com
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 4/4] net/enic: extend fdir support for 1300
> > series adapters
> > 
> > Hi John,
> > 
> > On 9/29/2016 9:56 PM, John Daley wrote:
> > > 1300 series Cisco adapter firmware version 2.0(13) for UCS C-series
> > > servers and 3.1(2) for blade servers supports more filtering
> > > capabilities. The feature can be enabled via Cisco CIMC or USCM with
> > > the 'advanced filters' radio button. When enabled, the these
> > > additional flow director modes are available:
> > >   RTE_ETH_FLOW_NONFRAG_IPV4_OTHER
> > >   RTE_ETH_FLOW_NONFRAG_IPV4_SCTP
> > >   RTE_ETH_FLOW_NONFRAG_IPV6_UDP
> > >   RTE_ETH_FLOW_NONFRAG_IPV6_TCP
> > >   RTE_ETH_FLOW_NONFRAG_IPV6_SCTP
> > >   RTE_ETH_FLOW_NONFRAG_IPV6_OTHER
> > >
> > > Changes:
> > > - Detect and set an 'advanced filters' flag dependent on the adapter
> > >   capability.
> > > - Implement RTE_ETH_FILTER_INFO filter op to return the flow types
> > >   available dependent on whether advanced filters are enabled.
> > > - Use a function pointer to select how filters are added to the adapter:
> > >   copy_fltr_v1() for older firmware/adapters or copy_fltr_v2() for
> > >   adapters which support advanced filters.
> > > - Apply fdir global masks to filters when in advanced filter mode.
> > > - Update documentation.
> > >
> > > Signed-off-by: John Daley 
> > > Reviewed-by: Nelson Escobar 
> > > ---
> > 
> > <...>
> > 
> > >
> > > +void enic_fdir_info_get(struct enic *enic, struct rte_eth_fdir_info
> > > +*info) {
> > > + info->mode = enic->fdir.modes;
> > 
> > This cause a icc build error:
> > .../drivers/net/enic/enic_clsf.c(77):
> > error #188: enumerated type mixed with another type
> > info->mode = enic->fdir.modes;
> >^
> > 
> > Just casting to the enum fixes it:
> > +   info->mode = (enum rte_fdir_mode)enic->fdir.modes;
> > 
> > Since the modification is trivial, if you agree with the change, we can 
> > apply it
> > without needing a new version of the patch?
> > 
> 
> Looks good, thank you and sorry for the trouble.
> -john
> 
Series applied to dpdk-next-net/rel_16_11

/Bruce

[dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new API's

[Iremonger, Bernard]

Hi Thomas,




> > > > > > > > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add
> > > > > > > > tests for new API's
> > > > > > > >
> > > > > > > > 2016-10-12 16:03, Bernard Iremonger:
> > > > > > > > > --- a/app/test-pmd/Makefile
> > > > > > > > > +++ b/app/test-pmd/Makefile
> > > > > > > > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c  SRCS-y +=
> > > > > > > > > icmpecho.c
> > > > > > > > >  SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > > > > > > > >
> > > > > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > > > > > > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -
> > lrte_pmd_ixgbe
> > > > > > endif
> > > > > > > > > +
> > > > > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > > > > > > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > > > > > > > +LDLIBS += -lrte_pmd_ixgbe endif endif
> > > > > > > >
> > > > > > > > Sorry if I miss something, but I thought it was enough to do:
> > > > > > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -
> lrte_pmd_ixgbe
> > > > > > >
> > > > > > > No unfortunately not, the above line does not work for all
> > > > > > > scenarios
> > .
> > > > > > >
> > > > > > > There are 4 scenarios as follows:
> > > > > > >
> > > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with
> > > > > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > > > >
> > > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with
> > > > > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > > > > >
> > > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with
> > > > > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > > > > >
> > > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with
> > > > > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > > > >
> > > > > > > I have been doing quite a bit of building today to get it to
> > > > > > > work in all 4
> > > > > > scenarios.
> > > > > >
> > > > > > I have a doubt about the tests because LDLIBS-y does not exist.
> > > > > > There is _LDLIBS-y and LDLIBS.
> > > > > > But in the static case, you wrote:
> > > > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -
> lrte_pmd_ixgbe
> > > > endif
> > > > > > Please could you check?
> > > > >
> > > > > LDLIBS-y exists in some of the scenarios but not all.
> > > >
> > > > I think I'm something obvious.
> > > > Please could you point the line where LDLIBS-y is used?
> > >
> > > Line 62  of latest Makefile;
> > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> >
> > No, I mean where do you find LDLIBS- (without underscore) before your
> > patch?
> > git grep '\ 
> 
> Before my patch LDLIBS was not used in the testpmd Makefile.
> 
> The linking was done in rte.app.mk, this uses LDLIBS and _LDLIBS-y.
> I don't see LDLIBS-y either.
> 
> Regards,
> 
> Bernard.
> 

_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe

Works in the 4 scenarios, I will send a v9

Regards,

Bernard.

[dpdk-dev] [PATCH] net/enic: update enic guide and add warning for invalid conf

[Bruce Richardson]

On Mon, Oct 10, 2016 at 03:16:09PM +0100, Mcnamara, John wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John Daley
> > Sent: Thursday, September 29, 2016 9:55 PM
> > To: Richardson, Bruce 
> > Cc: dev at dpdk.org; Nelson Escobar 
> > Subject: [dpdk-dev] [PATCH] net/enic: update enic guide and add warning
> > for invalid conf
> > 
> > From: Nelson Escobar 
> > 
> > Update the enic guide to better explain how to setup vNIC parameters on
> > the Cisco VIC since the introduction of rx scatter and print an error
> > message for the case of having 1 RQ configured in the vNIC.
> > 
> > Signed-off-by: Nelson Escobar 
> 
> Hi,
> 
> It would be better in the RST documentation to use  backticks to
> designate function and variable names as fixed width. Also, the documentation
> convention is to use Rx/Tx. However, these are minor so the patch is okay as
> it is.
> 
> Acked-by: John McNamara 
> 
Applied to dpdk-next-net/rel_16_11 as "document how to configure vNIC 
parameters"
so as to make it clear that this is one logical change, rather than two - which
would be implied by the use of "and" in the title.

/Bruce

[dpdk-dev] [PATCH] net/mlx: align drivers to latest naming convention

[Bruce Richardson]

On Fri, Oct 07, 2016 at 03:24:27PM +0200, Adrien Mazarguil wrote:
> On Fri, Oct 07, 2016 at 03:04:13PM +0200, David Marchand wrote:
> > Fixes: 2f45703c17ac ("drivers: make driver names consistent")
> > 
> > Signed-off-by: David Marchand 

> Acked-by: Adrien Mazarguil 
> 
Applied to dpdk-next-net/rel_16_11

/Bruce

[dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new API's

[Thomas Monjalon]

2016-10-12 16:03, Bernard Iremonger:
> --- a/app/test-pmd/Makefile
> +++ b/app/test-pmd/Makefile
> @@ -58,6 +58,17 @@ SRCS-y += csumonly.c
>  SRCS-y += icmpecho.c
>  SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
>  
> +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> +endif
> +
> +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> +LDLIBS += -lrte_pmd_ixgbe
> +endif
> +endif

Sorry if I miss something, but I thought it was enough to do:
LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe

[dpdk-dev] [PATCH] hash: fix incorrect bucket size usage

[Thomas Monjalon]

2016-10-12 02:26, Pablo de Lara:
> Multiwriter insert function was using a fixed value for
> the bucket size, instead of using the
> RTE_HASH_BUCKET_ENTRIES macro, which value was changed
> recently (making it inconsistent in this case).
> 
> Fixes: be856325cba3 ("hash: add scalable multi-writer insertion with Intel 
> TSX")
> 
> Signed-off-by: Pablo de Lara 

Applied, thanks

[dpdk-dev] [PATCH v2] hash: fix unlimited cuckoo path

[Thomas Monjalon]

2016-10-12 01:50, Pablo de Lara:
> When trying to insert a new entry, if its target bucket is full,
> the alternative location (bucket) of one of the entries is checked,
> to try to find an empty slot, with make_space_bucket.
> This function is called every time a new bucket is checked, recursively.
> To avoid having a very long insert operation (and to avoid filling up
> the stack), a limit in the number of pushes is introduced.
> 
> Fixes: 48a399119619 ("hash: replace with cuckoo hash implementation")
> 
> Signed-off-by: Pablo de Lara 

Applied, thanks

[dpdk-dev] [PATCH v2 00/15] Add support for secondary queue set in nicvf thunderx driver

[Bruce Richardson]

On Fri, Sep 30, 2016 at 02:05:39PM +0200, Kamil Rytarowski wrote:
> This series of patches adds support for secondary queue set in nicvf thunderx
> driver
> 
> There are two types of VFs:
>  - Primary VF
>  - Secondary VF
> 
> Each port consist of a primary VF and n secondary VF(s). Each VF provides 8
> Tx/Rx queues to a port. In case port is configured to use more than 8 queues,
> then it requires one (or more) secondary VF. Each secondary VF adds additional
> 8 queues to the queue set.
> 
> During PMD driver initialization, the primary VF's are enumerated by checking 
> the
> specific flag (see READY message). They are at the beginning of  VF list (the 
> remain
> ones are secondary VF's).
> 
> The primary VFs are used as master queue sets. Secondary VFs provide
> additional queue sets for primary ones. If a port is configured for more then
> 8 queues then it will request for additional queues from secondary VFs.
> 
> Secondary VFs cannot be shared between primary VFs.
> 
> Primary VFs are present on the tail of the 'Network devices using kernel
> driver' list, secondary VFs are on the remaining tail of the list.
> 
> The VNIC driver in the multiqueue setup works differently than other drivers
> like `ixgbe`. We need to bind separately each specific queue set device with
> the ``tools/dpdk-devbind.py`` utility.
> 
> Depending on the hardware used, the kernel driver sets a threshold ``vf_id``.
> VFs that try to attach with an id below or equal to this boundary are
> considered primary VFs. VFs that try to attach with an id above this boundary
> are considered secondary VFs.
> 
> This patchset also contains other cleanups and improvements like fixing
> erroneous checksum calculation and preparing the thunderx driver for the multi
> queue set feature support.
> 
> 
> These changes base on the following pending patches:
> 
> [dpdk-dev,1/3] net/thunderx: remove generic passx references from the driver
> http://dpdk.org/dev/patchwork/patch/14963/
> 
> [dpdk-dev,2/3] net/thunderx: introduce cqe_rx2 HW capability flag
> http://dpdk.org/dev/patchwork/patch/14964/
> 
> [dpdk-dev,3/3] net/thunderx: add 81xx SoC support
> http://dpdk.org/dev/patchwork/patch/14965/
> 
> Kamil Rytarowski (15):
>   net/thunderx: cleanup the driver before adding new features
>   net/thunderx: correct transmit checksum handling
>   net/thunderx/base: add family of functions to store qsets
>   net/thunderx/base: add secondary queue set support
>   net/thunderx: add family of functions to store DPDK qsets
>   net/thunderx: add secondary queue set in interrupt functions
>   net/thunderx: remove problematic private_data->eth_dev link
>   net/thunderx: add helper utils for secondary qset support
>   net/thunderx: add secondary qset support in dev stop/close
>   net/thunderx: add secondary qset support in device start
>   net/thunderx: add secondary qset support in device configure
>   net/thunderx: add final bits for secondary queue support
>   net/thunderx: document secondary queue set support
>   ethdev: Support VFs on the different PCI domains
>   net/thunderx: Bump driver version to 2.0
> 
Series applied to dpdk-next-net/rel_16_11, with the exception of patch 14 which
has been resubmitted as a separate ethdev patch: 
http://dpdk.org/dev/patchwork/patch/16480/

/Bruce

[dpdk-dev] [PATCH v4 1/2] i40e: Add packet_type metadata in the i40e vPMD

[Bruce Richardson]

On Thu, Oct 06, 2016 at 03:28:39PM +, Chen, Jing D wrote:
> 
> > -Original Message-
> > From: Shaw, Jeffrey B
> > Sent: Wednesday, October 5, 2016 11:38 PM
> > To: dev at dpdk.org
> > Cc: Zhang, Helin ; Wu, Jingjing
> > ; damarion at cisco.com; Zhang, Qi Z
> > ; Chen, Jing D 
> > Subject: [PATCH v4 1/2] i40e: Add packet_type metadata in the i40e vPMD
> > 
> > From: Damjan Marion 
> > 
> > The ptype is decoded from the rx descriptor and stored in the packet type
> > field in the mbuf using the same function as the non-vector driver.
> > 
> > Signed-off-by: Damjan Marion 
> > Signed-off-by: Jeff Shaw 
> > Acked-by: Qi Zhang 
> > ---
> > 
> > Changes in v2:
> >  - Add missing reference to i40e_recv_scattered_pkts_vec() when
> >querying supported packet types.
> > 
> > Changes in v3:
> >  - None. (Please ignore this version).
> > 
> > Changes in v4:
> >  - Fix rss/fdir status mask and shift to get accurate Flow Director Filter
> >Match (FLM) indication.
> > 
> >  drivers/net/i40e/i40e_rxtx.c | 567 
> > +--
> >  drivers/net/i40e/i40e_rxtx.h | 563
> > ++
> >  drivers/net/i40e/i40e_rxtx_vec.c |  16 ++
> >  3 files changed, 582 insertions(+), 564 deletions(-)
> Acked-by : Jing Chen 
> 
Series applied to dpdk-next-net/rel_16_11

/Bruce

[dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new API's

[Iremonger, Bernard]

Hi Thomas,



> > > > > > > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add
> > > > > > > tests for new API's
> > > > > > >
> > > > > > > 2016-10-12 16:03, Bernard Iremonger:
> > > > > > > > --- a/app/test-pmd/Makefile
> > > > > > > > +++ b/app/test-pmd/Makefile
> > > > > > > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c  SRCS-y +=
> > > > > > > > icmpecho.c
> > > > > > > >  SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > > > > > > >
> > > > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > > > > > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -
> lrte_pmd_ixgbe
> > > > > endif
> > > > > > > > +
> > > > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > > > > > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > > > > > > +LDLIBS += -lrte_pmd_ixgbe endif endif
> > > > > > >
> > > > > > > Sorry if I miss something, but I thought it was enough to do:
> > > > > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > > > > >
> > > > > > No unfortunately not, the above line does not work for all scenarios
> .
> > > > > >
> > > > > > There are 4 scenarios as follows:
> > > > > >
> > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with
> > > > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > > >
> > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with
> > > > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > > > >
> > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with
> > > > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > > > >
> > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with
> > > > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > > >
> > > > > > I have been doing quite a bit of building today to get it to
> > > > > > work in all 4
> > > > > scenarios.
> > > > >
> > > > > I have a doubt about the tests because LDLIBS-y does not exist.
> > > > > There is _LDLIBS-y and LDLIBS.
> > > > > But in the static case, you wrote:
> > > > >   LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > > endif
> > > > > Please could you check?
> > > >
> > > > LDLIBS-y exists in some of the scenarios but not all.
> > >
> > > I think I'm something obvious.
> > > Please could you point the line where LDLIBS-y is used?
> >
> > Line 62  of latest Makefile;
> > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> 
> No, I mean where do you find LDLIBS- (without underscore) before your
> patch?
> git grep '\

[dpdk-dev] [PATCH v3] test_cryptodev_perf: IV and digest should be stored at a DMAeble address

[akhil.go...@nxp.com]

From: Akhil Goyal 

For physical crypto devices, IV and digest are processed by the crypto
device which need the contents to be written on some DMA able address.

So in order to do that, IV and digest are accomodated in the packet.

Signed-off-by: Akhil Goyal 
v2: patch rebased
v3: fix broken compilation
---
 app/test/test_cryptodev_perf.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/app/test/test_cryptodev_perf.c b/app/test/test_cryptodev_perf.c
index 4aee9af..d498195 100644
--- a/app/test/test_cryptodev_perf.c
+++ b/app/test/test_cryptodev_perf.c
@@ -2722,9 +2722,12 @@ test_perf_set_crypto_op_aes(struct rte_crypto_op *op, 
struct rte_mbuf *m,
op->sym->auth.aad.length = AES_CIPHER_IV_LENGTH;

/* Cipher Parameters */
-   op->sym->cipher.iv.data = aes_iv;
+   op->sym->cipher.iv.data = (uint8_t *)m->buf_addr + m->data_off;
+   op->sym->cipher.iv.phys_addr = rte_pktmbuf_mtophys(m);
op->sym->cipher.iv.length = AES_CIPHER_IV_LENGTH;

+   rte_memcpy(op->sym->cipher.iv.data, aes_iv, AES_CIPHER_IV_LENGTH);
+
/* Data lengths/offsets Parameters */
op->sym->auth.data.offset = 0;
op->sym->auth.data.length = data_len;
@@ -2893,7 +2896,9 @@ test_perf_aes_sha(uint8_t dev_id, uint16_t queue_id,
rte_pktmbuf_free(mbufs[k]);
return -1;
}
-
+   /* Make room for Digest and IV in mbuf */
+   rte_pktmbuf_append(mbufs[i], digest_length);
+   rte_pktmbuf_prepend(mbufs[i], AES_CIPHER_IV_LENGTH);
}


-- 
2.9.3

[dpdk-dev] [PATCH 1/2] net/bonding: validate speed after link up

[Bruce Richardson]

On Wed, Oct 05, 2016 at 12:53:00PM +, Iremonger, Bernard wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Eric Kinzie
> > Sent: Thursday, August 4, 2016 7:25 PM
> > To: dev at dpdk.org
> > Cc: Jan Blunck 
> > Subject: [dpdk-dev] [PATCH 1/2] net/bonding: validate speed after link up
> > 
> > It's possible for the bonding driver to mistakenly reject an interface 
> > based in
> > it's, as yet, unnegotiated link speed and duplex.  Always allow the 
> > interface
> > to be added to the bonding interface but require link properties validation 
> > to
> > succeed before slave is activated.
> > 
> > Fixes: 2efb58cbab6e ("bond: new link bonding library")
> > 
> > Signed-off-by: Eric Kinzie 
> 
> Acked-by: Bernard Iremonger 
> 
Series applied to dpdk-next-net/rel_16_11

/Bruce

[dpdk-dev] [PATCH v2] app/testpmd: add support to configure 25G and 50G speeds

[Ajit Khaparde]

Support to configure 25G and 50G speeds is missing from testpmd.
This patch also updates the testpmd user guide accordingly.

Signed-off-by: Ajit Khaparde 
--
v2: shorten lines > 80 character limit
---
 app/test-pmd/cmdline.c  | 16 +++-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  2 +-
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index a1da8b8..b8c7b8b 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -545,7 +545,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"Detach physical or virtual dev by port_id\n\n"

"port config (port_id|all)"
-   " speed (10|100|1000|1|4|10|auto)"
+   " speed 
(10|100|1000|1|25000|4|5|10|auto)"
" duplex (half|full|auto)\n"
"Set speed and duplex for all ports or port_id\n\n"

@@ -1016,8 +1016,12 @@ parse_and_check_speed_duplex(char *speedstr, char 
*duplexstr, uint32_t *speed)
*speed = ETH_LINK_SPEED_1G;
} else if (!strcmp(speedstr, "1")) {
*speed = ETH_LINK_SPEED_10G;
+   } else if (!strcmp(speedstr, "25000")) {
+   *speed = ETH_LINK_SPEED_25G;
} else if (!strcmp(speedstr, "4")) {
*speed = ETH_LINK_SPEED_40G;
+   } else if (!strcmp(speedstr, "5")) {
+   *speed = ETH_LINK_SPEED_50G;
} else if (!strcmp(speedstr, "10")) {
*speed = ETH_LINK_SPEED_100G;
} else if (!strcmp(speedstr, "auto")) {
@@ -1067,7 +1071,7 @@ cmdline_parse_token_string_t cmd_config_speed_all_item1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_all, item1, "speed");
 cmdline_parse_token_string_t cmd_config_speed_all_value1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_all, value1,
-   
"10#100#1000#1#4#10#auto");
+   
"10#100#1000#1#25000#4#5#10#auto");
 cmdline_parse_token_string_t cmd_config_speed_all_item2 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_all, item2, "duplex");
 cmdline_parse_token_string_t cmd_config_speed_all_value2 =
@@ -1077,7 +1081,8 @@ cmdline_parse_token_string_t cmd_config_speed_all_value2 =
 cmdline_parse_inst_t cmd_config_speed_all = {
.f = cmd_config_speed_all_parsed,
.data = NULL,
-   .help_str = "port config all speed 10|100|1000|1|4|10|auto 
duplex "
+   .help_str = "port config all speed "
+   "10|100|1000|1|25000|4|5|10|auto duplex "
"half|full|auto",
.tokens = {
(void *)_config_speed_all_port,
@@ -1141,7 +1146,7 @@ cmdline_parse_token_string_t 
cmd_config_speed_specific_item1 =
"speed");
 cmdline_parse_token_string_t cmd_config_speed_specific_value1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, value1,
-   
"10#100#1000#1#4#10#auto");
+   
"10#100#1000#1#25000#4#5#10#auto");
 cmdline_parse_token_string_t cmd_config_speed_specific_item2 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, item2,
"duplex");
@@ -1152,7 +1157,8 @@ cmdline_parse_token_string_t 
cmd_config_speed_specific_value2 =
 cmdline_parse_inst_t cmd_config_speed_specific = {
.f = cmd_config_speed_specific_parsed,
.data = NULL,
-   .help_str = "port config X speed 10|100|1000|1|4|10|auto 
duplex "
+   .help_str = "port config X speed "
+   "10|100|1000|1|25000|4|5|10|auto duplex "
"half|full|auto",
.tokens = {
(void *)_config_speed_specific_port,
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index f87e0c2..e1eea34 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1167,7 +1167,7 @@ port config - speed

 Set the speed and duplex mode for all ports or a specific port::

-   testpmd> port config (port_id|all) speed 
(10|100|1000|1|4|10|auto) \
+   testpmd> port config (port_id|all) speed 
(10|100|1000|1|25000|4|5|10|auto) \
 duplex (half|full|auto)

 port config - queues/descriptors
-- 
2.8.4 (Apple Git-73)

[dpdk-dev] [PATCH] Revert "bonding: use existing enslaved device queues"

[Ilya Maximets]

On 07.10.2016 05:02, Eric Kinzie wrote:
> On Wed Sep 07 15:28:10 +0300 2016, Ilya Maximets wrote:
>> This reverts commit 5b7bb2bda5519b7800f814df64d4e015282140e5.
>>
>> It is necessary to reconfigure all queues every time because configuration
>> can be changed.
>>
>> For example, if we're reconfiguring bonding device with new memory pool,
>> already configured queues will still use the old one. And if the old
>> mempool be freed, application likely will panic in attempt to use
>> freed mempool.
>>
>> This happens when we use the bonding device with OVS 2.6 while MTU
>> reconfiguration:
>>
>> PANIC in rte_mempool_get_ops():
>> assert "(ops_index >= 0) && (ops_index < RTE_MEMPOOL_MAX_OPS_IDX)" failed
>>
>> Cc: 
>> Signed-off-by: Ilya Maximets 
>> ---
>>  drivers/net/bonding/rte_eth_bond_pmd.c | 10 ++
>>  1 file changed, 2 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c 
>> b/drivers/net/bonding/rte_eth_bond_pmd.c
>> index b20a272..eb5b6d1 100644
>> --- a/drivers/net/bonding/rte_eth_bond_pmd.c
>> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
>> @@ -1305,8 +1305,6 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
>>  struct bond_rx_queue *bd_rx_q;
>>  struct bond_tx_queue *bd_tx_q;
>>  
>> -uint16_t old_nb_tx_queues = slave_eth_dev->data->nb_tx_queues;
>> -uint16_t old_nb_rx_queues = slave_eth_dev->data->nb_rx_queues;
>>  int errval;
>>  uint16_t q_id;
>>  
>> @@ -1347,9 +1345,7 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
>>  }
>>  
>>  /* Setup Rx Queues */
>> -/* Use existing queues, if any */
>> -for (q_id = old_nb_rx_queues;
>> - q_id < bonded_eth_dev->data->nb_rx_queues; q_id++) {
>> +for (q_id = 0; q_id < bonded_eth_dev->data->nb_rx_queues; q_id++) {
>>  bd_rx_q = (struct bond_rx_queue 
>> *)bonded_eth_dev->data->rx_queues[q_id];
>>  
>>  errval = rte_eth_rx_queue_setup(slave_eth_dev->data->port_id, 
>> q_id,
>> @@ -1365,9 +1361,7 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
>>  }
>>  
>>  /* Setup Tx Queues */
>> -/* Use existing queues, if any */
>> -for (q_id = old_nb_tx_queues;
>> - q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) {
>> +for (q_id = 0; q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) {
>>  bd_tx_q = (struct bond_tx_queue 
>> *)bonded_eth_dev->data->tx_queues[q_id];
>>  
>>  errval = rte_eth_tx_queue_setup(slave_eth_dev->data->port_id, 
>> q_id,
>> -- 
>> 2.7.4
>>
> 
> NAK
> 
> There are still some users of this code.  Let's give them a chance to
> comment before removing it.

Hi Eric,

Are these users in CC-list? If not, could you, please, add them?
This patch awaits in mail-list already more than a month. I think, it's enough
time period for all who wants to say something. Patch fixes a real bug that
prevent using of DPDK bonding in all applications that reconfigures devices
in runtime including OVS.

Best regards, Ilya Maximets.

[dpdk-dev] [PATCH] Revert "bonding: use existing enslaved device queues"

[Bruce Richardson]

On Wed, Oct 12, 2016 at 04:24:54PM +0300, Ilya Maximets wrote:
> On 07.10.2016 05:02, Eric Kinzie wrote:
> > On Wed Sep 07 15:28:10 +0300 2016, Ilya Maximets wrote:
> >> This reverts commit 5b7bb2bda5519b7800f814df64d4e015282140e5.
> >>
> >> It is necessary to reconfigure all queues every time because configuration
> >> can be changed.
> >>
> >> For example, if we're reconfiguring bonding device with new memory pool,
> >> already configured queues will still use the old one. And if the old
> >> mempool be freed, application likely will panic in attempt to use
> >> freed mempool.
> >>
> >> This happens when we use the bonding device with OVS 2.6 while MTU
> >> reconfiguration:
> >>
> >> PANIC in rte_mempool_get_ops():
> >> assert "(ops_index >= 0) && (ops_index < RTE_MEMPOOL_MAX_OPS_IDX)" failed
> >>
> >> Cc: 
> >> Signed-off-by: Ilya Maximets 
> >> ---
> >>  drivers/net/bonding/rte_eth_bond_pmd.c | 10 ++
> >>  1 file changed, 2 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c 
> >> b/drivers/net/bonding/rte_eth_bond_pmd.c
> >> index b20a272..eb5b6d1 100644
> >> --- a/drivers/net/bonding/rte_eth_bond_pmd.c
> >> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
> >> @@ -1305,8 +1305,6 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
> >>struct bond_rx_queue *bd_rx_q;
> >>struct bond_tx_queue *bd_tx_q;
> >>  
> >> -  uint16_t old_nb_tx_queues = slave_eth_dev->data->nb_tx_queues;
> >> -  uint16_t old_nb_rx_queues = slave_eth_dev->data->nb_rx_queues;
> >>int errval;
> >>uint16_t q_id;
> >>  
> >> @@ -1347,9 +1345,7 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
> >>}
> >>  
> >>/* Setup Rx Queues */
> >> -  /* Use existing queues, if any */
> >> -  for (q_id = old_nb_rx_queues;
> >> -   q_id < bonded_eth_dev->data->nb_rx_queues; q_id++) {
> >> +  for (q_id = 0; q_id < bonded_eth_dev->data->nb_rx_queues; q_id++) {
> >>bd_rx_q = (struct bond_rx_queue 
> >> *)bonded_eth_dev->data->rx_queues[q_id];
> >>  
> >>errval = rte_eth_rx_queue_setup(slave_eth_dev->data->port_id, 
> >> q_id,
> >> @@ -1365,9 +1361,7 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
> >>}
> >>  
> >>/* Setup Tx Queues */
> >> -  /* Use existing queues, if any */
> >> -  for (q_id = old_nb_tx_queues;
> >> -   q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) {
> >> +  for (q_id = 0; q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) {
> >>bd_tx_q = (struct bond_tx_queue 
> >> *)bonded_eth_dev->data->tx_queues[q_id];
> >>  
> >>errval = rte_eth_tx_queue_setup(slave_eth_dev->data->port_id, 
> >> q_id,
> >> -- 
> >> 2.7.4
> >>
> > 
> > NAK
> > 
> > There are still some users of this code.  Let's give them a chance to
> > comment before removing it.
> 
> Hi Eric,
> 
> Are these users in CC-list? If not, could you, please, add them?
> This patch awaits in mail-list already more than a month. I think, it's enough
> time period for all who wants to say something. Patch fixes a real bug that
> prevent using of DPDK bonding in all applications that reconfigures devices
> in runtime including OVS.
> 
Agreed.

Eric, does reverting this patch cause you problems directly, or is your concern
just with regards to potential impact to others?

Thanks,
/Bruce

[dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new API's

[Iremonger, Bernard]

Hi Thomas,


> > > > > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests
> > > > > for new API's
> > > > >
> > > > > 2016-10-12 16:03, Bernard Iremonger:
> > > > > > --- a/app/test-pmd/Makefile
> > > > > > +++ b/app/test-pmd/Makefile
> > > > > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c  SRCS-y += icmpecho.c
> > > > > >  SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > > > > >
> > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > > > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > > endif
> > > > > > +
> > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > > > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > > > > +LDLIBS += -lrte_pmd_ixgbe
> > > > > > +endif
> > > > > > +endif
> > > > >
> > > > > Sorry if I miss something, but I thought it was enough to do:
> > > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > > >
> > > > No unfortunately not, the above line does not work for all scenarios .
> > > >
> > > > There are 4 scenarios as follows:
> > > >
> > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with
> > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > >
> > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with
> > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > >
> > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with
> > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > >
> > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with
> > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > >
> > > > I have been doing quite a bit of building today to get it to work
> > > > in all 4
> > > scenarios.
> > >
> > > I have a doubt about the tests because LDLIBS-y does not exist.
> > > There is _LDLIBS-y and LDLIBS.
> > > But in the static case, you wrote:
> > >   LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> endif
> > > Please could you check?
> >
> > LDLIBS-y exists in some of the scenarios but not all.
> 
> I think I'm something obvious.
> Please could you point the line where LDLIBS-y is used?

Line 62  of latest Makefile;
LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe

LDLIBS-y does not exist when CONFIG_RTE_BUILD_SHARED_LIB=y


> > Do you want me to check the four scenarios  with just the line below.
> >
> > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> 
> Let's check the theory first :)

Ok

Regards,

Bernard.

[dpdk-dev] [PATCH v3] mk: gcc -march support for intel processors code names

[Thomas Monjalon]

2016-10-12 13:38, Pattan, Reshma:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > 2016-10-10 22:33, Reshma Pattan:
> > > The GCC 4.9 -march option supports the intel code names for
> > > processors, for example -march=silvermont, -march=broadwell.
> > > The RTE_MACHINE config flag can be used to pass code name to the
> > > compiler as -march flag.
> > >
> > > Signed-off-by: Reshma Pattan 
> > 
> > Applied, thanks
> > 
> > How the -march=broadwell option will work with icc and clang?
> 
> Clang does support broadwell option.
> And I do have Icc version" icc (ICC) 16.0.3 20160415" which doesn't support 
> code names.
> 
> Any other info you are explicitly looking for?

Yes, why are we still supporting ICC?

Clearly this patch does not care about ICC.
Note that it is not an acceptance blocker but it would be interesting
to have some news of ICC from time to time, regarding supported archs
and performance of the generated code.

[dpdk-dev] [PATCH v3] doc: add limitations for i40e PMD

[Bruce Richardson]

On Fri, Sep 30, 2016 at 03:09:53PM +, Mcnamara, John wrote:
> 
> 
> > -Original Message-
> > From: Wu, Jingjing
> > Sent: Friday, September 30, 2016 7:46 AM
> > To: dev at dpdk.org
> > Cc: Wu, Jingjing ; Xing, Beilei
> > ; Mcnamara, John 
> > Subject: [PATCH v3] doc: add limitations for i40e PMD
> > 
> > This patch adds "Limitations or Known issues" section for i40e PMD,
> > including two items:
> > 1. MPLS packet classification on X710/XL710 2. 16 Byte Descriptor cannot
> > be used on DPDK VF 3. Link down with i40e kernel driver after DPDK
> > application exist
> > 
> > Signed-off-by: Jingjing Wu 
> 
> 
> Acked-by: John McNamara 
> 
Applied to dpdk-next-net/rel_16_11

/Bruce

[dpdk-dev] [PATCH v4] net/mlx5: return RSS hash result in mbuf

[Bruce Richardson]

On Wed, Sep 28, 2016 at 02:11:18PM +0200, Nelio Laranjeiro wrote:
> Signed-off-by: Nelio Laranjeiro 
> ---
Applied to dpdk-next-net/rel_16_11

/Bruce

[dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new API's

[Bernard Iremonger]

add test for set vf vlan anti spoof
add test for set vf mac anti spoof
add test for set vf vlan stripq
add test for set vf vlan insert
add test for set tx loopback
add test for set all queues drop enable bit
add test for set vf split drop enable bit
add test for set vf mac address
add new API's to testpmd help command.

add new API's to the testpmd guide

modify Makefile, add library rte_pmd_ixgbe to LDLIBS.

Signed-off-by: Bernard Iremonger 
---
 app/test-pmd/Makefile   |  11 +
 app/test-pmd/cmdline.c  | 699 +++-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  62 ++-
 3 files changed, 768 insertions(+), 4 deletions(-)

diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
index 2a0b5a5..472a016 100644
--- a/app/test-pmd/Makefile
+++ b/app/test-pmd/Makefile
@@ -58,6 +58,17 @@ SRCS-y += csumonly.c
 SRCS-y += icmpecho.c
 SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c

+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
+LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
+endif
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
+LDLIBS += -lrte_pmd_ixgbe
+endif
+endif
+
+
 CFLAGS_cmdline.o := -D_GNU_SOURCE

 # this application needs libraries first
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index a1da8b8..41c7acf 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -87,7 +87,9 @@
 #ifdef RTE_LIBRTE_PMD_BOND
 #include 
 #endif
-
+#ifdef RTE_LIBRTE_IXGBE_PMD
+#include 
+#endif
 #include "testpmd.h"

 static struct cmdline *testpmd_cl;
@@ -260,12 +262,37 @@ static void cmd_help_long_parsed(void *parsed_result,
"set portlist (x[,y]*)\n"
"Set the list of forwarding ports.\n\n"

+#ifdef RTE_LIBRTE_IXGBE_PMD
+   "set tx loopback (port_id) (on|off)\n"
+   "Enable or disable tx loopback.\n\n"
+
+   "set all queues drop (port_id) (on|off)\n"
+   "Set drop enable bit for all queues.\n\n"
+
+   "set vf split drop (port_id) (vf_id) (on|off)\n"
+   "Set split drop enable bit for a VF from the 
PF.\n\n"
+
+   "set vf mac antispoof (port_id) (vf_id) (on|off).\n"
+   "Set MAC antispoof for a VF from the PF.\n\n"
+#endif
+
"vlan set strip (on|off) (port_id)\n"
"Set the VLAN strip on a port.\n\n"

"vlan set stripq (on|off) (port_id,queue_id)\n"
"Set the VLAN strip for a queue on a port.\n\n"

+#ifdef RTE_LIBRTE_IXGBE_PMD
+   "set vf vlan stripq (port_id) (vf_id) (on|off)\n"
+   "Set the VLAN strip for all queues in a pool for a 
VF from the PF.\n\n"
+
+   "set vf vlan insert (port_id) (vf_id) (on|off)\n"
+   "Set VLAN insert for a VF from the PF.\n\n"
+
+   "set vf vlan antispoof (port_id) (vf_id) (on|off)\n"
+   "Set VLAN antispoof for a VF from the PF.\n\n"
+#endif
+
"vlan set filter (on|off) (port_id)\n"
"Set the VLAN filter on a port.\n\n"

@@ -359,6 +386,11 @@ static void cmd_help_long_parsed(void *parsed_result,
"mac_addr add port (port_id) vf (vf_id) (mac_address)\n"
"Add a MAC address for a VF on the port.\n\n"

+#ifdef RTE_LIBRTE_IXGBE_PMD
+   "set vf mac addr (port_id) (vf_id) 
(XX:XX:XX:XX:XX:XX)\n"
+   "Set the MAC address for a VF from the PF.\n\n"
+#endif
+
"set port (port_id) uta (mac_address|all) (on|off)\n"
"Add/Remove a or all unicast hash filter(s)"
"from port X.\n\n"
@@ -10700,6 +10732,661 @@ cmdline_parse_inst_t cmd_config_e_tag_filter_del = {
NULL,
},
 };
+#ifdef RTE_LIBRTE_IXGBE_PMD
+
+/* vf vlan anti spoof configuration */
+
+/* Common result structure for vf vlan anti spoof */
+struct cmd_vf_vlan_anti_spoof_result {
+   cmdline_fixed_string_t set;
+   cmdline_fixed_string_t vf;
+   cmdline_fixed_string_t vlan;
+   cmdline_fixed_string_t antispoof;
+   uint8_t port_id;
+   uint32_t vf_id;
+   cmdline_fixed_string_t on_off;
+};
+
+/* Common CLI fields for vf vlan anti spoof enable disable */
+cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_set =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_vlan_anti_spoof_result,
+set, "set");
+cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_vf =
+   TOKEN_STRING_INITIALIZER
+   (struct cmd_vf_vlan_anti_spoof_result,
+vf, "vf");
+cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_vlan =
+   TOKEN_STRING_INITIALIZER
+   

[dpdk-dev] [PATCH v8 1/2] net/ixgbe: add API's for VF management

[Bernard Iremonger]

Add API's to configure and manage VF's on an Intel 82559 NIC.

add rte_pmd_ixgbe_set_vf_vlan_anti_spoof function.
add rte_pmd_ixgbe_set_vf_mac_anti_spoof function.
add rte_pmd_ixgbe_set_vf_stripq function.

Signed-off-by: Alex Zelezniak 

add rte_pmd_ixgbe_set_vf_vlan_insert function.
add rte_pmd_ixgbe_set_tx_loopback function.
add rte_pmd_ixgbe_set_all_queues_drop function.
add rte_pmd_ixgbe_set_vf_split_drop_en function.
add rte_pmd_ixgbe_set_vf_mac_addr function.

Signed-off-by: Bernard Iremonger 
---
 drivers/net/ixgbe/Makefile  |   4 +-
 drivers/net/ixgbe/ixgbe_ethdev.c| 240 
 drivers/net/ixgbe/rte_pmd_ixgbe.h   | 182 +
 drivers/net/ixgbe/rte_pmd_ixgbe_version.map |  13 ++
 4 files changed, 438 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ixgbe/rte_pmd_ixgbe.h

diff --git a/drivers/net/ixgbe/Makefile b/drivers/net/ixgbe/Makefile
index a6c71f3..94ddc7b 100644
--- a/drivers/net/ixgbe/Makefile
+++ b/drivers/net/ixgbe/Makefile
@@ -1,6 +1,6 @@
 #   BSD LICENSE
 #
-#   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+#   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
 #   All rights reserved.
 #
 #   Redistribution and use in source and binary forms, with or without
@@ -119,6 +119,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_bypass.c
 SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_82599_bypass.c
 endif

+# install this header file
+SYMLINK-$(CONFIG_RTE_LIBRTE_IXGBE_PMD)-include := rte_pmd_ixgbe.h

 # this lib depends upon:
 DEPDIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += lib/librte_eal lib/librte_ether
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 6b3d4fa..35281f9 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -72,6 +72,8 @@
 #include "base/ixgbe_phy.h"
 #include "ixgbe_regs.h"

+#include "rte_pmd_ixgbe.h"
+
 /*
  * High threshold controlling when to start sending XOFF frames. Must be at
  * least 8 bytes less than receive packet buffer size. This value is in units
@@ -4046,6 +4048,35 @@ ixgbe_set_default_mac_addr(struct rte_eth_dev *dev, 
struct ether_addr *addr)
ixgbe_add_rar(dev, addr, 0, 0);
 }

+int
+rte_pmd_ixgbe_set_vf_mac_addr(uint8_t port, uint16_t vf, struct ether_addr 
*mac_addr)
+{
+   struct ixgbe_hw *hw;
+   struct ixgbe_vf_info *vfinfo;
+   int rar_entry;
+   uint8_t *new_mac = (uint8_t *)(mac_addr);
+   struct rte_eth_dev *dev;
+   struct rte_eth_dev_info dev_info;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+   dev = _eth_devices[port];
+   rte_eth_dev_info_get(port, _info);
+
+   if (vf >= dev_info.max_vfs)
+   return -EINVAL;
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   vfinfo = *(IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private));
+   rar_entry = hw->mac.num_rar_entries - (vf + 1);
+
+   if (is_valid_assigned_ether_addr((struct ether_addr *)new_mac)) {
+   rte_memcpy(vfinfo[vf].vf_mac_addresses, new_mac, 
ETHER_ADDR_LEN);
+   return hw->mac.ops.set_rar(hw, rar_entry, new_mac, vf, 
IXGBE_RAH_AV);
+   }
+   return -EINVAL;
+}
+
 static int
 ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
 {
@@ -4639,6 +4670,215 @@ ixgbe_set_pool_vlan_filter(struct rte_eth_dev *dev, 
uint16_t vlan,
return ret;
 }

+int
+rte_pmd_ixgbe_set_vf_vlan_anti_spoof(uint8_t port, uint16_t vf, uint8_t on)
+{
+   struct ixgbe_hw *hw;
+   struct ixgbe_mac_info *mac;
+   struct rte_eth_dev *dev;
+   struct rte_eth_dev_info dev_info;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+   dev = _eth_devices[port];
+   rte_eth_dev_info_get(port, _info);
+
+   if (vf >= dev_info.max_vfs)
+   return -EINVAL;
+
+   if (on > 1)
+   return -EINVAL;
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   mac = >mac;
+
+   mac->ops.set_vlan_anti_spoofing(hw, on, vf);
+
+   return 0;
+}
+
+int
+rte_pmd_ixgbe_set_vf_mac_anti_spoof(uint8_t port, uint16_t vf, uint8_t on)
+{
+   struct ixgbe_hw *hw;
+   struct ixgbe_mac_info *mac;
+   struct rte_eth_dev *dev;
+   struct rte_eth_dev_info dev_info;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+   dev = _eth_devices[port];
+   rte_eth_dev_info_get(port, _info);
+
+   if (vf >= dev_info.max_vfs)
+   return -EINVAL;
+
+   if (on > 1)
+   return -EINVAL;
+
+   hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   mac = >mac;
+   mac->ops.set_mac_anti_spoofing(hw, on, vf);
+
+   return 0;
+}
+
+int
+rte_pmd_ixgbe_set_vf_vlan_insert(uint8_t port, uint16_t vf, uint8_t on)
+{
+   struct ixgbe_hw *hw;
+   uint32_t ctrl;
+   struct rte_eth_dev *dev;
+   struct rte_eth_dev_info dev_info;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port, 

[dpdk-dev] [PATCH v8 0/2] add API's for VF management

[Bernard Iremonger]

This patchset contains new DPDK API's for use
with the Virtual Function Daemon (VFD).

The need to configure and manage VF's on a NIC has grown to the
point where a DPDK based tool, VFD, has been developed to do this.

This patch set adds API extensions to DPDK for VF configuration.

Eight new API's have been added for the Intel 82559 NIC.

Changes have been made to testpmd to facilitate testing of the new API's.
The testpmd documentation has been updated to document the testpmd changes.

Changes in v8:
rebase to latest master branch.
add new API's to testpmd help command.
modify testpmd  Makefile to build with and without ixgbe PMD,
in shared library mode and default mode.

Changes in v7:
rebase to latest master branch.
minor changes to ixgbe PMD following internal review.

Changes in v6:
rebase to latest master branch.
fix ixgbe makefile.
move set_vf_vlan_stripq function from ethdev to ixgbe PMD.
revise testpmd command for set_vf_vlan_stripq.

Changes in v5:
rebase to latest master branch.
remove new API's from eth_dev_ops structure.
add public API's to ixgbe PMD.
revise testpmd commands for new API's

Changes in v4:
The rte_eth_dev_vf_ping API has been dropped as it is a work around for a bug.
The rte_eth_dev_set_vf_vlan_strip API has been renamed to
rte_eth_dev_set_vf_vlan_stripq.

Changes in v3:
rebase to latest master branch.
drop patches for callback functions
revise VF id checks in new librte_ether functions
revise testpmd commands for new API's

Changes in V2:
rebase to latest master branch.
fix compile  error with clang.

Bernard Iremonger (2):
  net/ixgbe: add API's for VF management
  app/test_pmd: add tests for new API's

 app/test-pmd/Makefile   |  11 +
 app/test-pmd/cmdline.c  | 699 +++-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  62 ++-
 drivers/net/ixgbe/Makefile  |   4 +-
 drivers/net/ixgbe/ixgbe_ethdev.c| 240 ++
 drivers/net/ixgbe/rte_pmd_ixgbe.h   | 182 
 drivers/net/ixgbe/rte_pmd_ixgbe_version.map |  13 +
 7 files changed, 1206 insertions(+), 5 deletions(-)
 create mode 100644 drivers/net/ixgbe/rte_pmd_ixgbe.h

-- 
2.9.0

[dpdk-dev] [PATCH v5] drivers/net:new PMD using tun/tap host interface

[Ferruh Yigit]

On 10/11/2016 10:51 PM, Keith Wiles wrote:
> The rte_eth_tap.c PMD creates a device using TUN/TAP interfaces
> on the local host. The PMD allows for DPDK and the host to
> communicate using a raw device interface on the host and in
> the DPDK application. The device created is a Tap device with
> a L2 packet header.
> 
> v5 - merge in changes from list review see related emails.
>  fixed checkpatch issues and many minor edits
> v4 - merge with latest driver changes
> v3 - fix includes by removing ifdef for other type besides Linux.
>  Fix the copyright notice in the Makefile
> v2 - merge all of the patches into one patch.
>  Fix a typo on naming the tap device.
>  Update the maintainers list
> 
> Signed-off-by: Keith Wiles 
> ---

<..>

> diff --git a/config/common_base b/config/common_base
> index f5d2eff..356c631 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -592,3 +592,8 @@ CONFIG_RTE_APP_TEST_RESOURCE_TAR=n
>  CONFIG_RTE_TEST_PMD=y
>  CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
>  CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
> +
> +#
> +# Set TAP PMD to 'n' as it is only supported in Linux for now.

This comments moved to final .config and creates confusion, can we
remove it if you don't have a strong option to keep it?

<..>

> diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
> new file mode 100644
> index 000..eed81ec
> --- /dev/null
> +++ b/doc/guides/nics/tap.rst

<..>

> +.. code-block:: console
> +
> +   The interfaced name can be changed by adding the iface=foo0
> +   e.g. --vdev=eth_tap,iface=foo0 --vdev=eth_tap,iface=foo1, ...

For all file:
%s/eth_tap/net_tap/g, there are multiple lines with this usage


<..>

> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> new file mode 100644
> index 000..c13aa1b
> --- /dev/null
> +++ b/drivers/net/tap/rte_eth_tap.c

<..>

> +
> +struct tap_info {
> + char name[RTE_ETH_NAME_MAX_LEN]; /* Interface name supplied/given */
> + int speed;   /* Speed of interface */
> +};

This struct can go away, it is not used, since with the updated code
rte_pmd_tap_probe() used tap_name and speed as seperate variables
instead of struct.


<..>

> +
> + /* If the name is different that new name as default */
> + if (name && strcmp(name, ifr.ifr_name))
> + snprintf(name, RTE_ETH_NAME_MAX_LEN-1, "%s", ifr.ifr_name);

syntax, space around "-"

<..>

> +
> +static void
> +tap_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *tap_stats)
> +{
> + unsigned i, imax;

checkpatch complain about not using "unsigned int"


<..>

> +static int
> +tap_setup_queue(struct rte_eth_dev *dev,
> + struct pmd_internals *internals,
> + uint16_t qid)
> +{
> + struct rx_queue *rx = >rxq[qid];
> + struct tx_queue *tx = >txq[qid];
> + int fd;
> +
> + if ((fd = rx->fd) < 0)
> + if ((fd = tx->fd) < 0) {
> + RTE_LOG(INFO, PMD, "Add queue to TAP %s for qid %d\n",
> + dev->data->name, qid);
> + if ((fd = tun_alloc(dev->data->name)) < 0) {

checkpatch complain about assignment in the if condition


<..>

> + /* Now get the space available for data in the mbuf */
> + buf_size = (uint16_t) (rte_pktmbuf_data_room_size(mp) -

syntax, no space after cast


<..>

> + /* Create the first Tap device */
> + if ((fd = tun_alloc(tap_name)) < 0) {

checkpatch complains about assignment in if condition

> + RTE_LOG(ERR, PMD, "tun_alloc(%s) failed\n", dev->data->name);
> + rte_free(pmd);

rte_free(data) or goto error_exit; ?

> + rte_eth_dev_release_port(dev);
> + return -EINVAL;
> + }
> +
> + /* Presetup the fds to -1 as being not working */
> + for(i = 0; i < RTE_PMD_TAP_MAX_QUEUES; i++) {
> + pmd->fds[i] = -1;
> + pmd->rxq[i].fd = -1;
> + pmd->txq[i].fd = -1;
> + }
> +
> + /* Take the TUN/TAP fd and place in the first location */
> + pmd->rxq[0].fd = fd;
> + pmd->txq[0].fd = fd;
> + pmd->fds[0] = fd;
> +
> + if (pmd_mac_address(fd, dev, >eth_addr) < 0) {
> + rte_free(pmd);

rte_free(data) or goto error_exit; ?


<..>

> +static int
> +set_interface_name(const char *key __rte_unused,
> +const char *value,
> +void *extra_args)
> +{
> + char *name = (char *)extra_args;
> +
> + if (value)
> + snprintf(name, RTE_ETH_NAME_MAX_LEN-1, "%s", value);

syntax, space around "-"

> + else
> + snprintf(name, RTE_ETH_NAME_MAX_LEN-1, "%s%d",

syntax, space around "-"

> +  DEFAULT_TAP_NAME, (tap_unit-1));

syntax, space around "-"

> +
> + return 0;
> +}
> +
> +static int
> +set_interface_speed(const char *key __rte_unused,
> + const char *value,
> + void *extra_args)
> +{
> + *(int *)extra_args = (value)? 

[dpdk-dev] [PATCH v6] drivers/net:new PMD using tun/tap host interface

[Keith Wiles]

The rte_eth_tap.c PMD creates a device using TUN/TAP interfaces
on the local host. The PMD allows for DPDK and the host to
communicate using a raw device interface on the host and in
the DPDK application. The device created is a Tap device with
a L2 packet header.

v6 - fixed the checkpatch issues
v5 - merge in changes from list review see related emails
 fixed many minor edits
v4 - merge with latest driver changes
v3 - fix includes by removing ifdef for other type besides Linux
 Fix the copyright notice in the Makefile
v2 - merge all of the patches into one patch
 Fix a typo on naming the tap device
 Update the maintainers list

Signed-off-by: Keith Wiles 
---
 MAINTAINERS |   5 +
 config/common_base  |   5 +
 config/common_linuxapp  |   1 +
 doc/guides/nics/tap.rst | 138 ++
 drivers/net/Makefile|   1 +
 drivers/net/tap/Makefile|  57 +++
 drivers/net/tap/rte_eth_tap.c   | 759 
 drivers/net/tap/rte_pmd_tap_version.map |   4 +
 mk/rte.app.mk   |   1 +
 9 files changed, 971 insertions(+)
 create mode 100644 doc/guides/nics/tap.rst
 create mode 100644 drivers/net/tap/Makefile
 create mode 100644 drivers/net/tap/rte_eth_tap.c
 create mode 100644 drivers/net/tap/rte_pmd_tap_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index cd8d167..f905709 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -394,6 +394,11 @@ F: doc/guides/nics/pcap_ring.rst
 F: app/test/test_pmd_ring.c
 F: app/test/test_pmd_ring_perf.c

+Tap PMD
+M: Keith Wiles 
+F: drivers/net/tap
+F: doc/guides/nics/tap.rst
+
 Null Networking PMD
 M: Tetsuya Mukawa 
 F: drivers/net/null/
diff --git a/config/common_base b/config/common_base
index f5d2eff..356c631 100644
--- a/config/common_base
+++ b/config/common_base
@@ -592,3 +592,8 @@ CONFIG_RTE_APP_TEST_RESOURCE_TAR=n
 CONFIG_RTE_TEST_PMD=y
 CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
 CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
+
+#
+# Set TAP PMD to 'n' as it is only supported in Linux for now.
+#
+CONFIG_RTE_LIBRTE_PMD_TAP=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 2483dfa..782b503 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -44,3 +44,4 @@ CONFIG_RTE_LIBRTE_PMD_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
 CONFIG_RTE_LIBRTE_POWER=y
 CONFIG_RTE_VIRTIO_USER=y
+CONFIG_RTE_LIBRTE_PMD_TAP=y
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
new file mode 100644
index 000..eed81ec
--- /dev/null
+++ b/doc/guides/nics/tap.rst
@@ -0,0 +1,138 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Tun/Tap Poll Mode Driver
+
+
+The rte_eth_tap.c PMD creates a device using TUN/TAP interfaces on the local
+host. The PMD allows for DPDK and the host to communicate using a raw device
+interface on the host and in the DPDK application.
+
+The device created is a TAP device, which sends/receives packet in a raw format
+with a L2 header. The usage for a TAP PMD is for connectivity to the local host
+using a TAP interface. When the TAP PMD is initialized it will create a number
+of tap devices in the host accessed via 'ifconfig -a' or 'ip' command. The
+commands can be used to assign and query the virtual like device.
+
+These TAP interfaces can be used with 

[dpdk-dev] [PATCH v3 0/7] vhost: add dequeue zero copy support

[Yuanhan Liu]

On Sun, Oct 09, 2016 at 03:27:53PM +0800, Yuanhan Liu wrote:
> This patch set enables vhost dequeue zero copy. The majority work goes
> to patch 4: "vhost: add dequeue zero copy".

Applied to dpdk-next-virtio.

--yliu
> 
> The basic idea of dequeue zero copy is, instead of copying data from the
> desc buf, here we let the mbuf reference the desc buf addr directly.
> 
> The major issue behind that is how and when to update the used ring.
> You could check the commit log of patch 4 for more details.
> 
> Patch 5 introduces a new flag, RTE_VHOST_USER_DEQUEUE_ZERO_COPY, to enable
> dequeue zero copy, which is disabled by default.
> 
> The performance gain is quite impressive. For a simple dequeue workload
> (running rxonly in vhost-pmd and runnin txonly in guest testpmd), it yields
> 50+% performance boost for packet size 1500B. For VM2VM iperf test case,
> it's even better: about 70% boost.
> 
> For small packets, the performance is worse (it's expected, as the extra
> overhead introduced by zero copy outweighs the benefits from saving few
> bytes copy).
> 
> v3: - rebase: mainly for removing conflicts with the Tx indirect patch
> - don't update last_used_idx twice for zero-copy mode
> - handle two mssiing "Tx -> dequeue" renames in log and usage
> 
> v2: - renamed "tx zero copy" to "dequeue zero copy", to reduce confusions.
> - hnadle the case that a desc buf might across 2 host phys pages
> - use MAP_POPULATE to let kernel populate the page tables
> - updated release note
> - doc-ed the limitations for the vm2nic case
> - merge 2 continuous guest phys memory region
> - and few more trivial changes, please see them in the corresponding
>   patches
> 
> ---
> Yuanhan Liu (7):
>   vhost: simplify memory regions handling
>   vhost: get guest/host physical address mappings
>   vhost: introduce last avail idx for dequeue
>   vhost: add dequeue zero copy
>   vhost: add a flag to enable dequeue zero copy
>   examples/vhost: add an option to enable dequeue zero copy
>   net/vhost: add an option to enable dequeue zero copy
> 
>  doc/guides/prog_guide/vhost_lib.rst|  35 +++-
>  doc/guides/rel_notes/release_16_11.rst |  13 ++
>  drivers/net/vhost/rte_eth_vhost.c  |  13 ++
>  examples/vhost/main.c  |  19 +-
>  lib/librte_vhost/rte_virtio_net.h  |   1 +
>  lib/librte_vhost/socket.c  |   5 +
>  lib/librte_vhost/vhost.c   |  12 ++
>  lib/librte_vhost/vhost.h   | 102 ---
>  lib/librte_vhost/vhost_user.c  | 315 
> ++---
>  lib/librte_vhost/virtio_net.c  | 196 +---
>  10 files changed, 549 insertions(+), 162 deletions(-)
> 
> -- 
> 1.9.0

[dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new API's

[Iremonger, Bernard]

Hi Thomas,



> Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new
> API's
> 
> 2016-10-12 15:27, Iremonger, Bernard:
> > Hi Thomas,
> >
> > 
> >
> > > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for
> > > new API's
> > >
> > > 2016-10-12 16:03, Bernard Iremonger:
> > > > --- a/app/test-pmd/Makefile
> > > > +++ b/app/test-pmd/Makefile
> > > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c  SRCS-y += icmpecho.c
> > > >  SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > > >
> > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> endif
> > > > +
> > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > > +LDLIBS += -lrte_pmd_ixgbe
> > > > +endif
> > > > +endif
> > >
> > > Sorry if I miss something, but I thought it was enough to do:
> > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> >
> > No unfortunately not, the above line does not work for all scenarios .
> >
> > There are 4 scenarios as follows:
> >
> > CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with
> CONFIG_RTE_BUILD_SHARED_LIB=n
> >
> > CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with
> CONFIG_RTE_BUILD_SHARED_LIB=y
> >
> > CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with
> CONFIG_RTE_BUILD_SHARED_LIB=y
> >
> > CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with
> CONFIG_RTE_BUILD_SHARED_LIB=n
> >
> > I have been doing quite a bit of building today to get it to work in all 4
> scenarios.
> 
> I have a doubt about the tests because LDLIBS-y does not exist.
> There is _LDLIBS-y and LDLIBS.
> But in the static case, you wrote:
>   LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> endif Please could you check?

LDLIBS-y exists in some of the scenarios but not all.
Do you want me to check the four scenarios  with just the line below.

LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe

Regards,

Bernard.

[dpdk-dev] [PATCH] dpdk-procinfo: free allocated xstats memory upon failure

[Thomas Monjalon]

2016-10-04 17:42, Reshma Pattan:
> Some of the failures cases inside the nic_xstats_display()
> function doesn't free the allocated memory for the xstats and
> their names, memory is freed now.
> 
> Fixes: e2aae1c1 ("ethdev: remove name from extended statistic fetch")
> Fixes: 22561383 ("app: replace dump_cfg by proc_info")
> 
> Signed-off-by: Reshma Pattan 

Applied, thanks

[dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new API's

[Iremonger, Bernard]

Hi Thomas,



> Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new
> API's
> 
> 2016-10-12 16:03, Bernard Iremonger:
> > --- a/app/test-pmd/Makefile
> > +++ b/app/test-pmd/Makefile
> > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c  SRCS-y += icmpecho.c
> >  SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> >
> > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe endif
> > +
> > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > +LDLIBS += -lrte_pmd_ixgbe
> > +endif
> > +endif
> 
> Sorry if I miss something, but I thought it was enough to do:
> LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe

No unfortunately not, the above line does not work for all scenarios .

There are 4 scenarios as follows:

CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with CONFIG_RTE_BUILD_SHARED_LIB=n

CONFIG_RTE_LIBRTE_IXGBE_PMD=y  with CONFIG_RTE_BUILD_SHARED_LIB=y

CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with CONFIG_RTE_BUILD_SHARED_LIB=y

CONFIG_RTE_LIBRTE_IXGBE_PMD=n  with CONFIG_RTE_BUILD_SHARED_LIB=n

I have been doing quite a bit of building today to get it to work in all 4 
scenarios.

Regards,

Bernard.

[dpdk-dev] [PATCH v7 2/2] app/test_pmd: add tests for new API's

[Iremonger, Bernard]

Hi Pablo,



> > Subject: Re: [dpdk-dev] [PATCH v7 2/2] app/test_pmd: add tests for new
> > API's
> >
> > Hi Thomas,
> >
> > 
> >
> > > > > Subject: Re: [dpdk-dev] [PATCH v7 2/2] app/test_pmd: add tests
> > > > > for new API's
> > > > >
> > > > > 2016-10-11 16:09, Ferruh Yigit:
> > > > > > This will cause a compilation error for shared libraries.
> > > > > > Because PMDs not linked against application when compiled as
> > > > > > shared library but used as plugins.
> > > > > >
> > > > > > Since it has been decided to have NIC specific APIs, we need
> > > > > > to re-work that approach to fix shared library compilation.
> > > > >
> > > > > If testpmd uses the ixgbe API, it must be linked with the PMD.
> > > > > Is there any issue adapting the testpmd makefile?
> > > > > Hope that dlopen an already linked PMD is nicely managed.
> > > >
> > > > The ixgbe API will  be used by other apps, for example Virtual
> > > > Function Daemon (VFD) Moving the following line in rte.app.mak
> > > > solves the problem
> > > >
> > > > Line 117: _LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD)  += -
> > > lrte_pmd_ixgbe
> > > >
> > > > To Line 103.
> > > >
> > > > Will this be acceptable?
> > >
> > > I think we must not link PMD in the general case but let this
> > > responsibility to the application in case it uses some specific functions.
> > > Does it make sense?
> >
> > Yes, ok, will just modify the testpmd makefile  for this case.
> 
> A couple of things:
> You would need to use #ifdef RTE_LIBRTE_IXGBE_PMD in testpmd, right?
> In case IXGBE is not available (maybe just modifying the makefile solves the
> problem).
> 
> Could you also add these new functions in the testpmd help?
> Just add them in cmd_help_long_parsed.
> 
> Thanks,
> Pablo

I have added #ifdef RTE_LIBRTE_IXGBE_PMD in testpmd.
The make file is modified to handle ixgbe PMD present and not present in shared 
library mode and default mode.
I have added the new functions to the testpmd help.

Thanks for reviewing.

Regards,

Bernard.

[dpdk-dev] [PATCH] pdump: fix dir permissions value in mkdir call

[Thomas Monjalon]

2016-10-10 22:44, Remy Horton:
> 
> On 10/10/2016 15:35, Reshma Pattan wrote:
> [..]
> > Fixes: e4ffa2d3 ("pdump: fix error handlings")
> > Fixes: bdd8dcc6 ("pdump: fix default socket path")
> >
> > Reported-by: Jianfeng Tan 
> > Signed-off-by: Reshma Pattan 
> > ---
> >  lib/librte_pdump/rte_pdump.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Acked-by: Remy Horton 

Applied, thanks

[dpdk-dev] [PATCH v3] mk: gcc -march support for intel processors code names

[Thomas Monjalon]

2016-10-10 22:33, Reshma Pattan:
> The GCC 4.9 -march option supports the intel code names for processors,
> for example -march=silvermont, -march=broadwell.
> The RTE_MACHINE config flag can be used to pass code name to
> the compiler as -march flag.
> 
> Release notes is updated.
> 
> Linux and FreeBSD getting started guides are updated with recommended
> gcc version as 4.9 and above.
> 
> Some of the gmake command examples in sample application guide and driver
> guides are updated with gcc version as 4.9.
> 
> Signed-off-by: Reshma Pattan 

Applied, thanks

How the -march=broadwell option will work with icc and clang?

[dpdk-dev] [PATCH] dpdk-procinfo: free allocated xstats memory upon failure

[Remy Horton]

On 04/10/2016 17:42, Reshma Pattan wrote:
> Some of the failures cases inside the nic_xstats_display()
> function doesn't free the allocated memory for the xstats and
> their names, memory is freed now.
>
> Fixes: e2aae1c1 ("ethdev: remove name from extended statistic fetch")
> Fixes: 22561383 ("app: replace dump_cfg by proc_info")
>
> Signed-off-by: Reshma Pattan 

Acked-by: Remy Horton 

[dpdk-dev] [PATCH] eal: avoid unnecessary conflicts over rte_config file

[John Ousterhout]

Before this patch, DPDK used the file ~/.rte_config as a lock to detect
potential interference between multiple DPDK applications running on the
same machine. However, if a single user ran DPDK applications concurrently
on several different machines, and if the user's home directory was shared
between the machines via NFS, DPDK would incorrectly detect conflicts
for all but the first application and abort them. This patch fixes the
problem by incorporating the machine name into the config file name (e.g.,
~/.rte_hostname_config).

Signed-off-by: John Ousterhout 
---
 doc/guides/prog_guide/multi_proc_support.rst | 11 +++
 lib/librte_eal/common/eal_common_proc.c  |  8 ++--
 lib/librte_eal/common/eal_filesystem.h   | 15 +--
 3 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/doc/guides/prog_guide/multi_proc_support.rst 
b/doc/guides/prog_guide/multi_proc_support.rst
index badd102..a54fa1c 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -129,10 +129,13 @@ Support for this usage scenario is provided using the 
``--file-prefix`` paramete

 By default, the EAL creates hugepage files on each hugetlbfs filesystem using 
the rtemap_X filename,
 where X is in the range 0 to the maximum number of hugepages -1.
-Similarly, it creates shared configuration files, memory mapped in each 
process, using the /var/run/.rte_config filename,
-when run as root (or $HOME/.rte_config when run as a non-root user;
-if filesystem and device permissions are set up to allow this).
-The rte part of the filenames of each of the above is configurable using the 
file-prefix parameter.
+Similarly, it creates shared configuration files, memory mapped in each 
process.
+When run as root, the name of the configuration file will be
+/var/run/.rte_*host*_config, where *host* is the name of the machine.
+When run as a non-root user, the the name of the configuration file will be
+$HOME/.rte_*host*_config (if filesystem and device permissions are set up to 
allow this).
+If the ``--file-prefix`` parameter has been specified, its value will be used
+in place of "rte" in the file names.

 In addition to specifying the file-prefix parameter,
 any DPDK applications that are to be run side-by-side must explicitly limit 
their memory use.
diff --git a/lib/librte_eal/common/eal_common_proc.c 
b/lib/librte_eal/common/eal_common_proc.c
index 12e0fca..517aa0c 100644
--- a/lib/librte_eal/common/eal_common_proc.c
+++ b/lib/librte_eal/common/eal_common_proc.c
@@ -45,12 +45,8 @@ rte_eal_primary_proc_alive(const char *config_file_path)

if (config_file_path)
config_fd = open(config_file_path, O_RDONLY);
-   else {
-   char default_path[PATH_MAX+1];
-   snprintf(default_path, PATH_MAX, RUNTIME_CONFIG_FMT,
-default_config_dir, "rte");
-   config_fd = open(default_path, O_RDONLY);
-   }
+   else
+   config_fd = open(eal_runtime_config_path(), O_RDONLY);
if (config_fd < 0)
return 0;

diff --git a/lib/librte_eal/common/eal_filesystem.h 
b/lib/librte_eal/common/eal_filesystem.h
index fdb4a70..4929aa3 100644
--- a/lib/librte_eal/common/eal_filesystem.h
+++ b/lib/librte_eal/common/eal_filesystem.h
@@ -41,7 +41,7 @@
 #define EAL_FILESYSTEM_H

 /** Path of rte config file. */
-#define RUNTIME_CONFIG_FMT "%s/.%s_config"
+#define RUNTIME_CONFIG_FMT "%s/.%s_%s_config"

 #include 
 #include 
@@ -59,11 +59,22 @@ eal_runtime_config_path(void)
static char buffer[PATH_MAX]; /* static so auto-zeroed */
const char *directory = default_config_dir;
const char *home_dir = getenv("HOME");
+   static char nameBuffer[1000];
+   int result;

if (getuid() != 0 && home_dir != NULL)
directory = home_dir;
+
+   /*
+* Include the name of the host in the config file path. Otherwise,
+* if DPDK applications run on different hosts but share a home
+* directory (e.g. via NFS), they will choose the same config
+* file and conflict unnecessarily.
+*/
+   result = gethostname(nameBuffer, sizeof(nameBuffer)-1);
snprintf(buffer, sizeof(buffer) - 1, RUNTIME_CONFIG_FMT, directory,
-   internal_config.hugefile_prefix);
+   internal_config.hugefile_prefix,
+   (result == 0) ? nameBuffer : "unknown-host");
return buffer;
 }

-- 
2.8.3

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

[Wenzhuo Lu]

The vlan mask and tunnel id mask of flow director
are defined as big endian. So they should be
converted.
When the mask is printed, the parameters are not
converted either. This patch converts the mask
parameters.
Some lines of the mask print are too long, split
them to more lines.

Fixes: 7c554b4f0484 ("app/testpmd: update display of flow director information")
Fixes: 53b2bb9b7ea7 ("app/testpmd: new flow director commands")
Signed-off-by: Wenzhuo Lu 
---
 app/test-pmd/cmdline.c |  6 +++---
 app/test-pmd/config.c  | 34 +-
 2 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 259090a..7c5c5e7 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -9074,16 +9074,16 @@ cmd_flow_director_mask_parsed(void *parsed_result,
return;
}

-   mask->vlan_tci_mask = res->vlan_mask;
+   mask->vlan_tci_mask = rte_cpu_to_be_16(res->vlan_mask);
} else if (fdir_conf.mode ==  RTE_FDIR_MODE_PERFECT_TUNNEL) {
if (strcmp(res->mode_value, "Tunnel")) {
printf("Please set mode to Tunnel.\n");
return;
}

-   mask->vlan_tci_mask = res->vlan_mask;
+   mask->vlan_tci_mask = rte_cpu_to_be_16(res->vlan_mask);
mask->mac_addr_byte_mask = res->mac_addr_byte_mask;
-   mask->tunnel_id_mask = res->tunnel_id_mask;
+   mask->tunnel_id_mask = rte_cpu_to_be_32(res->tunnel_id_mask);
mask->tunnel_type_mask = res->tunnel_type_mask;
} else {
if (strcmp(res->mode_value, "IP")) {
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 238c4fd..742a8d8 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2045,25 +2045,33 @@ set_qmap(portid_t port_id, uint8_t is_rx, uint16_t 
queue_id, uint8_t map_value)
 static inline void
 print_fdir_mask(struct rte_eth_fdir_masks *mask)
 {
-   printf("\nvlan_tci: 0x%04x", mask->vlan_tci_mask);
+   printf("\nvlan_tci: 0x%04x", rte_be_to_cpu_16(mask->vlan_tci_mask));

if (fdir_conf.mode == RTE_FDIR_MODE_PERFECT_TUNNEL)
printf(", mac_addr: 0x%02x, tunnel_type: 0x%01x,"
" tunnel_id: 0x%08x",
mask->mac_addr_byte_mask, mask->tunnel_type_mask,
-   mask->tunnel_id_mask);
+   rte_be_to_cpu_32(mask->tunnel_id_mask));
else if (fdir_conf.mode != RTE_FDIR_MODE_PERFECT_MAC_VLAN) {
-   printf(", src_ipv4: 0x%08x, dst_ipv4: 0x%08x,"
-   " src_port: 0x%04x, dst_port: 0x%04x",
-   mask->ipv4_mask.src_ip, mask->ipv4_mask.dst_ip,
-   mask->src_port_mask, mask->dst_port_mask);
-
-   printf("\nsrc_ipv6: 0x%08x,0x%08x,0x%08x,0x%08x,"
-   " dst_ipv6: 0x%08x,0x%08x,0x%08x,0x%08x",
-   mask->ipv6_mask.src_ip[0], mask->ipv6_mask.src_ip[1],
-   mask->ipv6_mask.src_ip[2], mask->ipv6_mask.src_ip[3],
-   mask->ipv6_mask.dst_ip[0], mask->ipv6_mask.dst_ip[1],
-   mask->ipv6_mask.dst_ip[2], mask->ipv6_mask.dst_ip[3]);
+   printf(", src_ipv4: 0x%08x, dst_ipv4: 0x%08x",
+   rte_be_to_cpu_32(mask->ipv4_mask.src_ip),
+   rte_be_to_cpu_32(mask->ipv4_mask.dst_ip));
+
+   printf("\nsrc_port: 0x%04x, dst_port: 0x%04x",
+   rte_be_to_cpu_16(mask->src_port_mask),
+   rte_be_to_cpu_16(mask->dst_port_mask));
+
+   printf("\nsrc_ipv6: 0x%08x,0x%08x,0x%08x,0x%08x",
+   rte_be_to_cpu_32(mask->ipv6_mask.src_ip[0]),
+   rte_be_to_cpu_32(mask->ipv6_mask.src_ip[1]),
+   rte_be_to_cpu_32(mask->ipv6_mask.src_ip[2]),
+   rte_be_to_cpu_32(mask->ipv6_mask.src_ip[3]));
+
+   printf("\ndst_ipv6: 0x%08x,0x%08x,0x%08x,0x%08x",
+   rte_be_to_cpu_32(mask->ipv6_mask.dst_ip[0]),
+   rte_be_to_cpu_32(mask->ipv6_mask.dst_ip[1]),
+   rte_be_to_cpu_32(mask->ipv6_mask.dst_ip[2]),
+   rte_be_to_cpu_32(mask->ipv6_mask.dst_ip[3]));
}

printf("\n");
-- 
1.9.3

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

[Wenzhuo Lu]

In mac-vlan mode, MAC address mask is not supported by HW.
The MAC address mask should not be set in mac-vlan mode.
Remove this parameter from the CLI. Remove MAC address
from mask print too.

Fixes: 53b2bb9b7ea7 ("app/testpmd: new flow director commands")
Signed-off-by: Wenzhuo Lu 
---
 app/test-pmd/cmdline.c  |  5 +
 app/test-pmd/config.c   | 13 ++---
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  3 +--
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 6e95ca2..259090a 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -720,7 +720,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"Set flow director IP mask.\n\n"

"flow_director_mask (port_id) mode MAC-VLAN"
-   " vlan (vlan_value) mac (mac_value)\n"
+   " vlan (vlan_value)\n"
"Set flow director MAC-VLAN mask.\n\n"

"flow_director_mask (port_id) mode Tunnel"
@@ -9075,7 +9075,6 @@ cmd_flow_director_mask_parsed(void *parsed_result,
}

mask->vlan_tci_mask = res->vlan_mask;
-   mask->mac_addr_byte_mask = res->mac_addr_byte_mask;
} else if (fdir_conf.mode ==  RTE_FDIR_MODE_PERFECT_TUNNEL) {
if (strcmp(res->mode_value, "Tunnel")) {
printf("Please set mode to Tunnel.\n");
@@ -9206,8 +9205,6 @@ cmdline_parse_inst_t cmd_set_flow_director_mac_vlan_mask 
= {
(void *)_flow_director_mask_mode_mac_vlan,
(void *)_flow_director_mask_vlan,
(void *)_flow_director_mask_vlan_value,
-   (void *)_flow_director_mask_mac,
-   (void *)_flow_director_mask_mac_value,
NULL,
},
 };
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 83bebfe..238c4fd 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2045,16 +2045,15 @@ set_qmap(portid_t port_id, uint8_t is_rx, uint16_t 
queue_id, uint8_t map_value)
 static inline void
 print_fdir_mask(struct rte_eth_fdir_masks *mask)
 {
-   printf("\nvlan_tci: 0x%04x, ", mask->vlan_tci_mask);
+   printf("\nvlan_tci: 0x%04x", mask->vlan_tci_mask);

-   if (fdir_conf.mode == RTE_FDIR_MODE_PERFECT_MAC_VLAN)
-   printf("mac_addr: 0x%02x", mask->mac_addr_byte_mask);
-   else if (fdir_conf.mode == RTE_FDIR_MODE_PERFECT_TUNNEL)
-   printf("mac_addr: 0x%02x, tunnel_type: 0x%01x, tunnel_id: 
0x%08x",
+   if (fdir_conf.mode == RTE_FDIR_MODE_PERFECT_TUNNEL)
+   printf(", mac_addr: 0x%02x, tunnel_type: 0x%01x,"
+   " tunnel_id: 0x%08x",
mask->mac_addr_byte_mask, mask->tunnel_type_mask,
mask->tunnel_id_mask);
-   else {
-   printf("src_ipv4: 0x%08x, dst_ipv4: 0x%08x,"
+   else if (fdir_conf.mode != RTE_FDIR_MODE_PERFECT_MAC_VLAN) {
+   printf(", src_ipv4: 0x%08x, dst_ipv4: 0x%08x,"
" src_port: 0x%04x, dst_port: 0x%04x",
mask->ipv4_mask.src_ip, mask->ipv4_mask.dst_ip,
mask->src_port_mask, mask->dst_port_mask);
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index f87e0c2..ed04532 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1844,8 +1844,7 @@ Set flow director's input masks::
   src_mask (ipv4_src) (ipv6_src) (src_port) \
   dst_mask (ipv4_dst) (ipv6_dst) (dst_port)

-   flow_director_mask (port_id) mode MAC-VLAN vlan (vlan_value) \
-  mac (mac_value)
+   flow_director_mask (port_id) mode MAC-VLAN vlan (vlan_value)

flow_director_mask (port_id) mode Tunnel vlan (vlan_value) \
   mac (mac_value) tunnel-type (tunnel_type_value) \
-- 
1.9.3

[dpdk-dev] [PATCH v2 1/3] ixgbe: fix wrong flow director mask

[Wenzhuo Lu]

In mac-vlan mode, MAC address mask is not supported by HW.
The MAC address mask should not be set in mac-vlan mode.
Instead, only set it in tunnel mode.

Fixes: 82fb702077f6 ("ixgbe: support new flow director modes for X550")
Signed-off-by: Wenzhuo Lu 
---
 drivers/net/ixgbe/ixgbe_fdir.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_fdir.c b/drivers/net/ixgbe/ixgbe_fdir.c
index 861c7cb..4b81ee3 100644
--- a/drivers/net/ixgbe/ixgbe_fdir.c
+++ b/drivers/net/ixgbe/ixgbe_fdir.c
@@ -432,12 +432,12 @@ fdir_set_input_mask_x550(struct rte_eth_dev *dev,
fdiripv6m |= IXGBE_FDIRIP6M_TUNNEL_TYPE |
IXGBE_FDIRIP6M_TNI_VNI;

-   mac_mask = input_mask->mac_addr_byte_mask;
-   fdiripv6m |= (mac_mask << IXGBE_FDIRIP6M_INNER_MAC_SHIFT)
-   & IXGBE_FDIRIP6M_INNER_MAC;
-   info->mask.mac_addr_byte_mask = input_mask->mac_addr_byte_mask;
-
if (mode == RTE_FDIR_MODE_PERFECT_TUNNEL) {
+   mac_mask = input_mask->mac_addr_byte_mask;
+   fdiripv6m |= (mac_mask << IXGBE_FDIRIP6M_INNER_MAC_SHIFT)
+   & IXGBE_FDIRIP6M_INNER_MAC;
+   info->mask.mac_addr_byte_mask = input_mask->mac_addr_byte_mask;
+
switch (input_mask->tunnel_type_mask) {
case 0:
/* Mask turnnel type */
-- 
1.9.3

[dpdk-dev] [PATCH v2 0/3] fix flow director mask issues

[Wenzhuo Lu]

There're 2 issues about flow director mask.
1, MAC address mask is not supported in mac-vlan mode.
2, All the parameter are defined as big endian, but
   they're not treated approriately.
This patch set is used to fix these 2 issues.

v2:
- Re-split the patches and reword commit log. No code change.

Wenzhuo Lu (3):
  ixgbe: fix wrong flow director mask
  app/testpmd: fix wrong flow director mask
  app/testpmd: fix flow director endian issue

 app/test-pmd/cmdline.c  | 11 +++-
 app/test-pmd/config.c   | 43 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  3 +-
 drivers/net/ixgbe/ixgbe_fdir.c  | 10 +++
 4 files changed, 35 insertions(+), 32 deletions(-)

-- 
1.9.3

[dpdk-dev] [PATCH] net/enic: fix poor multi-queue Rx performance

[John Daley]

The rx_free_thresh was not being initialized and left at 0
on 1/2 of the RQs which could lead to poor multi-queue
performanace.

Fixes: 856d7ba7ed22 ("net/enic: support scattered Rx")

Signed-off-by: John Daley 
Reviewed-by: Nelson Escobar 
---
 drivers/net/enic/enic.h| 2 +-
 drivers/net/enic/enic_ethdev.c | 7 ++-
 drivers/net/enic/enic_main.c   | 8 ++--
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 4ea4e4a..0d7f379 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -256,7 +256,7 @@ extern int enic_stop_rq(struct enic *enic, uint16_t 
queue_idx);
 extern void enic_free_rq(void *rxq);
 extern int enic_alloc_rq(struct enic *enic, uint16_t queue_idx,
unsigned int socket_id, struct rte_mempool *mp,
-   uint16_t nb_desc);
+   uint16_t nb_desc, uint16_t free_thresh);
 extern int enic_set_rss_nic_cfg(struct enic *enic);
 extern int enic_set_vnic_res(struct enic *enic);
 extern void enic_set_hdr_split_size(struct enic *enic, u16 split_hdr_size);
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 4d24bbd..ef20714 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -315,16 +315,13 @@ static int enicpmd_dev_rx_queue_setup(struct rte_eth_dev 
*eth_dev,
eth_dev->data->rx_queues[queue_idx] =
(void *)>rq[enic_sop_rq(queue_idx)];

-   ret = enic_alloc_rq(enic, queue_idx, socket_id, mp, nb_desc);
+   ret = enic_alloc_rq(enic, queue_idx, socket_id, mp, nb_desc,
+   rx_conf->rx_free_thresh);
if (ret) {
dev_err(enic, "error in allocating rq\n");
return ret;
}

-   enic->rq[queue_idx].rx_free_thresh = rx_conf->rx_free_thresh;
-   dev_debug(enic, "Set queue_id:%u free thresh:%u\n", queue_idx,
-   enic->rq[queue_idx].rx_free_thresh);
-
return enicpmd_dev_setup_intr(enic);
 }

diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 622b317..eb6ae08 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -603,7 +603,7 @@ int enic_stop_rq(struct enic *enic, uint16_t queue_idx)

 int enic_alloc_rq(struct enic *enic, uint16_t queue_idx,
unsigned int socket_id, struct rte_mempool *mp,
-   uint16_t nb_desc)
+   uint16_t nb_desc, uint16_t free_thresh)
 {
int rc;
uint16_t sop_queue_idx = enic_sop_rq(queue_idx);
@@ -624,6 +624,10 @@ int enic_alloc_rq(struct enic *enic, uint16_t queue_idx,
rq_data->socket_id = socket_id;
rq_data->mp = mp;
rq_sop->in_use = 1;
+   rq_sop->rx_free_thresh = free_thresh;
+   rq_data->rx_free_thresh = free_thresh;
+   dev_debug(enic, "Set queue_id:%u free thresh:%u\n", queue_idx,
+ free_thresh);

mbuf_size = (uint16_t)(rte_pktmbuf_data_room_size(mp) -
   RTE_PKTMBUF_HEADROOM);
@@ -1236,7 +1240,7 @@ int enic_set_mtu(struct enic *enic, uint16_t new_mtu)

enic_free_rq(rq);
rc = enic_alloc_rq(enic, rq_idx, rq->socket_id, rq->mp,
-  rq->tot_nb_desc);
+  rq->tot_nb_desc, rq->rx_free_thresh);
if (rc) {
dev_err(enic,
"Fatal MTU alloc error- No traffic will 
pass\n");
-- 
2.10.0

[dpdk-dev] [PATCH v4] log: respect rte_openlog_stream calls before rte_eal_init

[John Ousterhout]

Suppose an application starts up, calls rte_eal_init, then later on invokes
code like this:

fclose(stderr);
stderr = fopen("foo", "w");

This might happen if it is using stderr for its log, but decides to roll
the log over to a new file.

Now stderr has changed.  However, if DPDK made a copy of it with a
statement like this:

FILE *default_log_stream = stderr;

then default_log_stream will continue to refer to the old log file, not the
new one.

Thus, it's better to grab the value of stderr at the last possible moment
before logging.

-John-

On Wed, Oct 12, 2016 at 12:47 PM, Thomas Monjalon  wrote:

> 2016-10-12 12:38, John Ousterhout:
> > @@ -127,6 +125,19 @@ rte_vlog(uint32_t level, uint32_t logtype, const
> char *format, va_list ap)
> >  {
> >   int ret;
> >   FILE *f = rte_logs.file;
> > + if (f == NULL) {
> > + f = default_log_stream;
> > + if (f == NULL) {
> > + /*
> > +  * Grab the current value of stderr here, rather
> than
> > +  * just initializing default_log_stream to stderr.
> This
> > +  * ensures that we will always use the current
> value
> > +  * of stderr, even if the application closes and
> > +  * reopens it.
> > +  */
> > + f = stderr;
> > + }
> > + }
>
> I don't understand this big comment.
> What is the difference with initializing default_log_stream to stderr?
> What do you mean by "if the application closes and reopens it"?
>

[dpdk-dev] [PATCH 2/2] net/enic: trivial function name changes

[John Daley]

The function names for converting between RQ indexes known to
the RTE code and intenal RQ indexes for primary Start of Packet
(SOP) queues and spill-over (Data) queues was unclear and
confusing.

Clarify with more explicit function names.

Signed-off-by: John Daley 
Reviewed-by: Nelson Escobar 
---
 drivers/net/enic/enic.h| 16 -
 drivers/net/enic/enic_clsf.c   |  2 +-
 drivers/net/enic/enic_ethdev.c |  6 ++---
 drivers/net/enic/enic_main.c   | 51 --
 4 files changed, 43 insertions(+), 32 deletions(-)

diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 13a4b31..45b27a5 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -175,19 +175,23 @@ static inline unsigned int 
enic_sop_rq_idx_to_cq_idx(unsigned int sop_idx)
 {
return sop_idx / 2;
 }
-static inline unsigned int enic_rq_sop(unsigned int sop_rq)
+
+/* Get the RTE RQ index from a Start of Packet(SOP) RQ index */
+static inline unsigned int enic_sop_rq_idx_to_rte_idx(unsigned int sop_idx)
 {
-   return sop_rq / 2;
+   return sop_idx / 2;
 }

-static inline unsigned int enic_sop_rq(unsigned int rq)
+/* Get the Start of Packet(SOP) RQ index from a RTE RQ index */
+static inline unsigned int enic_rte_rq_idx_to_sop_idx(unsigned int rte_idx)
 {
-   return rq * 2;
+   return rte_idx * 2;
 }

-static inline unsigned int enic_data_rq(unsigned int rq)
+/* Get the Data RQ index from a RTE RQ index */
+static inline unsigned int enic_rte_rq_idx_to_data_idx(unsigned int rte_idx)
 {
-   return rq * 2 + 1;
+   return rte_idx * 2 + 1;
 }

 static inline unsigned int enic_vnic_rq_count(struct enic *enic)
diff --git a/drivers/net/enic/enic_clsf.c b/drivers/net/enic/enic_clsf.c
index c709be9..724957a 100644
--- a/drivers/net/enic/enic_clsf.c
+++ b/drivers/net/enic/enic_clsf.c
@@ -384,7 +384,7 @@ int enic_fdir_add_fltr(struct enic *enic, struct 
rte_eth_fdir_filter *params)
}

/* Get the enicpmd RQ from the DPDK Rx queue */
-   queue = enic_sop_rq(params->action.rx_queue);
+   queue = enic_rte_rq_idx_to_sop_idx(params->action.rx_queue);

if (!enic->rq[queue].in_use)
return -EINVAL;
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 4d24bbd..18bb356 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -154,7 +154,7 @@ static int enicpmd_dev_setup_intr(struct enic *enic)
return 0;
/* check start of packet (SOP) RQs only in case scatter is disabled. */
for (index = 0; index < enic->rq_count; index++) {
-   if (!enic->rq[enic_sop_rq(index)].ctrl)
+   if (!enic->rq[enic_rte_rq_idx_to_sop_idx(index)].ctrl)
break;
}
if (enic->rq_count != index)
@@ -277,7 +277,7 @@ static uint32_t enicpmd_dev_rx_queue_count(struct 
rte_eth_dev *dev,
return 0;
}

-   rq_num = enic_sop_rq(rx_queue_id);
+   rq_num = enic_rte_rq_idx_to_sop_idx(rx_queue_id);
cq = >cq[enic_cq_rq(enic, rq_num)];
cq_idx = cq->to_clean;

@@ -313,7 +313,7 @@ static int enicpmd_dev_rx_queue_setup(struct rte_eth_dev 
*eth_dev,
}

eth_dev->data->rx_queues[queue_idx] =
-   (void *)>rq[enic_sop_rq(queue_idx)];
+   (void *)>rq[enic_rte_rq_idx_to_sop_idx(queue_idx)];

ret = enic_alloc_rq(enic, queue_idx, socket_id, mp, nb_desc);
if (ret) {
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 65a8307..7689c3c 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -241,14 +241,14 @@ void enic_init_vnic_resources(struct enic *enic)
struct vnic_rq *data_rq;

for (index = 0; index < enic->rq_count; index++) {
-   cq_idx = enic_cq_rq(enic, enic_sop_rq(index));
+   cq_idx = enic_cq_rq(enic, enic_rte_rq_idx_to_sop_idx(index));

-   vnic_rq_init(>rq[enic_sop_rq(index)],
+   vnic_rq_init(>rq[enic_rte_rq_idx_to_sop_idx(index)],
cq_idx,
error_interrupt_enable,
error_interrupt_offset);

-   data_rq = >rq[enic_data_rq(index)];
+   data_rq = >rq[enic_rte_rq_idx_to_data_idx(index)];
if (data_rq->in_use)
vnic_rq_init(data_rq,
 cq_idx,
@@ -462,17 +462,17 @@ int enic_enable(struct enic *enic)

for (index = 0; index < enic->rq_count; index++) {
err = enic_alloc_rx_queue_mbufs(enic,
-   >rq[enic_sop_rq(index)]);
+   >rq[enic_rte_rq_idx_to_sop_idx(index)]);
if (err) {
dev_err(enic, "Failed to alloc sop RX queue mbufs\n");
return err;
}
err = enic_alloc_rx_queue_mbufs(enic,
-   

[dpdk-dev] [PATCH 1/2] net/enic: fix crash on MTU update or rxq reconfigure

[John Daley]

The incorrect completion queue corresponding to an RQ would be
freed if multiple Rx queues are in use and the MTU is changed,
or an Rx queue is released. This could lead to a segmentation fault
when the device is disabled or even in the Rx or Tx paths.

The index of the completion queue corresponding to a RQ needed
to be adjusted after Rx scatter was introduced.

Fixes: 856d7ba7ed22 ("net/enic: support scattered Rx")

Signed-off-by: John Daley 
Reviewed-by: Nelson Escobar 
---
 drivers/net/enic/enic.h  | 5 +
 drivers/net/enic/enic_main.c | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 4ea4e4a..13a4b31 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -170,6 +170,11 @@ struct enic {

 };

+/* Get the CQ index from a Start of Packet(SOP) RQ index */
+static inline unsigned int enic_sop_rq_idx_to_cq_idx(unsigned int sop_idx)
+{
+   return sop_idx / 2;
+}
 static inline unsigned int enic_rq_sop(unsigned int sop_rq)
 {
return sop_rq / 2;
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 622b317..65a8307 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -541,7 +541,7 @@ void enic_free_rq(void *rxq)
if (rq_data->in_use)
vnic_rq_free(rq_data);

-   vnic_cq_free(>cq[rq_sop->index]);
+   vnic_cq_free(>cq[enic_sop_rq_idx_to_cq_idx(rq_sop->index)]);

rq_sop->in_use = 0;
rq_data->in_use = 0;
-- 
2.10.0

[dpdk-dev] [PATCH] net/enic: fix crash on MTU update or rxq reconfigure

[John Daley]

The incorrect completion queue corresponding to an RQ would be
freed if multiple Rx queues are in use and the MTU is changed,
or an Rx queue is released. This could lead to a segmentation fault
when the device is disabled or even in the Rx or Tx paths.

The index of the completion queue corresponding to a RQ needed
to be adjusted after Rx scatter was introduced.

Fixes: 856d7ba7ed22 ("net/enic: support scattered Rx")

Signed-off-by: John Daley 
Reviewed-by: Nelson Escobar 
---
 drivers/net/enic/enic.h  | 5 +
 drivers/net/enic/enic_main.c | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 4ea4e4a..13a4b31 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -170,6 +170,11 @@ struct enic {

 };

+/* Get the CQ index from a Start of Packet(SOP) RQ index */
+static inline unsigned int enic_sop_rq_idx_to_cq_idx(unsigned int sop_idx)
+{
+   return sop_idx / 2;
+}
 static inline unsigned int enic_rq_sop(unsigned int sop_rq)
 {
return sop_rq / 2;
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 622b317..65a8307 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -541,7 +541,7 @@ void enic_free_rq(void *rxq)
if (rq_data->in_use)
vnic_rq_free(rq_data);

-   vnic_cq_free(>cq[rq_sop->index]);
+   vnic_cq_free(>cq[enic_sop_rq_idx_to_cq_idx(rq_sop->index)]);

rq_sop->in_use = 0;
rq_data->in_use = 0;
-- 
2.10.0

[dpdk-dev] [PATCH v3] mk: gcc -march support for intel processors code names

[Pattan, Reshma]

Hi

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, October 12, 2016 1:34 PM
> To: Pattan, Reshma 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] mk: gcc -march support for intel processors
> code names
> 
> 2016-10-10 22:33, Reshma Pattan:
> > The GCC 4.9 -march option supports the intel code names for
> > processors, for example -march=silvermont, -march=broadwell.
> > The RTE_MACHINE config flag can be used to pass code name to the
> > compiler as -march flag.
> >
> > Signed-off-by: Reshma Pattan 
> 
> Applied, thanks
> 
> How the -march=broadwell option will work with icc and clang?

Clang does support broadwell option.
And I do have Icc version" icc (ICC) 16.0.3 20160415" which doesn't support 
code names.

Any other info you are explicitly looking for?

Thanks,
Reshma

[dpdk-dev] [PATCH 2/2] net/enic: revert "fix calculation of truncated packets"

[John Daley]

From: Nelson Escobar 

The reason this commit was needed was because of a misconfiguration of
the receive queue when not using Rx scatter.  This patch is
unnecessary if the receive queue is configured correctly.

Fixes: d142e1ac1089 ("net/enic: fix calculation of truncated packets")

Signed-off-by: Nelson Escobar 
Reviewed-by: John Daley 
---
 drivers/net/enic/enic_main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 836dcfe..b65a079 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -174,8 +174,7 @@ void enic_dev_stats_get(struct enic *enic, struct 
rte_eth_stats *r_stats)
 * which can make ibytes be slightly higher than it should be.
 */
rx_packet_errors = rte_atomic64_read(_stats->rx_packet_errors);
-   rx_truncated = rx_packet_errors - stats->rx.rx_errors -
-   stats->rx.rx_no_bufs;
+   rx_truncated = rx_packet_errors - stats->rx.rx_errors;

r_stats->ipackets = stats->rx.rx_frames_ok - rx_truncated;
r_stats->opackets = stats->tx.tx_frames_ok;
-- 
2.10.0

[dpdk-dev] [PATCH 1/2] net/enic: fix error in init of RQ when not using Rx scatter

[John Daley]

From: Nelson Escobar 

The Rx scatter patch was accidentally setting the index of the
secondary receive queue in the primary receive queue's initialization
when the secondary receive queue wasn't needed and was disabled.  This
caused some misleading hardware counters in some situations.

Fixes: 856d7ba7ed22 ("net/enic: support scattered Rx")

Signed-off-by: Nelson Escobar 
Reviewed-by: John Daley 
---
 drivers/net/enic/base/vnic_rq.c | 6 --
 drivers/net/enic/base/vnic_rq.h | 1 +
 drivers/net/enic/enic_main.c| 2 ++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/enic/base/vnic_rq.c b/drivers/net/enic/base/vnic_rq.c
index 0e700a1..10a40c1 100644
--- a/drivers/net/enic/base/vnic_rq.c
+++ b/drivers/net/enic/base/vnic_rq.c
@@ -87,9 +87,11 @@ void vnic_rq_init_start(struct vnic_rq *rq, unsigned int 
cq_index,
iowrite32(0, >ctrl->error_status);
iowrite32(fetch_index, >ctrl->fetch_index);
iowrite32(posted_index, >ctrl->posted_index);
-   if (rq->is_sop)
-   iowrite32(((rq->is_sop << 10) | rq->data_queue_idx),
+   if (rq->data_queue_enable)
+   iowrite32(((1 << 10) | rq->data_queue_idx),
  >ctrl->data_ring);
+   else
+   iowrite32(0, >ctrl->data_ring);
 }

 void vnic_rq_init(struct vnic_rq *rq, unsigned int cq_index,
diff --git a/drivers/net/enic/base/vnic_rq.h b/drivers/net/enic/base/vnic_rq.h
index 7d96b0f..f3fd39f 100644
--- a/drivers/net/enic/base/vnic_rq.h
+++ b/drivers/net/enic/base/vnic_rq.h
@@ -91,6 +91,7 @@ struct vnic_rq {
uint16_t rxst_idx;
uint32_t tot_pkts;
uint16_t data_queue_idx;
+   uint8_t data_queue_enable;
uint8_t is_sop;
uint8_t in_use;
struct rte_mbuf *pkt_first_seg;
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 622b317..836dcfe 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -640,10 +640,12 @@ int enic_alloc_rq(struct enic *enic, uint16_t queue_idx,

if (mbufs_per_pkt > 1) {
dev_info(enic, "Rq %u Scatter rx mode in use\n", queue_idx);
+   rq_sop->data_queue_enable = 1;
rq_data->in_use = 1;
} else {
dev_info(enic, "Rq %u Scatter rx mode not being used\n",
 queue_idx);
+   rq_sop->data_queue_enable = 0;
rq_data->in_use = 0;
}

-- 
2.10.0

[dpdk-dev] [PATCH] mempool: Add sanity check when secondary link in less mempools than primary

[Jean Tourrilhes]

mempool: Add sanity check when secondary link in less mempools than primary

If the primary and secondary process were build using different build
systems, the list of constructors included by the linker in each
binary might be different. Mempools are registered via constructors, so
the linker magic will directly impact which tailqs are registered with
the primary and the secondary.

DPDK currently assumes that the secondary has a superset of the
mempools registered at the primary, and they are in the same order
(same index in primary and secondary). In some build scenario, the
secondary might not initialise any mempools at all. This would result
in an obscure segfault when trying to use the mempool. Instead, fail
early with a more explicit error message.

Signed-off-by: Jean Tourrilhes 
---
 lib/librte_mempool/rte_mempool.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 2e28e2e..4fe9158 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -1275,6 +1275,16 @@ rte_mempool_lookup(const char *name)
return NULL;
}

+   /* Sanity check : secondary may have initialised less mempools
+* than primary due to linker and constructor magic. Note that
+* this does not address the case where the constructor order
+* is different between primary and secondary and where the index
+* points to the wrong ops. Jean II */
+   if(mp->ops_index >= (int32_t) rte_mempool_ops_table.num_ops) {
+   /* Do not dump mempool list, it will segfault. */
+   rte_panic("Cannot find ops for mempool, ops_index %d, num_ops 
%d - maybe due to build process or linker configuration\n", mp->ops_index, 
rte_mempool_ops_table.num_ops);
+   }
+
return mp;
 }

[dpdk-dev] [PATCH v4] log: respect rte_openlog_stream calls before rte_eal_init

[John Ousterhout]

Before this patch, application-specific loggers could not be
installed before rte_eal_init completed (the initialization process
called rte_openlog_stream, overwriting any previously installed
logger). This made it impossible for an application to capture the
initial log messages generated during rte_eal_init. This patch changes
initialization so that information from a previous call to
rte_openlog_stream is not lost. Specifically:
* The default log stream is now maintained separately from an
  application-specific log stream installed with rte_openlog_stream.
* rte_eal_common_log_init has been renamed to eal_log_set_default,
  since this is all it does. It no longer invokes rte_openlog_stream; it
  just updates the default stream. Also, this method now returns void,
  rather than int, since there are no errors.

This patch also removes the "early log" mechanism and cleans up the
log initialization mechanism:
* The default log stream defaults to stderr on all platforms if
  eal_log_set_default hasn't been invoked (Linux used to use stdout
  during the first part of initialization).
* Removed rte_eal_log_early_init; all of the desired functionality can
  be achieved by calling eal_log_set_default.
* Removed lib/librte_eal/bsdapp/eal/eal_log.c: it contained only one
  function, rte_eal_log_init, which is not needed or invoked for BSD.
* Removed declaration for eal_default_log_stream in rte_log.h (it's now
  private to eal_common_log.c).
* Moved call to rte_eal_log_init earlier in rte_eal_init for Linux, so
  that it starts using the preferrred log ASAP.

Signed-off-by: John Ousterhout 

v4:
* Fixed problems from checkpatches.

v3:
* Made stderr the initial default log stream for Linux.
* Deleted lib/librte_eal/bsdapp/eal/eal_log.c.
* Deleted declaration for eal_default_log_stream in rte_log.h.
* Moved rte_eal_log_init call for Linux.

v2:
* Removed the early log mechanism, renamed rte_eal_common_log_init.
---
 lib/librte_eal/bsdapp/eal/Makefile  |  3 +-
 lib/librte_eal/bsdapp/eal/eal.c |  6 
 lib/librte_eal/bsdapp/eal/eal_log.c | 57 -
 lib/librte_eal/common/eal_common_log.c  | 30 ++---
 lib/librte_eal/common/eal_private.h | 16 +++--
 lib/librte_eal/common/include/rte_log.h |  5 +--
 lib/librte_eal/linuxapp/eal/eal.c   |  9 ++
 lib/librte_eal/linuxapp/eal/eal_log.c   | 40 +--
 8 files changed, 29 insertions(+), 137 deletions(-)
 delete mode 100644 lib/librte_eal/bsdapp/eal/eal_log.c

diff --git a/lib/librte_eal/bsdapp/eal/Makefile 
b/lib/librte_eal/bsdapp/eal/Makefile
index 7a0fea5..34340c1 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -50,12 +50,11 @@ EXPORT_MAP := rte_eal_version.map

 LIBABIVER := 3

-# specific to linuxapp exec-env
+# specific to bsdapp exec-env
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_memory.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_hugepage_info.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_thread.c
-SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_log.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_pci.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_debug.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_lcore.c
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index a0c8f8c..6a6ae86 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -501,9 +501,6 @@ rte_eal_init(int argc, char **argv)

thread_id = pthread_self();

-   if (rte_eal_log_early_init() < 0)
-   rte_panic("Cannot init early logs\n");
-
eal_log_level_parse(argc, argv);

/* set log level as early as possible */
@@ -552,9 +549,6 @@ rte_eal_init(int argc, char **argv)
if (rte_eal_tailqs_init() < 0)
rte_panic("Cannot init tail queues for objects\n");

-/* if (rte_eal_log_init(argv[0], internal_config.syslog_facility) < 0)
-   rte_panic("Cannot init logs\n");*/
-
if (rte_eal_alarm_init() < 0)
rte_panic("Cannot init interrupt-handling thread\n");

diff --git a/lib/librte_eal/bsdapp/eal/eal_log.c 
b/lib/librte_eal/bsdapp/eal/eal_log.c
deleted file mode 100644
index a425f7a..000
--- a/lib/librte_eal/bsdapp/eal/eal_log.c
+++ /dev/null
@@ -1,57 +0,0 @@
-/*-
- *   BSD LICENSE
- *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
- *   All rights reserved.
- *
- *   Redistribution and use in source and binary forms, with or without
- *   modification, are permitted provided that the following conditions
- *   are met:
- *
- * * Redistributions of source code must retain the above copyright
- *   notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- *   notice, this list of conditions and the following disclaimer in
- *   the documentation and/or other materials provided 

[dpdk-dev] [PATCH v3] log: respect rte_openlog_stream calls before rte_eal_init

[John Ousterhout]

Before this patch, application-specific loggers could not be
installed before rte_eal_init completed (the initialization process
called rte_openlog_stream, overwriting any previously installed
logger). This made it impossible for an application to capture the
initial log messages generated during rte_eal_init. This patch changes
initialization so that information from a previous call to
rte_openlog_stream is not lost. Specifically:
* The default log stream is now maintained separately from an
  application-specific log stream installed with rte_openlog_stream.
* rte_eal_common_log_init has been renamed to eal_log_set_default,
  since this is all it does. It no longer invokes rte_openlog_stream; it
  just updates the default stream. Also, this method now returns void,
  rather than int, since there are no errors.

This patch also removes the "early log" mechanism and cleans up the
log initialization mechanism:
* The default log stream defaults to stderr on all platforms if
  eal_log_set_default hasn't been invoked (Linux used to use stdout
  during the first part of initialization).
* Removed rte_eal_log_early_init; all of the desired functionality can
  be achieved by calling eal_log_set_default.
* Removed lib/librte_eal/bsdapp/eal/eal_log.c: it contained only one
  function, rte_eal_log_init, which is not needed or invoked for BSD.
* Removed declaration for eal_default_log_stream in rte_log.h (it's now
  private to eal_common_log.c).
* Moved call to rte_eal_log_init earlier in rte_eal_init for Linux, so
  that it starts using the preferrred log ASAP.

Signed-off-by: John Ousterhout 

v3:
* Made stderr the initial default log stream for Linux.
* Deleted lib/librte_eal/bsdapp/eal/eal_log.c.
* Deleted declaration for eal_default_log_stream in rte_log.h.
* Moved rte_eal_log_init call for Linux.

v2:
* Removed the early log mechanism, renamed rte_eal_common_log_init.
---
 lib/librte_eal/bsdapp/eal/Makefile  |  3 +-
 lib/librte_eal/bsdapp/eal/eal.c |  6 
 lib/librte_eal/bsdapp/eal/eal_log.c | 57 -
 lib/librte_eal/common/eal_common_log.c  | 29 ++---
 lib/librte_eal/common/eal_private.h | 16 +++--
 lib/librte_eal/common/include/rte_log.h |  5 +--
 lib/librte_eal/linuxapp/eal/eal.c   |  9 ++
 lib/librte_eal/linuxapp/eal/eal_log.c   | 40 +--
 8 files changed, 28 insertions(+), 137 deletions(-)
 delete mode 100644 lib/librte_eal/bsdapp/eal/eal_log.c

diff --git a/lib/librte_eal/bsdapp/eal/Makefile 
b/lib/librte_eal/bsdapp/eal/Makefile
index 7a0fea5..34340c1 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -50,12 +50,11 @@ EXPORT_MAP := rte_eal_version.map

 LIBABIVER := 3

-# specific to linuxapp exec-env
+# specific to bsdapp exec-env
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_memory.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_hugepage_info.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_thread.c
-SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_log.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_pci.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_debug.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_lcore.c
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index a0c8f8c..6a6ae86 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -501,9 +501,6 @@ rte_eal_init(int argc, char **argv)

thread_id = pthread_self();

-   if (rte_eal_log_early_init() < 0)
-   rte_panic("Cannot init early logs\n");
-
eal_log_level_parse(argc, argv);

/* set log level as early as possible */
@@ -552,9 +549,6 @@ rte_eal_init(int argc, char **argv)
if (rte_eal_tailqs_init() < 0)
rte_panic("Cannot init tail queues for objects\n");

-/* if (rte_eal_log_init(argv[0], internal_config.syslog_facility) < 0)
-   rte_panic("Cannot init logs\n");*/
-
if (rte_eal_alarm_init() < 0)
rte_panic("Cannot init interrupt-handling thread\n");

diff --git a/lib/librte_eal/bsdapp/eal/eal_log.c 
b/lib/librte_eal/bsdapp/eal/eal_log.c
deleted file mode 100644
index a425f7a..000
--- a/lib/librte_eal/bsdapp/eal/eal_log.c
+++ /dev/null
@@ -1,57 +0,0 @@
-/*-
- *   BSD LICENSE
- *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
- *   All rights reserved.
- *
- *   Redistribution and use in source and binary forms, with or without
- *   modification, are permitted provided that the following conditions
- *   are met:
- *
- * * Redistributions of source code must retain the above copyright
- *   notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- *   notice, this list of conditions and the following disclaimer in
- *   the documentation and/or other materials provided with the
- *   distribution.
- * * 

[dpdk-dev] [PATCH v3 0/5] vhost: optimize enqueue

[Wang, Zhihong]

> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> Sent: Wednesday, October 12, 2016 10:53 AM
> To: Wang, Zhihong ; Jianbo Liu  linaro.org>
> Cc: Maxime Coquelin ; dev at dpdk.org; Thomas
> Monjalon 
> Subject: Re: [dpdk-dev] [PATCH v3 0/5] vhost: optimize enqueue
> 
> On Thu, Sep 22, 2016 at 01:47:45PM +0800, Jianbo Liu wrote:
> > On 22 September 2016 at 10:29, Yuanhan Liu 
> wrote:
> > > On Wed, Sep 21, 2016 at 08:54:11PM +0800, Jianbo Liu wrote:
> > >> >> > My setup consists of one host running a guest.
> > >> >> > The guest generates as much 64bytes packets as possible using
> > >> >>
> > >> >> Have you tested with other different packet size?
> > >> >> My testing shows that performance is dropping when packet size is more
> > >> >> than 256.
> > >> >
> > >> >
> > >> > Hi Jianbo,
> > >> >
> > >> > Thanks for reporting this.
> > >> >
> > >> >  1. Are you running the vector frontend with mrg_rxbuf=off?
> > >> >
> > Yes, my testing is mrg_rxbuf=off, but not vector frontend PMD.
> >
> > >> >  2. Could you please specify what CPU you're running? Is it Haswell
> > >> > or Ivy Bridge?
> > >> >
> > It's an ARM server.
> >
> > >> >  3. How many percentage of drop are you seeing?
> > The testing result:
> > size (bytes) improvement (%)
> > 64   3.92
> > 128 11.51
> > 256  24.16
> > 512  -13.79
> > 1024-22.51
> > 1500-12.22
> > A correction is that performance is dropping if byte size is larger than 
> > 512.
> 
> I have thought of this twice. Unfortunately, I think I may need NACK this
> series.
> 
> Merging two code path into one is really good: as you stated, it improves
> the maintainability. But only if we see no performance regression on both
> path after the refactor. Unfortunately, that's not the case here: it hurts
> the performance for one code path (non-mrg Rx).
> 
> That makes me think we may should not do the code path merge at all. I think
> that also aligns with what you have said before (internally): we could do the
> merge if it gives comparable performance before and after that.
> 
> Besides that, I don't quite like the way you did in patch 2 (rewrite enqueue):
> you made a lot of changes in one patch. That means if something wrong
> happened,
> it is hard to narrow down which change introduces that regression. Badly,
> that's exactly what we met here. Weeks have been passed, I see no progress.
> 
> That's the reason we like the idea of "one patch only does one thing, an
> atomic thing".


Yuanhan, folks,

Thanks for the analysis. I disagree here though.

I analyze, develop, benchmark on x86 platforms, where this patch
works great.

I've been trying to analyze on ARM too but it takes time and I've
had a schedule. Also since the ARM perf issue comes when it's
v6 already, I might not be able to make it in time. However
that's what I have to do for this patch to be merged in this
or the next release.

In the meantime, may I suggest we consider the possibility to
have dedicated codes for **perf critical paths** for different
kinds of architecture?

It can be hard for a person to have both the knowledge and the
development environment for multiple archs at the same time.

Moreover, different optimization techniques might be required for
different archs, so it's hard and unnecessary to make a function
works for all archs, sometimes it's just not the right thing to do.


Thanks
Zhihong


> 
> So I will apply the first patch (it's a bug fixing patch) and ask you to
> refactor the rest, without the code path merge.
> 
> I think we could still have a good maintainability code base if we introduce
> more common helper functions that can be used on both Rx path, or even on
> Tx path (such as update_used_ring, or shadow_used_ring).
> 
> It's a bit late for too many changes for v16.11. I think you could just
> grab patch 6 (vhost: optimize cache access) to the old mrg-Rx code path,
> if that also helps the performance? Let us handle the left in next release,
> such as shadow used ring.
> 
> Thanks.
> 
>   --yliu

[dpdk-dev] [Qemu-devel] [PATCH 1/2] vhost: enable any layout feature

[Yuanhan Liu]

On Tue, Oct 11, 2016 at 02:57:49PM +0800, Yuanhan Liu wrote:
> > > > > > There was an example: the vhost enqueue optmization patchset from
> > > > > > Zhihong [0] uses memset, and it introduces more than 15% drop (IIRC)

Though it doesn't matter now, but I have verified it yesterday (with and
wihtout memset), the drop could be up to 30+%.

This is to let you know that it could behaviour badly if memset is not
inlined.

> > > > > > on my Ivybridge server: it has no such issue on his server though.
> > > > > >
> > > > > > [0]: http://dpdk.org/ml/archives/dev/2016-August/045272.html
> > > > > >
> > > > > > --yliu
> > > > >
> > > > > I'd say that's weird. what's your config? any chance you
> > > > > are using an old compiler?
> > > > 
> > > > Not really, it's gcc 5.3.1. Maybe Zhihong could explain more. IIRC,
> > > > he said the memset is not well optimized for Ivybridge server.
> > > 
> > > The dst is remote in that case. It's fine on Haswell but has complication
> > > in Ivy Bridge which (wasn't supposed to but) causes serious frontend 
> > > issue.
> > > 
> > > I don't think gcc inlined it there. I'm using fc24 gcc 6.1.1.
> > 
> > 
> > So try something like this then:
> 
> Yes, I saw memset is inlined when this diff is applied.

I have another concern though: It's a trick could let gcc do the inline,
I am not quite sure whether that's ture with other compilers (i.e. clang,
icc, or even, older gcc).

For this case, I think I still prefer some trick like
*(struct ..*) = {0, }

Or even, we may could introduce rte_memset(). IIRC, that has been
proposed somehow before?

--yliu

[dpdk-dev] [PATCH] net/enic: remove assert which causes compile error

[John Daley]

Remove an RTE_ASSERT which will not compile if enabled and is not needed.

Fixes: a1f7c7b3b5b2 ("net/enic: extend fdir support for 1300 series adapters")

Signed-off-by: John Daley 
---
Would have been nice if I caught this yesterday before you applied a1f7c7b3 :(

 drivers/net/enic/enic_clsf.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/enic/enic_clsf.c b/drivers/net/enic/enic_clsf.c
index c709be9..d2413d7 100644
--- a/drivers/net/enic/enic_clsf.c
+++ b/drivers/net/enic/enic_clsf.c
@@ -142,8 +142,6 @@ copy_fltr_v2(struct filter_v2 *fltr, struct 
rte_eth_fdir_input *input,
struct filter_generic_1 *gp = >u.generic_1;
int i;

-   RTE_ASSERT(enic->adv_filters);
-
fltr->type = FILTER_DPDK_1;
memset(gp, 0, sizeof(*gp));

-- 
2.10.0

[dpdk-dev] [PATCH] examples/l2fwd-crypto: fix verify with decrypt in chain

[Piotr Azarewicz]

This patch fix setting crypto operation data parameters in l2fwd-crypto
application.
>From now decryption in chain with auth verify work fine.

How to reproduce the issue:

1. Run l2fwd_crypto with command:
-c 0x3 -n 4 --vdev "crypto_aesni_mb" \
--vdev "crypto_aesni_mb" \
-- -p 0x3 --chain CIPHER_HASH \
--cipher_op ENCRYPT --cipher_algo AES_CBC \
--cipher_key 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f \
--iv 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:ff \
--auth_op GENERATE --auth_algo SHA1_HMAC \
--auth_key
11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:
11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:
11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11

2. Send packet with payload and capture forwarded packet.
Payload in forwarded packet is encrypted, what is good.

3. Run l2fwd_crypto with command:
-c 0x3 -n 4 --vdev "crypto_aesni_mb" \
--vdev "crypto_aesni_mb" \
-- -p 0x3 --chain HASH_CIPHER \
--cipher_op DECRYPT --cipher_algo AES_CBC \
--cipher_key 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f \
--iv 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:ff \
--auth_op VERIFY --auth_algo SHA1_HMAC \
--auth_key
11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:
11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:
11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11

4. Send earlier captured packet and capture forwarded packet.
Payload in newly captured packet is not decrypted, what is wrong.

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

Signed-off-by: Piotr Azarewicz 
---
 examples/l2fwd-crypto/main.c |   23 ---
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index dae45f5..43fef59 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -451,6 +451,10 @@ l2fwd_simple_crypto_enqueue(struct rte_mbuf *m,

/* Zero pad data to be crypto'd so it is block aligned */
data_len  = rte_pktmbuf_data_len(m) - ipdata_offset;
+
+   if (cparams->do_hash && cparams->hash_verify)
+   data_len -= cparams->digest_length;
+
pad_len = data_len % cparams->block_size ? cparams->block_size -
(data_len % cparams->block_size) : 0;

@@ -472,8 +476,8 @@ l2fwd_simple_crypto_enqueue(struct rte_mbuf *m,
op->sym->auth.digest.data = (uint8_t 
*)rte_pktmbuf_append(m,
cparams->digest_length);
} else {
-   op->sym->auth.digest.data = (uint8_t 
*)rte_pktmbuf_append(m,
-   cparams->digest_length);
+   op->sym->auth.digest.data = rte_pktmbuf_mtod(m,
+   uint8_t *) + ipdata_offset + data_len;
}

op->sym->auth.digest.phys_addr = rte_pktmbuf_mtophys_offset(m,
@@ -508,21 +512,10 @@ l2fwd_simple_crypto_enqueue(struct rte_mbuf *m,
cparams->cipher_algo == 
RTE_CRYPTO_CIPHER_KASUMI_F8 ||
cparams->cipher_algo == 
RTE_CRYPTO_CIPHER_ZUC_EEA3) {
op->sym->cipher.data.offset = ipdata_offset << 3;
-   if (cparams->do_hash && cparams->hash_verify)
-   /* Do not cipher the hash tag */
-   op->sym->cipher.data.length = (data_len -
-   cparams->digest_length) << 3;
-   else
-   op->sym->cipher.data.length = data_len << 3;
-
+   op->sym->cipher.data.length = data_len << 3;
} else {
op->sym->cipher.data.offset = ipdata_offset;
-   if (cparams->do_hash && cparams->hash_verify)
-   /* Do not cipher the hash tag */
-   op->sym->cipher.data.length = data_len -
-   cparams->digest_length;
-   else
-   op->sym->cipher.data.length = data_len;
+   op->sym->cipher.data.length = data_len;
}
}

-- 
1.7.9.5

[dpdk-dev] [PATCH v3 0/5] vhost: optimize enqueue

[Yuanhan Liu]

On Thu, Sep 22, 2016 at 01:47:45PM +0800, Jianbo Liu wrote:
> On 22 September 2016 at 10:29, Yuanhan Liu  
> wrote:
> > On Wed, Sep 21, 2016 at 08:54:11PM +0800, Jianbo Liu wrote:
> >> >> > My setup consists of one host running a guest.
> >> >> > The guest generates as much 64bytes packets as possible using
> >> >>
> >> >> Have you tested with other different packet size?
> >> >> My testing shows that performance is dropping when packet size is more
> >> >> than 256.
> >> >
> >> >
> >> > Hi Jianbo,
> >> >
> >> > Thanks for reporting this.
> >> >
> >> >  1. Are you running the vector frontend with mrg_rxbuf=off?
> >> >
> Yes, my testing is mrg_rxbuf=off, but not vector frontend PMD.
> 
> >> >  2. Could you please specify what CPU you're running? Is it Haswell
> >> > or Ivy Bridge?
> >> >
> It's an ARM server.
> 
> >> >  3. How many percentage of drop are you seeing?
> The testing result:
> size (bytes) improvement (%)
> 64   3.92
> 128 11.51
> 256  24.16
> 512  -13.79
> 1024-22.51
> 1500-12.22
> A correction is that performance is dropping if byte size is larger than 512.

I have thought of this twice. Unfortunately, I think I may need NACK this
series.

Merging two code path into one is really good: as you stated, it improves
the maintainability. But only if we see no performance regression on both 
path after the refactor. Unfortunately, that's not the case here: it hurts
the performance for one code path (non-mrg Rx).

That makes me think we may should not do the code path merge at all. I think
that also aligns with what you have said before (internally): we could do the
merge if it gives comparable performance before and after that.

Besides that, I don't quite like the way you did in patch 2 (rewrite enqueue):
you made a lot of changes in one patch. That means if something wrong happened,
it is hard to narrow down which change introduces that regression. Badly,
that's exactly what we met here. Weeks have been passed, I see no progress.

That's the reason we like the idea of "one patch only does one thing, an
atomic thing".

So I will apply the first patch (it's a bug fixing patch) and ask you to
refactor the rest, without the code path merge.

I think we could still have a good maintainability code base if we introduce 
more common helper functions that can be used on both Rx path, or even on
Tx path (such as update_used_ring, or shadow_used_ring).

It's a bit late for too many changes for v16.11. I think you could just
grab patch 6 (vhost: optimize cache access) to the old mrg-Rx code path,
if that also helps the performance? Let us handle the left in next release,
such as shadow used ring.

Thanks.

--yliu

[dpdk-dev] [PATCH v4] drivers/net:new PMD using tun/tap host interface

[Michał Mirosław]

2016-10-11 22:56 GMT+02:00 Wiles, Keith :
>> On Oct 11, 2016, at 6:30 AM, Micha? Miros?aw  wrote:
>>
>> 2016-10-04 16:45 GMT+02:00, Keith Wiles :
>>> The rte_eth_tap.c PMD creates a device using TUN/TAP interfaces
>>> on the local host. The PMD allows for DPDK and the host to
>>> communicate using a raw device interface on the host and in
>>> the DPDK application. The device created is a Tap device with
>>> a L2 packet header.
>> [...]
>>> +static uint16_t
>>> +pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>>> +{
>>> +int len, n;
>>> +struct rte_mbuf *mbuf;
>>> +struct rx_queue *rxq = queue;
>>> +struct pollfd pfd;
>>> +uint16_t num_rx;
>>> +unsigned long num_rx_bytes = 0;
>>> +
>>> +pfd.events = POLLIN;
>>> +pfd.fd = rxq->fd;
>>> +for (num_rx = 0; num_rx < nb_pkts; ) {
>>> +n = poll(, 1, 0);
>>> +
>>> +if (n <= 0)
>>> +break;
>>> +
>>
>> Considering that syscalls are rather expensive, it would be cheaper to
>> allocate an mbuf here and free it when read() returns -1 instead of
>> calling poll() to check whether a packet is waiting. This way you
>> save a syscall per packet and replace one syscall with one mbuf free
>> per poll.
>
> I made this change, but saw no performance difference in the two methods. 
> Removing poll seems reasonable as it is simpler. TAP is already so slow is 
> why the performance did not change is my guess. Anyone wanting to use TAP as 
> a high performance interface is going to be surprised. I believe the best use 
> case for the TAP interface is for control or exception path.

Agreed, TAP does not look like designed for performance as a first goal.

You could do the same simplification for TX path, BTW.

Best Regards,
Micha? Miros?aw

[dpdk-dev] ZUC PMD as shared library

[Thomas Monjalon]

2016-10-12 02:23, De Lara Guarch, Pablo:
> Hi Thomas,
> 
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > 
> > Hi Pablo,
> > 
> > You are probably aware of the issue, but I would like to make it clear
> > in case someone else run into the same trouble:
> > 
> > It is impossible to build the ZUC crypto PMD as a shared library:
> > 
> > libsso-zuc-0.1.1/build/libsso_zuc.a(sso_zuc_yasm.o):
> > relocation R_X86_64_32 against `EK_d' can not be used
> > when making a shared object; recompile with -fPIC
> > 
> > The library libsso-zuc-0.1.1 needs an update to make the asm code
> > relocatable.
> > Should we explicit this limitation in the PMD doc?
> 
> Sorry for not replying to this earlier.
> Yes, you are right, thanks for pointing it out.
> I think the same problem is in KASUMI, so I will send a doc update for both 
> PMDs.

No, KASUMI works as shared library, because there is no asm code.

Documenting the bug would be nice as a first step.
But it is a serious bug, so a fix in ZUC library is highly desirable.

[dpdk-dev] [PATCH v2] log: respect rte_openlog_stream calls before rte_eal_init

[Thomas Monjalon]

2016-10-11 14:46, John Ousterhout:
> All of your suggestions look reasonable and fairly straightforward; I'll
> work on a new patch that includes them.
> 
> Given that rte_eal_log_init is a no-op (and won't even be invoked), would
> it be better to remove that function completely, and even delete the file
> containing it (eal_log.c), or is it better to retain the empty function in
> order to maintain a parallel structure with Linux? Personally I'd lean
> towards deleting the file. As it stands, the interface to that function
> doesn't even make sense for BSD; the arguments were chosen for Linux and
> are ignored in BSD.
> 
> Let me know your preference.

Yes you can remove the file.

[dpdk-dev] [PATCH 1/5] i40e: extract non-x86 specific code from vector driver

[Zhang, Qi Z]

Hi Jianbo

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jianbo Liu
> Sent: Wednesday, August 24, 2016 5:54 PM
> To: Zhang, Helin ; Wu, Jingjing
> ; jerin.jacob at caviumnetworks.com; dev at dpdk.org
> Cc: Jianbo Liu 
> Subject: [dpdk-dev] [PATCH 1/5] i40e: extract non-x86 specific code from 
> vector
> driver
> 
> move scalar code which does not use x86 intrinsic functions to new file
> "i40e_rxtx_vec_common.h", while keeping x86 code in i40e_rxtx_vec.c.
> This allows the scalar code to to be shared among vector drivers for different
> platforms.
> 
> Signed-off-by: Jianbo Liu 
> ---
>  drivers/net/i40e/i40e_rxtx_vec.c| 184 +---
>  drivers/net/i40e/i40e_rxtx_vec_common.h | 239
> 
>  2 files changed, 243 insertions(+), 180 deletions(-)  create mode 100644
> drivers/net/i40e/i40e_rxtx_vec_common.h
> 
> diff --git a/drivers/net/i40e/i40e_rxtx_vec.c 
> b/drivers/net/i40e/i40e_rxtx_vec.c
> index 51fb282..f847469 100644
> --- a/drivers/net/i40e/i40e_rxtx_vec.c
> +++ b/drivers/net/i40e/i40e_rxtx_vec.c
> @@ -39,6 +39,7 @@
>  #include "base/i40e_type.h"
>  #include "i40e_ethdev.h"
>  #include "i40e_rxtx.h"
> +#include "i40e_rxtx_vec_common.h"
> 
>  #include 
> 
> @@ -421,68 +422,6 @@ i40e_recv_pkts_vec(void *rx_queue, struct rte_mbuf
> **rx_pkts,
>   return _recv_raw_pkts_vec(rx_queue, rx_pkts, nb_pkts, NULL);  }
> 
> -static inline uint16_t
> -reassemble_packets(struct i40e_rx_queue *rxq, struct rte_mbuf **rx_bufs,
> -uint16_t nb_bufs, uint8_t *split_flags)
> -{
> - struct rte_mbuf *pkts[RTE_I40E_VPMD_RX_BURST]; /*finished pkts*/
> - struct rte_mbuf *start = rxq->pkt_first_seg;
> - struct rte_mbuf *end =  rxq->pkt_last_seg;
> - unsigned pkt_idx, buf_idx;
> -
> - for (buf_idx = 0, pkt_idx = 0; buf_idx < nb_bufs; buf_idx++) {
> - if (end != NULL) {
> - /* processing a split packet */
> - end->next = rx_bufs[buf_idx];
> - rx_bufs[buf_idx]->data_len += rxq->crc_len;
> -
> - start->nb_segs++;
> - start->pkt_len += rx_bufs[buf_idx]->data_len;
> - end = end->next;
> -
> - if (!split_flags[buf_idx]) {
> - /* it's the last packet of the set */
> - start->hash = end->hash;
> - start->ol_flags = end->ol_flags;
> - /* we need to strip crc for the whole packet */
> - start->pkt_len -= rxq->crc_len;
> - if (end->data_len > rxq->crc_len) {
> - end->data_len -= rxq->crc_len;
> - } else {
> - /* free up last mbuf */
> - struct rte_mbuf *secondlast = start;
> -
> - while (secondlast->next != end)
> - secondlast = secondlast->next;
> - secondlast->data_len -= (rxq->crc_len -
> - end->data_len);
> - secondlast->next = NULL;
> - rte_pktmbuf_free_seg(end);
> - end = secondlast;
> - }
> - pkts[pkt_idx++] = start;
> - start = end = NULL;
> - }
> - } else {
> - /* not processing a split packet */
> - if (!split_flags[buf_idx]) {
> - /* not a split packet, save and skip */
> - pkts[pkt_idx++] = rx_bufs[buf_idx];
> - continue;
> - }
> - end = start = rx_bufs[buf_idx];
> - rx_bufs[buf_idx]->data_len += rxq->crc_len;
> - rx_bufs[buf_idx]->pkt_len += rxq->crc_len;
> - }
> - }
> -
> - /* save the partial packet for next time */
> - rxq->pkt_first_seg = start;
> - rxq->pkt_last_seg = end;
> - memcpy(rx_bufs, pkts, pkt_idx * (sizeof(*pkts)));
> - return pkt_idx;
> -}
> -
>   /* vPMD receive routine that reassembles scattered packets
>   * Notice:
>   * - nb_pkts < RTE_I40E_DESCS_PER_LOOP, just return no packet @@
> -548,73 +487,6 @@ vtx(volatile struct i40e_tx_desc *txdp,
>   vtx1(txdp, *pkt, flags);
>  }
> 
> -static inline int __attribute__((always_inline)) -i40e_tx_free_bufs(struct
> i40e_tx_queue *txq) -{
> - struct i40e_tx_entry *txep;
> - uint32_t n;
> - uint32_t i;
> - int nb_free = 0;
> - struct rte_mbuf *m, *free[RTE_I40E_TX_MAX_FREE_BUF_SZ];
> -
> - /* check DD bits on threshold descriptor */
> 

[dpdk-dev] [PATCH 2/5] i40e: implement vector PMD for ARM architecture

[Zhang, Qi Z]

Hi Jianbo:

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jianbo Liu
> Sent: Wednesday, August 24, 2016 5:54 PM
> To: Zhang, Helin ; Wu, Jingjing
> ; jerin.jacob at caviumnetworks.com; dev at dpdk.org
> Cc: Jianbo Liu 
> Subject: [dpdk-dev] [PATCH 2/5] i40e: implement vector PMD for ARM
> architecture
> 
> Use ARM NEON intrinsic to implement i40e vPMD
> 
> Signed-off-by: Jianbo Liu 
> ---
>  drivers/net/i40e/Makefile |   4 +
>  drivers/net/i40e/i40e_rxtx_vec_neon.c | 581
> ++
>  2 files changed, 585 insertions(+)
>  create mode 100644 drivers/net/i40e/i40e_rxtx_vec_neon.c
> 
> diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile index
> 53fe145..9e92b38 100644
> --- a/drivers/net/i40e/Makefile
> +++ b/drivers/net/i40e/Makefile
> @@ -97,7 +97,11 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_dcb.c
> 
>  SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_ethdev.c
>  SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_rxtx.c
> +ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
> +SRCS-$(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR) += i40e_rxtx_vec_neon.c
> else
>  SRCS-$(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR) += i40e_rxtx_vec.c
> +endif
>  SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_ethdev_vf.c
>  SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_pf.c
>  SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_fdir.c diff --git
> a/drivers/net/i40e/i40e_rxtx_vec_neon.c
> b/drivers/net/i40e/i40e_rxtx_vec_neon.c
> new file mode 100644
> index 000..015fa9f
> --- /dev/null
> +++ b/drivers/net/i40e/i40e_rxtx_vec_neon.c
> @@ -0,0 +1,581 @@
> +/*-
> + *   BSD LICENSE
> + *
> + *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> + *   Copyright(c) 2016, Linaro Limited
> + *   All rights reserved.
> + *
> + *   Redistribution and use in source and binary forms, with or without
> + *   modification, are permitted provided that the following conditions
> + *   are met:
> + *
> + * * Redistributions of source code must retain the above copyright
> + *   notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + *   notice, this list of conditions and the following disclaimer in
> + *   the documentation and/or other materials provided with the
> + *   distribution.
> + * * Neither the name of Intel Corporation nor the names of its
> + *   contributors may be used to endorse or promote products derived
> + *   from this software without specific prior written permission.
> + *
> + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
> BUT NOT
> + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> LOSS OF USE,
> + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND ON ANY
> + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
> OF THE USE
> + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "base/i40e_prototype.h"
> +#include "base/i40e_type.h"
> +#include "i40e_ethdev.h"
> +#include "i40e_rxtx.h"
> +#include "i40e_rxtx_vec_common.h"
> +
> +#include 
> +
> +#pragma GCC diagnostic ignored "-Wcast-qual"
> +
> +static inline void
> +i40e_rxq_rearm(struct i40e_rx_queue *rxq) {
> + int i;
> + uint16_t rx_id;
> + volatile union i40e_rx_desc *rxdp;
> + struct i40e_rx_entry *rxep = >sw_ring[rxq->rxrearm_start];
> + struct rte_mbuf *mb0, *mb1;
> + uint64x2_t dma_addr0, dma_addr1;
> + uint64x2_t zero = vdupq_n_u64(0);
> + uint64_t paddr;
> + uint8x8_t p;
> +
> + rxdp = rxq->rx_ring + rxq->rxrearm_start;
> +
> + /* Pull 'n' more MBUFs into the software ring */
> + if (unlikely(rte_mempool_get_bulk(rxq->mp,
> +   (void *)rxep,
> +   RTE_I40E_RXQ_REARM_THRESH) < 0)) {
> + if (rxq->rxrearm_nb + RTE_I40E_RXQ_REARM_THRESH >=
> + rxq->nb_rx_desc) {
> + for (i = 0; i < RTE_I40E_DESCS_PER_LOOP; i++) {
> + rxep[i].mbuf = >fake_mbuf;
> + vst1q_u64((uint64_t *)[i].read, zero);
> + }
> + }
> + rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed +=
> + RTE_I40E_RXQ_REARM_THRESH;
> + return;
> + }
> +
> + p = vld1_u8((uint8_t *)>mbuf_initializer);
> +
> + /* Initialize 

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

[Zhao1, Wei]

Hi  Adrien Mazarguil,

> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Tuesday, October 11, 2016 4:21 PM
> To: Zhao1, Wei 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [RFC v2] Generic flow 
> director/filtering/classification
> API
> 
> Hi Wei,
> 
> On Tue, Oct 11, 2016 at 01:47:53AM +, Zhao1, Wei wrote:
> > Hi  Adrien Mazarguil,
> >  There is a struct rte_flow_action_rss in rte_flow.txt, the  member
> rss_conf is a pointer type, is there any convenience in using pointer?
> > Why not using  struct rte_eth_rss_conf rss_conf type, as
> rte_flow_item_ipv4/ rte_flow_item_ipv6 struct member?
> >
> > Thank you.
> >
> >  struct rte_flow_action_rss {
> > struct rte_eth_rss_conf *rss_conf; /**< RSS parameters. */
> > uint16_t queues; /**< Number of entries in queue[]. */
> > uint16_t queue[]; /**< Queues indices to use. */ };
> 
> Well I thought it made sharing flow RSS configuration with its counterpart in
> struct rte_eth_conf easier (this pointer should even be const). Also, while
> ABI breakage would still occur if rte_eth_rss_conf happened to be modified,
> the impact on this API would be limited as it would not cause a change in
> structure size. We'd ideally need some kind of version field to be completely
> safe but I guess that would be somewhat overkill.
> 
> Now considering this API was written without an initial implementation, all
> structure definitions that do not make sense are still open to debate, we can
> adjust them as needed.
> 
> --
> Adrien Mazarguil
> 6WIND

Your explanation seems very reasonable for me, structure pointer is an very 
experienced usage in this situation.
Thank you!

[dpdk-dev] [PATCH] hash: fix incorrect bucket size usage

[Pablo de Lara]

Multiwriter insert function was using a fixed value for
the bucket size, instead of using the
RTE_HASH_BUCKET_ENTRIES macro, which value was changed
recently (making it inconsistent in this case).

Fixes: be856325cba3 ("hash: add scalable multi-writer insertion with Intel TSX")

Signed-off-by: Pablo de Lara 
---
 lib/librte_hash/rte_cuckoo_hash_x86.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/librte_hash/rte_cuckoo_hash_x86.h 
b/lib/librte_hash/rte_cuckoo_hash_x86.h
index 47aec6d..0c94244 100644
--- a/lib/librte_hash/rte_cuckoo_hash_x86.h
+++ b/lib/librte_hash/rte_cuckoo_hash_x86.h
@@ -167,7 +167,8 @@ rte_hash_cuckoo_make_space_mw_tm(const struct rte_hash *h,

/* Cuckoo bfs Search */
while (likely(tail != head && head <
-   queue + RTE_HASH_BFS_QUEUE_MAX_LEN - 
4)) {
+   queue + RTE_HASH_BFS_QUEUE_MAX_LEN -
+   RTE_HASH_BUCKET_ENTRIES)) {
curr_bkt = tail->bkt;
for (i = 0; i < RTE_HASH_BUCKET_ENTRIES; i++) {
if (curr_bkt->key_idx[i] == EMPTY_SLOT) {
-- 
2.7.4

[dpdk-dev] ZUC PMD as shared library

[De Lara Guarch, Pablo]

Hi Thomas,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Saturday, October 08, 2016 10:19 AM
> To: De Lara Guarch, Pablo
> Cc: dev at dpdk.org
> Subject: ZUC PMD as shared library
> 
> Hi Pablo,
> 
> You are probably aware of the issue, but I would like to make it clear
> in case someone else run into the same trouble:
> 
> It is impossible to build the ZUC crypto PMD as a shared library:
> 
> libsso-zuc-0.1.1/build/libsso_zuc.a(sso_zuc_yasm.o):
>   relocation R_X86_64_32 against `EK_d' can not be used
>   when making a shared object; recompile with -fPIC
> 
> The library libsso-zuc-0.1.1 needs an update to make the asm code
> relocatable.
> Should we explicit this limitation in the PMD doc?

Sorry for not replying to this earlier.
Yes, you are right, thanks for pointing it out.
I think the same problem is in KASUMI, so I will send a doc update for both 
PMDs.

Thanks,
Pablo

[dpdk-dev] [PATCH v7 2/2] app/test_pmd: add tests for new API's

[De Lara Guarch, Pablo]

Hi,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Iremonger, Bernard
> Sent: Tuesday, October 11, 2016 9:35 AM
> To: Thomas Monjalon
> Cc: Yigit, Ferruh; dev at dpdk.org; Shah, Rahul R; Lu, Wenzhuo;
> az5157 at att.com
> Subject: Re: [dpdk-dev] [PATCH v7 2/2] app/test_pmd: add tests for new API's
> 
> Hi Thomas,
> 
> 
> 
> > > > Subject: Re: [dpdk-dev] [PATCH v7 2/2] app/test_pmd: add tests for
> > > > new API's
> > > >
> > > > 2016-10-11 16:09, Ferruh Yigit:
> > > > > This will cause a compilation error for shared libraries. Because
> > > > > PMDs not linked against application when compiled as shared
> > > > > library but used as plugins.
> > > > >
> > > > > Since it has been decided to have NIC specific APIs, we need to
> > > > > re-work that approach to fix shared library compilation.
> > > >
> > > > If testpmd uses the ixgbe API, it must be linked with the PMD.
> > > > Is there any issue adapting the testpmd makefile?
> > > > Hope that dlopen an already linked PMD is nicely managed.
> > >
> > > The ixgbe API will  be used by other apps, for example Virtual
> > > Function Daemon (VFD) Moving the following line in rte.app.mak solves
> > > the problem
> > >
> > > Line 117: _LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD)  += -
> > lrte_pmd_ixgbe
> > >
> > > To Line 103.
> > >
> > > Will this be acceptable?
> >
> > I think we must not link PMD in the general case but let this 
> > responsibility to
> > the application in case it uses some specific functions.
> > Does it make sense?
> 
> Yes, ok, will just modify the testpmd makefile  for this case.

A couple of things:
You would need to use #ifdef RTE_LIBRTE_IXGBE_PMD in testpmd, right?
In case IXGBE is not available (maybe just modifying the makefile solves the 
problem).

Could you also add these new functions in the testpmd help?
Just add them in cmd_help_long_parsed.

Thanks,
Pablo

> 
> Regards,
> 
> Bernard.

[dpdk-dev] [PATCH v2] hash: fix unlimited cuckoo path

[Pablo de Lara]

When trying to insert a new entry, if its target bucket is full,
the alternative location (bucket) of one of the entries is checked,
to try to find an empty slot, with make_space_bucket.
This function is called every time a new bucket is checked, recursively.
To avoid having a very long insert operation (and to avoid filling up
the stack), a limit in the number of pushes is introduced.

Fixes: 48a399119619 ("hash: replace with cuckoo hash implementation")

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

Changes in v2:
- Included Fixes line

 lib/librte_hash/rte_cuckoo_hash.c | 6 +-
 lib/librte_hash/rte_cuckoo_hash.h | 2 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/lib/librte_hash/rte_cuckoo_hash.c 
b/lib/librte_hash/rte_cuckoo_hash.c
index 3324b17..51db006 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -419,6 +419,7 @@ rte_hash_reset(struct rte_hash *h)
 static inline int
 make_space_bucket(const struct rte_hash *h, struct rte_hash_bucket *bkt)
 {
+   static unsigned int nr_pushes;
unsigned i, j;
int ret;
uint32_t next_bucket_idx;
@@ -455,11 +456,13 @@ make_space_bucket(const struct rte_hash *h, struct 
rte_hash_bucket *bkt)
break;

/* All entries have been pushed, so entry cannot be added */
-   if (i == RTE_HASH_BUCKET_ENTRIES)
+   if (i == RTE_HASH_BUCKET_ENTRIES || nr_pushes > RTE_HASH_MAX_PUSHES)
return -ENOSPC;

/* Set flag to indicate that this entry is going to be pushed */
bkt->flag[i] = 1;
+
+   nr_pushes++;
/* Need room in alternative bucket to insert the pushed entry */
ret = make_space_bucket(h, next_bkt[i]);
/*
@@ -469,6 +472,7 @@ make_space_bucket(const struct rte_hash *h, struct 
rte_hash_bucket *bkt)
 * or return error
 */
bkt->flag[i] = 0;
+   nr_pushes = 0;
if (ret >= 0) {
next_bkt[i]->sig_alt[ret] = bkt->sig_current[i];
next_bkt[i]->sig_current[ret] = bkt->sig_alt[i];
diff --git a/lib/librte_hash/rte_cuckoo_hash.h 
b/lib/librte_hash/rte_cuckoo_hash.h
index c00aafa..1b8ffed 100644
--- a/lib/librte_hash/rte_cuckoo_hash.h
+++ b/lib/librte_hash/rte_cuckoo_hash.h
@@ -140,6 +140,8 @@ enum add_key_case {

 #define LCORE_CACHE_SIZE   64

+#define RTE_HASH_MAX_PUSHES 100
+
 #define RTE_HASH_BFS_QUEUE_MAX_LEN   1000

 #define RTE_XABORT_CUCKOO_PATH_INVALIDED 0x4
-- 
2.7.4

[dpdk-dev] [PATCH] hash: fix unlimited cuckoo path

[Pablo de Lara]

When trying to insert a new entry, if its target bucket is full,
the alternative location (bucket) of one of the entries is checked,
to try to find an empty slot, with make_space_bucket.
This function is called every time a new bucket is checked, recursively.
To avoid having a very long insert operation (and to avoid filling up
the stack), a limit in the number of pushes is introduced.

Signed-off-by: Pablo de Lara 
---
 lib/librte_hash/rte_cuckoo_hash.c | 6 +-
 lib/librte_hash/rte_cuckoo_hash.h | 2 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/lib/librte_hash/rte_cuckoo_hash.c 
b/lib/librte_hash/rte_cuckoo_hash.c
index 3324b17..51db006 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -419,6 +419,7 @@ rte_hash_reset(struct rte_hash *h)
 static inline int
 make_space_bucket(const struct rte_hash *h, struct rte_hash_bucket *bkt)
 {
+   static unsigned int nr_pushes;
unsigned i, j;
int ret;
uint32_t next_bucket_idx;
@@ -455,11 +456,13 @@ make_space_bucket(const struct rte_hash *h, struct 
rte_hash_bucket *bkt)
break;

/* All entries have been pushed, so entry cannot be added */
-   if (i == RTE_HASH_BUCKET_ENTRIES)
+   if (i == RTE_HASH_BUCKET_ENTRIES || nr_pushes > RTE_HASH_MAX_PUSHES)
return -ENOSPC;

/* Set flag to indicate that this entry is going to be pushed */
bkt->flag[i] = 1;
+
+   nr_pushes++;
/* Need room in alternative bucket to insert the pushed entry */
ret = make_space_bucket(h, next_bkt[i]);
/*
@@ -469,6 +472,7 @@ make_space_bucket(const struct rte_hash *h, struct 
rte_hash_bucket *bkt)
 * or return error
 */
bkt->flag[i] = 0;
+   nr_pushes = 0;
if (ret >= 0) {
next_bkt[i]->sig_alt[ret] = bkt->sig_current[i];
next_bkt[i]->sig_current[ret] = bkt->sig_alt[i];
diff --git a/lib/librte_hash/rte_cuckoo_hash.h 
b/lib/librte_hash/rte_cuckoo_hash.h
index c00aafa..1b8ffed 100644
--- a/lib/librte_hash/rte_cuckoo_hash.h
+++ b/lib/librte_hash/rte_cuckoo_hash.h
@@ -140,6 +140,8 @@ enum add_key_case {

 #define LCORE_CACHE_SIZE   64

+#define RTE_HASH_MAX_PUSHES 100
+
 #define RTE_HASH_BFS_QUEUE_MAX_LEN   1000

 #define RTE_XABORT_CUCKOO_PATH_INVALIDED 0x4
-- 
2.7.4

[dpdk-dev] [PATCH 1/4] testpmd: Add support to configure 25G and 50G speeds

[De Lara Guarch, Pablo]

Hi,

> From: Ajit Khaparde [mailto:ajit.khaparde at broadcom.com]
> Sent: Monday, October 10, 2016 11:41 AM
> To: Yigit, Ferruh
> Cc: dev at dpdk.org; De Lara Guarch, Pablo
> Subject: Re: [dpdk-dev] [PATCH 1/4] testpmd: Add support to configure 25G
> and 50G speeds
> 
> On Mon, Oct 10, 2016 at 10:01 AM, Ferruh Yigit 
> wrote:
> Hi Ajit,
> 
> On 9/29/2016 6:03 PM, Ajit Khaparde wrote:
> > Support to configure 25G and 50G speeds is missing from testpmd.
> > This patch also updates the testpmd user guide accordingly.
> >
> > Signed-off-by: Ajit Khaparde 
> 
> This patch seems not really part of the patchset for bnxt driver, but
> standalone testpmd only modification,
> ??
> and can be threaded as single patch.
> ?OK. Got it.
> I had worked on this change in the middle of other things.
> ?So it got bundled along with other bnxt patches.
> 
> 
> I am adding testpmd maintainer to cc.
> ?Let me know if you want me to send it again as a standalone patch.

Yes, I think it is a good idea.
Apart from that, there are a couple of things to fix:

There are two lines that exceed the character limit (from checkpatch):
WARNING: line over 80 characters
#55: FILE: app/test-pmd/cmdline.c:1084:
+   .help_str = "port config all speed 
10|100|1000|1|25000|4|5|10|auto duplex "

WARNING: line over 80 characters
#73: FILE: app/test-pmd/cmdline.c:1159:
+   .help_str = "port config X speed 
10|100|1000|1|25000|4|5|10|auto duplex "

check-git-log.sh complains about the title:

Wrong headline label:
testpmd: Add support to configure 25G and 50G speeds
Wrong headline uppercase:
testpmd: Add support to configure 25G and 50G speeds

Title should be "app/testpmd: add "

Could you send a separate v2 with this changes?
And probably change the bnxt patchset to 3 patches only.

Thanks,
Pablo

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

[Jerin Jacob]

Thanks to Intel and NXP folks for the positive and constructive feedback
I've received so far. Here is the updated RFC(v2).

I've attempted to address as many comments as possible.

This series adds rte_eventdev.h to the DPDK tree with
adequate documentation in doxygen format.

Updates are also available online:

Related draft header file (this patch):
https://rawgit.com/jerinjacobk/libeventdev/master/rte_eventdev.h

PDF version(doxgen output):
https://rawgit.com/jerinjacobk/libeventdev/master/librte_eventdev_v2.pdf

Repo:
https://github.com/jerinjacobk/libeventdev

v1..v2

- Added Cavium, Intel, NXP copyrights in header file

- Changed the concept of flow queues to flow ids.
This is avoid dictating a specific structure to hold the flows.
A s/w implementation can do atomic load balancing on multiple
flow ids more efficiently than maintaining each event in a specific flow queue.

- Change the scheduling group to event queue.
A scheduling group is more a stream of events, so an event queue is a better
 abstraction.

- Introduced event port concept, Instead of trying eventdev access to the lcore,
a higher level of abstraction called event port is needed which is the
application i/f to the eventdev to dequeue and enqueue the events.
One or more event queues can be linked to single event port.
There can be more than one event port per lcore allowing multiple lightweight
threads to have their own i/f into eventdev, if the implementation supports it.
An event port will be bound to a lcore or a lightweight thread to keep
portable application workflow.
An event port abstraction also encapsulates dequeue depth and enqueue depth for
a scheduler implementations which can schedule multiple events at a time and
output events that can be buffered.

- Added configuration options with event queue(nb_atomic_flows,
nb_atomic_order_sequences, single consumer etc)
and event port(dequeue_queue_depth, enqueue_queue_depth etc) to define the
limits on the resource usage.(Useful for optimized software implementation)

- Introduced RTE_EVENT_DEV_CAP_QUEUE_QOS and RTE_EVENT_DEV_CAP_EVENT_QOS
schemes of priority handling

- Added event port to event queue servicing priority.
This allows two event ports to connect to the same event queue with
different priorities.

- Changed the workflow as schedule/dequeue/enqueue.
An implementation is free to define schedule as NOOP.
A distributed s/w scheduler can use this to schedule events;
also a centralized s/w scheduler can make this a NOOP on non-scheduler cores.

- Removed Cavium HW specific schedule_from_group API

- Removed Cavium HW specific ctxt_update/ctxt_wait APIs.
 Introduced a more generic "event pinning" concept. i.e
If the normal workflow is a dequeue -> do work based on event type -> enqueue,
a pin_event argument to enqueue
where the pinned event is returned through the normal dequeue)
allows application workflow to remain the same whether or not an
implementation supports it.

- Added dequeue() burst variant

- Added the definition of a closed/open system - where open system is memory
backed and closed system eventdev has limited capacity.
In such systems, it is also useful to denote per event port how many packets
can be active in the system.
This can serve as a threshold for ethdev like devices so they don't overwhelm
core to core events.

- Added the option to specify maximum amount of time(in ns) application needs
wait on dequeue()

- Removed the scheme of expressing the number of flows in log2 format

Open item or the item needs improvement.

- Abstract the differences in event QoS management with different priority 
schemes
available in different HW or SW implementations with portable application 
workflow.

Based on the feedback, there three different kinds of QoS support available in
three different HW or SW implementations.
1) Priority associated with the event queue
2) Priority associated with each event enqueue
(Same flow can have two different priority on two separate enqueue)
3) Priority associated with the flow(each flow has unique priority)

In v2, The differences abstracted based on device capability
(RTE_EVENT_DEV_CAP_QUEUE_QOS for the first scheme,
RTE_EVENT_DEV_CAP_EVENT_QOS for the second and third scheme).
This scheme would call for different application workflow for
nontrivial QoS-enabled applications.

Looking forward to getting comments from both application and driver
implementation perspective.

/Jerin

---
 doc/api/doxy-api-index.md  |1 +
 doc/api/doxy-api.conf  |1 +
 lib/librte_eventdev/rte_eventdev.h | 1204 
 3 files changed, 1206 insertions(+)
 create mode 100644 lib/librte_eventdev/rte_eventdev.h

diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 6675f96..28c1329 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -40,6 +40,7 @@ There are many libraries, so their headers may be grouped by 
topics: