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

[Thomas Monjalon]

2016-03-22 21:51, Bruce Richardson:
> On Mon, Mar 21, 2016 at 02:18:43PM +0800, Jingjing Wu wrote:
> > v5 changes:
> >  - remove the reorganizing of struct rte_eth_fdir_flow
> >  - remove fdir supporting on Tunnel Id
> >  - rebase to latest dpdk/master
> >
> Thomas, given the above removal, are you ok with the ethdev changes now 
> present
> in this patchset?

Of course, yes.

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

[Markos Chandras]

Hi,

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

I can add this information to the commit message and send a v2 if needed.

> 
>> -GCC_VERSION = $(subst .,,$(shell $(CC) -dumpversion | cut -f1-2 -d.))
>> +GCC_MAJOR = $(shell echo __GNUC__ | $(CC) -E -x c - | tail -n 1)
>> +GCC_MINOR = $(shell echo __GNUC_MINOR__ | $(CC) -E -x c - | tail -n 1)
>> +GCC_VERSION = $(GCC_MAJOR)$(GCC_MINOR)
> 
> Are we sure the minor will always be only one digit?
> 

Well, I can't be sure but minor has always been a single digit since gcc
>= 3 if I am not mistaken. But does it matter? What if it is two or more
digits? The previous code did something similar so if you had gcc
5.12.34 installed (and lets assume this is what is being returned by
-dumpversion), it would have returned 512. The comparison would still
work as it is at the moment no?

-- 
markos

[dpdk-dev] Error when starting testpmd in dpdk 2.2.0 ("Creation of mbuf pool for socket 0 failed")

[Kevin Wilson]

Hi,

I am getting the following error while running testpmd:

RING: Cannot reserve memory

EAL: Error - exiting with code: 1
  Cause:  Creation of mbuf pool for socket 0 failed

I am running it thus:

build/app/testpmd --log-level 8 -c7 -n3 -- \
  -i --nb-cores=2 --nb-ports=2 --pkt-filter-mode=perfect

And I followed the instruction on http://dpdk.org/doc/quick-start

However, on my machine, as opposed to what appears in the link above,
there is no

/sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepage

, and under /sys/devices/system/node I have only a single node called "node1".

I don't know what is the reason for this, this is Fedora 23 x86_64
standard distro and a standard kernel (4.2.3-300.fc23.x86_64), and on
a different machine I **do** have node0.

So instead

echo 64 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages

I run

echo 64 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages

Could this be related somehow to the problem I have ?

More info:
This is a 16 core machine.

I also delved a bit into the code and added a debug message which
prints the pool name in the method where the failure occur,
mbuf_pool_create(),  and this is what I see:

calling rte_pktmbuf_pool_create(), pool_name=mbuf_pool_socket_0 in
mbuf_pool_create

Any ideas ?

Regards,
Kevin

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

[Bruce Richardson]

On Mon, Mar 21, 2016 at 02:18:43PM +0800, Jingjing Wu wrote:
> v5 changes:
>  - remove the reorganizing of struct rte_eth_fdir_flow
>  - remove fdir supporting on Tunnel Id
>  - rebase to latest dpdk/master
>
Thomas, given the above removal, are you ok with the ethdev changes now present
in this patchset?

/Bruce

[dpdk-dev] Question on examples/multi_process app

[Bruce Richardson]

On Tue, Mar 22, 2016 at 08:03:42PM +, Harish Patil wrote:
> Hi,
> I have a question regarding symmetric_mp and mp_server applications under
> examples/multi_process. In those apps, rte_eth_promiscuous_enable() is
> called before rte_eth_dev_start(). Is this the correct way to initialize
> the port/device? As per the description in
> http://dpdk.org/doc/api/rte__ethdev_8h.html:
> 
> "The functions exported by the application Ethernet API to setup a device
> designated by its port identifier must be invoked in the following order:
> 
> * rte_eth_dev_configure()
> * rte_eth_tx_queue_setup()
> * rte_eth_rx_queue_setup()
> * rte_eth_dev_start()
> 
> Then, the network application can invoke, in any order, the functions
> exported by the Ethernet API to get the MAC address of a given device, to
> get the speed and the status of a device physical link, to
> receive/transmit [burst of] packets, and so on.?
> 
> So should I consider this as an application issue or whether the PMD is
> expected to handle it? If PMD is to handle it, then should the PMD be:
> 
> 1) Rejecting the Promisc config? OR
> 2) Cache the config and apply when dev_start() is called at later point?
> 
> Thanks,
> Harish
> 
Good question. I think most/all of the Intel adapters, - for which the app was
originally written, way back in the day when there were only 2 PMDs in DPDK :)
- will handle the promiscuous mode call either before or after the dev start.
Assuming that's the case, and if it makes life easier for other driver writers,
we should indeed standardize on one supported way of doing things - the way
specified in the documentation being that one way, I would guess.

So, e1000, ixgbe maintainers - do you see any issues with forcing the 
promiscuous
mode set API to be called after the call to dev_start()?

/Bruce

[dpdk-dev] [PATCH v2 3/3] l2fwd-crypto: add NULL in cipher/auth algo list

[Pablo de Lara]

NULL crypto operation is now supported, but l2fwd-crypto
was missing an update on the list of supported algorithms
that can be passed from command line.

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

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index f8713e4..cb3bdbe 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -859,6 +859,9 @@ parse_cipher_algo(enum rte_crypto_cipher_algorithm *algo, 
char *optarg)
} else if (strcmp("AES_GCM", optarg) == 0) {
*algo = RTE_CRYPTO_CIPHER_AES_GCM;
return 0;
+   } else if (strcmp("NULL", optarg) == 0) {
+   *algo = RTE_CRYPTO_CIPHER_NULL;
+   return 0;
} else if (strcmp("SNOW3G_UEA2", optarg) == 0) {
*algo = RTE_CRYPTO_CIPHER_SNOW3G_UEA2;
return 0;
@@ -916,6 +919,9 @@ parse_auth_algo(enum rte_crypto_auth_algorithm *algo, char 
*optarg)
} else if (strcmp("MD5_HMAC", optarg) == 0) {
*algo = RTE_CRYPTO_AUTH_MD5_HMAC;
return 0;
+   } else if (strcmp("NULL", optarg) == 0) {
+   *algo = RTE_CRYPTO_AUTH_NULL;
+   return 0;
} else if (strcmp("SHA1_HMAC", optarg) == 0) {
*algo = RTE_CRYPTO_AUTH_SHA1_HMAC;
return 0;
-- 
2.5.0

[dpdk-dev] [PATCH v2 2/3] l2fwd-crypto: add AES GCM in auth algo list

[Pablo de Lara]

AES GCM is an algorithm for both ciphering and authentication,
but the authentication algorithm was missing in the
list of supported algorithms that can be passed from command line.

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

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 2fd0778..f8713e4 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -910,7 +910,10 @@ parse_key(uint8_t *data, char *input_arg)
 static int
 parse_auth_algo(enum rte_crypto_auth_algorithm *algo, char *optarg)
 {
-   if (strcmp("MD5_HMAC", optarg) == 0) {
+   if (strcmp("AES_GCM", optarg) == 0) {
+   *algo = RTE_CRYPTO_AUTH_AES_GCM;
+   return 0;
+   } else if (strcmp("MD5_HMAC", optarg) == 0) {
*algo = RTE_CRYPTO_AUTH_MD5_HMAC;
return 0;
} else if (strcmp("SHA1_HMAC", optarg) == 0) {
-- 
2.5.0

[dpdk-dev] [PATCH v2 1/3] l2fwd-crypto: add SNOW3G algorithms

[Pablo de Lara]

Since SNOW3G UEA2/UIA2 are supported now by both HW and SW,
l2fwd-crypto may use them, extending the list of algorithms
parsed from command line.

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

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 762d22a..2fd0778 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -178,6 +178,9 @@ struct l2fwd_crypto_params {
uint8_t do_cipher;
uint8_t do_hash;
uint8_t hash_verify;
+
+   enum rte_crypto_cipher_algorithm cipher_algo;
+   enum rte_crypto_auth_algorithm auth_algo;
 };

 /** lcore configuration */
@@ -426,8 +429,14 @@ l2fwd_simple_crypto_enqueue(struct rte_mbuf *m,
rte_pktmbuf_pkt_len(m) - 
cparams->digest_length);
op->sym->auth.digest.length = cparams->digest_length;

-   op->sym->auth.data.offset = ipdata_offset;
-   op->sym->auth.data.length = data_len;
+   /* For SNOW3G algorithms, offset/length must be in bits */
+   if (cparams->auth_algo == RTE_CRYPTO_AUTH_SNOW3G_UIA2) {
+   op->sym->auth.data.offset = ipdata_offset << 3;
+   op->sym->auth.data.length = data_len << 3;
+   } else {
+   op->sym->auth.data.offset = ipdata_offset;
+   op->sym->auth.data.length = data_len;
+   }

if (cparams->aad.length) {
op->sym->auth.aad.data = cparams->aad.data;
@@ -441,13 +450,25 @@ l2fwd_simple_crypto_enqueue(struct rte_mbuf *m,
op->sym->cipher.iv.phys_addr = cparams->iv.phys_addr;
op->sym->cipher.iv.length = cparams->iv.length;

-   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;
+   /* For SNOW3G algorithms, offset/length must be in bits */
+   if (cparams->cipher_algo == RTE_CRYPTO_CIPHER_SNOW3G_UEA2) {
+   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;
+
+   } 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->m_src = m;
@@ -630,6 +651,8 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)
port_cparams[i].hash_verify = 1;
else
port_cparams[i].hash_verify = 0;
+
+   port_cparams[i].auth_algo = 
options->auth_xform.auth.algo;
}

if (port_cparams[i].do_cipher) {
@@ -640,6 +663,7 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)
generate_random_key(port_cparams[i].iv.data,

sizeof(port_cparams[i].iv.length));

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

port_cparams[i].session = initialize_crypto_session(options,
@@ -835,6 +859,9 @@ parse_cipher_algo(enum rte_crypto_cipher_algorithm *algo, 
char *optarg)
} else if (strcmp("AES_GCM", optarg) == 0) {
*algo = RTE_CRYPTO_CIPHER_AES_GCM;
return 0;
+   } else if (strcmp("SNOW3G_UEA2", optarg) == 0) {
+   *algo = RTE_CRYPTO_CIPHER_SNOW3G_UEA2;
+   return 0;
}

printf("Cipher algorithm  not supported!\n");
@@ -901,6 +928,9 @@ parse_auth_algo(enum rte_crypto_auth_algorithm *algo, char 
*optarg)
} else if (strcmp("SHA512_HMAC", optarg) == 0) {
*algo = RTE_CRYPTO_AUTH_SHA512_HMAC;
return 0;
+   } else if (strcmp("SNOW3G_UIA2", optarg) == 0) {
+   *algo = RTE_CRYPTO_AUTH_SNOW3G_UIA2;
+   return 0;
}

  

[dpdk-dev] [PATCH v2 0/3] Extend list of supported algorithms in L2fwd-crypto

[Pablo de Lara]

New cipher/authentication algorithms are supported in cryptodev,
so L2fwd-crypto needs to have the list of supported algorithms updated.

Changes in v2:
- Added other two algorithms
- Modified offset and length in bits for SNOW3G algorithms

Pablo de Lara (3):
  l2fwd-crypto: add SNOW3G algorithms
  l2fwd-crypto: add AES GCM in auth algo list
  l2fwd-crypto: add NULL in cipher/auth algo list

 examples/l2fwd-crypto/main.c | 59 
 1 file changed, 49 insertions(+), 10 deletions(-)

-- 
2.5.0

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

[Zhe Tao]

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

start
=

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

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

Signed-off-by: Zhe Tao 
---
 drivers/net/i40e/i40e_rxtx.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 1488f2f..ffd6dba 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -1545,6 +1545,7 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, 
uint16_t nb_pkts)
uint16_t slen;
uint64_t buf_dma_addr;
union i40e_tx_offload tx_offload = {0};
+   bool enable_checksum = 0;

txq = tx_queue;
sw_ring = txq->sw_ring;
@@ -1620,7 +1621,13 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts, uint16_t nb_pkts)

/* Enable checksum offloading */
cd_tunneling_params = 0;
-   if (ol_flags & I40E_TX_CKSUM_OFFLOAD_MASK) {
+   /* Check whether need to do checksum or not */
+   if ((ol_flags & I40E_TX_CKSUM_OFFLOAD_MASK) ||
+   ((ol_flags & PKT_TX_IPV6) && (ol_flags & PKT_TX_TCP_SEG))) {
+   enable_checksum = 1;
+   }
+
+   if (enable_checksum) {
i40e_txd_enable_checksum(ol_flags, _cmd, _offset,
tx_offload, _tunneling_params);
}
-- 
2.1.4

[dpdk-dev] [PATCH 3/8] drivers/net/e1000: Fix missing brackets

[Thomas Monjalon]

2016-03-01 13:02, Panu Matilainen:
> On 02/26/2016 03:13 PM, Aaron Conole wrote:
> > "Lu, Wenzhuo"  writes:
> >> Normally we will not maintain the base code. It's just taken from kernel 
> >> driver.
> >> Agree with you that the whitespace is misleading. But as it's no real
> >> impact. I'd like to say not a big deal, better not change it. :)
> >
> > Thanks for this hint. It turns out my patch is wrong. It should actually
> > be this (and I've confirmed by looking at the drivers):
[...]
> > I will cook up a v2 of this patch if it makes sense. It is a real bug,
> > so should be fixed.

Yes, waiting for your v2.

> Yes, it quite clearly is a real bug and there needs to be a documented 
> way of getting these things fixed. The README in the base/ directory is 
> not particularly helpful, since it only says "dont touch it".

Yes don't touch it ;)

> This is apparently fixed in FreeBSD codebase so fixing it would be 
> "just" a matter of pulling in a newer version.

Probably.

> The other alternatives are either disabling the whole driver in gcc 6 
> builds, or paper over the bug with warning disablers, or have everybody 
> patch their packages locally to fix it, all of which just feel so stupid 
> they're not alternatives, really.

No they are not sane alternatives.

> OTOH the bug has been there for 2.5 years (since commit 
> 38db3f7f50bde45477f564783a06ac8fbd3348fa) and nobody has noticed...
> 
> Thomas, Bruce, thoughts/comments?

It is in the hands of Wenzhuo, the e1000 maintainer.
You just need his ack.

[dpdk-dev] [PATCH 1/8] lpm: Fix pointer aliasing issues

[Thomas Monjalon]

2016-02-25 21:30, Bruce Richardson:
> On Thu, Feb 25, 2016 at 01:48:34PM -0500, Aaron Conole wrote:
> >  /**
> > + * Convert from tbl_entry types to integer types
> > + */
> > +static inline uint16_t
> > +rte_lpm_tbl24_entry_to_uint16(const struct rte_lpm_tbl24_entry *entry)
> > +{
> > +   union {
> > +   uint16_t   i;
> > +   struct rte_lpm_tbl24_entry s;
> > +   } tbl_entry_u;
> > +
> > +   tbl_entry_u.s = *entry;
> > +   return tbl_entry_u.i;
> > +}
> > +
> > +static inline uint16_t
> > +rte_lpm_tbl8_entry_to_uint16(const struct rte_lpm_tbl8_entry *entry)
> > +{
> > +   union {
> > +   uint16_t  i;
> > +   struct rte_lpm_tbl8_entry s;
> > +   } tbl_entry_u;
> > +
> > +   tbl_entry_u.s = *entry;
> > +   return tbl_entry_u.i;
> > +}
> > +
> 
> These two new functions could be reduced to one with the help of patch:
> http://dpdk.org/dev/patchwork/patch/9087/

Aaron, any news about a rework of this patch?

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

[Thomas Monjalon]

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

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

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

[dpdk-dev] [PATCH v3] mk: fix eal shared library dependencies -lrt

[Thomas Monjalon]

2016-03-22 13:51, Daniel Mrzyglod:
> For GLIBC < 2.17 it is necessery to add -lrt for linker
> from glibc > 2.17 The `clock_*' suite of functions (declared in ) is 
> now
> available directly in the main C library. This affect Ubuntu 12.04 in i686
> and other older Linux Distros).
> 
> v3: change LDFLAGS to LDLIBS
> v2: Add missed example
> v1: Initial revision
> 
> 
> Fixes: 4758404a3084 ("mk: fix eal shared library dependencies")
> 
> Signed-off-by: Daniel Mrzyglod 

Applied, thanks

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

[Daniele Di Proietto]

Hi Christian,

thanks for the report.  I've managed to reproduce the problem and I
observed two separate issues:

1) short version: it appears to be a problem in DPDK 2.2 and it should be
fixed by 9a0615af7746("virtio: fix restart"), now on master.

long version:

for every DPDK device added to OVS, these calls are issued:

netdev_open()
...
   rte_eth_dev_configure()
   rte_eth_rx_queue_setup()
   rte_eth_dev_start()

before receiving packets, the datapath calls netdev_set_multiq, which
reinitializes the device

netdev_set_multiq()
...
   rte_eth_dev_stop()
   rte_eth_dev_configure()
   rte_eth_rx_queue_setup()
   rte_eth_dev_start()

The problem is that the second rte_eth_dev_start() doesn't actually
initializes dev->data->rx_queues[0], because it (wrongly?) assumes that
it's already initialized. This causes the next call to rte_eth_ex_burst()
to crash.

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

2) When ovs-vswitchd is started with --monitor, there will be a parent
process (the monitor) that simply restarts the child if it crashes, while
the child does the actual ovs-vswitchd job.

It appears that the monitor feature is broken with DPDK, because the DPDK
library is wrongly initialized in the parent process.  If the child
crashes, all the DPDK memzones are preserved, meaning that new allocations
will likely fail.

The fix for this is calling rte_eal_init() in the child process, after
parsing other ovs-vswitchd command line options. This is done (among other
things) in Aaron's series currently under review:

http://openvswitch.org/pipermail/dev/2016-March/067422.html

I think we need a separate fix for branch-2.5.

On 18/03/2016 08:20, "Christian Ehrhardt"
 wrote:

>Hi,
>I was trying to replicate a setup that I have working on physical devices
>(ixgbe) under kvm since there is a virtio pmd driver.
>
>
>TL;DR:
>- under KVM with virtio-pci (working on baremetal with ixgbe cards)
>- adding dpdk port to ovs fails with memzone  already exists
>and causes a segfault
>- I couldn't find a solution in similar mails that popped up here
>recently, any help or pointer appreciated.
>
>
>## Details ##
>I thought I've read that others have it working I thought that would be a
>great way to gain more debug control of the environment, but something
>seems to be eluding me.
>
>
>There were quite some similar mails on the List recently, but none seemed
>to hit the same issue as I do. At least none of the tunings/workarounds
>seemed to apply to me.
>
>As versions I have Openvswitch 2.5, DPDK 2.2, Qemu 2.5, Kernel 4.4 - so a
>fairly recent software stack.
>
>
>The super-short repro summary is:
>1. starting ovs-dpdk like
>ovs-vswitchd --dpdk -c 0x1 -n 4 --pci-blacklist :00:03.0 -m 2048 --
>unix:/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info
>--mlockall --no-chdir --log-file=/var/log/openvswitch/ovs-vswitchd.log
>--pidfile=/var/run/openvswitch/ovs-vswitchd.pid
> --detach --monitor
>2. add a bridge and a ovs dpdk port
>
>ovs-vsctl add-port ovsdpdkbr0 dpdk0 -- set Interface dpdk0 type=dpdk
>
>ovs-vsctl add-port ovsdpdkbr0 dpdk0 -- set Interface dpdk0 type=dpdk
>
>
>
>The log of the initialization after #1 looks good to me - I can see two
>of my three virtio devices recognized and one blacklisted.
>Memory allocation looks good, ... I'll attach the log at the end of the
>mail
>
>
>
>
>## ISSUE ##
>But when I add a port and refer to one of the dpdk ports it fails with
>the following:
>ovs-vsctl[14023]: ovs|1|vsctl|INFO|Called as ovs-vsctl add-port
>ovsdpdkbr0 dpdk0 -- set Interface dpdk0 type=dpdk
>ovs-vswitchd[13903]: EAL: memzone_reserve_aligned_thread_unsafe():
>memzone  already exists
>ovs-vswitchd[13903]: EAL: memzone_reserve_aligned_thread_unsafe():
>memzone  already exists
>ovs-vswitchd[13903]: EAL: memzone_reserve_aligned_thread_unsafe():
>memzone  already exists
>kernel: show_signal_msg: 18 callbacks suppressed
>kernel: pmd12[14025]: segfault at 2 ip 7f3eb205eab2 sp
>7f3e3dffa590 error 4 in libdpdk.so.0[7f3eb1fdf000+1e9000]
>ovs-vswitchd[13902]: ovs|3|daemon_unix(monitor)|ERR|1 crashes: pid
>13903 died, killed (Segmentation fault), core dumped, restarting
>systemd-udevd[14040]: Could not generate persistent MAC address for
>ovs-netdev: No such file or directory
>kernel: device ovs-netdev entered promiscuous mode
>ovs-vswitchd[14036]: EAL: memzone_reserve_aligned_thread_unsafe():
>memzone  already exists
>ovs-vswitchd[14036]: RING: Cannot reserve memory
>kernel: device ovsdpdkbr0 entered promiscuous mode
>ovs-vswitchd[14036]: EAL: memzone_reserve_aligned_thread_unsafe():
>memzone  already exists
>ovs-vswitchd[14036]: RING: Cannot reserve memory
>
>
>
>
>
>## Experiments (failed) ##
>I thought it could be related to all the multiqueue chances that recently
>going in.
>My usual setup has 4 vCPUs and 4 queues per virtio-net device.
>I tried them with only 1 of 4 queues, also with only 1 queue defined and
>only 1 CPU - but all fail the same 

[dpdk-dev] [PATCH 2/2] mk: fix two more missing libm dependencies

[Thomas Monjalon]

2016-03-21 11:48, Ferruh Yigit:
> On 3/21/2016 11:33 AM, Panu Matilainen wrote:
> > Commit e86a699cf6b1 missed two further libm dependencies: ceil() used by
> > librte_meter is typically inlined so the missing dependency does not
> > actually cause failures, and librte_pmd_nfp is not built by default
> > so its easy to miss.
> > 
> > This causes duplicates in LDLIBS in many configurations so its vital
> > they are removed before passing to linker.
> > 
> > Fixes: e86a699cf6b1 ("mk: fix shared library dependencies on libm and 
> > librt")
> > 
> > Reported-by: Ferruh Yigit 
> > Signed-off-by: Panu Matilainen 
> 
> Tested-by: Ferruh Yigit 

Applied, thanks

[dpdk-dev] [PATCH] mk: restrict CPU flags list

[Thomas Monjalon]

2016-03-21 21:27, Thomas Monjalon:
> When compiling each file, the CPU flags are given as RTE_MACHINE_CPUFLAG_*
> and in the list RTE_COMPILE_TIME_CPUFLAGS.
> 
> RTE_MACHINE_CPUFLAG_* are used to check the CPU features when compiling.
> 
> The list RTE_COMPILE_TIME_CPUFLAGS is used only to check the CPU at
> runtime in the function rte_cpu_check_supported(). So it is not needed to
> define this list for every files.
> That's why RTE_COMPILE_TIME_CPUFLAGS is removed from the common variable
> MACHINE_CFLAGS and is added only to the CFLAGS of eal_common_cpuflags.c.
> 
> Signed-off-by: Thomas Monjalon 

Applied

[dpdk-dev] [PATCH] examples/l3fwd: remove old SSE4 comments

[Thomas Monjalon]

The flag ENABLE_MULTI_BUFFER_OPTIMIZE has been removed so the
related comments are now useless.

Fixes: 26b5b020 ("examples/l3fwd: modularize")

Signed-off-by: Thomas Monjalon 
---
 examples/l3fwd/l3fwd_em.c  | 9 -
 examples/l3fwd/l3fwd_lpm.c | 8 
 2 files changed, 17 deletions(-)

Applied

diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 50f09e5..526b485 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -314,11 +314,6 @@ em_get_ipv6_dst_port(void *ipv6_hdr,  uint8_t portid, void 
*lookup_struct)
return (uint8_t)((ret < 0) ? portid : ipv6_l3fwd_out_if[ret]);
 }

-
-/*
- * Include header file if SSE4_1 is enabled for
- * buffer optimization i.e. ENABLE_MULTI_BUFFER_OPTIMIZE=1.
- */
 #if defined(__SSE4_1__)
 #if defined(NO_HASH_MULTI_LOOKUP)
 #include "l3fwd_em_sse.h"
@@ -592,10 +587,6 @@ em_main_loop(__attribute__((unused)) void *dummy)
if (nb_rx == 0)
continue;

-   /*
-* For SSE4_1 use ENABLE_MULTI_BUFFER_OPTIMIZE=1
-* code.
-*/
 #if defined(__SSE4_1__)
l3fwd_em_send_packets(nb_rx, pkts_burst,
portid, qconf);
diff --git a/examples/l3fwd/l3fwd_lpm.c b/examples/l3fwd/l3fwd_lpm.c
index 990a7f1..3767923 100644
--- a/examples/l3fwd/l3fwd_lpm.c
+++ b/examples/l3fwd/l3fwd_lpm.c
@@ -105,10 +105,6 @@ static struct ipv6_l3fwd_lpm_route 
ipv6_l3fwd_lpm_route_array[] = {
 struct rte_lpm *ipv4_l3fwd_lpm_lookup_struct[NB_SOCKETS];
 struct rte_lpm6 *ipv6_l3fwd_lpm_lookup_struct[NB_SOCKETS];

-/*
- * Include header file if SSE4_1 is enabled for
- * buffer optimization i.e. ENABLE_MULTI_BUFFER_OPTIMIZE=1.
- */
 #if defined(__SSE4_1__)
 #include "l3fwd_lpm_sse.h"
 #else
@@ -183,10 +179,6 @@ lpm_main_loop(__attribute__((unused)) void *dummy)
if (nb_rx == 0)
continue;

-   /*
-* For SSE4_1 use ENABLE_MULTI_BUFFER_OPTIMIZE=1
-* code.
-*/
 #if defined(__SSE4_1__)
l3fwd_lpm_send_packets(nb_rx, pkts_burst,
portid, qconf);
-- 
2.7.0

[dpdk-dev] Question on examples/multi_process app

[Harish Patil]

Hi,
I have a question regarding symmetric_mp and mp_server applications under
examples/multi_process. In those apps, rte_eth_promiscuous_enable() is
called before rte_eth_dev_start(). Is this the correct way to initialize
the port/device? As per the description in
http://dpdk.org/doc/api/rte__ethdev_8h.html:

"The functions exported by the application Ethernet API to setup a device
designated by its port identifier must be invoked in the following order:

* rte_eth_dev_configure()
* rte_eth_tx_queue_setup()
* rte_eth_rx_queue_setup()
* rte_eth_dev_start()

Then, the network application can invoke, in any order, the functions
exported by the Ethernet API to get the MAC address of a given device, to
get the speed and the status of a device physical link, to
receive/transmit [burst of] packets, and so on.?

So should I consider this as an application issue or whether the PMD is
expected to handle it? If PMD is to handle it, then should the PMD be:

1) Rejecting the Promisc config? OR
2) Cache the config and apply when dev_start() is called at later point?

Thanks,
Harish

[dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-process environment

[De Lara Guarch, Pablo]

Hi Thomas,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, March 22, 2016 11:42 AM
> To: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio
> Cc: dev at dpdk.org; Dhana Eadala; Richardson, Bruce; Qiu, Michael
> Subject: Re: [dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-
> process environment
> 
> Hi,
> 
> Pablo, Sergio, please could you help with this issue?

I agree this is not the best way to fix this. I will try to have a fix without 
having to use ifdefs.

Thanks,
Pablo
> 
> 2016-03-13 22:16, Dhana Eadala:
> > We found a problem in dpdk-2.2 using under multi-process environment.
> > Here is the brief description how we are using the dpdk:
> >
> > We have two processes proc1, proc2 using dpdk. These proc1 and proc2
> are
> > two different compiled binaries.
> > proc1 is started as primary process and proc2 as secondary process.
> >
> > proc1:
> > Calls srcHash = rte_hash_create("src_hash_name") to create rte_hash
> structure.
> > As part of this, this api initalized the rte_hash structure and set the
> > srcHash->rte_hash_cmp_eq to the address of memcmp() from proc1
> address space.
> >
> > proc2:
> > calls srcHash =  rte_hash_find_existing("src_hash_name").
> > This function call returns the rte_hash created by proc1.
> > This srcHash->rte_hash_cmp_eq still points to the address of
> > memcmp() from proc1 address space.
> > Later proc2  calls
> > rte_hash_lookup_with_hash(srcHash, (const void*) , key.sig);
> > rte_hash_lookup_with_hash() invokes __rte_hash_lookup_with_hash(),
> > which in turn calls h->rte_hash_cmp_eq(key, k->key, h->key_len).
> > This leads to a crash as h->rte_hash_cmp_eq is an address
> > from proc1 address space and is invalid address in proc2 address space.
> >
> > We found, from dpdk documentation, that
> >
> > "
> >  The use of function pointers between multiple processes
> >  running based of different compiled
> >  binaries is not supported, since the location of a given function
> >  in one process may be different to
> >  its location in a second. This prevents the librte_hash library
> >  from behaving properly as in a  multi-
> >  threaded instance, since it uses a pointer to the hash function internally.
> >
> >  To work around this issue, it is recommended that
> >  multi-process applications perform the hash
> >  calculations by directly calling the hashing function
> >  from the code and then using the
> >  rte_hash_add_with_hash()/rte_hash_lookup_with_hash() functions
> >  instead of the functions which do
> >  the hashing internally, such as rte_hash_add()/rte_hash_lookup().
> > "
> >
> > We did follow the recommended steps by invoking
> rte_hash_lookup_with_hash().
> > It was no issue up to and including dpdk-2.0.
> > In later releases started crashing because rte_hash_cmp_eq is
> > introduced in dpdk-2.1
> >
> > We fixed it with the following patch and would like to
> > submit the patch to dpdk.org.
> > Patch is created such that, if anyone wanted to use dpdk in
> > multi-process environment with function pointers not shared, they need to
> > define RTE_LIB_MP_NO_FUNC_PTR in their Makefile.
> > Without defining this flag in Makefile, it works as it is now.
> 
> Introducing #ifdef RTE_LIB_MP_NO_FUNC_PTR is not recommended.

[dpdk-dev] [PATCH] examples/performance-thread: fix build without SSE4.1

[Thomas Monjalon]

> clang reports these errors:
> 
> error: too many arguments to function call, expected 2, have 3
>   examples/performance-thread/l3fwd-thread/main.c:1220:1: note:
>   'l3fwd_simple_forward' declared here
> 
> examples/l3fwd/main.c:550:1: error: unused function 'send_packetsx4'
> 
> The function is used only when ENABLE_MULTI_BUFFER_OPTIMIZE is 1.
> 
> Fixes: d48415e1fee3 ("examples/performance-thread: add l3fwd-thread app")
> 
> Signed-off-by: Thomas Monjalon 

Applied

[dpdk-dev] [PATCH] examples/ip_pipeline: fix configuration parser

[Thomas Monjalon]

2016-03-14 12:22, Fan Zhang:
> Fixes: 377cd98e ("example/ip_pipeline: add link identification")
> 
> Signed-off-by: Fan Zhang 
> Acked-by: Cristian Dumitrescu 

Applied, thanks

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

[Stephen Hemminger]

On Mon, 21 Mar 2016 11:07:56 +0100
Thomas Monjalon  wrote:

> 2016-03-21 17:01, Qian Xu:
> > INTX is badly emulated in Vmware, INTX toggle check didn't work
> > with Vmware e1000 device. The patch is to fix the issue.
> 
> Is it possible to detect a VMware e1000 device?
> 
> > --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > case RTE_INTR_MODE_LEGACY:
> > -   if (pci_intx_mask_supported(dev)) {
> > -   dev_dbg(>dev, "using INTX");
> > -   udev->info.irq_flags = IRQF_SHARED;
> > -   udev->info.irq = dev->irq;
> > -   udev->mode = RTE_INTR_MODE_LEGACY;
> > -   break;
> > -   }
> > -   dev_notice(>dev, "PCI INTX mask not supported\n");
> > +dev_dbg(>dev, "using INTX");
> > +udev->info.irq_flags = IRQF_SHARED;
> > +udev->info.irq = dev->irq;
> > +udev->mode = RTE_INTR_MODE_LEGACY;
> > +break;
> > /* fall back to no IRQ */
> > case RTE_INTR_MODE_NONE:
> 
> This patch is removing the INTX support detection and the
> fallback to no IRQ.
> 

I agree with Thomas. If the kernel's "does INTx work" test fails then
most likely VMware is broken and later attempts to mask the interrupt
won't work. Better to have the DPDK abstraction layer
handle this. The EAL should:
 1) log a message when detected
 2) report that link state (and data) interrupts are not supported
by setting proper flags so application knows that LSC is not available.
 3) give an error return on all attempts to enable interrupts.

[dpdk-dev] [PATCH] testpmd: fix enumerated type mixed with another type

[Thomas Monjalon]

2016-03-22 15:52, Tomasz Kulasek:
> This patch fixes error #188: enumerated type mixed with another type,
> when uint32_t is casted on enum type in icc.
> 
> Fixes: 05f1b9c82ec2 ("app/testpmd: add commands for L2 tunnel config")
> 
> Signed-off-by: Tomasz Kulasek 

Applied, thanks

[dpdk-dev] [PATCH] doc: notify Rx errors not counting missed packets anymore

[Thomas Monjalon]

2016-03-22 16:57, Thomas Monjalon:
> Fixes: 86057c9992f5 ("ethdev: remove missed packets from error counter")
> 
> Suggested-by: Maryam Tahhan 
> Signed-off-by: Thomas Monjalon 
[...]
> +* The ethdev statistics counter imissed is considered exclusive with ierrors.
> +  Every drivers are now counting the missed packets only once, and not
> +  incrementing ierrors anymore for not received packets.
> +

Applied with this rewording:

* The ethdev statistics counter imissed is considered to be independent of 
ierrors.
  All drivers are now counting the missed packets only once, i.e. drivers will
  not increment ierrors anymore for missed packets.

Thanks Maryam for suggesting

[dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue

[Thomas Monjalon]

> > Issuing a zero objects dequeue with a single consumer has no effect.
> > Doing so with multiple consumers, can get more than one thread to succeed
> > the compare-and-set operation and observe starvation or even deadlock in
> > the while loop that checks for preceding dequeues.  The problematic piece
> > of code when n = 0:
> > 
> > cons_next = cons_head + n;
> > success = rte_atomic32_cmpset(>cons.head, cons_head, cons_next);
> > 
> > The same is possible on the enqueue path.
> > 
> > Signed-off-by: Lazaros Koromilas 
> 
> Acked-by: Olivier Matz 

Applied, thanks

[dpdk-dev] [PATCH] l2fwd-crypto: add SNOW3G algorithms

[De Lara Guarch, Pablo]

> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, March 22, 2016 1:17 PM
> To: dev at dpdk.org
> Cc: Doherty, Declan; De Lara Guarch, Pablo
> Subject: [PATCH] l2fwd-crypto: add SNOW3G algorithms
> 
> Since SNOW3G UEA2/UIA2 are supported now by both HW and SW,
> l2fwd-crypto may use them, extending the list of algorithms
> parsed from command line.
> 
> Signed-off-by: Pablo de Lara 

Nack, need to change the data length/offset to bits.

[dpdk-dev] [PATCH v2 7/7] drivers/net/ixgbe: Fix uninitialized warning

[Aaron Conole]

Silence a compiler warning that this variable may be used uninitialized.

Signed-off-by: Aaron Conole 
Acked-by: Helin Zhang 
---
v2:
* No change (apart from adding ACK)

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

diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index ff6ddb8..885fbd7 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -1614,7 +1614,7 @@ ixgbe_recv_pkts_lro(void *rx_queue, struct rte_mbuf 
**rx_pkts, uint16_t nb_pkts,
struct ixgbe_rx_entry *rxe;
struct ixgbe_scattered_rx_entry *sc_entry;
struct ixgbe_scattered_rx_entry *next_sc_entry;
-   struct ixgbe_rx_entry *next_rxe;
+   struct ixgbe_rx_entry *next_rxe = NULL;
struct rte_mbuf *first_seg;
struct rte_mbuf *rxm;
struct rte_mbuf *nmb;
@@ -1791,7 +1791,7 @@ next_desc:
 * the pointer to the first mbuf at the NEXTP entry in the
 * sw_sc_ring and continue to parse the RX ring.
 */
-   if (!eop) {
+   if (!eop && next_rxe) {
rxm->next = next_rxe->mbuf;
next_sc_entry->fbuf = first_seg;
goto next_desc;
-- 
2.8.0.rc2.35.gc2c5f6b.dirty

[dpdk-dev] [PATCH v2 6/7] drivers/net/ixgbe: Signed left shift operator

[Aaron Conole]

Tell the compiler to use an unsigned constant for the config shifts.

Signed-off-by: Aaron Conole 
Acked-by: Panu Matilainen 
Acked-by: Helin Zhang 
---
v2:
* No change (apart from adding ACKs)

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

diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c
index b854c72..f61653b 100644
--- a/drivers/net/ixgbe/ixgbe_pf.c
+++ b/drivers/net/ixgbe/ixgbe_pf.c
@@ -236,9 +236,9 @@ int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
vfre_slot = (vf_num >> VFRE_SHIFT) > 0 ? 1 : 0;

/* Enable pools reserved to PF only */
-   IXGBE_WRITE_REG(hw, IXGBE_VFRE(vfre_slot), (~0) << vfre_offset);
+   IXGBE_WRITE_REG(hw, IXGBE_VFRE(vfre_slot), (~0U) << vfre_offset);
IXGBE_WRITE_REG(hw, IXGBE_VFRE(vfre_slot ^ 1), vfre_slot - 1);
-   IXGBE_WRITE_REG(hw, IXGBE_VFTE(vfre_slot), (~0) << vfre_offset);
+   IXGBE_WRITE_REG(hw, IXGBE_VFTE(vfre_slot), (~0U) << vfre_offset);
IXGBE_WRITE_REG(hw, IXGBE_VFTE(vfre_slot ^ 1), vfre_slot - 1);

/* PFDMA Tx General Switch Control Enables VMDQ loopback */
-- 
2.8.0.rc2.35.gc2c5f6b.dirty

[dpdk-dev] [PATCH v2 5/7] drivers/net/e1000/igb: Signed left shift operator

[Aaron Conole]

Tell the compiler to use an unsigned constant for the config shifts.

Signed-off-by: Aaron Conole 
Acked-by: Panu Matilainen 
Acked-by: Helin Zhang 
---
v2:
* No change (apart from adding ACKs)

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

diff --git a/drivers/net/e1000/igb_pf.c b/drivers/net/e1000/igb_pf.c
index 95204e9..7029251 100644
--- a/drivers/net/e1000/igb_pf.c
+++ b/drivers/net/e1000/igb_pf.c
@@ -172,8 +172,8 @@ int igb_pf_host_configure(struct rte_eth_dev *eth_dev)
E1000_WRITE_REG(hw, E1000_VT_CTL, vtctl);

/* Enable pools reserved to PF only */
-   E1000_WRITE_REG(hw, E1000_VFRE, (~0) << vf_num);
-   E1000_WRITE_REG(hw, E1000_VFTE, (~0) << vf_num);
+   E1000_WRITE_REG(hw, E1000_VFRE, (~0U) << vf_num);
+   E1000_WRITE_REG(hw, E1000_VFTE, (~0U) << vf_num);

/* PFDMA Tx General Switch Control Enables VMDQ loopback */
if (hw->mac.type == e1000_i350)
-- 
2.8.0.rc2.35.gc2c5f6b.dirty

[dpdk-dev] [PATCH v2 4/7] drivers/net/ixgbe: Fix vlan filter missing brackets

[Aaron Conole]

The ixgbe vlan filter code has an if check with an incorrect whitespace.

Signed-off-by: Aaron Conole 
Acked-by: Panu Matilainen 
Acked-by: Helin Zhang 
---
v2:
* No change (apart from adding ACKs)

 drivers/net/ixgbe/ixgbe_ethdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index d4d883a..e290bce 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -4377,10 +4377,11 @@ ixgbe_set_pool_vlan_filter(struct rte_eth_dev *dev, 
uint16_t vlan,
if (ixgbe_vmdq_mode_check(hw) < 0)
return -ENOTSUP;
for (pool_idx = 0; pool_idx < ETH_64_POOLS; pool_idx++) {
-   if (pool_mask & ((uint64_t)(1ULL << pool_idx)))
+   if (pool_mask & ((uint64_t)(1ULL << pool_idx))) {
ret = hw->mac.ops.set_vfta(hw,vlan,pool_idx,vlan_on);
if (ret < 0)
return ret;
+   }
}

return ret;
-- 
2.8.0.rc2.35.gc2c5f6b.dirty

[dpdk-dev] [PATCH v2 3/7] drivers/net/e1000: Fix missing lsc interrupt check brackets

[Aaron Conole]

The device lsc interrupt check has a misleading whitespace around it which
can be improved by adding appropriate braces to the check. Since the ret
variable was checked after previous assignment, this introduces no functional
change.

Fixes commit 921a72008f76 ("e1000: add Rx interrupt handler")

Signed-off-by: Aaron Conole 
Acked-by: Panu Matilainen 
---
v2:
* Added Fixes line.

 drivers/net/e1000/em_ethdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 1f0a7f4..9b5e1af 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -666,13 +666,14 @@ eth_em_start(struct rte_eth_dev *dev)

if (rte_intr_allow_others(intr_handle)) {
/* check if lsc interrupt is enabled */
-   if (dev->data->dev_conf.intr_conf.lsc != 0)
+   if (dev->data->dev_conf.intr_conf.lsc != 0) {
ret = eth_em_interrupt_setup(dev);
if (ret) {
PMD_INIT_LOG(ERR, "Unable to setup interrupts");
em_dev_clear_queues(dev);
return ret;
}
+   }
} else {
rte_intr_callback_unregister(intr_handle,
eth_em_interrupt_handler,
-- 
2.8.0.rc2.35.gc2c5f6b.dirty

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

[Aaron Conole]

The register read/write mphy functions have misleading whitespace around
the locked check. This cleanup merely preserves the existing functionality
while improving the ready check.

Fixes commit 38db3f7f50bd ("e1000: update base driver")

Signed-off-by: Aaron Conole 
---
v2:
* Changed from "whitespace-only" fix to a functional change
  moving the phy writes into protection of the `if (locked)`
  code
* Added "Fixes" line.

 drivers/net/e1000/base/e1000_phy.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/e1000/base/e1000_phy.c 
b/drivers/net/e1000/base/e1000_phy.c
index d43b7ce..ad3fd58 100644
--- a/drivers/net/e1000/base/e1000_phy.c
+++ b/drivers/net/e1000/base/e1000_phy.c
@@ -4153,12 +4153,12 @@ s32 e1000_read_phy_reg_mphy(struct e1000_hw *hw, u32 
address, u32 *data)
*data = E1000_READ_REG(hw, E1000_MPHY_DATA);

/* Disable access to mPHY if it was originally disabled */
-   if (locked)
+   if (locked) {
ready = e1000_is_mphy_ready(hw);
if (!ready)
return -E1000_ERR_PHY;
-   E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
-   E1000_MPHY_DIS_ACCESS);
+   E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL, 
E1000_MPHY_DIS_ACCESS);
+   }

return E1000_SUCCESS;
 }
@@ -4218,12 +4218,12 @@ s32 e1000_write_phy_reg_mphy(struct e1000_hw *hw, u32 
address, u32 data,
E1000_WRITE_REG(hw, E1000_MPHY_DATA, data);

/* Disable access to mPHY if it was originally disabled */
-   if (locked)
+   if (locked) {
ready = e1000_is_mphy_ready(hw);
if (!ready)
return -E1000_ERR_PHY;
-   E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
-   E1000_MPHY_DIS_ACCESS);
+   E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL, 
E1000_MPHY_DIS_ACCESS);
+   }

return E1000_SUCCESS;
 }
-- 
2.8.0.rc2.35.gc2c5f6b.dirty

[dpdk-dev] [PATCH v2 1/7] app/test/test: Fix missing brackets

[Aaron Conole]

The test application calls printf(...) with the suite->suite_name argument.
The intent (based on whitespace) in the printf is to check suite->suite_name
first and then apply the printf. This doesn't happen due to missing brackets.

Signed-off-by: Aaron Conole 
Acked-by: Panu Matilainen 
---
v2:
* No change (apart from adding ACKs)

 app/test/test.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/app/test/test.c b/app/test/test.c
index f35b304..ccad0e3 100644
--- a/app/test/test.c
+++ b/app/test/test.c
@@ -162,9 +162,10 @@ unit_test_suite_runner(struct unit_test_suite *suite)
int test_success;
unsigned total = 0, executed = 0, skipped = 0, succeeded = 0, failed = 
0;

-   if (suite->suite_name)
+   if (suite->suite_name) {
printf(" + 
--- +\n");
printf(" + Test Suite : %s\n", suite->suite_name);
+   }

if (suite->setup)
if (suite->setup() != 0)
-- 
2.8.0.rc2.35.gc2c5f6b.dirty

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

[Aaron Conole]

This series brings a number of code cleanups to allow building using gcc6,
with various legitimate warnings being fixed.

Some of these fixes are to the drivers area, making this series a bit
atypical. However, the fixes identified in patches 2 and 3 are actual
bugs and should be fixed.

The first patch from the original series has been dropped. It is no
longer needed, after commit 5ecdeba601d1 ("lpm: merge tbl24 and tbl8
structures").


Aaron Conole (7):
  app/test/test: Fix missing brackets
  drivers/net/e1000: Fix missing brackets
  drivers/net/e1000: Fix missing lsc interrupt check brackets
  drivers/net/ixgbe: Fix vlan filter missing brackets
  drivers/net/e1000/igb: Signed left shift operator
  drivers/net/ixgbe: Signed left shift operator
  drivers/net/ixgbe: Fix uninitialized warning

 app/test/test.c|  3 ++-
 drivers/net/e1000/base/e1000_phy.c | 12 ++--
 drivers/net/e1000/em_ethdev.c  |  3 ++-
 drivers/net/e1000/igb_pf.c |  4 ++--
 drivers/net/ixgbe/ixgbe_ethdev.c   |  3 ++-
 drivers/net/ixgbe/ixgbe_pf.c   |  4 ++--
 drivers/net/ixgbe/ixgbe_rxtx.c |  4 ++--
 7 files changed, 18 insertions(+), 15 deletions(-)

-- 
2.8.0.rc2.35.gc2c5f6b.dirty

[dpdk-dev] [PATCH v2] enic: fix incorrect setting of rx descriptor limit

[Bruce Richardson]

On Tue, Mar 22, 2016 at 05:32:41PM +, Bruce Richardson wrote:
> On Fri, Mar 18, 2016 at 11:33:34AM -0700, John Daley wrote:
> > From: Nelson Escobar 
> > 
> > On initialization, the rq descriptor count was set to the limit
> > of the vic.  When the requested number of rx descriptors was
> > less than this count, enic_alloc_rq() was incorrectly setting
> > the count to the lower value.  This results in later calls to
> > enic_alloc_rq() incorrectly using the lower value as the adapter
> > limit.
> > 
> > Signed-off-by: Nelson Escobar 
> > Fixes: fefed3d1e62c ("enic: new driver")
> > Reviewed-by: John Daley 
> 
> Please put the fixes line above the signoffs, not in the middle of them. It 
> just
> makes it easier to read. I'll fix this for this patch when applying it.
> 
> /Bruce

Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH v2] enic: fix incorrect setting of rx descriptor limit

[Bruce Richardson]

On Fri, Mar 18, 2016 at 11:33:34AM -0700, John Daley wrote:
> From: Nelson Escobar 
> 
> On initialization, the rq descriptor count was set to the limit
> of the vic.  When the requested number of rx descriptors was
> less than this count, enic_alloc_rq() was incorrectly setting
> the count to the lower value.  This results in later calls to
> enic_alloc_rq() incorrectly using the lower value as the adapter
> limit.
> 
> Signed-off-by: Nelson Escobar 
> Fixes: fefed3d1e62c ("enic: new driver")
> Reviewed-by: John Daley 

Please put the fixes line above the signoffs, not in the middle of them. It just
makes it easier to read. I'll fix this for this patch when applying it.

/Bruce

[dpdk-dev] [PATCH v3] enic: update enic PMD maintainer and pointer to the guide.

[Bruce Richardson]

On Fri, Mar 18, 2016 at 11:27:07AM -0700, John Daley wrote:
> Change maintainers for ENIC PMD and fix pointer to enic
> documentation in MAINTAINERS.
> 
> Signed-off-by: John Daley 
> ---
Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH 1/2] mlx5: fix overwritten RSS configuration

[Bruce Richardson]

On Fri, Mar 18, 2016 at 05:27:47PM +0100, Adrien Mazarguil wrote:
> On Fri, Mar 18, 2016 at 01:54:42PM +0100, Nelio Laranjeiro wrote:
> > RSS configuration provided by the application should not be used as storage
> > by the PMD.
> > 
> > Fixes: 2f97422e7759 ("mlx5: support RSS hash update and get")
> > 
> > Signed-off-by: Nelio Laranjeiro 
> > ---
> >  drivers/net/mlx5/mlx5.h| 1 +
> >  drivers/net/mlx5/mlx5_ethdev.c | 1 +
> >  drivers/net/mlx5/mlx5_rss.c| 7 ++-
> >  drivers/net/mlx5/mlx5_rxq.c| 2 +-
> >  4 files changed, 5 insertions(+), 6 deletions(-)
> 
> Acked-by: Adrien Mazarguil 
> 
> -- 
Patchset applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH] ixgbe: fix reta query and update on x550

[Bruce Richardson]

On Fri, Mar 18, 2016 at 03:19:35AM +, Lu, Wenzhuo wrote:
> Hi,
> 
> 
> > -Original Message-
> > From: Wang, Xiao W
> > Sent: Friday, March 18, 2016 10:28 AM
> > To: Zhang, Helin
> > Cc: dev at dpdk.org; Lu, Wenzhuo; Wang, Xiao W
> > Subject: [PATCH] ixgbe: fix reta query and update on x550
> > 
> > For x550 device, the reta table has 512 entries, but in function
> > ixgbe_dev_rss_reta_query and ixgbe_dev_rss_reta_update we use an "uint8_t i"
> > to traverse the entries, this will lead the function to an endless loop.
> > 
> > This patch changes the data type from uint8_t to uint16_t to fix the issue.
> > 
> > Fixes: 4bee94a6c22f ("ixgbe: support 512 RSS entries on x550")
> > 
> > Signed-off-by: Wang Xiao W 
> Acked-by: Wenzhuo Lu 
> 
Applied to dpdk-next-net/rel_16_04

/Bruce

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

[Loftus, Ciara]

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

Hi Tetsuya,

Thanks again for the patch.

Acked-by: Ciara Loftus 

Thanks,
Ciara

[dpdk-dev] [PATCH v4 0/5] lpm allocation fixes

[Thomas Monjalon]

2016-03-21 15:06, Christian Ehrhardt:
> Poking a bit on autotest revealed a few shortcomings in the lpm allocation 
> path.
> Thanks to the feedback to the first revision of the patches here v2.
> Also Oliver Matz spotted similar issues and made me aware - thanks!
> Integrating them revealed even more use after free / leak issues.
> 
> *updates in v4*
> - re-removing the { } on single line ifs accidentially droped in v3
> - adding the ack of Oliver Matz
> 
> *updates in v3*
> - lpm create/free path for v20 and v1604 got the same fixes that were
>   already identified for lpm6 before
> 
> *updates in v2*
> - lpm/lpm6 patches split
> - following dpdk coding guidelines regarding single line if's
> - adding singed-off and acked-bys gathered so far
> - combine all three related patches in one series
> 
> Christian Ehrhardt (5):
>   lpm6: fix use after free of lpm in rte_lpm6_create
>   lpm6: fix missing free of rules_tbl and lpm
>   lpm: fix missing free of lpm
>   lpm: fix use after free of lpm in rte_lpm_create*
>   lpm: fix missing free of rules_tbl and lpm in rte_lpm_free*

Applied, thanks

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

[Markos Chandras]

This is similar to what's being used in the Linux kernel. Querying the
GCC macros directly gives more accurate results compared to -dumpversion
which could vary across distributions.

Signed-off-by: Markos Chandras 
---
In openSUSE Tumbleweed (and in any other SUSE distribution which
uses (or will use) gcc >= 5), gcc -dumpversion returns '5'. This is on
purpose as discussed in https://bugzilla.opensuse.org/show_bug.cgi?id=941428
As a result of which, the gcc-4.x comparison (40 against 5) does not
work leading to tons of warnings and failures during build. This patch
aims to change the way the gcc version is obtained by using the gcc macros
directly.
---
 mk/toolchain/gcc/rte.toolchain-compat.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mk/toolchain/gcc/rte.toolchain-compat.mk 
b/mk/toolchain/gcc/rte.toolchain-compat.mk
index e144216..6eed20c 100644
--- a/mk/toolchain/gcc/rte.toolchain-compat.mk
+++ b/mk/toolchain/gcc/rte.toolchain-compat.mk
@@ -38,7 +38,9 @@

 #find out GCC version

-GCC_VERSION = $(subst .,,$(shell $(CC) -dumpversion | cut -f1-2 -d.))
+GCC_MAJOR = $(shell echo __GNUC__ | $(CC) -E -x c - | tail -n 1)
+GCC_MINOR = $(shell echo __GNUC_MINOR__ | $(CC) -E -x c - | tail -n 1)
+GCC_VERSION = $(GCC_MAJOR)$(GCC_MINOR)

 # if GCC is older than 4.x
 ifeq ($(shell test $(GCC_VERSION) -lt 40 && echo 1), 1)
-- 
2.7.3

[dpdk-dev] [PATCH] eal/ppc: fix secondary process to map hugepages in correct order

[Bruce Richardson]

On Tue, Mar 22, 2016 at 04:35:32PM +, Sergio Gonzalez Monroy wrote:
> First of all, forgive my ignorance regarding ppc64 and if the questions are
> naive but after having a
> look to the already existing code for ppc64 and this patch now, why are we
> doing this reverse mapping at all?
> 
> I guess the question revolves around the comment in eal_memory.c:
> 1316 /* On PPC64 architecture, the mmap always start from
> higher
> 1317  * virtual address to lower address. Here, both the
> physical
> 1318  * address and virtual address are in descending order
> */
> 
> From looking at the code, for ppc64 we do qsort in reverse order and
> thereafter everything looks to be is
> done to account for that reverse sorting.
> 
> CC: Chao Zhu and David Marchand as original author and reviewer of the code.
> 
> Sergio
>

Just to add my 2c here. At one point, with I believe some i686 installs - don't
remember the specific OS/kernel, we found that the mmap calls were returning
the highest free address first and then working downwards - must like seems
to be described here. To fix this we changed the mmap code from assuming that
addresses are mapped upwards, to instead explicitly requesting a large free
block of memory (mmap of /dev/zero) to find a free address space
range of the correct size, and then explicitly mmapping each individual page to
the appropriate place in that free range. With this scheme it didn't matter 
whether
the OS tried to mmap the pages from the highest or lowest address because we
always told the OS where to put the page (and we knew the slot was free from
the earlier block mmap).
Would this scheme not also work for PPC in a similar way? (Again, forgive
unfamiliarity with PPC! :-) )

/Bruce

> 
> On 07/03/2016 14:13, Gowrishankar wrote:
> >From: Gowri Shankar 
> >
> >For a secondary process address space to map hugepages from every segment of
> >primary process, hugepage_file entries has to be mapped reversely from the
> >list that primary process updated for every segment. This is for a reason 
> >that,
> >in ppc64, hugepages are sorted for decrementing addresses.
> >
> >Signed-off-by: Gowrishankar 
> >---
> >  lib/librte_eal/linuxapp/eal/eal_memory.c |   26 --
> >  1 file changed, 16 insertions(+), 10 deletions(-)
> >
> >diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c 
> >b/lib/librte_eal/linuxapp/eal/eal_memory.c
> >index 5b9132c..6aea5d0 100644
> >--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> >+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> >@@ -1400,7 +1400,7 @@ rte_eal_hugepage_attach(void)
> >  {
> > const struct rte_mem_config *mcfg = 
> > rte_eal_get_configuration()->mem_config;
> > const struct hugepage_file *hp = NULL;
> >-unsigned num_hp = 0;
> >+unsigned num_hp = 0, mapped_hp = 0;
> > unsigned i, s = 0; /* s used to track the segment number */
> > off_t size;
> > int fd, fd_zero = -1, fd_hugepage = -1;
> >@@ -1486,14 +1486,12 @@ rte_eal_hugepage_attach(void)
> > goto error;
> > }
> >-num_hp = size / sizeof(struct hugepage_file);
> >-RTE_LOG(DEBUG, EAL, "Analysing %u files\n", num_hp);
> >-
> > s = 0;
> > while (s < RTE_MAX_MEMSEG && mcfg->memseg[s].len > 0){
> > void *addr, *base_addr;
> > uintptr_t offset = 0;
> > size_t mapping_size;
> >+unsigned int index;
> >  #ifdef RTE_LIBRTE_IVSHMEM
> > /*
> >  * if segment has ioremap address set, it's an IVSHMEM segment 
> > and
> >@@ -1504,6 +1502,8 @@ rte_eal_hugepage_attach(void)
> > continue;
> > }
> >  #endif
> >+num_hp = mcfg->memseg[s].len / mcfg->memseg[s].hugepage_sz;
> >+RTE_LOG(DEBUG, EAL, "Analysing %u files in segment %u\n", 
> >num_hp, s);
> > /*
> >  * free previously mapped memory so we can map the
> >  * hugepages into the space
> >@@ -1514,18 +1514,23 @@ rte_eal_hugepage_attach(void)
> > /* find the hugepages for this segment and map them
> >  * we don't need to worry about order, as the server sorted the
> >  * entries before it did the second mmap of them */
> >+#ifdef RTE_ARCH_PPC_64
> >+for (i = num_hp-1; i < num_hp && offset < mcfg->memseg[s].len; 
> >i--){
> >+#else
> > for (i = 0; i < num_hp && offset < mcfg->memseg[s].len; i++){
> >-if (hp[i].memseg_id == (int)s){
> >-fd = open(hp[i].filepath, O_RDWR);
> >+#endif
> >+index = i + mapped_hp;
> >+if (hp[index].memseg_id == (int)s){
> >+fd = open(hp[index].filepath, O_RDWR);
> > if (fd < 0) {
> > RTE_LOG(ERR, EAL, "Could not open %s\n",
> >-hp[i].filepath);
> >+  

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

[Tetsuya Mukawa]

Currently, the maximum value of rx/tx queueus are kept by EAL. But,
the value are used like below different meanings in vhost PMD.
 - The maximum value of current enabled queues.
 - The maximum value of current supported queues.

This wrong double meaning will cause an issue like below steps.

* Invoke application with below option.
  --vdev 'eth_vhost0,iface=,queues=4'
* Configure queues like below.
  rte_eth_dev_configure(portid, 2, 2, ...);
* Configure queues again like below.
  rte_eth_dev_configure(portid, 4, 4, ...);

The second rte_eth_dev_configure() will be failed because both
the maximum value of current enabled queues and supported queues
will be '2' after calling first rte_eth_dev_configure().

To fix the issue, the patch prepare one more variable to keep the
number of maximum supported queues in vhost PMD.

Signed-off-by: Tetsuya Mukawa 
---
 drivers/net/vhost/rte_eth_vhost.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/net/vhost/rte_eth_vhost.c 
b/drivers/net/vhost/rte_eth_vhost.c
index 6b9d287..5fd8c70 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -88,6 +88,7 @@ struct vhost_queue {
 struct pmd_internal {
char *dev_name;
char *iface_name;
+   uint16_t max_queues;

volatile uint16_t once;
 };
@@ -555,11 +556,19 @@ static void
 eth_dev_info(struct rte_eth_dev *dev,
 struct rte_eth_dev_info *dev_info)
 {
+   struct pmd_internal *internal;
+
+   internal = dev->data->dev_private;
+   if (internal == NULL) {
+   RTE_LOG(ERR, PMD, "Invalid device specified\n");
+   return;
+   }
+
dev_info->driver_name = drivername;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t)-1;
-   dev_info->max_rx_queues = dev->data->nb_rx_queues;
-   dev_info->max_tx_queues = dev->data->nb_tx_queues;
+   dev_info->max_rx_queues = internal->max_queues;
+   dev_info->max_tx_queues = internal->max_queues;
dev_info->min_rx_bufsize = 0;
 }

@@ -751,6 +760,7 @@ eth_dev_vhost_create(const char *name, char *iface_name, 
int16_t queues,
memmove(data->name, eth_dev->data->name, sizeof(data->name));
data->nb_rx_queues = queues;
data->nb_tx_queues = queues;
+   internal->max_queues = queues;
data->dev_link = pmd_link;
data->mac_addrs = eth_addr;

-- 
2.1.4

[dpdk-dev] [PATCH] doc: notify Rx errors not counting missed packets anymore

[Thomas Monjalon]

Fixes: 86057c9992f5 ("ethdev: remove missed packets from error counter")

Suggested-by: Maryam Tahhan 
Signed-off-by: Thomas Monjalon 
---
 doc/guides/rel_notes/release_16_04.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index e6a9144..060e1d4 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -410,6 +410,10 @@ This section should contain API changes. Sample format:
 * Add a short 1-2 sentence description of the API change. Use fixed width
   quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past 
tense.

+* The ethdev statistics counter imissed is considered exclusive with ierrors.
+  Every drivers are now counting the missed packets only once, and not
+  incrementing ierrors anymore for not received packets.
+
 * The ethdev structure ``rte_eth_dev_info`` was changed to support device
   speed capabilities.

-- 
2.7.0

[dpdk-dev] [PATCH 0/3] enic PMD receive path fixes

[Bruce Richardson]

On Thu, Mar 17, 2016 at 03:57:04PM -0700, John Daley wrote:
> These patches fix up some bugs in the enic receive path.
> 
> John Daley (3):
>   enic: mbuf->ol_flags could be set incorrectly
>   enic: handle error packets properly
>   enic: small cleanup- remove a packet_error conditional
> 
>  drivers/net/enic/enic_rx.c | 53 
> ++
>  1 file changed, 21 insertions(+), 32 deletions(-)
> 
> -- 
> 2.7.0
> 

Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH] enic: prevent segfaults when allocating too many TX or RX queues

[Bruce Richardson]

On Tue, Mar 22, 2016 at 04:46:30PM +, Bruce Richardson wrote:
> On Thu, Mar 17, 2016 at 03:49:58PM -0700, John Daley wrote:
> > From: Nelson Escobar 
> > 
> > Add checks to make sure we don't try to allocate more tx or rx queues
> > than we support.
> > 
> > Signed-off-by: Nelson Escobar 
> > Reviewed-by: John Daley 
> 
> Better to use the word fix in the title to indicate this is a bug-fix. Also 
> missing
> a fixes line of: 
> 
> Fixes: fefed3d1e62c ("enic: new driver")
> 
> Will fix this up on apply.
> 
> /Bruce

Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH 1/8] lpm: Fix pointer aliasing issues

[Aaron Conole]

Thomas Monjalon  writes:

> 2016-02-25 21:30, Bruce Richardson:
>> On Thu, Feb 25, 2016 at 01:48:34PM -0500, Aaron Conole wrote:
>> >  /**
>> > + * Convert from tbl_entry types to integer types
>> > + */
>> > +static inline uint16_t
>> > +rte_lpm_tbl24_entry_to_uint16(const struct rte_lpm_tbl24_entry *entry)
>> > +{
>> > +  union {
>> > +  uint16_t   i;
>> > +  struct rte_lpm_tbl24_entry s;
>> > +  } tbl_entry_u;
>> > +
>> > +  tbl_entry_u.s = *entry;
>> > +  return tbl_entry_u.i;
>> > +}
>> > +
>> > +static inline uint16_t
>> > +rte_lpm_tbl8_entry_to_uint16(const struct rte_lpm_tbl8_entry *entry)
>> > +{
>> > +  union {
>> > +  uint16_t  i;
>> > +  struct rte_lpm_tbl8_entry s;
>> > +  } tbl_entry_u;
>> > +
>> > +  tbl_entry_u.s = *entry;
>> > +  return tbl_entry_u.i;
>> > +}
>> > +
>> 
>> These two new functions could be reduced to one with the help of patch:
>> http://dpdk.org/dev/patchwork/patch/9087/
>
> Aaron, any news about a rework of this patch?

The rework of this series is in my TODO list with deadline of
Thursday. I'll repost the series before then. Sorry for the
confusion/delay.

-Aaron

[dpdk-dev] [PATCH] enic: prevent segfaults when allocating too many TX or RX queues

[Bruce Richardson]

On Thu, Mar 17, 2016 at 03:49:58PM -0700, John Daley wrote:
> From: Nelson Escobar 
> 
> Add checks to make sure we don't try to allocate more tx or rx queues
> than we support.
> 
> Signed-off-by: Nelson Escobar 
> Reviewed-by: John Daley 

Better to use the word fix in the title to indicate this is a bug-fix. Also 
missing
a fixes line of: 

Fixes: fefed3d1e62c ("enic: new driver")

Will fix this up on apply.

/Bruce

[dpdk-dev] [PATCH] enic: add missing \n to a few print statements

[Bruce Richardson]

On Thu, Mar 17, 2016 at 03:48:13PM -0700, John Daley wrote:
> From: Nelson Escobar 
> 
> Signed-off-by: Nelson Escobar 
> Acked-by: John Daley 

Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH] eal/ppc: fix secondary process to map hugepages in correct order

[Sergio Gonzalez Monroy]

First of all, forgive my ignorance regarding ppc64 and if the questions 
are naive but after having a
look to the already existing code for ppc64 and this patch now, why are 
we doing this reverse mapping at all?

I guess the question revolves around the comment in eal_memory.c:
1316 /* On PPC64 architecture, the mmap always start 
from higher
1317  * virtual address to lower address. Here, both the 
physical
1318  * address and virtual address are in descending 
order */

 From looking at the code, for ppc64 we do qsort in reverse order and 
thereafter everything looks to be is
done to account for that reverse sorting.

CC: Chao Zhu and David Marchand as original author and reviewer of the code.

Sergio


On 07/03/2016 14:13, Gowrishankar wrote:
> From: Gowri Shankar 
>
> For a secondary process address space to map hugepages from every segment of
> primary process, hugepage_file entries has to be mapped reversely from the
> list that primary process updated for every segment. This is for a reason 
> that,
> in ppc64, hugepages are sorted for decrementing addresses.
>
> Signed-off-by: Gowrishankar 
> ---
>   lib/librte_eal/linuxapp/eal/eal_memory.c |   26 --
>   1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c 
> b/lib/librte_eal/linuxapp/eal/eal_memory.c
> index 5b9132c..6aea5d0 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> @@ -1400,7 +1400,7 @@ rte_eal_hugepage_attach(void)
>   {
>   const struct rte_mem_config *mcfg = 
> rte_eal_get_configuration()->mem_config;
>   const struct hugepage_file *hp = NULL;
> - unsigned num_hp = 0;
> + unsigned num_hp = 0, mapped_hp = 0;
>   unsigned i, s = 0; /* s used to track the segment number */
>   off_t size;
>   int fd, fd_zero = -1, fd_hugepage = -1;
> @@ -1486,14 +1486,12 @@ rte_eal_hugepage_attach(void)
>   goto error;
>   }
>   
> - num_hp = size / sizeof(struct hugepage_file);
> - RTE_LOG(DEBUG, EAL, "Analysing %u files\n", num_hp);
> -
>   s = 0;
>   while (s < RTE_MAX_MEMSEG && mcfg->memseg[s].len > 0){
>   void *addr, *base_addr;
>   uintptr_t offset = 0;
>   size_t mapping_size;
> + unsigned int index;
>   #ifdef RTE_LIBRTE_IVSHMEM
>   /*
>* if segment has ioremap address set, it's an IVSHMEM segment 
> and
> @@ -1504,6 +1502,8 @@ rte_eal_hugepage_attach(void)
>   continue;
>   }
>   #endif
> + num_hp = mcfg->memseg[s].len / mcfg->memseg[s].hugepage_sz;
> + RTE_LOG(DEBUG, EAL, "Analysing %u files in segment %u\n", 
> num_hp, s);
>   /*
>* free previously mapped memory so we can map the
>* hugepages into the space
> @@ -1514,18 +1514,23 @@ rte_eal_hugepage_attach(void)
>   /* find the hugepages for this segment and map them
>* we don't need to worry about order, as the server sorted the
>* entries before it did the second mmap of them */
> +#ifdef RTE_ARCH_PPC_64
> + for (i = num_hp-1; i < num_hp && offset < mcfg->memseg[s].len; 
> i--){
> +#else
>   for (i = 0; i < num_hp && offset < mcfg->memseg[s].len; i++){
> - if (hp[i].memseg_id == (int)s){
> - fd = open(hp[i].filepath, O_RDWR);
> +#endif
> + index = i + mapped_hp;
> + if (hp[index].memseg_id == (int)s){
> + fd = open(hp[index].filepath, O_RDWR);
>   if (fd < 0) {
>   RTE_LOG(ERR, EAL, "Could not open %s\n",
> - hp[i].filepath);
> + hp[index].filepath);
>   goto error;
>   }
>   #ifdef RTE_EAL_SINGLE_FILE_SEGMENTS
> - mapping_size = hp[i].size * hp[i].repeated;
> + mapping_size = hp[index].size * 
> hp[index].repeated;
>   #else
> - mapping_size = hp[i].size;
> + mapping_size = hp[index].size;
>   #endif
>   addr = mmap(RTE_PTR_ADD(base_addr, offset),
>   mapping_size, PROT_READ | 
> PROT_WRITE,
> @@ -1534,7 +1539,7 @@ rte_eal_hugepage_attach(void)
>   if (addr == MAP_FAILED ||
>   addr != RTE_PTR_ADD(base_addr, 
> offset)) {
>   RTE_LOG(ERR, EAL, "Could not mmap %s\n",
> - hp[i].filepath);
> + hp[index].filepath);

[dpdk-dev] [PATCH v3 0/5] Implement missing features in mlx5

[Bruce Richardson]

On Thu, Mar 17, 2016 at 04:38:53PM +0100, Adrien Mazarguil wrote:
> This patchset adds to mlx5 a few features available in mlx4 (TX from
> secondary processes) or provided by Verbs (support for HW packet padding,
> TX VLAN insertion).
> 
> Release notes and documentation are updated accordingly.
> 
> Changes in v3:
> - Removed compilation option for TX VLAN insertion, the method to use is now
>   determined at runtime.
> - Modified releases notes slightly.
> 
> Changes in v2:
> - Added support for CRC stripping configuration.
> - Updated packet padding feature macro and made cosmetic changes to its
>   implementation to match CRC stripping's.
> - Updated release notes about packet padding.
> - Updated TX VLAN insertion documentation.
> 
> Olga Shern (2):
>   mlx5: add RX CRC stripping configuration
>   mlx5: add support for HW packet padding
> 
> Or Ami (2):
>   mlx5: add callbacks to support link (up / down) changes
>   mlx5: allow operation in secondary processes
> 
> Yaacov Hazan (1):
>   mlx5: add VLAN insertion offload
>
Applied to dpdk-next-net/rel_16_04.

/Bruce

[dpdk-dev] [PATCH] ixgbe: add TX queue number check

[Wenzhuo Lu]

Ixgbe supports at most 128 TX queues. But in none VT nor DCB mode
the queues 64 ~ 127 should not be used. Ixgbe doesn't do any check
about that. If a queue larger than 64 is used, the TX packets will
be dropped silently. It's hard to debug.
This check is added to forbid using queue number larger than 64
during device configuration, so the user can know the problem as
early as possible.

Signed-off-by: Wenzhuo Lu 
Reported-by: Antonio Fischetti 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 11 ++-
 drivers/net/ixgbe/ixgbe_ethdev.h |  1 +
 2 files changed, 11 insertions(+), 1 deletion(-)

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

if (RTE_ETH_DEV_SRIOV(dev).active != 0) {
/* check multi-queue mode */
@@ -2002,6 +2002,15 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
return -EINVAL;
}
}
+
+   if (dev_conf->txmode.mq_mode == ETH_MQ_TX_NONE) {
+   if (nb_tx_q > IXGBE_NONE_VT_DCB_MAX_TXQ_NB) {
+   PMD_INIT_LOG(ERR,
+"None VT nor DCB, nb_tx_q > %d.",
+IXGBE_NONE_VT_DCB_MAX_TXQ_NB);
+   return -EINVAL;
+   }
+   }
}
return 0;
 }
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index 5c3aa16..50ee73f 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -61,6 +61,7 @@
 #define IXGBE_MAX_RX_QUEUE_NUM 128
 #define IXGBE_VMDQ_DCB_NB_QUEUES IXGBE_MAX_RX_QUEUE_NUM
 #define IXGBE_DCB_NB_QUEUES  IXGBE_MAX_RX_QUEUE_NUM
+#define IXGBE_NONE_VT_DCB_MAX_TXQ_NB 64

 #ifndef NBBY
 #define NBBY   8   /* number of bits in a byte */
-- 
1.9.3

[dpdk-dev] multi-segment mbuf

[Clarylin L]

Ok...I think you meant there's a bug in the driver code when formatting
multi-segment mbuf.

On Tue, Mar 22, 2016 at 3:13 PM, Stephen Hemminger <
stephen at networkplumber.org> wrote:

> Read the source.
>
> A multi-segment mbuf has the first mbuf with nb_segs > 1 and chained by
> next pointer.
> It is a bug in the creator of the mbuf, if number of segments and next
> chain don't
> match.
>
> There is a rte_pktmbuf_dump(), you can use to look at how your mbuf is
> formatted.
>
> On Tue, Mar 22, 2016 at 1:36 PM, Clarylin L  wrote:
>
>> Sorry my bad. The mbuf size has been accidentally changed to 3000.
>>
>> After fixing this by setting mbuf size to 2048, multi-segment mbuf still
>> doesn't work. I was trying to send 2500-byte packets to the target system
>> and was expecting to see two-segment mbuf chain), but got errors on it.
>>
>> Tue Mar 22 14:52:00 2016^@PMD: rte_enic_pmd: packet error
>>
>>
>> Tue Mar 22 14:52:01 2016^@PMD: rte_enic_pmd: packet error
>>
>>
>> Tue Mar 22 14:52:02 2016^@PMD: rte_enic_pmd: packet error
>>
>>
>> Tue Mar 22 14:52:03 2016^@PMD: rte_enic_pmd: packet error
>>
>>
>> Tue Mar 22 14:52:04 2016^@PMD: rte_enic_pmd: packet error
>>
>>
>> Is enic supporting multi-segment mbuf? The dpdk version is 2.0.0. I have
>> enabled jumbo-frame and enable_scatter for the port.
>>
>> On Tue, Mar 22, 2016 at 3:27 AM, Bruce Richardson <
>> bruce.richardson at intel.com> wrote:
>>
>> > On Mon, Mar 21, 2016 at 04:34:50PM -0700, Clarylin L wrote:
>> > > I am trying multi-segment mbuf, but it seems not working.
>> > >
>> > > On my target host, the mbuf size is set to 2048 and I am trying to
>> send
>> > > large packet to it (say 2500 bytes without fragmentation) from another
>> > > host. I enabled both jumbo_frame and enable_scatter for the port. But
>> I
>> > saw
>> > > on the target only one mbuf is received with data_len equal to 2500
>> (it's
>> > > supposed to be a two-mbuf chain).  Although mbuf itself is not
>> working as
>> > > expected, ping between two hosts succeeded (large ping size; no
>> > > fragmentation).
>> > >
>> > > 1. my mbuf size is only 2048. how can it support receiving such large
>> > > packet in one mbuf?
>> > >
>> > > 2.how to make it work as expected (enable multi-segment mbuf and
>> receive
>> > > using mbuf chain when needed)?
>> > >
>> > > Appreciate your help.
>> >
>> > Hi,
>> >
>> > when you get the single mbuf with data_len == 2500, what is the buf_len
>> > value
>> > reported as?
>> >
>> > /Bruce
>> >
>>
>
>

[dpdk-dev] [PATCH] testpmd: fix enumerated type mixed with another type

[Tomasz Kulasek]

This patch fixes error #188: enumerated type mixed with another type,
when uint32_t is casted on enum type in icc.

Fixes: 05f1b9c82ec2 ("app/testpmd: add commands for L2 tunnel config")

Signed-off-by: Tomasz Kulasek 
---
 app/test-pmd/cmdline.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 9d52b8c..c34d4c1 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -9723,14 +9723,14 @@ cmdline_parse_token_num_t 
cmd_config_l2_tunnel_eth_type_eth_type_val =
(struct cmd_config_l2_tunnel_eth_type_result,
 eth_type_val, UINT16);

-static uint32_t
+static enum rte_eth_tunnel_type
 str2fdir_l2_tunnel_type(char *string)
 {
uint32_t i = 0;

static const struct {
char str[32];
-   uint32_t type;
+   enum rte_eth_tunnel_type type;
} l2_tunnel_type_str[] = {
{"E-tag", RTE_L2_TUNNEL_TYPE_E_TAG},
};
-- 
2.5.5

[dpdk-dev] multi-segment mbuf

[Clarylin L]

On my setup, the sending host is a regular one without running dpdk. It
sends out 2500-byte packet without fragmentation to the dpdk node.

Isn't it the enic pmd driver that is responsible for fetch the packet and
format the mbuf (or mbuf chain if required)? Or do you mean I need to write
my own codes to format the mbuf in the driver?

On Tue, Mar 22, 2016 at 3:13 PM, Stephen Hemminger <
stephen at networkplumber.org> wrote:

> Read the source.
>
> A multi-segment mbuf has the first mbuf with nb_segs > 1 and chained by
> next pointer.
> It is a bug in the creator of the mbuf, if number of segments and next
> chain don't
> match.
>
> There is a rte_pktmbuf_dump(), you can use to look at how your mbuf is
> formatted.
>
> On Tue, Mar 22, 2016 at 1:36 PM, Clarylin L  wrote:
>
>> Sorry my bad. The mbuf size has been accidentally changed to 3000.
>>
>> After fixing this by setting mbuf size to 2048, multi-segment mbuf still
>> doesn't work. I was trying to send 2500-byte packets to the target system
>> and was expecting to see two-segment mbuf chain), but got errors on it.
>>
>> Tue Mar 22 14:52:00 2016^@PMD: rte_enic_pmd: packet error
>>
>>
>> Tue Mar 22 14:52:01 2016^@PMD: rte_enic_pmd: packet error
>>
>>
>> Tue Mar 22 14:52:02 2016^@PMD: rte_enic_pmd: packet error
>>
>>
>> Tue Mar 22 14:52:03 2016^@PMD: rte_enic_pmd: packet error
>>
>>
>> Tue Mar 22 14:52:04 2016^@PMD: rte_enic_pmd: packet error
>>
>>
>> Is enic supporting multi-segment mbuf? The dpdk version is 2.0.0. I have
>> enabled jumbo-frame and enable_scatter for the port.
>>
>> On Tue, Mar 22, 2016 at 3:27 AM, Bruce Richardson <
>> bruce.richardson at intel.com> wrote:
>>
>> > On Mon, Mar 21, 2016 at 04:34:50PM -0700, Clarylin L wrote:
>> > > I am trying multi-segment mbuf, but it seems not working.
>> > >
>> > > On my target host, the mbuf size is set to 2048 and I am trying to
>> send
>> > > large packet to it (say 2500 bytes without fragmentation) from another
>> > > host. I enabled both jumbo_frame and enable_scatter for the port. But
>> I
>> > saw
>> > > on the target only one mbuf is received with data_len equal to 2500
>> (it's
>> > > supposed to be a two-mbuf chain).  Although mbuf itself is not
>> working as
>> > > expected, ping between two hosts succeeded (large ping size; no
>> > > fragmentation).
>> > >
>> > > 1. my mbuf size is only 2048. how can it support receiving such large
>> > > packet in one mbuf?
>> > >
>> > > 2.how to make it work as expected (enable multi-segment mbuf and
>> receive
>> > > using mbuf chain when needed)?
>> > >
>> > > Appreciate your help.
>> >
>> > Hi,
>> >
>> > when you get the single mbuf with data_len == 2500, what is the buf_len
>> > value
>> > reported as?
>> >
>> > /Bruce
>> >
>>
>
>

[dpdk-dev] [PATCH v3 1/3] xen: Add UIO kernel driver

[Jan Blunck]

On Tue, Mar 22, 2016 at 12:27 PM, Thomas Monjalon
 wrote:
> 2016-03-22 12:04, Jan Blunck:
>> On Tue, Mar 22, 2016 at 11:42 AM, Thomas Monjalon
>>  wrote:
>> > 2016-03-22 10:55, Jan Blunck:
>> >> New UIO helper kernel driver for Xen netfront UIO poll mode driver.
>> >>
>> >> Signed-off-by: Stephen Hemminger 
>> >> Signed-off-by: Jan Blunck 
>> >
>> > Is it contributed upstream?
>>
>> No. Haven't planed that yet.
>
> Integrating new kernel modules in DPDK, without upstream work,
> is not planned.
>

I'll look into the existing Linux kernel netfront driver and check if
upstream is actually willing to integrate the UIO part.

>> > Is there something common with igb_uio?
>>
>> AFAIK igb_uio is mapping the bars via UIO. The Xen netfront driver
>> isn't simulating a PCI interface. Instead it directly maps the TX/RX
>> ring.
>>
>> Overlap is limited to reading sysfs files. Don't know if that is worth
>> being extracted into a standalone header.
>
> No it is not worth extracting. I'm just trying to understand what this
> module is, because the log doesn't say much.
>

I can address that for the upstream submission and drop it from this series.

[dpdk-dev] [PATCH] i40e: fix using memory after free issue

[Bruce Richardson]

On Mon, Mar 14, 2016 at 09:02:04AM +, Jiangu Zhao wrote:
> The old code still uses entry in the next loop of LIST_FOREACH after free() 
> in i40e_res_pool_destroy().
> Change to a safe way to free entry, which is similar with LIST_FOREACH_SAFE 
> in FreeBSD.
> 
> Signed-off-by: Jiangu Zhao 

Thanks for the patch. It's missing a "fixes" line as descripted here:
http://dpdk.org/doc/guides/contributing/patches.html#commit-messages-body
so can you perhaps reply with the id of the commit this is fixing, (or add it
into the commit message if you end up doing a V2 of the patch)

Helin, can you perhaps review this patch as i40e maintainer.

> ---
>  drivers/net/i40e/i40e_ethdev.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 2f676f6..5af2128 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -3317,17 +3317,21 @@ i40e_res_pool_init (struct i40e_res_pool_info *pool, 
> uint32_t base,
>  static void
>  i40e_res_pool_destroy(struct i40e_res_pool_info *pool)
>  {
> - struct pool_entry *entry;
> + struct pool_entry *entry, *next_entry;
>  
>   if (pool == NULL)
>   return;
>  
> - LIST_FOREACH(entry, >alloc_list, next) {
> + for (entry = LIST_FIRST(>alloc_list); 
> + entry && (next_entry = LIST_NEXT(entry, next), 1);
> + entry = next_entry) {

Can we use LIST_FOREACH_SAFE?

/Bruce

[dpdk-dev] [PATCH] ethdev: don't count missed packets in erroneous packets counter

[Tahhan, Maryam]

> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, March 17, 2016 4:41 PM
> To: Igor Ryzhov 
> Cc: dev at dpdk.org; Tahhan, Maryam ;
> olivier.matz at 6wind.com
> Subject: Re: [dpdk-dev] [PATCH] ethdev: don't count missed packets in
> erroneous packets counter
> 
> CC Maryam and Olivier who had discussions about imissed and other
> stats:
>   http://dpdk.org/ml/archives/dev/2015-August/022905.html
>   http://dpdk.org/ml/archives/dev/2015-September/023351.html
>   http://dpdk.org/ml/archives/dev/2015-September/023612.html
> 
> 2016-03-10 16:03, Igor Ryzhov:
> > Comment for "ierrors" counter says that it counts erroneous received
> packets. But for some reason "imissed" counter is added to "ierrors"
> counter in most drivers. It is a mistake, because missed packets are
> obviously not received. This patch fixes it.
> 
> According to this patch
>   http://dpdk.org/browse/dpdk/commit/?id=70bdb186
> imissed was kept in ierrors because of backward compatibility.
> I'm OK to remove imissed from ierrors.
> 
> Fixes: 70bdb18657da ("ethdev: add Rx error counters for missed, badcrc
> and badlen packets")
> Fixes: 6bfe648406b5 ("i40e: add Rx error statistics")
> Fixes: 856505d303f4 ("cxgbe: add port statistics")
> 
> Acked-by: Thomas Monjalon 

Looks fine, but make sure to add an explicit comment in release notes somewhere 
to flag the change. In case any apps were accounting for imissed as part of 
ierrors like testpmd was: 

-   if (((stats->ierrors - stats->imissed) + stats->rx_nombuf) > 0) 
{
+   if ((stats->ierrors + stats->rx_nombuf) > 0) {
printf("  RX-error:%"PRIu64"\n", stats->ierrors);
printf("  RX-nombufs: %14"PRIu64"\n",
   stats->rx_nombuf);

[dpdk-dev] [PATCH v6 0/2] i40evf: pf reset event report

[Bruce Richardson]

On Tue, Mar 15, 2016 at 09:59:38AM +0800, Jingjing Wu wrote:
> v6 changes:
>  - rebase on latest dpdk-next-net/rel_16_04 branch (commit 94d8f4bf963a)
>  - fix complie issue
> 
> v5 changes:
>  - doc rewording and format fixing.
> 
> v4 changes:
>  - rebase on latest dpdk-next-net/rel_16_04 branch (commit 0f9564a0e4f2)
> 
> v3 changes:
>  - commit log doc rewording.
>  - rebase on latest dpdk-next-net/rel_16_04 branch.
>  - remove few useless line.
>  - adjust interval and increase times for waiting pf msg
> 
> v2 changes:
>  - remove the change on vf reset status checking
>  - add pf event report support in release note
> 
> When Linux PF and DPDK VF are used for i40e PMD, In case of PF
> reset, interrupt request will go via adminq event, VF need be
> informed, a callback mechanism is introduced by VF. This will
> allow VF to invoke callback when reset happens.
> Users can register a callback for this interrupt event like:
> rte_eth_dev_callback_register(portid,
>  RTE_ETH_EVENT_INTR_RESET,
>  reset_event_callback,
>  arg);
> 
> 
> Jingjing Wu (2):
>   i40evf: allocate virtchnl cmd buffer for each vf
>   i40evf: support to report pf reset event
> 
Applied to dpdk-next-net/rel_16_04.

/Bruce

[dpdk-dev] multi-segment mbuf

[Stephen Hemminger]

Read the source.

A multi-segment mbuf has the first mbuf with nb_segs > 1 and chained by
next pointer.
It is a bug in the creator of the mbuf, if number of segments and next
chain don't
match.

There is a rte_pktmbuf_dump(), you can use to look at how your mbuf is
formatted.

On Tue, Mar 22, 2016 at 1:36 PM, Clarylin L  wrote:

> Sorry my bad. The mbuf size has been accidentally changed to 3000.
>
> After fixing this by setting mbuf size to 2048, multi-segment mbuf still
> doesn't work. I was trying to send 2500-byte packets to the target system
> and was expecting to see two-segment mbuf chain), but got errors on it.
>
> Tue Mar 22 14:52:00 2016^@PMD: rte_enic_pmd: packet error
>
>
> Tue Mar 22 14:52:01 2016^@PMD: rte_enic_pmd: packet error
>
>
> Tue Mar 22 14:52:02 2016^@PMD: rte_enic_pmd: packet error
>
>
> Tue Mar 22 14:52:03 2016^@PMD: rte_enic_pmd: packet error
>
>
> Tue Mar 22 14:52:04 2016^@PMD: rte_enic_pmd: packet error
>
>
> Is enic supporting multi-segment mbuf? The dpdk version is 2.0.0. I have
> enabled jumbo-frame and enable_scatter for the port.
>
> On Tue, Mar 22, 2016 at 3:27 AM, Bruce Richardson <
> bruce.richardson at intel.com> wrote:
>
> > On Mon, Mar 21, 2016 at 04:34:50PM -0700, Clarylin L wrote:
> > > I am trying multi-segment mbuf, but it seems not working.
> > >
> > > On my target host, the mbuf size is set to 2048 and I am trying to send
> > > large packet to it (say 2500 bytes without fragmentation) from another
> > > host. I enabled both jumbo_frame and enable_scatter for the port. But I
> > saw
> > > on the target only one mbuf is received with data_len equal to 2500
> (it's
> > > supposed to be a two-mbuf chain).  Although mbuf itself is not working
> as
> > > expected, ping between two hosts succeeded (large ping size; no
> > > fragmentation).
> > >
> > > 1. my mbuf size is only 2048. how can it support receiving such large
> > > packet in one mbuf?
> > >
> > > 2.how to make it work as expected (enable multi-segment mbuf and
> receive
> > > using mbuf chain when needed)?
> > >
> > > Appreciate your help.
> >
> > Hi,
> >
> > when you get the single mbuf with data_len == 2500, what is the buf_len
> > value
> > reported as?
> >
> > /Bruce
> >
>

[dpdk-dev] [PATCH] l2fwd-crypto: add SNOW3G algorithms

[Trahe, Fiona]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Tuesday, March 22, 2016 1:17 PM
> To: dev at dpdk.org
> Cc: Doherty, Declan; De Lara Guarch, Pablo
> Subject: [dpdk-dev] [PATCH] l2fwd-crypto: add SNOW3G algorithms
> 
> Since SNOW3G UEA2/UIA2 are supported now by both HW and SW, l2fwd-
> crypto may use them, extending the list of algorithms parsed from command
> line.
> 
> Signed-off-by: Pablo de Lara 

Acked-by: Fiona Trahe 

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

[Stephen Hemminger]

Normal usage of rte_eth_dev_xstats_get is to call twice. The
first time the function is called with portid, xstats = NULL
and n = 0; this returns the number of entries in the statistics
table that need to be allocated.

The problem is that the routine adds a count value to NULL (0)
and assumes that this is a valid pointer (it isn't). Device drivers
all have a check for NULL, and this no longer matches.

Bug was introduced by commit d4fef8b0d5e5
("ethdev: expose generic and driver specific stats in xstats")

Signed-off-by: Stephen Hemminger 
---
 lib/librte_ether/rte_ethdev.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index db35102..8721a6b 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1495,8 +1495,9 @@ rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstats 
*xstats,
/* Retrieve the xstats from the driver at the end of the
 * xstats struct.
 */
-   xcount = (*dev->dev_ops->xstats_get)(dev, [count],
-(n > count) ? n - count : 0);
+   xcount = (*dev->dev_ops->xstats_get)(dev,
+xstats ? xstats + count : NULL,
+(n > count) ? n - count : 0);

if (xcount < 0)
return xcount;
-- 
2.1.4

[dpdk-dev] [PATCH] l2fwd-crypto: fix incorrect parameter in help

[Trahe, Fiona]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Tuesday, March 22, 2016 1:21 PM
> To: dev at dpdk.org
> Cc: Doherty, Declan; De Lara Guarch, Pablo
> Subject: [dpdk-dev] [PATCH] l2fwd-crypto: fix incorrect parameter in help
> 
> Previous cdev parameter was changed to cdev_type, to select a crypto device
> type preference (HW/SW/ANY), instead of the device itself (QAT/AESNI...).
> 
> Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")
> 
> Signed-off-by: Pablo de Lara 
Acked-by: Fiona Trahe 

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

[Marvin Liu]

Build log:
/root/dpdk/app/test-pmd/cmdline.c:6687:45: error: no member named
's6_addr32' in 'struct in6_addr'
rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);

This is caused by macro "s6_addr32" not defined on FreeBSD and testpmd
swap big endian parameter to host endian. Move the swap action to i40e
ethdev will fix this issue.

Fixes: 7b1312891b69 ("ethdev: add IP in GRE tunnel")

Signed-off-by: Marvin Liu 

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 9d52b8c..4f3d1e4 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6678,14 +6678,12 @@ cmd_tunnel_filter_parsed(void *parsed_result,

if (res->ip_value.family == AF_INET) {
tunnel_filter_conf.ip_addr.ipv4_addr =
-   rte_be_to_cpu_32(res->ip_value.addr.ipv4.s_addr);
+   res->ip_value.addr.ipv4.s_addr;
tunnel_filter_conf.ip_type = RTE_TUNNEL_IPTYPE_IPV4;
} else {
-   int i;
-   for (i = 0; i < 4; i++) {
-   tunnel_filter_conf.ip_addr.ipv6_addr[i] =
-   rte_be_to_cpu_32(res->ip_value.addr.ipv6.s6_addr32[i]);
-   }
+   memcpy(&(tunnel_filter_conf.ip_addr.ipv6_addr),
+   &(res->ip_value.addr.ipv6),
+   sizeof(struct in6_addr));
tunnel_filter_conf.ip_type = RTE_TUNNEL_IPTYPE_IPV6;
}

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 10e0d38..43c2d5c 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -6015,6 +6015,7 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
uint8_t add)
 {
uint16_t ip_type;
+   uint32_t ipv4_addr;
uint8_t i, tun_type = 0;
/* internal varialbe to convert ipv6 byte order */
uint32_t convert_ipv6[4];
@@ -6040,14 +6041,15 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
pfilter->inner_vlan = rte_cpu_to_le_16(tunnel_filter->inner_vlan);
if (tunnel_filter->ip_type == RTE_TUNNEL_IPTYPE_IPV4) {
ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV4;
+   ipv4_addr = rte_be_to_cpu_32(tunnel_filter->ip_addr.ipv4_addr);
rte_memcpy(>ipaddr.v4.data,
-   
_cpu_to_le_32(tunnel_filter->ip_addr.ipv4_addr),
+   _cpu_to_le_32(ipv4_addr),
sizeof(pfilter->ipaddr.v4.data));
} else {
ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV6;
for (i = 0; i < 4; i++) {
convert_ipv6[i] =
-   rte_cpu_to_le_32(tunnel_filter->ip_addr.ipv6_addr[i]);
+   
rte_cpu_to_le_32(rte_be_to_cpu_32(tunnel_filter->ip_addr.ipv6_addr[i]));
}
rte_memcpy(>ipaddr.v6.data, _ipv6,
sizeof(pfilter->ipaddr.v6.data));
-- 
1.9.3

[dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue

[Xie, Huawei]

On 3/22/2016 6:13 PM, Richardson, Bruce wrote:
> On Mon, Mar 21, 2016 at 05:47:44PM +, Xie, Huawei wrote:
>> On 3/18/2016 10:17 PM, Bruce Richardson wrote:
>>> On Fri, Mar 18, 2016 at 01:47:29PM +0100, Mauricio V?squez wrote:
 Hi,


 On Fri, Mar 18, 2016 at 11:35 AM, Thomas Monjalon >>> 6wind.com
> wrote:
> 2016-03-18 11:27, Olivier Matz:
>> On 03/18/2016 11:18 AM, Bruce Richardson wrote:
> +   /* Avoid the unnecessary cmpset operation below, which is
> also
> +* potentially harmful when n equals 0. */
> +   if (n == 0)
>
 What about using unlikely here?

>>> Unless there is a measurable performance increase by adding in
> likely/unlikely
>>> I'd suggest avoiding it's use. In general, likely/unlikely should only
> be used
>>> for things like catestrophic errors because the penalty for taking the
> unlikely
>>> leg of the code can be quite severe. For normal stuff, where the code
> nearly
>>> always goes one way in the branch but occasionally goes the other, the
> hardware
>>> branch predictors generally do a good enough job.
>> Do you mean using likely/unlikely could be worst than not using it
>> in this case?
>>
>> To me, using unlikely here is not a bad idea: it shows to the compiler
>> and to the reader of the code that is case is not the usual case.
> It would be nice to have a guideline section about likely/unlikely in
> doc/guides/contributing/design.rst
>
> Bruce gave a talk at Dublin about this kind of things.
> I'm sure he could contribute more design guidelines ;)
>
 There is a small explanation in the section "Branch Prediction" of
 doc/guides/contributing/coding_style.rst, but I do not know if that is
 enough to understand when to use them.

 I've made a fast check and there are many PMDs that use them to check if
 number of packets is zero in the transmission function.
>>> Yeah, and I wonder how many of those are actually necessary too :-)
>>>
>>> It's not a big deal either way, I just think the patch is fine as-is without
>>> the extra macros.
>> IMO we use likely/unlikely in two cases, catastrophic errors and the
>> code nearly always goes one way, i.e, preferred/favored fast path.
>> Likely/unlikely helps not only for branch predication but also for cache
> For branch prediction, anything after the first time through the code path
> the prediction will be based on what happened before rather than any static
> hints in the code.

Yes, maybe i didn't make myself clear? My main concern isn't about
branch predication...

>> usage. The code generated for the likely path will directly follow the
>> branch instruction. To me, it is reasonable enough to add unlikely for n
>> == 0, which we don't expect to happen.
>> I remember with/without likely, compiler could generate three kind of
>> instructions. Didn't deep dive into it.
>>
>>> /Bruce
>>>

[dpdk-dev] Regarding DPDK installation

[Thomas Monjalon]

2016-03-22 13:13, Vivek Gupta:
> I am trying to install DPDK 2.2 on Ubuntu 14.

Do you just want to compile DPDK or really install it?
Where do you want to install DPDK?

> After configuring all necessary variables in common_linuxapp
> file, I run following two commands
> 
> make config T=x86_64-ivshmem-linuxapp-gcc

The "make config" command is useless if using "install T=" after.

> make install T=x86_64-ivshmem-linuxapp-gcc

The install directory is not specified in this command.

> After 'make install T=x86_64-ivshmem-linuxapp-gcc' , installation fails with 
> message as below
> 
> **
> Build complete [x86_64-native-linuxapp-gcc]
> Installation cannot run with T defined and DESTDIR undefined
> **

Why don't you use DESTDIR as suggested?

Or instead of using the old all-in-one "install T=", you can use
the more standard syntax in 3 commands:
make config T=

make
make install [DESTDIR=] [prefix=]

> I have gone through following patches:
> http://dpdk.org/dev/patchwork/patch/9270/
> http://dpdk.org/dev/patchwork/patch/9272/
> More interestingly  I found that changes suggested in above patches
> were already in place except of below two-
> addition of 'prefix' in file .../doc/build-sdk-quick-txt  [ Applied in ]
> addition of  'make install T=X86_64-native-linuxapp-gcc'  in file 
> ../doc/guides/prog_guide/dev_kit_root_make_help.rst

These patches have been Superseded by newer (see the State field).

> In file doc/guides/prog_guide/dev_kit_root_make_help.rst , I had "make 
> install DESTDIR=myinstall" which i replaced with "make install 
> DESTDIR=myinstall prefix=/usr"and tried but no success 
>  so change the content as suggested in patch#9270 as "make install 
> T=x86_64-native-linuxapp-gcc prefix=/usr" but no progress.
> 
> Kindly suggest to solve this issue.

Please read the whole doc/guides/prog_guide/dev_kit_root_make_help.rst
and don't hesitate to suggest any change if something is not clear.
Thanks

> ::DISCLAIMER::
[...]

no disclaimer please

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

[Konstantin Ananyev]

Fixes: 39625417585 ("mbuf: redefine packet type")

Current vector RX can't always set packet_type properly.
To be more specific:
a) it never sets RTE_PTYPE_L2_ETHER
b) it doesn't handle tunnel ipv4/ipv6 case correctly.
c) it doesn't check is IXGBE_RXDADV_PKTTYPE_ETQF set or not.
While a) is pretty easy to fix, b) and c) are not that straightforward
in terms of SIMD ops (specially b).
So far I wasn't able to make vRX support packet_type properly without
noticeable performance loss.
So for now, just remove that functionality at all from vector RX and
update dev_supported_ptypes_get().

Signed-off-by: Konstantin Ananyev 
---
 drivers/net/ixgbe/ixgbe_ethdev.c   |  4 +---
 drivers/net/ixgbe/ixgbe_rxtx_vec.c | 34 +++---
 2 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index c1a8630..29527de 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2962,9 +2962,7 @@ ixgbe_dev_supported_ptypes_get(struct rte_eth_dev *dev)
if (dev->rx_pkt_burst == ixgbe_recv_pkts ||
dev->rx_pkt_burst == ixgbe_recv_pkts_lro_single_alloc ||
dev->rx_pkt_burst == ixgbe_recv_pkts_lro_bulk_alloc ||
-   dev->rx_pkt_burst == ixgbe_recv_pkts_bulk_alloc ||
-   dev->rx_pkt_burst == ixgbe_recv_pkts_vec ||
-   dev->rx_pkt_burst == ixgbe_recv_scattered_pkts_vec)
+   dev->rx_pkt_burst == ixgbe_recv_pkts_bulk_alloc)
return ptypes;
return NULL;
 }
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c 
b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
index ccd93c7..5040704 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
@@ -220,8 +220,6 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct 
rte_mbuf **rx_pkts,
0, 0/* ignore pkt_type field */
);
__m128i dd_check, eop_check;
-   __m128i desc_mask = _mm_set_epi32(0x, 0x,
- 0x, 0x07F0);

/* nb_pkts shall be less equal than RTE_IXGBE_MAX_RX_BURST */
nb_pkts = RTE_MIN(nb_pkts, RTE_IXGBE_MAX_RX_BURST);
@@ -259,9 +257,8 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct 
rte_mbuf **rx_pkts,
13, 12,  /* octet 12~13, 16 bits data_len */
0xFF, 0xFF,  /* skip high 16 bits pkt_len, zero out */
13, 12,  /* octet 12~13, low 16 bits pkt_len */
-   0xFF, 0xFF,  /* skip high 16 bits pkt_type */
-   1,   /* octet 1, 8 bits pkt_type field */
-   0/* octet 0, 4 bits offset 4 pkt_type field */
+   0xFF, 0xFF,  /* skip 32 bit pkt_type */
+   0xFF, 0xFF
);

/* Cache is empty -> need to scan the buffer rings, but first move
@@ -278,7 +275,6 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct 
rte_mbuf **rx_pkts,
for (pos = 0, nb_pkts_recd = 0; pos < nb_pkts;
pos += RTE_IXGBE_DESCS_PER_LOOP,
rxdp += RTE_IXGBE_DESCS_PER_LOOP) {
-   __m128i descs0[RTE_IXGBE_DESCS_PER_LOOP];
__m128i descs[RTE_IXGBE_DESCS_PER_LOOP];
__m128i pkt_mb1, pkt_mb2, pkt_mb3, pkt_mb4;
__m128i zero, staterr, sterr_tmp1, sterr_tmp2;
@@ -289,7 +285,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct 
rte_mbuf **rx_pkts,

/* Read desc statuses backwards to avoid race condition */
/* A.1 load 4 pkts desc */
-   descs0[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));
+   descs[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));

/* B.2 copy 2 mbuf point into rx_pkts  */
_mm_storeu_si128((__m128i *)_pkts[pos], mbp1);
@@ -297,10 +293,10 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct 
rte_mbuf **rx_pkts,
/* B.1 load 1 mbuf point */
mbp2 = _mm_loadu_si128((__m128i *)_ring[pos+2]);

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

/* B.2 copy 2 mbuf point into rx_pkts  */
_mm_storeu_si128((__m128i *)_pkts[pos+2], mbp2);
@@ -312,14 +308,6 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct 
rte_mbuf **rx_pkts,
rte_prefetch0(_pkts[pos + 3]->cacheline1);
}

-   /* A* mask out 0~3 bits RSS type */
-   descs[3] = _mm_and_si128(descs0[3], desc_mask);
-   

[dpdk-dev] [PATCH 2/3] bnx2x: Tx performance improvement fixes

[Bruce Richardson]

On Thu, Mar 10, 2016 at 05:47:56PM -0800, Rasesh Mody wrote:
> Signed-off-by: Harish Patil 
> Signed-off-by: Rasesh Mody 
> ---
>  drivers/net/bnx2x/bnx2x.c|  207 
> +-
>  drivers/net/bnx2x/bnx2x.h|4 +-
>  drivers/net/bnx2x/bnx2x_ethdev.c |   53 ++
>  drivers/net/bnx2x/bnx2x_rxtx.c   |   47 +
>  4 files changed, 173 insertions(+), 138 deletions(-)
> 
This patch needs a commit message with a description of changes and how they 
help with performance.

If there are multiple changes being made to improve the performance, or add in
extra TX features, they would be better split into separate patches, with one
unique change per patch. If any of the changes are bug-fixes as opposed to
performance improvements (since the word "fixes" appears in the title here), 
they
should each be in a separate patch, with a message describing the fix and
including a "fixes" line in the message as described here:
http://dpdk.org/doc/guides/contributing/patches.html#commit-messages-body

Thanks,
/Bruce

[dpdk-dev] [PATCH] ixgbe: avoid unnessary break when checking at the tail of rx hwring

[Ananyev, Konstantin]

> -Original Message-
> From: Jianbo Liu [mailto:jianbo.liu at linaro.org]
> Sent: Monday, March 21, 2016 2:27 AM
> To: Richardson, Bruce
> Cc: Lu, Wenzhuo; Zhang, Helin; Ananyev, Konstantin; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] ixgbe: avoid unnessary break when checking at 
> the tail of rx hwring
> 
> On 18 March 2016 at 18:03, Bruce Richardson  
> wrote:
> > On Thu, Mar 17, 2016 at 10:20:01AM +0800, Jianbo Liu wrote:
> >> On 16 March 2016 at 19:14, Bruce Richardson  >> intel.com> wrote:
> >> > On Wed, Mar 16, 2016 at 03:51:53PM +0800, Jianbo Liu wrote:
> >> >> Hi Wenzhuo,
> >> >>
> >> >> On 16 March 2016 at 14:06, Lu, Wenzhuo  wrote:
> >> >> > HI Jianbo,
> >> >> >
> >> >> >
> >> >> >> -Original Message-
> >> >> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jianbo Liu
> >> >> >> Sent: Monday, March 14, 2016 10:26 PM
> >> >> >> To: Zhang, Helin; Ananyev, Konstantin; dev at dpdk.org
> >> >> >> Cc: Jianbo Liu
> >> >> >> Subject: [dpdk-dev] [PATCH] ixgbe: avoid unnessary break when 
> >> >> >> checking at the
> >> >> >> tail of rx hwring
> >> >> >>
> >> >> >> When checking rx ring queue, it's possible that loop will break at 
> >> >> >> the tail while
> >> >> >> there are packets still in the queue header.
> >> >> > Would you like to give more details about in what scenario this issue 
> >> >> > will be hit? Thanks.
> >> >> >
> >> >>
> >> >> vPMD will place extra RTE_IXGBE_DESCS_PER_LOOP - 1 number of empty
> >> >> descriptiors at the end of hwring to avoid overflow when do checking
> >> >> on rx side.
> >> >>
> >> >> For the loop in _recv_raw_pkts_vec(), we check 4 descriptors each
> >> >> time. If all 4 DD are set, and all 4 packets are received.That's OK in
> >> >> the middle.
> >> >> But if come to the end of hwring, and less than 4 descriptors left, we
> >> >> still need to check 4 descriptors at the same time, so the extra empty
> >> >> descriptors are checked with them.
> >> >> This time, the number of received packets is apparently less than 4,
> >> >> and we break out of the loop because of the condition "var !=
> >> >> RTE_IXGBE_DESCS_PER_LOOP".
> >> >> So the problem arises. It is possible that there could be more packets
> >> >> at the hwring beginning that still waiting for being received.
> >> >> I think this fix can avoid this situation, and at least reduce the
> >> >> latency for the packets in the header.
> >> >>
> >> > Packets are always received in order from the NIC, so no packets ever 
> >> > get left
> >> > behind or skipped on an RX burst call.
> >> >
> >> > /Bruce
> >> >
> >>
> >> I knew packets are received in order, and no packets will be skipped,
> >> but some will be left behind as I explained above.
> >> vPMD will not received nb_pkts required by one RX burst call, and
> >> those at the beginning of hwring are still waiting to be received till
> >> the next call.
> >>
> >> Thanks!
> >> Jianbo
> > HI Jianbo,
> >
> > ok, I understand now. I'm not sure that this is a significant problem 
> > though,
> > since we are working in polling mode. Is there a performance impact to your
> > change, because I don't think that we can reduce performance just to fix 
> > this?
> >
> > Regards,
> > /Bruce
> It will be a problem because the possibility could be high.
> Considering rx hwring size is 128 and rx burst is 32, the possiblity
> can be 32/128.
> I know this change is critical, so I want you (and maintainers) to do
> full evaluations about throughput/latency..before making conclusion.

I am still not sure what is a problem you are trying to solve here.
Yes recv_raw_pkts_vec() call wouldn't wrap around HW ring boundary,  
and yes can return less packets that are actually available by the HW.
Though as Bruce pointed, they'll be returned to the user by next call.
Actually recv_pkts_bulk_alloc() works in a similar way.
Why do you consider that as a problem?
Konstantin

> 
> Jianbo

[dpdk-dev] [PATCH] mlx4: use dummy rxqs when a non-pow2 number is requested

[Wiles, Keith]

Hi Olivier,

>Hi Keith,
>
>On 03/21/2016 06:38 PM, Wiles, Keith wrote:
>>> On Mar 21, 2016, at 11:10 AM, Olivier Matz  
>>> wrote:
>>>
>>> When using RSS, the number of rxqs has to be a power of two.
>>> This is a problem because there is no API is dpdk that makes
>>> the application aware of that.
>>>
>>> A good compromise is to allow the application to request a
>>> number of rxqs that is not a power of 2, but having inactive
>>> queues that will never receive packets. In this configuration,
>>> a warning will be issued to users to let them know that
>>> this is not an optimal configuration.
>> 
>> Not sure I like this solution. I think an error should be returned with a 
>> log message instead. What if the next driver needs power of three or must be 
>> odd or even number. 
>> 
>> The bigger problem is the application is no longer portable for any given 
>> nic configuration.
>> 
>> We need a method for the application to query the system for these types of 
>> information. But as we do not have that API we need to just error the 
>> request off.
>
>
>The initial problem is that the driver says "I support a maximum
>of X queues" and if the application configures a lower number, it
>gets an error.
>
>There is no API in DPDK to tell that only specific number of queues
>are supported. Adding an API is a solution, but in this case it's
>probably overkill. With this patch, the driver can present the proper
>number of queues to the application, knowing that the spreading of
>the packets won't be ideal (some queues won't receive packets), but
>it will work.
>
>A step further in this direction would be to configure more queues
>than asked in hardware to do a better spreading, almost similar to
>what is done with RETA tables in mlx5. But this is more complicated
>to do, especially if we want it for 16.04.

Well I guess I must agree with the solution, but I am not real happy. Can we 
mark this a temp fix until we figure out a cleaner solution as I would not want 
this type of solution forever or be the standard way to handle these problems.

>
>Hope this is clearer with the explanation.
>
>Regards,
>Olivier
>
>


Regards,
Keith

[dpdk-dev] [PATCH v2] mk: fix eal shared library dependencies -lrt

[Panu Matilainen]

On 03/22/2016 11:58 AM, Daniel Mrzyglod wrote:
> For GLIBC < 2.17 it is necessery to add -lrt for linker
> from glibc > 2.17 The `clock_*' suite of functions (declared in ) is 
> now
> available directly in the main C library. This affect Ubuntu 12.04 in i686
> and other older Linux Distros).
>
> Fixes: 4758404a3084 ("mk: fix eal shared library dependencies")
>
> Signed-off-by: Daniel Mrzyglod 
> ---
>   app/test/Makefile| 1 +
>   examples/ptpclient/Makefile  | 1 +
>   lib/librte_eal/linuxapp/eal/Makefile | 1 +
>   3 files changed, 3 insertions(+)
>
> diff --git a/app/test/Makefile b/app/test/Makefile
> index 00e4df2..707930f 100644
> --- a/app/test/Makefile
> +++ b/app/test/Makefile
> @@ -114,6 +114,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_string.c
>   SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_lib.c
>
>   ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y)
> +LDFLAGS += -lrt
>   SRCS-y += test_red.c
>   SRCS-y += test_sched.c
>   endif
> diff --git a/examples/ptpclient/Makefile b/examples/ptpclient/Makefile
> index b77cf71..082c690 100644
> --- a/examples/ptpclient/Makefile
> +++ b/examples/ptpclient/Makefile
> @@ -46,6 +46,7 @@ SRCS-y := ptpclient.c
>
>   CFLAGS += -O3
>   CFLAGS += $(WERROR_FLAGS)
> +LDFLAGS += -lrt

These two should be LDLIBS instead. LDFLAGS is for passing in other 
arguments to the linker, such as path, LDLIBS exists solely for passing 
in the actual libraries.

- Panu -

[dpdk-dev] Regarding DPDK installation

[Vivek Gupta]

Hi

>Do you just want to compile DPDK or really install it?Where do you want to 
>install DPDK?
I want to install DPDK into {$HOME}/dpdk   downloaded tar ball.

> The install directory is not specified in this command.
 After your suggestion i used as 
make config T=x86_64-ivshmem-linuxapp-gcc DESTDIR=install 

and it successfully creates a install directory and libraries into it.
Doing so would require any change for RTE_SDK and RTE_TARGET?

Thanks && Regards
Vivek Gupta

From: Thomas Monjalon [thomas.monja...@6wind.com]
Sent: Tuesday, March 22, 2016 7:06 PM
To: Vivek Gupta
Cc: dev at dpdk.org
Subject: Re: Regarding DPDK installation

2016-03-22 13:13, Vivek Gupta:
> I am trying to install DPDK 2.2 on Ubuntu 14.

Do you just want to compile DPDK or really install it?
Where do you want to install DPDK?

> After configuring all necessary variables in common_linuxapp
> file, I run following two commands
>
> make config T=x86_64-ivshmem-linuxapp-gcc

The "make config" command is useless if using "install T=" after.

> make install T=x86_64-ivshmem-linuxapp-gcc

The install directory is not specified in this command.

> After 'make install T=x86_64-ivshmem-linuxapp-gcc' , installation fails with 
> message as below
>
> **
> Build complete [x86_64-native-linuxapp-gcc]
> Installation cannot run with T defined and DESTDIR undefined
> **

Why don't you use DESTDIR as suggested?

Or instead of using the old all-in-one "install T=", you can use
the more standard syntax in 3 commands:
make config T=

make
make install [DESTDIR=] [prefix=]

> I have gone through following patches:
> http://dpdk.org/dev/patchwork/patch/9270/
> http://dpdk.org/dev/patchwork/patch/9272/
> More interestingly  I found that changes suggested in above patches
> were already in place except of below two-
> addition of 'prefix' in file .../doc/build-sdk-quick-txt  [ Applied in ]
> addition of  'make install T=X86_64-native-linuxapp-gcc'  in file 
> ../doc/guides/prog_guide/dev_kit_root_make_help.rst

These patches have been Superseded by newer (see the State field).

> In file doc/guides/prog_guide/dev_kit_root_make_help.rst , I had "make 
> install DESTDIR=myinstall" which i replaced with "make install 
> DESTDIR=myinstall prefix=/usr"and tried but no success
>  so change the content as suggested in patch#9270 as "make install 
> T=x86_64-native-linuxapp-gcc prefix=/usr" but no progress.
>
> Kindly suggest to solve this issue.

Please read the whole doc/guides/prog_guide/dev_kit_root_make_help.rst
and don't hesitate to suggest any change if something is not clear.
Thanks

> ::DISCLAIMER::
[...]

no disclaimer please


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.

[dpdk-dev] [PATCH v3] mk: fix eal shared library dependencies -lrt

[Daniel Mrzyglod]

For GLIBC < 2.17 it is necessery to add -lrt for linker
from glibc > 2.17 The `clock_*' suite of functions (declared in ) is now
available directly in the main C library. This affect Ubuntu 12.04 in i686
and other older Linux Distros).

v3: change LDFLAGS to LDLIBS
v2: Add missed example
v1: Initial revision


Fixes: 4758404a3084 ("mk: fix eal shared library dependencies")

Signed-off-by: Daniel Mrzyglod 
---
 app/test/Makefile| 1 +
 examples/ptpclient/Makefile  | 1 +
 lib/librte_eal/linuxapp/eal/Makefile | 1 +
 3 files changed, 3 insertions(+)

diff --git a/app/test/Makefile b/app/test/Makefile
index 00e4df2..707930f 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -114,6 +114,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_string.c
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_lib.c

 ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y)
+LDLIBS += -lrt
 SRCS-y += test_red.c
 SRCS-y += test_sched.c
 endif
diff --git a/examples/ptpclient/Makefile b/examples/ptpclient/Makefile
index b77cf71..082c690 100644
--- a/examples/ptpclient/Makefile
+++ b/examples/ptpclient/Makefile
@@ -46,6 +46,7 @@ SRCS-y := ptpclient.c

 CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -lrt

 # workaround for a gcc bug with noreturn attribute
 # http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
b/lib/librte_eal/linuxapp/eal/Makefile
index 25b3a8e..1860739 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -52,6 +52,7 @@ CFLAGS += $(WERROR_FLAGS) -O3
 LDLIBS += -ldl
 LDLIBS += -lpthread
 LDLIBS += -lgcc_s
+LDLIBS += -lrt

 # specific to linuxapp exec-env
 SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) := eal.c
-- 
2.5.5

[dpdk-dev] [PATCH v2] mk: fix eal shared library dependencies -lrt

[Daniel Mrzyglod]

For GLIBC < 2.17 it is necessery to add -lrt for linker
from glibc > 2.17 The `clock_*' suite of functions (declared in ) is now
available directly in the main C library. This affect Ubuntu 12.04 in i686
and other older Linux Distros).

v3: change LDFLAGS to LDLIBS
v2: Add missed example
v1: Initial revision


Fixes: 4758404a3084 ("mk: fix eal shared library dependencies")

Signed-off-by: Daniel Mrzyglod 
---
 app/test/Makefile| 1 +
 examples/ptpclient/Makefile  | 1 +
 lib/librte_eal/linuxapp/eal/Makefile | 1 +
 3 files changed, 3 insertions(+)

diff --git a/app/test/Makefile b/app/test/Makefile
index 00e4df2..707930f 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -114,6 +114,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_string.c
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_lib.c

 ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y)
+LDLIBS += -lrt
 SRCS-y += test_red.c
 SRCS-y += test_sched.c
 endif
diff --git a/examples/ptpclient/Makefile b/examples/ptpclient/Makefile
index b77cf71..082c690 100644
--- a/examples/ptpclient/Makefile
+++ b/examples/ptpclient/Makefile
@@ -46,6 +46,7 @@ SRCS-y := ptpclient.c

 CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -lrt

 # workaround for a gcc bug with noreturn attribute
 # http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
b/lib/librte_eal/linuxapp/eal/Makefile
index 25b3a8e..1860739 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -52,6 +52,7 @@ CFLAGS += $(WERROR_FLAGS) -O3
 LDLIBS += -ldl
 LDLIBS += -lpthread
 LDLIBS += -lgcc_s
+LDLIBS += -lrt

 # specific to linuxapp exec-env
 SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) := eal.c
-- 
2.5.5

[dpdk-dev] [PATCH 00/10] cxgbe: Add flow director support

[Bruce Richardson]

On Wed, Feb 03, 2016 at 02:02:21PM +0530, Rahul Lakkireddy wrote:
> This series of patches extend the flow director filter and add support
> for Chelsio T5 hardware filtering capabilities.
> 
> Chelsio T5 supports carrying out filtering in hardware which supports 3
> actions to carry out on a packet which hit a filter viz.
> 
> 1. Action Pass - Packets hitting a filter rule can be directed to a
>particular RXQ.
> 
> 2. Action Drop - Packets hitting a filter rule are dropped in h/w.
> 
> 3. Action Switch - Packets hitting a filter rule can be switched in h/w
>from one port to another, without involvement of host.  Also, the
>action Switch also supports rewrite of src-mac/dst-mac headers as
>well as rewrite of vlan headers.  It also supports rewrite of IP
>headers and thereby, supports NAT (Network Address Translation)
>in h/w.
> 
> Also, each filter rule can optionally support specifying a mask value
> i.e. it's possible to create a filter rule for an entire subnet of IP
> addresses or a range of tcp/udp ports, etc.
> 
> Patch 1 does the following:
> - Adds a new flow RTE_ETH_FLOW_RAW_PKT to allow specifying a generic
>   flow.
> - Adds an additional generic array to rte_eth_fdir_flow to allow
>   specifying generic flow input.
> - Adds an additional mask for the flow input to allow range of values
>   to be matched in the flow input.
> - Adds a new behavior 'switch'.
> - Adds a generic array to hold behavior arguments that can be passed
>   when a particular behavior is taken. For ex: in case of action
>   'switch', pass additional 4-tuple to allow rewriting src/dst ip and
>   port addresses to support NAT'ing.
> 
Patch 1 of this set is not mergable for 16.04 because there is no agreement on
the way forward for filtering APIs, and the fact that the changes proposed are
not acceptable to the maintainers as-is.
Therefore the whole patchset must be deferred for a later release. I'm updating
the status in patchwork to "Changes Requested".

Regards,
/Bruce

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

[Ananyev, Konstantin]

Hi, 

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


Wonder can't we just include PKT_TX_TCP_SEG into I40E_TX_CKSUM_OFFLOAD_MASK,
and keep i40e_xmit_pkts() unchanged?
Konstantin

[dpdk-dev] multi-segment mbuf

[Clarylin L]

Sorry my bad. The mbuf size has been accidentally changed to 3000.

After fixing this by setting mbuf size to 2048, multi-segment mbuf still
doesn't work. I was trying to send 2500-byte packets to the target system
and was expecting to see two-segment mbuf chain), but got errors on it.

Tue Mar 22 14:52:00 2016^@PMD: rte_enic_pmd: packet error


Tue Mar 22 14:52:01 2016^@PMD: rte_enic_pmd: packet error


Tue Mar 22 14:52:02 2016^@PMD: rte_enic_pmd: packet error


Tue Mar 22 14:52:03 2016^@PMD: rte_enic_pmd: packet error


Tue Mar 22 14:52:04 2016^@PMD: rte_enic_pmd: packet error


Is enic supporting multi-segment mbuf? The dpdk version is 2.0.0. I have
enabled jumbo-frame and enable_scatter for the port.

On Tue, Mar 22, 2016 at 3:27 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:

> On Mon, Mar 21, 2016 at 04:34:50PM -0700, Clarylin L wrote:
> > I am trying multi-segment mbuf, but it seems not working.
> >
> > On my target host, the mbuf size is set to 2048 and I am trying to send
> > large packet to it (say 2500 bytes without fragmentation) from another
> > host. I enabled both jumbo_frame and enable_scatter for the port. But I
> saw
> > on the target only one mbuf is received with data_len equal to 2500 (it's
> > supposed to be a two-mbuf chain).  Although mbuf itself is not working as
> > expected, ping between two hosts succeeded (large ping size; no
> > fragmentation).
> >
> > 1. my mbuf size is only 2048. how can it support receiving such large
> > packet in one mbuf?
> >
> > 2.how to make it work as expected (enable multi-segment mbuf and receive
> > using mbuf chain when needed)?
> >
> > Appreciate your help.
>
> Hi,
>
> when you get the single mbuf with data_len == 2500, what is the buf_len
> value
> reported as?
>
> /Bruce
>

[dpdk-dev] [dpdk-users] how to Read(Write) from(to) via lcores in dpdk regardless of NIC

[Mahdi Moradmand Badie]

Dear Andriy,
I did my task with the help of rte_ring, but now I wanna replace rte_ring
with real share cache(L3),
May I ask you if there is any possibility in DPDK in order to do it.
Thanks in advance,

On 9 March 2016 at 05:26, Andriy Berestovskyy  wrote:

> Mahdi,
> 1. Sure, the rte_ring is another good way to communicate between the
> lcores. If you have just one "worker" lcore or you do not care about
> packet ordering, you might prefer using rte_ring over the
> rte_distributor.
>
>
> 2. For the simplicity, you might assume that any of your shared
> structures (rte_ring or rte_distributor) eventually get into the
> cache.
>
> Andriy
>
> On Tue, Mar 8, 2016 at 10:49 PM, Mahdi Moradmand Badie
>  wrote:
> > Another issue, ;)
> > How I could access to the share memory cache of lcores (L3), the rte_ring
> > is exactly that??
> >
> > On 8 March 2016 at 13:08, Mahdi Moradmand Badie 
> > wrote:
> >
> >> Dear Andriy,
> >> Sorry for interrupt again,
> >> As I see in rte_distributor, it is using rte_eth (ethernet), while I
> >> wanna without using any NIC because I don't have it on my personal
> computer
> >> :)
> >>
> >> On 8 March 2016 at 11:49, Mahdi Moradmand Badie  >
> >> wrote:
> >>
> >>> Thanks so much Andriy,
> >>> Regarding cross-post, yes you are right sorry about that and of course
> >>> afterwards.
> >>>
> >>> On 8 March 2016 at 03:17, Andriy Berestovskyy 
> wrote:
> >>>
>  Hi Mahdi,
>  Looks like the DPDK's rte_distributor is the right tool for your task.
>  Please have a look at:
>  http://dpdk.org/doc/guides/prog_guide/packet_distrib_lib.html
> 
>  There is also the Distributor Sample Application in DPDK:
>  http://dpdk.org/doc/guides/sample_app_ug/dist_app.html
> 
> 
>  Please do not cross-post to dev@ mailing list.
> 
>  Regards,
>  Andriy
> 
>  On Tue, Mar 8, 2016 at 6:41 AM, Mahdi Moradmand Badie
>   wrote:
>  > I wanna create for example 3 different packets in core_0 as master
> and
>  > store them one by one in share memory(rte_ring),
>  > then the core_1 as slave read them and do function on them (ex.
>  P1+P2+P3)
>  > and again store in share memory, finally the core_0 read the packets
>  from
>  > share memory and compare them with whatever expected :)
>  > As I said and you mentioned is the same? :)
>  >
>  > On 8 March 2016 at 00:35, Hamed Zaghaghi 
>  wrote:
>  >
>  >> Hi,
>  >>
>  >> If I understood well you need to do these tasks:
>  >> 1. Packet crafting (I think that DPDK has no functions for this
> task)
>  >> 2. Store packets (DPDK has (rte_mbuf)[
>  >> http://dpdk.org/doc/api/rte__mbuf_8h.html])
>  >> 3. Share between lcores (DPDK offers rte_ring)
>  >>
>  >>
>  >>
>  >> On Tue, Mar 8, 2016 at 8:45 AM Mahdi Moradmand Badie <
>  >> mahdi.mbadie at gmail.com> wrote:
>  >>
>  >>> Dear Hamed,
>  >>>
>  >>> First of all thank you so much for your kindly reply,
>  >>>
>  >>> It's the primary part of the big project, in order to be more
>  familiar
>  >>> with DPDK,
>  >>> I have to implement the mentioned framework by use of DPDK,
>  >>> And finally we wanna implement the cache locking approach (via
> help
>  of
>  >>> features like Cache Allocation Technology(CAT), Cache Monitoring
>  Technology
>  >>> (CMT)) in Xeon processor (my supervisor told me this simple
> exercise
>  >>> will be helpful to do the final part) in such a way we could
>  dedicate a
>  >>> specific part of shared memory (L3) to each core which the other
>  don't
>  >>> access to it.
>  >>> Obviously using of DPDK with Xeon which both are from "Intel", is
>  >>> considered as strength point.
>  >>>
>  >>> I hope this was more clear :)
>  >>>
>  >>> On 7 March 2016 at 23:56, Hamed Zaghaghi <
> hamed.zaghaghi at gmail.com>
>  >>> wrote:
>  >>>
>   Hi Mahdi,
>  
>   Why do you want to use DPDK when you don't use NIC? You can do
> what
>  you
>   want outside of DPDK.
>  
>   Regards,
>   Hamed Zaghaghi
>  
>   On Tue, Mar 8, 2016 at 12:16 AM Mahdi Moradmand Badie <
>   mahdi.mbadie at gmail.com> wrote:
>  
>  > Dear All,
>  > I am Mahdi and I am new in DPDK,
>  > I wanna generate for example 3 different packets in core0 as
> master
>  > write
>  > it to share memory (L3), then core1 as slave read this packets,
>  change
>  > them
>  > with for example function1 and write again in share memory (L3)
> and
>  > finally
>  > check the result with whatever I expect.
>  > The most important thing is that I don't wanna use NIC and I
> don't
>  know
>  > for
>  > working with cores how I can write/read to/from them, I mean
> with
>  which
>  > template and 

[dpdk-dev] [PATCH] l2fwd-crypto: fix incorrect parameter in help

[Pablo de Lara]

Previous cdev parameter was changed to cdev_type,
to select a crypto device type preference (HW/SW/ANY),
instead of the device itself (QAT/AESNI...).

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

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

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 762d22a..59f8c92 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -769,7 +769,7 @@ l2fwd_crypto_usage(const char *prgname)
"  -t PERIOD: statistics will be refreshed each PERIOD seconds"
" (0 to disable, 10 default, 86400 maximum)\n"

-   "  --cdev AESNI_MB / QAT\n"
+   "  --cdev_type HW / SW / ANY\n"
"  --chain HASH_CIPHER / CIPHER_HASH\n"

"  --cipher_algo ALGO\n"
-- 
2.5.0

[dpdk-dev] [PATCH] l2fwd-crypto: add SNOW3G algorithms

[Pablo de Lara]

Since SNOW3G UEA2/UIA2 are supported now by both HW and SW,
l2fwd-crypto may use them, extending the list of algorithms
parsed from command line.

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

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 59f8c92..05cdd26 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -835,6 +835,9 @@ parse_cipher_algo(enum rte_crypto_cipher_algorithm *algo, 
char *optarg)
} else if (strcmp("AES_GCM", optarg) == 0) {
*algo = RTE_CRYPTO_CIPHER_AES_GCM;
return 0;
+   } else if (strcmp("SNOW3G_UEA2", optarg) == 0) {
+   *algo = RTE_CRYPTO_CIPHER_SNOW3G_UEA2;
+   return 0;
}

printf("Cipher algorithm  not supported!\n");
@@ -901,6 +904,9 @@ parse_auth_algo(enum rte_crypto_auth_algorithm *algo, char 
*optarg)
} else if (strcmp("SHA512_HMAC", optarg) == 0) {
*algo = RTE_CRYPTO_AUTH_SHA512_HMAC;
return 0;
+   } else if (strcmp("SNOW3G_UIA2", optarg) == 0) {
+   *algo = RTE_CRYPTO_AUTH_SNOW3G_UIA2;
+   return 0;
}

printf("Authentication algorithm specified not supported!\n");
-- 
2.5.0

[dpdk-dev] Reg: promiscuous mode on VF

[bharath paulraj]

Thanks a lot Michael.  Finally i am able to see some light. I will try the
same in our setup and will post you the results.

Thanks,
Bharath

On Tue, Mar 22, 2016 at 12:09 PM, Qiu, Michael 
wrote:

> Yes, we could let ovs using 82599 VF to do rx/tx. I don't know what's
> your l2 bridge, but since ovs could work I think your bridge also could
> work. But I only tested with one VF.
>
> Make sure below two patches (bifurcate driver) are included in your kernel:
>
> _https://patchwork.ozlabs.org/patch/476511/_
> _https://patchwork.ozlabs.org/patch/476516/_
>
> Mostly, if your kernel version in 4.2 or newer, it should be included.
>
> After you create VF, before you passthrough the VF to guest:
>
> (vf +1) << 32 + queue-index,
>
>
>  1. where vf is the VF index starting from 0
>  2. the queue-index is 0 if multi-queue support is not turned on, and
> this value is [0,1] if multiple-queue is turned on
>
>
> echo 1 > /sys/bus/pci/devices/\:05\:00.0/sriov_numvfs
> ifconfig $(PF_INTF) up
> ifconfig $(VF0_INFT) up
> ip link set $(PF_INTF) promisc on
> ethtool -K $(PF_INTF) ntuple on
> ethtool -N $(PF_INTF) flow-type udp4 dst-port 4789 action 0x1
> (VF0 queue 0)
>
> Here we using flow director to all let packets according to the rules to
> the VF, But I don't know if it could let the packets to other VFs at the
> same time.
>
> Thanks,
> Michael
>
> On 3/17/2016 2:43 PM, bharath paulraj wrote:
> > Hi Lu, Helin, Greg,
> >
> >   Many thanks for your response, which is really quick. Now, If I want
> > to implement L2 bridging with Intel virtualization technologies, using
> > 82599 controller, then Michael is my only hope, as getting the new
> > kernel versions and upstream support will take considerable amount of
> > time.
> >
> >Michael, Could you please share your experience on L2 bridging
> > using Intel virtualization technologies.
> >
> > Thanks,
> > Bharath
> >
> > On Wed, Mar 16, 2016 at 9:40 PM, Rose, Gregory V
> > mailto:gregory.v.rose at intel.com>> wrote:
> >
> > Intel has not supported promiscuous mode for virtual functions due
> > to the security concerns mentioned below.
> >
> > There will be upstream support in an upcoming Linux kernel for
> > setting virtual functions as "trusted" and when that is available
> > then Intel will allow virtual functions to enter unicast
> > promiscuous mode on those Ethernet controllers that support
> > promiscuous mode for virtual functions in the HW/FW.  Be aware
> > that not all Intel Ethernet controllers have support for unicast
> > promiscuous mode for virtual functions.  The only currently
> > released product that does is the X710/XL710.
> >
> > The key take away is that unicast promiscuous mode for X710/XL710
> > virtual functions requires Linux kernel support, iproute2 package
> > support and driver support.  Only when all three of these are in
> > place will the feature work.
> >
> > Thanks,
> >
> > - Greg
> >
> > -Original Message-
> > From: Zhang, Helin
> > Sent: Wednesday, March 16, 2016 9:04 AM
> > To: bharath paulraj  > >; Lu, Wenzhuo  > >; Rowden, Aaron F
> > mailto:aaron.f.rowden at intel.com>>;
> > Rose, Gregory V  > >
> > Cc: dev at dpdk.org ; Qiu, Michael
> > mailto:michael.qiu at intel.com>>; Jayakumar,
> > Muthurajan  > >
> > Subject: RE: [dpdk-dev] Reg: promiscuous mode on VF
> >
> > Hi Bharath
> >
> > For your question of "why intel does not support unicast
> > promiscuos mode?", I'd ask Aaron or Greg to give answers.
> > Thank you very much!
> >
> > Regards,
> > Helin
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org
> > ] On Behalf Of bharath paulraj
> > > Sent: Wednesday, March 16, 2016 11:29 PM
> > > To: Lu, Wenzhuo
> > > Cc: dev at dpdk.org 
> > > Subject: Re: [dpdk-dev] Reg: promiscuous mode on VF
> > >
> > > Hi Lu,
> > >
> > > Many thanks for your response. Again I have few more queries.
> > > If VF unicast promiscuous mode is not supported then can't we
> > > implement a Layer 2 bridging functionality using intel
> > virtualization
> > > technologies? Or Is there any other way, say tweeking some hardware
> > > registers or drivers, which may help us in implementing Layer 2
> > bridging.
> > > Also I would like to know, why intel does not support unicast
> > promiscuos mode?
> > > It could have been optional register settings and user should
> > have had
> > > a previleage to set or unset it. Besides, security reasons, is
> there
> > > any other big reason why Intel does not support this?
> > >
> > > Thanks,
> > > 

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

[Michael Frasca]

If the provided configuration does not call for RSS, then RSS is
explicitly disabled. Without this change, the device continues to
operate under the previous RSS configuration.

Fixes: 57033cdf8fdc ("fm10k: add PF RSS")

Signed-off-by: Michael Frasca 
---
 drivers/net/fm10k/fm10k_ethdev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 4b07a8b..4d5365a 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -531,8 +531,10 @@ fm10k_dev_rss_configure(struct rte_eth_dev *dev)

if (dev->data->nb_rx_queues == 1 ||
dev_conf->rxmode.mq_mode != ETH_MQ_RX_RSS ||
-   dev_conf->rx_adv_conf.rss_conf.rss_hf == 0)
+   dev_conf->rx_adv_conf.rss_conf.rss_hf == 0) {
+   FM10K_WRITE_REG(hw, FM10K_MRQC(0), 0);
return;
+   }

/* random key is rss_intel_key (default) or user provided (rss_key) */
if (dev_conf->rx_adv_conf.rss_conf.rss_key == NULL)
-- 
2.5.0

[dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-process environment

[Thomas Monjalon]

Hi,

Pablo, Sergio, please could you help with this issue?

2016-03-13 22:16, Dhana Eadala:
> We found a problem in dpdk-2.2 using under multi-process environment.
> Here is the brief description how we are using the dpdk:
> 
> We have two processes proc1, proc2 using dpdk. These proc1 and proc2 are
> two different compiled binaries.
> proc1 is started as primary process and proc2 as secondary process.
> 
> proc1:
> Calls srcHash = rte_hash_create("src_hash_name") to create rte_hash structure.
> As part of this, this api initalized the rte_hash structure and set the
> srcHash->rte_hash_cmp_eq to the address of memcmp() from proc1 address space.
> 
> proc2:
> calls srcHash =  rte_hash_find_existing("src_hash_name").
> This function call returns the rte_hash created by proc1.
> This srcHash->rte_hash_cmp_eq still points to the address of
> memcmp() from proc1 address space.
> Later proc2  calls
> rte_hash_lookup_with_hash(srcHash, (const void*) , key.sig);
> rte_hash_lookup_with_hash() invokes __rte_hash_lookup_with_hash(),
> which in turn calls h->rte_hash_cmp_eq(key, k->key, h->key_len).
> This leads to a crash as h->rte_hash_cmp_eq is an address
> from proc1 address space and is invalid address in proc2 address space.
> 
> We found, from dpdk documentation, that
> 
> "
>  The use of function pointers between multiple processes
>  running based of different compiled
>  binaries is not supported, since the location of a given function
>  in one process may be different to
>  its location in a second. This prevents the librte_hash library
>  from behaving properly as in a  multi-
>  threaded instance, since it uses a pointer to the hash function internally.
> 
>  To work around this issue, it is recommended that
>  multi-process applications perform the hash
>  calculations by directly calling the hashing function
>  from the code and then using the
>  rte_hash_add_with_hash()/rte_hash_lookup_with_hash() functions
>  instead of the functions which do
>  the hashing internally, such as rte_hash_add()/rte_hash_lookup().
> "
> 
> We did follow the recommended steps by invoking rte_hash_lookup_with_hash().
> It was no issue up to and including dpdk-2.0.
> In later releases started crashing because rte_hash_cmp_eq is
> introduced in dpdk-2.1
> 
> We fixed it with the following patch and would like to
> submit the patch to dpdk.org.
> Patch is created such that, if anyone wanted to use dpdk in
> multi-process environment with function pointers not shared, they need to
> define RTE_LIB_MP_NO_FUNC_PTR in their Makefile.
> Without defining this flag in Makefile, it works as it is now.

Introducing #ifdef RTE_LIB_MP_NO_FUNC_PTR is not recommended.

[dpdk-dev] [PATCH] eal/ppc: fix secondary process to map hugepages in correct order

[Thomas Monjalon]

Sergio, your help is required here.
Thanks

2016-03-17 10:35, gowrishankar:
> Could this patch be reviewed please.
> 
> Thanks,
> Gowrishankar
> 
> On Monday 07 March 2016 07:43 PM, Gowrishankar wrote:
> > From: Gowri Shankar 
> >
> > For a secondary process address space to map hugepages from every segment of
> > primary process, hugepage_file entries has to be mapped reversely from the
> > list that primary process updated for every segment. This is for a reason 
> > that,
> > in ppc64, hugepages are sorted for decrementing addresses.
> >
> > Signed-off-by: Gowrishankar 
> > ---
> >   lib/librte_eal/linuxapp/eal/eal_memory.c |   26 --
> >   1 file changed, 16 insertions(+), 10 deletions(-)

[dpdk-dev] [PATCH v3 1/3] xen: Add UIO kernel driver

[Thomas Monjalon]

2016-03-22 12:04, Jan Blunck:
> On Tue, Mar 22, 2016 at 11:42 AM, Thomas Monjalon
>  wrote:
> > 2016-03-22 10:55, Jan Blunck:
> >> New UIO helper kernel driver for Xen netfront UIO poll mode driver.
> >>
> >> Signed-off-by: Stephen Hemminger 
> >> Signed-off-by: Jan Blunck 
> >
> > Is it contributed upstream?
> 
> No. Haven't planed that yet.

Integrating new kernel modules in DPDK, without upstream work,
is not planned.

> > Is there something common with igb_uio?
> 
> AFAIK igb_uio is mapping the bars via UIO. The Xen netfront driver
> isn't simulating a PCI interface. Instead it directly maps the TX/RX
> ring.
> 
> Overlap is limited to reading sysfs files. Don't know if that is worth
> being extracted into a standalone header.

No it is not worth extracting. I'm just trying to understand what this
module is, because the log doesn't say much.

[dpdk-dev] [PATCH] eal/ppc: fix secondary process to map hugepages in correct order

[Sergio Gonzalez Monroy]

On 22/03/2016 11:36, Thomas Monjalon wrote:
> Sergio, your help is required here.

I missed it with the /ppc tag.
I'll get to it.

Sergio

> Thanks
>
> 2016-03-17 10:35, gowrishankar:
>> Could this patch be reviewed please.
>>
>> Thanks,
>> Gowrishankar
>>
>> On Monday 07 March 2016 07:43 PM, Gowrishankar wrote:
>>> From: Gowri Shankar 
>>>
>>> For a secondary process address space to map hugepages from every segment of
>>> primary process, hugepage_file entries has to be mapped reversely from the
>>> list that primary process updated for every segment. This is for a reason 
>>> that,
>>> in ppc64, hugepages are sorted for decrementing addresses.
>>>
>>> Signed-off-by: Gowrishankar 
>>> ---
>>>lib/librte_eal/linuxapp/eal/eal_memory.c |   26 
>>> --
>>>1 file changed, 16 insertions(+), 10 deletions(-)
>

[dpdk-dev] [PATCH v3 1/3] xen: Add UIO kernel driver

[Jan Blunck]

On Tue, Mar 22, 2016 at 11:42 AM, Thomas Monjalon
 wrote:
> 2016-03-22 10:55, Jan Blunck:
>> New UIO helper kernel driver for Xen netfront UIO poll mode driver.
>>
>> Signed-off-by: Stephen Hemminger 
>> Signed-off-by: Jan Blunck 
>
> Is it contributed upstream?

No. Haven't planed that yet.

> Is there something common with igb_uio?

AFAIK igb_uio is mapping the bars via UIO. The Xen netfront driver
isn't simulating a PCI interface. Instead it directly maps the TX/RX
ring.

Overlap is limited to reading sysfs files. Don't know if that is worth
being extracted into a standalone header.

[dpdk-dev] [PATCH v3 2/3] xen: Add netfront poll mode driver

[Jan Blunck]

On Tue, Mar 22, 2016 at 11:07 AM, David Marchand
 wrote:
> Hello,
>
> On Tue, Mar 22, 2016 at 10:55 AM, Jan Blunck  wrote:
>> +static struct eth_dev_ops xen_eth_dev_ops = {
>> +   /*dev*/
>> +   .dev_configure= xen_dev_configure,
>> +   .dev_close= xen_dev_close,
>> +   .dev_start= xen_dev_start,
>> +   .dev_stop = xen_dev_stop,
>> +   .dev_infos_get= xen_dev_info_get,
>> +   .link_update  = xen_dev_link_update,
>> +   /*rxtx*/
>> +   .stats_get= xen_dev_stats_get,
>> +   .stats_reset  = xen_dev_stats_reset,
>> +   .rx_queue_setup   = xen_dev_rx_queue_setup,
>> +   .rx_queue_release = xen_dev_rx_queue_release,
>> +   .tx_queue_setup   = xen_dev_tx_queue_setup,
>> +   .tx_queue_release = xen_dev_tx_queue_release,
>> +};
>
> Is there anything preventing it from being const ?
>

I don't think so. Will constify it for the next round.

Thanks,
Jan

>
> --
> David Marchand

[dpdk-dev] [PATCH v3 1/3] xen: Add UIO kernel driver

[Thomas Monjalon]

2016-03-22 10:55, Jan Blunck:
> New UIO helper kernel driver for Xen netfront UIO poll mode driver.
> 
> Signed-off-by: Stephen Hemminger 
> Signed-off-by: Jan Blunck 

Is it contributed upstream?
Is there something common with igb_uio?

[dpdk-dev] [PATCH] mlx4: check if port is configured for Ethernet

[Adrien Mazarguil]

Notify user otherwise. A similar check has already been added to mlx5 in
commit "mlx5: check port is configured as ethernet device".

Signed-off-by: Adrien Mazarguil 
---
 drivers/net/mlx4/mlx4.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index cc4e9aa..fbbabf6 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -5463,6 +5463,13 @@ mlx4_pci_devinit(struct rte_pci_driver *pci_drv, struct 
rte_pci_device *pci_dev)
ERROR("port query failed: %s", strerror(err));
goto port_error;
}
+
+   if (port_attr.link_layer != IBV_LINK_LAYER_ETHERNET) {
+   ERROR("port %d is not configured in Ethernet mode",
+ port);
+   goto port_error;
+   }
+
if (port_attr.state != IBV_PORT_ACTIVE)
DEBUG("port %d is not active: \"%s\" (%d)",
  port, ibv_port_state_str(port_attr.state),
-- 
2.1.4

[dpdk-dev] [PATCH v3 00/10] qede: Add qede PMD

[Bruce Richardson]

On Tue, Mar 22, 2016 at 11:21:25AM +, Richardson, Bruce wrote:
> I've had a quick scan over this patchset, and as you've probably seen I've 
> made some public comments on it. General comments on the whole patchset are:
> * Please run checkpatch on the patchset and clear up as many issues as you 
> can. There are a number of typos called out which especially must be fixed. 
> Both myself and Thomas always run checkpatch against patches before applying 
> them. [I suggest using Thomas's checkpatches.sh script to do the checks as it 
> disables many unnecessary warnings from checkpatch]
> * Please put in commit descriptions for all patches bar those doing trivial 
> things. The first three patches probably don't need a commit message, but the 
> rest do.
> 
> /Bruce
> 
> > -Original Message-
> > From: Rasesh Mody [mailto:rasesh.mody at qlogic.com]
> > Sent: Saturday, March 19, 2016 12:53 AM
> > To: thomas.monjalon at 6wind.com; Richardson, Bruce
> > 
> > Cc: dev at dpdk.org; ameen.rahman at qlogic.com; harish.patil at qlogic.com;
> > sony.chacko at qlogic.com; Rasesh Mody 
> > Subject: [PATCH v3 00/10] qede: Add qede PMD
> > 
> > Submitting v3 patch series for QEDE PMD. There is no code change from v2
> > series except PMD version change. Earlier we had generated and tested the
> > v2 series against dpdk tree then latest.
> > 
> > The v3 series includes:
> >  - Patches generated and tested against latest dpdk-next-net
> >  - Reworked MAINTAINERS patch to make it apply cleanly
> >  - Incorporated Overview.rst update in the documentation patch
> > 
> > Please Apply.
> > 
> > Thanks!
> > Rasesh
> > 
> > Rasesh Mody (10):
> >   qede: Add maintainers
> >   qede: Add documentation
> >   qede: Add license file
> >   qede: Add base driver
> >   qede: Add core driver
> >   qede: Add L2 support
> >   qede: Add SRIOV support
> >   qede: Add attention support
> >   qede: Add DCBX support
> >   qede: Enable PMD build
> > 
Clang gives a compile error after applying this patchset. Please investigate.

== Build drivers/net/qede
  CC base/ecore_dev.o
fatal error: unknown warning option '-Wno-shift-negative-value'; did you mean
  '-Wno-shift-sign-overflow'? [-Wunknown-warning-option]
/home/bruce/next-net/dpdk-next-net/mk/internal/rte.compile-pre.mk:126: recipe 
for target 'base/ecore_dev.o' failed

This is seen with clang 3.6 on Fedora 23.
"clang version 3.6.0 (tags/RELEASE_360/final)"


Similarly, 32-bit (i686) build fails:

== Build drivers/net/qede
  CC base/ecore_dev.o
/home/bruce/next-net/dpdk-next-net/drivers/net/qede/base/ecore_dev.c: In 
function ?ecore_chain_alloc_sanity_check?:
/home/bruce/next-net/dpdk-next-net/drivers/net/qede/base/ecore_dev.c:2571:32: 
error: format ?%lx? expects argument of type ?long unsigned int?, but argument 
6 has type ?u64 {aka long long unsigned int}? [-Werror=format=]
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors

This is seen with gcc 5.3.1 on Fedora 23.

Regards,
/Bruce

[dpdk-dev] [PATCH] ethdev: don't count missed packets in erroneous packets counter

[Stephen Hemminger]

On Tue, 22 Mar 2016 15:23:22 +
"Tahhan, Maryam"  wrote:

> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Thursday, March 17, 2016 4:41 PM
> > To: Igor Ryzhov 
> > Cc: dev at dpdk.org; Tahhan, Maryam ;
> > olivier.matz at 6wind.com
> > Subject: Re: [dpdk-dev] [PATCH] ethdev: don't count missed packets in
> > erroneous packets counter
> > 
> > CC Maryam and Olivier who had discussions about imissed and other
> > stats:
> > http://dpdk.org/ml/archives/dev/2015-August/022905.html
> > http://dpdk.org/ml/archives/dev/2015-September/023351.html
> > http://dpdk.org/ml/archives/dev/2015-September/023612.html
> > 
> > 2016-03-10 16:03, Igor Ryzhov:  
> > > Comment for "ierrors" counter says that it counts erroneous received  
> > packets. But for some reason "imissed" counter is added to "ierrors"
> > counter in most drivers. It is a mistake, because missed packets are
> > obviously not received. This patch fixes it.
> > 
> > According to this patch
> > http://dpdk.org/browse/dpdk/commit/?id=70bdb186
> > imissed was kept in ierrors because of backward compatibility.
> > I'm OK to remove imissed from ierrors.
> > 
> > Fixes: 70bdb18657da ("ethdev: add Rx error counters for missed, badcrc
> > and badlen packets")
> > Fixes: 6bfe648406b5 ("i40e: add Rx error statistics")
> > Fixes: 856505d303f4 ("cxgbe: add port statistics")
> > 
> > Acked-by: Thomas Monjalon   
> 
> Looks fine, but make sure to add an explicit comment in release notes 
> somewhere to flag the change. In case any apps were accounting for imissed as 
> part of ierrors like testpmd was: 
> 
> - if (((stats->ierrors - stats->imissed) + stats->rx_nombuf) > 0) 
> {
> + if ((stats->ierrors + stats->rx_nombuf) > 0) {

Extra () in that expression.

[dpdk-dev] [PATCH v2 0/9] pci cleanup and blacklist rework

[David Marchand]

Hello Jan,

On Wed, Mar 16, 2016 at 5:07 PM, Jan Viktorin  
wrote:
> On Fri, 29 Jan 2016 15:49:04 +0100
> David Marchand  wrote:
>
>> Before 2.2.0 release, while preparing for more changes in eal (and fixing
>> a problem reported by Roger M. [1]), I came up with this (part of) patchset
>> that tries to make the pci code more compact and easier to read.
>
> what is the state of this series at the moment? Do you expect some more
> reviews? I remember that I've sent some reviews but I don't think they
> are integrated in the v2. By the way, there two patch series joined
> into one or something like that, am I right?

Yes, I do remember your comments.
I have them in my tree, but this series still needs more work.
Trying to come up with something this week.


Regards,
-- 
David Marchand

[dpdk-dev] [PATCH v3 10/10] qede: Enable PMD build

[Bruce Richardson]

On Fri, Mar 18, 2016 at 05:53:25PM -0700, Rasesh Mody wrote:
> Signed-off-by: Harish Patil 
> Signed-off-by: Rasesh Mody 
> Signed-off-by: Sony Chacko 
> ---
>  config/common_base|   14 ++
>  drivers/net/Makefile  |1 +
>  mk/rte.app.mk |2 ++
>  scripts/test-build.sh |1 +
>  4 files changed, 18 insertions(+)
> 
> diff --git a/config/common_base b/config/common_base
> index dbd405b..14b37df 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -295,6 +295,20 @@ CONFIG_RTE_LIBRTE_PMD_BOND=y
>  CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
>  CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
>  
> +# QLogic 25G/40G PMD
> +#
> +CONFIG_RTE_LIBRTE_QEDE_PMD=y
> +CONFIG_RTE_LIBRTE_QEDE_DEBUG_INIT=n
> +CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO=n
> +CONFIG_RTE_LIBRTE_QEDE_DEBUG_ECORE=n
> +CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX=n
> +CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX=n
> +CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US=24
> +CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US=48
> +CONFIG_RTE_LIBRTE_QEDE_TX_SWITCHING=y
> +#Provides path/name of the firmware file
> +CONFIG_RTE_LIBRTE_QEDE_FW=n
> +
>  #
>  # Compile software PMD backed by AF_PACKET sockets (Linux only)
>  #
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 0c3393f..61d3f16 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -51,5 +51,6 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += szedata2
>  DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
>  DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
>  DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
> +DIRS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede

In general, lists in DPDK, including this list of subdirectories in the makefile
are kept in alphabetical order, rather than just having new items appended at 
the
end.

/Bruce

>  
>  include $(RTE_SDK)/mk/rte.subdir.mk
> diff --git a/mk/rte.app.mk b/mk/rte.app.mk
> index a1cd9a3..9bb2264 100644
> --- a/mk/rte.app.mk
> +++ b/mk/rte.app.mk
> @@ -101,6 +101,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD)   += -libverbs
>  _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2)   += -lsze2
>  _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT)+= -lxenstore
>  _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD)  += -lgxio
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_QEDE_PMD)   += -lz
>  # QAT / AESNI GCM PMDs are dependent on libcrypto (from openssl)
>  # for calculating HMAC precomputes
>  ifeq ($(CONFIG_RTE_LIBRTE_PMD_QAT),y)
> @@ -146,6 +147,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD)  += 
> -lrte_pmd_mpipe
>  _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_RING)   += -lrte_pmd_ring
>  _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP)   += -lrte_pmd_pcap
>  _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET)  += -lrte_pmd_af_packet
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_QEDE_PMD)   += -lrte_pmd_qede
>  _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_NULL)   += -lrte_pmd_null
>  
>  ifeq ($(CONFIG_RTE_LIBRTE_CRYPTODEV),y)
> diff --git a/scripts/test-build.sh b/scripts/test-build.sh
> index 5f3cab5..dfc8915 100755
> --- a/scripts/test-build.sh
> +++ b/scripts/test-build.sh
> @@ -116,6 +116,7 @@ config () #   
>   test "$DPDK_DEP_ZLIB" != y || \
>   sed -ri  's,(BNX2X_PMD=)n,\1y,' $1/.config
>   sed -ri's,(NFP_PMD=)n,\1y,' $1/.config
> + sed -ri  's,(QEDE_PMD=)n,\1y,' $1/.config
>   test "$DPDK_DEP_PCAP" != y || \
>   sed -ri   's,(PCAP=)n,\1y,' $1/.config
>   test -z "$AESNI_MULTI_BUFFER_LIB_PATH" || \
> -- 
> 1.7.10.3
> 

[dpdk-dev] [PATCH v3 00/10] qede: Add qede PMD

[Richardson, Bruce]

I've had a quick scan over this patchset, and as you've probably seen I've made 
some public comments on it. General comments on the whole patchset are:
* Please run checkpatch on the patchset and clear up as many issues as you can. 
There are a number of typos called out which especially must be fixed. Both 
myself and Thomas always run checkpatch against patches before applying them. 
[I suggest using Thomas's checkpatches.sh script to do the checks as it 
disables many unnecessary warnings from checkpatch]
* Please put in commit descriptions for all patches bar those doing trivial 
things. The first three patches probably don't need a commit message, but the 
rest do.

/Bruce

> -Original Message-
> From: Rasesh Mody [mailto:rasesh.mody at qlogic.com]
> Sent: Saturday, March 19, 2016 12:53 AM
> To: thomas.monjalon at 6wind.com; Richardson, Bruce
> 
> Cc: dev at dpdk.org; ameen.rahman at qlogic.com; harish.patil at qlogic.com;
> sony.chacko at qlogic.com; Rasesh Mody 
> Subject: [PATCH v3 00/10] qede: Add qede PMD
> 
> Submitting v3 patch series for QEDE PMD. There is no code change from v2
> series except PMD version change. Earlier we had generated and tested the
> v2 series against dpdk tree then latest.
> 
> The v3 series includes:
>  - Patches generated and tested against latest dpdk-next-net
>  - Reworked MAINTAINERS patch to make it apply cleanly
>  - Incorporated Overview.rst update in the documentation patch
> 
> Please Apply.
> 
> Thanks!
> Rasesh
> 
> Rasesh Mody (10):
>   qede: Add maintainers
>   qede: Add documentation
>   qede: Add license file
>   qede: Add base driver
>   qede: Add core driver
>   qede: Add L2 support
>   qede: Add SRIOV support
>   qede: Add attention support
>   qede: Add DCBX support
>   qede: Enable PMD build
> 
>  MAINTAINERS |7 +
>  config/common_base  |   14 +
>  doc/guides/nics/index.rst   |1 +
>  doc/guides/nics/overview.rst|   78 +-
>  doc/guides/nics/qede.rst|  340 +
>  drivers/net/Makefile|1 +
>  drivers/net/qede/LICENSE.qede_pmd   |   28 +
>  drivers/net/qede/Makefile   |   95 +
>  drivers/net/qede/base/bcm_osal.c|  178 +
>  drivers/net/qede/base/bcm_osal.h|  395 +
>  drivers/net/qede/base/common_hsi.h  |  714 ++
>  drivers/net/qede/base/ecore.h   |  746 ++
>  drivers/net/qede/base/ecore_attn_values.h   |13287
> +++
>  drivers/net/qede/base/ecore_chain.h |  724 ++
>  drivers/net/qede/base/ecore_cxt.c   | 1961 
>  drivers/net/qede/base/ecore_cxt.h   |  157 +
>  drivers/net/qede/base/ecore_cxt_api.h   |   79 +
>  drivers/net/qede/base/ecore_dcbx.c  |  887 ++
>  drivers/net/qede/base/ecore_dcbx.h  |   55 +
>  drivers/net/qede/base/ecore_dcbx_api.h  |  160 +
>  drivers/net/qede/base/ecore_dev.c   | 3578 
>  drivers/net/qede/base/ecore_dev_api.h   |  497 +
>  drivers/net/qede/base/ecore_gtt_reg_addr.h  |   42 +
>  drivers/net/qede/base/ecore_gtt_values.h|   33 +
>  drivers/net/qede/base/ecore_hsi_common.h| 1912 
>  drivers/net/qede/base/ecore_hsi_eth.h   | 1912 
>  drivers/net/qede/base/ecore_hsi_tools.h | 1081 +++
>  drivers/net/qede/base/ecore_hw.c|  992 ++
>  drivers/net/qede/base/ecore_hw.h|  269 +
>  drivers/net/qede/base/ecore_hw_defs.h   |   49 +
>  drivers/net/qede/base/ecore_init_fw_funcs.c | 1275 +++
> drivers/net/qede/base/ecore_init_fw_funcs.h |  263 +
>  drivers/net/qede/base/ecore_init_ops.c  |  599 ++
>  drivers/net/qede/base/ecore_init_ops.h  |  103 +
>  drivers/net/qede/base/ecore_int.c   | 2225 +
>  drivers/net/qede/base/ecore_int.h   |  234 +
>  drivers/net/qede/base/ecore_int_api.h   |  277 +
>  drivers/net/qede/base/ecore_iov_api.h   |  933 ++
>  drivers/net/qede/base/ecore_iro.h   |  115 +
>  drivers/net/qede/base/ecore_iro_values.h|   59 +
>  drivers/net/qede/base/ecore_l2.c| 1798 
>  drivers/net/qede/base/ecore_l2.h|  151 +
>  drivers/net/qede/base/ecore_l2_api.h|  401 +
>  drivers/net/qede/base/ecore_mcp.c   | 1928 
>  drivers/net/qede/base/ecore_mcp.h   |  304 +
>  drivers/net/qede/base/ecore_mcp_api.h   |  611 ++
>  drivers/net/qede/base/ecore_proto_if.h  |   28 +
>  drivers/net/qede/base/ecore_rt_defs.h   |  446 +
>  drivers/net/qede/base/ecore_sp_api.h|   42 +
>  drivers/net/qede/base/ecore_sp_commands.c   |  525 ++
>  drivers/net/qede/base/ecore_sp_commands.h   |  137 +
>  drivers/net/qede/base/ecore_spq.c   |  944 ++
>  drivers/net/qede/base/ecore_spq.h   |  284 +
>  drivers/net/qede/base/ecore_sriov.c | 3422 +++
>  drivers/net/qede/base/ecore_sriov.h |  390 +
>  drivers/net/qede/base/ecore_status.h|   30 

[dpdk-dev] [PATCH v3 08/10] qede: Add attention support

[Bruce Richardson]

On Fri, Mar 18, 2016 at 05:53:23PM -0700, Rasesh Mody wrote:
> Signed-off-by: Harish Patil 
> Signed-off-by: Rasesh Mody 
> Signed-off-by: Sony Chacko 
> ---
Commit message describing the patch, please.

/Bruce

[dpdk-dev] [PATCH v3 2/3] xen: Add netfront poll mode driver

[David Marchand]

Hello,

On Tue, Mar 22, 2016 at 10:55 AM, Jan Blunck  wrote:
> +static struct eth_dev_ops xen_eth_dev_ops = {
> +   /*dev*/
> +   .dev_configure= xen_dev_configure,
> +   .dev_close= xen_dev_close,
> +   .dev_start= xen_dev_start,
> +   .dev_stop = xen_dev_stop,
> +   .dev_infos_get= xen_dev_info_get,
> +   .link_update  = xen_dev_link_update,
> +   /*rxtx*/
> +   .stats_get= xen_dev_stats_get,
> +   .stats_reset  = xen_dev_stats_reset,
> +   .rx_queue_setup   = xen_dev_rx_queue_setup,
> +   .rx_queue_release = xen_dev_rx_queue_release,
> +   .tx_queue_setup   = xen_dev_tx_queue_setup,
> +   .tx_queue_release = xen_dev_tx_queue_release,
> +};

Is there anything preventing it from being const ?


-- 
David Marchand

[dpdk-dev] [PATCH] ethdev: don't count missed packets in erroneous packets counter

[Thomas Monjalon]

2016-03-17 17:40, Thomas Monjalon:
> CC Maryam and Olivier who had discussions about imissed and other stats:
>   http://dpdk.org/ml/archives/dev/2015-August/022905.html
>   http://dpdk.org/ml/archives/dev/2015-September/023351.html
>   http://dpdk.org/ml/archives/dev/2015-September/023612.html
> 
> 2016-03-10 16:03, Igor Ryzhov:
> > Comment for "ierrors" counter says that it counts erroneous received 
> > packets. But for some reason "imissed" counter is added to "ierrors" 
> > counter in most drivers. It is a mistake, because missed packets are 
> > obviously not received. This patch fixes it.
> 
> According to this patch
>   http://dpdk.org/browse/dpdk/commit/?id=70bdb186
> imissed was kept in ierrors because of backward compatibility.
> I'm OK to remove imissed from ierrors.
> 
> Fixes: 70bdb18657da ("ethdev: add Rx error counters for missed, badcrc and 
> badlen packets")
> Fixes: 6bfe648406b5 ("i40e: add Rx error statistics")
> Fixes: 856505d303f4 ("cxgbe: add port statistics")
> 
> Acked-by: Thomas Monjalon 

Applied, thanks