[dpdk-dev] FYI: Using ccache a linux compiler caching tool with DPDK

[Thomas Monjalon]

2016-06-27 18:10, Wiles, Keith:
> It appears the ccache and clang have a few problems without the global having 
> the environment variable set:
> export CCACHE_CPP2=yes
> 
> Without this environment variable clang starts to complain about a number of 
> issues. If you see a compile problem please rebuild with ccache disabled 
> using ?sudo CCACHE_DISABLE=true ?? or uninstall ccache ?sudo apt-get remove 
> ccache?

With ccache 3.2, it is possible to replace the environment variable
CCACHE_CPP2=yes by the configuration run_second_cpp=true in ccache.conf.

See http://peter.eisentraut.org/blog/2014/12/01/ccache-and-clang-part-3/

> It is possible that GCC will also have compiler issues, but I do not seem to 
> see any, just try without ccache to verify.
> 
> Here is a link to help explain more details:
> See e.g. 
> http://petereisentraut.blogspot.com/2011/09/ccache-and-clang-part-2.html
> 
> If the build works then I have not found any issues with using ccache except 
> a faster build time ?  YMMV 
> 
> Regards,
> Keith

[dpdk-dev] [PATCH v3 4/5] testpmd: handle all rxqs in rss setup

[De Lara Guarch, Pablo]

Hi Nelio,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of N?lio Laranjeiro
> Sent: Monday, June 27, 2016 3:24 PM
> To: Wang, Zhihong
> Cc: dev at dpdk.org; Ananyev, Konstantin; Richardson, Bruce; De Lara Guarch,
> Pablo; thomas.monjalon at 6wind.com
> Subject: Re: [dpdk-dev] [PATCH v3 4/5] testpmd: handle all rxqs in rss setup
> 
> On Tue, Jun 14, 2016 at 07:08:05PM -0400, Zhihong Wang wrote:
> > This patch removes constraints in rxq handling when multiqueue is enabled
> > to handle all the rxqs.
> >
> > Current testpmd forces a dedicated core for each rxq, some rxqs may be
> > ignored when core number is less than rxq number, and that causes
> confusion
> > and inconvenience.
> >
> > One example: One Red Hat engineer was doing multiqueue test, there're 2
> > ports in guest each with 4 queues, and testpmd was used as the forwarding
> > engine in guest, as usual he used 1 core for forwarding, as a results he
> > only saw traffic from port 0 queue 0 to port 1 queue 0, then a lot of
> > emails and quite some time are spent to root cause it, and of course it's
> > caused by this unreasonable testpmd behavior.
> >
> > Moreover, even if we understand this behavior, if we want to test the
> > above case, we still need 8 cores for a single guest to poll all the
> > rxqs, obviously this is too expensive.
> >
> > We met quite a lot cases like this, one recent example:
> > http://openvswitch.org/pipermail/dev/2016-June/072110.html
> >
> >
> > Signed-off-by: Zhihong Wang 
> > ---
> >  app/test-pmd/config.c | 8 +---
> >  1 file changed, 1 insertion(+), 7 deletions(-)
> >
> > diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> > index ede7c78..4719a08 100644
> > --- a/app/test-pmd/config.c
> > +++ b/app/test-pmd/config.c
> > @@ -1199,19 +1199,13 @@ rss_fwd_config_setup(void)
> > cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
> > cur_fwd_config.nb_fwd_streams =
> > (streamid_t) (nb_q * cur_fwd_config.nb_fwd_ports);
> > -   if (cur_fwd_config.nb_fwd_streams > cur_fwd_config.nb_fwd_lcores)
> > -   cur_fwd_config.nb_fwd_streams =
> > -   (streamid_t)cur_fwd_config.nb_fwd_lcores;
> > -   else
> > -   cur_fwd_config.nb_fwd_lcores =
> > -   (lcoreid_t)cur_fwd_config.nb_fwd_streams;
> >
> > /* reinitialize forwarding streams */
> > init_fwd_streams();
> >
> > setup_fwd_config_of_each_lcore(_fwd_config);
> > rxp = 0; rxq = 0;
> > -   for (lc_id = 0; lc_id < cur_fwd_config.nb_fwd_lcores; lc_id++) {
> > +   for (lc_id = 0; lc_id < cur_fwd_config.nb_fwd_streams; lc_id++) {
> > struct fwd_stream *fs;
> >
> > fs = fwd_streams[lc_id];
> > --
> > 2.5.0
> 
> Hi Zhihong,
> 
> It seems this commits introduce a bug in pkt_burst_transmit(), this only
> occurs when the number of cores present in the coremask is greater than
> the number of queues i.e. coremask=0xffe --txq=4 --rxq=4.
> 
>   Port 0 Link Up - speed 4 Mbps - full-duplex
>   Port 1 Link Up - speed 4 Mbps - full-duplex
>   Done
>   testpmd> start tx_first
> io packet forwarding - CRC stripping disabled - packets/burst=64
> nb forwarding cores=10 - nb forwarding ports=2
> RX queues=4 - RX desc=256 - RX free threshold=0
> RX threshold registers: pthresh=0 hthresh=0 wthresh=0
> TX queues=4 - TX desc=256 - TX free threshold=0
> TX threshold registers: pthresh=0 hthresh=0 wthresh=0
> TX RS bit threshold=0 - TXQ flags=0x0
>   Segmentation fault (core dumped)
> 
> 
> If I start testpmd with a coremask with at most as many cores as queues,
> everything works well (i.e. coremask=0xff0, or 0xf00).
> 
> Are you able to reproduce the same issue?
> Note: It only occurs on dpdk/master branch (commit f2bb7ae1d204).

Thanks for reporting this. I was able to reproduce this issue and
sent a patch that should fix it. Could you verify it?
http://dpdk.org/dev/patchwork/patch/14430/


Thanks
Pablo
> 
> Regards,
> 
> --
> N?lio Laranjeiro
> 6WIND

[dpdk-dev] [PATCH v2] examples/l3fwd: update usage and documentation

[Beilei Xing]

Update l3fwd example usage and documentation with missing options.

Signed-off-by: Beilei Xing 
---
v2 changes:
 Update l3fwd main.c usage
 Update format in documentation.

 doc/guides/sample_app_ug/l3_forward.rst | 42 ++---
 examples/l3fwd/main.c   | 40 ---
 2 files changed, 54 insertions(+), 28 deletions(-)

diff --git a/doc/guides/sample_app_ug/l3_forward.rst 
b/doc/guides/sample_app_ug/l3_forward.rst
index 491f99d..c885cdb 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -88,32 +88,46 @@ To compile the application:
 Running the Application
 ---

-The application has a number of command line options:
+The application has a number of command line options::

-.. code-block:: console
+./l3fwd [EAL options] -- -p PORTMASK
+ [-P]
+ [-E]
+ [-L]
+ --config(port,queue,lcore)[,(port,queue,lcore)]
+ [--eth-dest=X,MM:MM:MM:MM:MM:MM]
+ [--enable-jumbo [--max-pkt-len PKTLEN]]
+ [--no-numa]
+ [--hash-entry-num]
+ [--ipv6]
+ [--parse-ptype]
+
+Where,
+
+* ``-p PORTMASK:`` Hexadecimal bitmask of ports to configure

-./build/l3fwd [EAL options] -- -p PORTMASK [-P]  
--config(port,queue,lcore)[,(port,queue,lcore)] [--enable-jumbo [--max-pkt-len 
PKTLEN]]  [--no-numa][--hash-entry-num][--ipv6] [--parse-ptype]
+* ``-P:`` Optional, sets all ports to promiscuous mode so that packets are 
accepted regardless of the packet's Ethernet MAC destination address.
+  Without this option, only packets with the Ethernet MAC destination address 
set to the Ethernet address of the port are accepted.

-where,
+* ``-E:`` Optional, enable exact match.

-*   -p PORTMASK: Hexadecimal bitmask of ports to configure
+* ``-L:`` Optional, enable longest prefix match.

-*   -P: optional, sets all ports to promiscuous mode so that packets are 
accepted regardless of the packet's Ethernet MAC destination address.
-Without this option, only packets with the Ethernet MAC destination 
address set to the Ethernet address of the port are accepted.
+* ``--config (port,queue,lcore)[,(port,queue,lcore)]:`` Determines which 
queues from which ports are mapped to which cores.

-*   --config (port,queue,lcore)[,(port,queue,lcore)]: determines which queues 
from which ports are mapped to which cores
+* ``--eth-dest=X,MM:MM:MM:MM:MM:MM:`` Optional, ethernet destination for port 
X.

-*   --enable-jumbo: optional, enables jumbo frames
+* ``--enable-jumbo:`` Optional, enables jumbo frames.

-*   --max-pkt-len: optional, maximum packet length in decimal (64-9600)
+* ``--max-pkt-len:`` Optional, under the premise of enabling jumbo, maximum 
packet length in decimal (64-9600).

-*   --no-numa: optional, disables numa awareness
+* ``--no-numa:`` Optional, disables numa awareness.

-*   --hash-entry-num: optional, specifies the hash entry number in hexadecimal 
to be setup
+* ``--hash-entry-num:`` Optional, specifies the hash entry number in 
hexadecimal to be setup.

-*   --ipv6: optional, set it if running ipv6 packets
+* ``--ipv6:`` Optional, set if running ipv6 packets.

-*   --parse-ptype: optional, set it if use software way to analyze packet type
+* ``--parse-ptype:`` Optional, set to use software to analyze packet type. 
Without this option, hardware will check the packet type.

 For example, consider a dual processor socket platform where cores 0-7 and 
16-23 appear on socket 0, while cores 8-15 and 24-31 appear on socket 1.
 Let's say that the programmer wants to use memory from both NUMA nodes, the 
platform has only two ports, one connected to each NUMA node,
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 7a79cd2..acedd20 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -311,20 +311,32 @@ init_lcore_rx_queues(void)
 static void
 print_usage(const char *prgname)
 {
-   printf ("%s [EAL options] -- -p PORTMASK -P"
-   "  [--config (port,queue,lcore)[,(port,queue,lcore]]"
-   "  [--enable-jumbo [--max-pkt-len PKTLEN]]\n"
-   "  -p PORTMASK: hexadecimal bitmask of ports to configure\n"
-   "  -P : enable promiscuous mode\n"
-   "  -E : enable exact match\n"
-   "  -L : enable longest prefix match\n"
-   "  --config (port,queue,lcore): rx queues configuration\n"
-   "  --eth-dest=X,MM:MM:MM:MM:MM:MM: optional, ethernet 
destination for port X\n"
-   "  --no-numa: optional, disable numa awareness\n"
-   "  --ipv6: optional, specify it if running ipv6 packets\n"
-   "  --enable-jumbo: enable jumbo frame"
-   " which max packet len is PKTLEN in decimal 

[dpdk-dev] [PATCH 2/4] virtio: introduce RTE_LIBRTE_VIRTIO_INC_VECTOR

[Jerin Jacob]

On Mon, Jun 27, 2016 at 04:19:57PM +0200, Thomas Monjalon wrote:
> 2016-06-27 17:24, Jerin Jacob:
> > --- a/config/common_base
> > +++ b/config/common_base
> > @@ -267,6 +267,7 @@ CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
> >  CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
> >  CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
> >  CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
> > +CONFIG_RTE_LIBRTE_VIRTIO_INC_VECTOR=y
> 
> I don't remember what means INC_VECTOR?
> Why a config option is needed for vector implementations?

I thought of adding additional configuration option(INC_VECTOR) _apart_ from
cpu flag based scheme in the patch because even though if a given platform
has cpu instruction support, in some platforms scalar version may
perform well wrt vector version(based on instruction latency, emulation 
required or not
etc). So a top level flag INC_VECTOR, can override the vector selection
for a given platform if required.

Regarding INC_VECTOR(INC in vector configuration name, I have no idea, I
followed the existing flags)
$ grep "INC_VECTOR" config/common_base
CONFIG_RTE_IXGBE_INC_VECTOR=y
CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=y
CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y

Jerin

[dpdk-dev] [RFC] librte_vhost: Add unix domain socket fd registration

[Yuanhan Liu]

On Fri, Jun 24, 2016 at 08:23:52AM -0400, Aaron Conole wrote:
> Is there still merit to this patch, given above?  If so, I'd finish my
> integration and testing work and submit it formally.

Sorry, I don't see the strong need of this patch (at least so far),
judging that vhost-user as the client could solve the issue your
patch meant to resolve.

--yliu

[dpdk-dev] [PATCH v2 2/2] fix building with clang-3.8.0 compiler

[Thomas Monjalon]

2016-06-27 16:51, Wiles, Keith:
> On 6/27/16, 11:40 AM, "Richardson, Bruce"  
> wrote:
> >On Mon, Jun 27, 2016 at 05:29:59PM +0100, Wiles, Keith wrote:
> >> On 6/27/16, 7:58 AM, on behalf of keith.wiles at intel.com> wrote:
> >> >On 6/27/16, 3:46 AM, "Richardson, Bruce"  
> >> >wrote:
> >> >>On Sun, Jun 26, 2016 at 10:54:12AM -0500, Keith Wiles wrote:
> >> I found the problem to the compile errors I am seeing with building with 
> >> clang and shared libraries.
> >> 
> >> The x86_64-linux-gnu/bits/string2.h header file if getting included from 
> >> string.h, but this would be mean __GNUC__ is defined and this is the clang 
> >> compiler. After much investigation it turns out ?ccache? is the problem 
> >> here. If ccache is enabled with clang builds the __GNUC__ is defined some 
> >> how, I never did find the location.
> >> 
> >> Just a warning it appears ?ccache? for caching object files is not 
> >> compatible with DPDK builds ? in all cases.
> >> 
> >Actually, I believe it's a more general ccache and clang problem, not DPDK 
> >specific.
> >
> >See e.g. 
> >http://petereisentraut.blogspot.com/2011/09/ccache-and-clang-part-2.html
> >
> >where the recommendation is to set "export CCACHE_CPP2=yes" in your 
> >environment.
> >This cleared quite a number of issues for me (and others) when compiling with
> >clang.
> 
> Adding the CCACHE_CPP2=yes
> 
> Cleaned up all of the compiler errors I was seeing ?
> 
> Do we need to document this in DPDK and if so where in the docs would someone 
> suggest it be placed?

I do not use ccache with clang because it is not known to work.
But if you are sure it can work with few configuration, I would be glad
to have a complete description.
However it is not related to DPDK at all. That's why a nice email well
written and explained on this ml looks enough to be found via Google.
Thanks

[dpdk-dev] weak functions in some drivers

[Ferruh Yigit]

On 6/21/2016 4:01 PM, Damjan Marion (damarion) wrote:
> 
> Hello,
> 

...

> 
> What is not clear to me is motivation to use weak here instead of simply 
> using CONFIG_RTE_I40E_INC_VECTOR
> macro to exclude stubs in i40e_rxtx.c. It will make library smaller and avoid 
> issues like this one
> which are quite hard to troubleshoot.

Since this issue seen in fd.io, I didn't investigated more, but I don't
want to clock your valid question, this is an attempt to resurrect the
question ...

> 
> BTW Looks like same issue is happening with fm10k driver.
> 

[dpdk-dev] dpdk config on VM

[Srinivasreddy R]

hi,
check with the below link .With little changes you can make it work for
your use case .
https://github.com/01org/dpdk-ovs/blob/development/docs/04_Sample_Configurations/02_Userspace-vHost.md


On Mon, Jun 27, 2016 at 2:50 PM, Raja Jayapal  wrote:

> Hi All,
>
> I am tyrying to install dpdk on ubuntu and test the applications.
> I have successfully installed dpdk on Host as per the instruction guide ,
> but little bit confused on how to bind it with VM.
>
> VM1(TrafficGen)--Host(DPDK)--VM2(Receiver)
>
> Do we need to install ovs to test the flows for the above scenarios?.
> I did search a lot, but didnt get clear idea like how to do config on VM
> side.
> Please point out some config/installation guide for the same.
>
>
> Thanks in Advance,
> Raja
> =-=-=
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>



Regards,
srinivas.

[dpdk-dev] FYI: Using ccache a linux compiler caching tool with DPDK

[Wiles, Keith]

FYI, Just to help document the issue here.

Using ccache on Linux can improve your compile time from a few minutes to a few 
seconds depending the use case.

On my machine Ubuntu 16.04 up to date as of 06/26/2016 using:
sudo apt-get install ccache

System Information:
   Model Name : Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
   sysname: Linux
   release: 4.4.0-24-generic
   version: #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 2016
   machine: x86_64

CPU Information:
   nthreads   :   2
   ncores :  18
   nsockets   :   2
   nbooks :   1
   nlcores:  72

72 lcores, 2 socket(s), 18 cores per socket, 2 hyper-thread(s) per core

Note: I have added the environment variable ?CCACHE_CPP2=yes

Builds using DPDK 16.07-rc0 on 06/27/2016
Build with ?time CCACHE_DISABLE=true make install 
T=x86_64-native-linuxapp-clang? gives:

real2m52.844s
user2m32.220s
sys 0m15.548s

Rebuild with no changes, just issue the above line again:

real0m9.929s
user0m5.056s
sys 0m3.036s

If you issue the above line with ?j appended give:

real0m4.292s
user0m5.304s
sys 0m4.348s

remove x86_64-native-linuxapp-clang build directory.
Build with ?time CCACHE_DISABLE=true make install 
T=x86_64-native-linuxapp-clang -j? gives:

real0m29.681s
user3m18.104s
sys 0m34.876s

cd x86_64-native-linuxapp-clang directory
make clean
time CCACHE_DISABLE=true make

real3m13.992s
user2m45.044s
sys 0m21.784s

make clean
make  # just to fill the ccache
make clean
time make

real0m15.066s
user0m6.776s
sys 0m3.684s

make clean
time make ?j

real0m4.527s
user0m7.060s
sys 0m5.428s


As you can see the performance gain is very nice and I ccache does seem to work 
correctly except in a few cases.

It appears the ccache and clang have a few problems without the global having 
the environment variable set:
export CCACHE_CPP2=yes

Without this environment variable clang starts to complain about a number of 
issues. If you see a compile problem please rebuild with ccache disabled using 
?sudo CCACHE_DISABLE=true ?? or uninstall ccache ?sudo apt-get remove ccache?

It is possible that GCC will also have compiler issues, but I do not seem to 
see any, just try without ccache to verify.

Here is a link to help explain more details:
See e.g. 
http://petereisentraut.blogspot.com/2011/09/ccache-and-clang-part-2.html

If the build works then I have not found any issues with using ccache except a 
faster build time ?  YMMV 

Regards,
Keith

[dpdk-dev] [PATCH 2/3] cmdline: remove duplicated symbols from .map

[Olivier MATZ]

On 06/27/2016 03:02 PM, Ferruh Yigit wrote:
> Fixes: 9d41beed24b0 ("lib: provide initial versioning")
> Signed-off-by: Ferruh Yigit 
> ---
>  lib/librte_cmdline/rte_cmdline_version.map | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/lib/librte_cmdline/rte_cmdline_version.map 
> b/lib/librte_cmdline/rte_cmdline_version.map
> index c9fc18a..04bcb38 100644
> --- a/lib/librte_cmdline/rte_cmdline_version.map
> +++ b/lib/librte_cmdline/rte_cmdline_version.map
> @@ -50,7 +50,6 @@ DPDK_2.0 {
>   cmdline_token_num_ops;
>   cmdline_token_portlist_ops;
>   cmdline_token_string_ops;
> - cmdline_token_string_ops;
>   cmdline_write_char;
>   rdline_add_history;
>   rdline_char_in;
> 


Acked-by: Olivier Matz 

[dpdk-dev] [PATCH v4 0/3] mempool: user-owned mempool caches

[Olivier MATZ]

Hi Lazaros,


On 06/27/2016 05:50 PM, Olivier Matz wrote:
> Updated version of the user-owned cache patchset.  It applies on top of
> the latest external mempool manager patches from David Hunt [1].
> 
> [1] http://dpdk.org/ml/archives/dev/2016-June/041479.html
> 
> v4 changes:
> 
>  * Fix compilation with shared libraries
>  * Add a GOTO_ERR() macro to factorize code in test_mempool.c
>  * Change title of patch 2 to conform to check-git-log.sh

As the rc1 is approaching, I submitted a v4 with some minor fixes.
Feel free to comment.

Regards,
Olivier

[dpdk-dev] [PATCH v4 3/3] mempool: allow for user-owned mempool caches

[Olivier Matz]

From: Lazaros Koromilas 

The mempool cache is only available to EAL threads as a per-lcore
resource. Change this so that the user can create and provide their own
cache on mempool get and put operations. This works with non-EAL threads
too. This commit introduces the new API calls:

rte_mempool_cache_create(size, socket_id)
rte_mempool_cache_free(cache)
rte_mempool_cache_flush(cache, mp)
rte_mempool_default_cache(mp, lcore_id)

Changes the API calls:

rte_mempool_generic_put(mp, obj_table, n, cache, flags)
rte_mempool_generic_get(mp, obj_table, n, cache, flags)

The cache-oblivious API calls use the per-lcore default local cache.

Signed-off-by: Lazaros Koromilas 
Acked-by: Olivier Matz 
---
 app/test/test_mempool.c|  75 +
 app/test/test_mempool_perf.c   |  70 ++---
 lib/librte_mempool/rte_mempool.c   |  66 +++-
 lib/librte_mempool/rte_mempool.h   | 163 +
 lib/librte_mempool/rte_mempool_version.map |   4 +
 5 files changed, 296 insertions(+), 82 deletions(-)

diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 55c2cbc..5b3c754 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -75,10 +75,18 @@
 #define MAX_KEEP 16
 #define MEMPOOL_SIZE 
((rte_lcore_count()*(MAX_KEEP+RTE_MEMPOOL_CACHE_MAX_SIZE))-1)

-#define RET_ERR() do { \
+#define LOG_ERR() do { \
printf("test failed at %s():%d\n", __func__, __LINE__); \
+   } while (0)
+#define RET_ERR() do { \
+   LOG_ERR();  \
return -1;  \
} while (0)
+#define GOTO_ERR(err, label) do {  \
+   LOG_ERR();  \
+   ret = err;  \
+   goto label; \
+   } while (0)

 static rte_atomic32_t synchro;

@@ -191,7 +199,7 @@ my_obj_init(struct rte_mempool *mp, __attribute__((unused)) 
void *arg,

 /* basic tests (done on one core) */
 static int
-test_mempool_basic(struct rte_mempool *mp)
+test_mempool_basic(struct rte_mempool *mp, int use_external_cache)
 {
uint32_t *objnum;
void **objtable;
@@ -199,47 +207,60 @@ test_mempool_basic(struct rte_mempool *mp)
char *obj_data;
int ret = 0;
unsigned i, j;
+   int offset;
+   struct rte_mempool_cache *cache;
+
+   if (use_external_cache) {
+   /* Create a user-owned mempool cache. */
+   cache = rte_mempool_cache_create(RTE_MEMPOOL_CACHE_MAX_SIZE,
+SOCKET_ID_ANY);
+   if (cache == NULL)
+   RET_ERR();
+   } else {
+   /* May be NULL if cache is disabled. */
+   cache = rte_mempool_default_cache(mp, rte_lcore_id());
+   }

/* dump the mempool status */
rte_mempool_dump(stdout, mp);

printf("get an object\n");
-   if (rte_mempool_get(mp, ) < 0)
-   RET_ERR();
+   if (rte_mempool_generic_get(mp, , 1, cache, 0) < 0)
+   GOTO_ERR(-1, out);
rte_mempool_dump(stdout, mp);

/* tests that improve coverage */
printf("get object count\n");
-   if (rte_mempool_count(mp) != MEMPOOL_SIZE - 1)
-   RET_ERR();
+   /* We have to count the extra caches, one in this case. */
+   offset = use_external_cache ? 1 * cache->len : 0;
+   if (rte_mempool_count(mp) + offset != MEMPOOL_SIZE - 1)
+   GOTO_ERR(-1, out);

printf("get private data\n");
if (rte_mempool_get_priv(mp) != (char *)mp +
MEMPOOL_HEADER_SIZE(mp, mp->cache_size))
-   RET_ERR();
+   GOTO_ERR(-1, out);

 #ifndef RTE_EXEC_ENV_BSDAPP /* rte_mem_virt2phy() not supported on bsd */
printf("get physical address of an object\n");
if (rte_mempool_virt2phy(mp, obj) != rte_mem_virt2phy(obj))
-   RET_ERR();
+   GOTO_ERR(-1, out);
 #endif

printf("put the object back\n");
-   rte_mempool_put(mp, obj);
+   rte_mempool_generic_put(mp, , 1, cache, 0);
rte_mempool_dump(stdout, mp);

printf("get 2 objects\n");
-   if (rte_mempool_get(mp, ) < 0)
-   RET_ERR();
-   if (rte_mempool_get(mp, ) < 0) {
-   rte_mempool_put(mp, obj);
-   RET_ERR();
-   }
+   if (rte_mempool_generic_get(mp, , 1, cache, 0) < 0)
+   GOTO_ERR(-1, out);
+   if (rte_mempool_generic_get(mp, , 1, cache, 0) < 0)
+   GOTO_ERR(-1, out);

[dpdk-dev] [PATCH v4 2/3] mempool: use bit flags to set multi consumers or producers

[Olivier Matz]

From: Lazaros Koromilas 

Pass the same flags as in rte_mempool_create().  Changes API calls:

rte_mempool_generic_put(mp, obj_table, n, flags)
rte_mempool_generic_get(mp, obj_table, n, flags)

Signed-off-by: Lazaros Koromilas 
Acked-by: Olivier Matz 
---
 lib/librte_mempool/rte_mempool.h | 58 +---
 1 file changed, 30 insertions(+), 28 deletions(-)

diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index a48f46d..971b1ba 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -953,12 +953,13 @@ void rte_mempool_dump(FILE *f, struct rte_mempool *mp);
  * @param n
  *   The number of objects to store back in the mempool, must be strictly
  *   positive.
- * @param is_mp
- *   Mono-producer (0) or multi-producers (1).
+ * @param flags
+ *   The flags used for the mempool creation.
+ *   Single-producer (MEMPOOL_F_SP_PUT flag) or multi-producers.
  */
 static inline void __attribute__((always_inline))
 __mempool_generic_put(struct rte_mempool *mp, void * const *obj_table,
- unsigned n, int is_mp)
+ unsigned n, int flags)
 {
struct rte_mempool_cache *cache;
uint32_t index;
@@ -971,7 +972,7 @@ __mempool_generic_put(struct rte_mempool *mp, void * const 
*obj_table,
__MEMPOOL_STAT_ADD(mp, put, n);

/* cache is not enabled or single producer or non-EAL thread */
-   if (unlikely(cache_size == 0 || is_mp == 0 ||
+   if (unlikely(cache_size == 0 || flags & MEMPOOL_F_SP_PUT ||
 lcore_id >= RTE_MAX_LCORE))
goto ring_enqueue;

@@ -1024,15 +1025,16 @@ ring_enqueue:
  *   A pointer to a table of void * pointers (objects).
  * @param n
  *   The number of objects to add in the mempool from the obj_table.
- * @param is_mp
- *   Mono-producer (0) or multi-producers (1).
+ * @param flags
+ *   The flags used for the mempool creation.
+ *   Single-producer (MEMPOOL_F_SP_PUT flag) or multi-producers.
  */
 static inline void __attribute__((always_inline))
 rte_mempool_generic_put(struct rte_mempool *mp, void * const *obj_table,
-   unsigned n, int is_mp)
+   unsigned n, int flags)
 {
__mempool_check_cookies(mp, obj_table, n, 0);
-   __mempool_generic_put(mp, obj_table, n, is_mp);
+   __mempool_generic_put(mp, obj_table, n, flags);
 }

 /**
@@ -1050,7 +1052,7 @@ __rte_deprecated static inline void 
__attribute__((always_inline))
 rte_mempool_mp_put_bulk(struct rte_mempool *mp, void * const *obj_table,
unsigned n)
 {
-   rte_mempool_generic_put(mp, obj_table, n, 1);
+   rte_mempool_generic_put(mp, obj_table, n, 0);
 }

 /**
@@ -1068,7 +1070,7 @@ __rte_deprecated static inline void 
__attribute__((always_inline))
 rte_mempool_sp_put_bulk(struct rte_mempool *mp, void * const *obj_table,
unsigned n)
 {
-   rte_mempool_generic_put(mp, obj_table, n, 0);
+   rte_mempool_generic_put(mp, obj_table, n, MEMPOOL_F_SP_PUT);
 }

 /**
@@ -1089,8 +1091,7 @@ static inline void __attribute__((always_inline))
 rte_mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
 unsigned n)
 {
-   rte_mempool_generic_put(mp, obj_table, n,
-   !(mp->flags & MEMPOOL_F_SP_PUT));
+   rte_mempool_generic_put(mp, obj_table, n, mp->flags);
 }

 /**
@@ -1105,7 +1106,7 @@ rte_mempool_put_bulk(struct rte_mempool *mp, void * const 
*obj_table,
 __rte_deprecated static inline void __attribute__((always_inline))
 rte_mempool_mp_put(struct rte_mempool *mp, void *obj)
 {
-   rte_mempool_generic_put(mp, , 1, 1);
+   rte_mempool_generic_put(mp, , 1, 0);
 }

 /**
@@ -1120,7 +1121,7 @@ rte_mempool_mp_put(struct rte_mempool *mp, void *obj)
 __rte_deprecated static inline void __attribute__((always_inline))
 rte_mempool_sp_put(struct rte_mempool *mp, void *obj)
 {
-   rte_mempool_generic_put(mp, , 1, 0);
+   rte_mempool_generic_put(mp, , 1, MEMPOOL_F_SP_PUT);
 }

 /**
@@ -1149,15 +1150,16 @@ rte_mempool_put(struct rte_mempool *mp, void *obj)
  *   A pointer to a table of void * pointers (objects).
  * @param n
  *   The number of objects to get, must be strictly positive.
- * @param is_mc
- *   Mono-consumer (0) or multi-consumers (1).
+ * @param flags
+ *   The flags used for the mempool creation.
+ *   Single-consumer (MEMPOOL_F_SC_GET flag) or multi-consumers.
  * @return
  *   - >=0: Success; number of objects supplied.
  *   - <0: Error; code of ring dequeue function.
  */
 static inline int __attribute__((always_inline))
 __mempool_generic_get(struct rte_mempool *mp, void **obj_table,
- unsigned n, int is_mc)
+ unsigned n, int flags)
 {
int ret;
struct rte_mempool_cache *cache;
@@ -1167,7 +1169,7 @@ __mempool_generic_get(struct rte_mempool *mp, void 
**obj_table,

[dpdk-dev] [PATCH v4 1/3] mempool: deprecate specific get/put functions

[Olivier Matz]

From: Lazaros Koromilas 

This commit introduces the API calls:

rte_mempool_generic_put(mp, obj_table, n, is_mp)
rte_mempool_generic_get(mp, obj_table, n, is_mc)

Deprecates the API calls:

rte_mempool_mp_put_bulk(mp, obj_table, n)
rte_mempool_sp_put_bulk(mp, obj_table, n)
rte_mempool_mp_put(mp, obj)
rte_mempool_sp_put(mp, obj)
rte_mempool_mc_get_bulk(mp, obj_table, n)
rte_mempool_sc_get_bulk(mp, obj_table, n)
rte_mempool_mc_get(mp, obj_p)
rte_mempool_sc_get(mp, obj_p)

We also check cookies in one place now.

Signed-off-by: Lazaros Koromilas 
Acked-by: Olivier Matz 
---
 app/test/test_mempool.c  |  10 ++--
 lib/librte_mempool/rte_mempool.h | 115 +++
 2 files changed, 85 insertions(+), 40 deletions(-)

diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 31582d8..55c2cbc 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -338,7 +338,7 @@ static int test_mempool_single_producer(void)
printf("obj not owned by this mempool\n");
RET_ERR();
}
-   rte_mempool_sp_put(mp_spsc, obj);
+   rte_mempool_put(mp_spsc, obj);
rte_spinlock_lock(_spinlock);
scsp_obj_table[i] = NULL;
rte_spinlock_unlock(_spinlock);
@@ -371,7 +371,7 @@ static int test_mempool_single_consumer(void)
rte_spinlock_unlock(_spinlock);
if (i >= MAX_KEEP)
continue;
-   if (rte_mempool_sc_get(mp_spsc, ) < 0)
+   if (rte_mempool_get(mp_spsc, ) < 0)
break;
rte_spinlock_lock(_spinlock);
scsp_obj_table[i] = obj;
@@ -477,13 +477,13 @@ test_mempool_basic_ex(struct rte_mempool *mp)
}

for (i = 0; i < MEMPOOL_SIZE; i ++) {
-   if (rte_mempool_mc_get(mp, [i]) < 0) {
+   if (rte_mempool_get(mp, [i]) < 0) {
printf("test_mp_basic_ex fail to get object for [%u]\n",
i);
goto fail_mp_basic_ex;
}
}
-   if (rte_mempool_mc_get(mp, _obj) == 0) {
+   if (rte_mempool_get(mp, _obj) == 0) {
printf("test_mempool_basic_ex get an impossible obj\n");
goto fail_mp_basic_ex;
}
@@ -494,7 +494,7 @@ test_mempool_basic_ex(struct rte_mempool *mp)
}

for (i = 0; i < MEMPOOL_SIZE; i++)
-   rte_mempool_mp_put(mp, obj[i]);
+   rte_mempool_put(mp, obj[i]);

if (rte_mempool_full(mp) != 1) {
printf("test_mempool_basic_ex the mempool should be full\n");
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 0a1777c..a48f46d 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -957,8 +957,8 @@ void rte_mempool_dump(FILE *f, struct rte_mempool *mp);
  *   Mono-producer (0) or multi-producers (1).
  */
 static inline void __attribute__((always_inline))
-__mempool_put_bulk(struct rte_mempool *mp, void * const *obj_table,
-   unsigned n, int is_mp)
+__mempool_generic_put(struct rte_mempool *mp, void * const *obj_table,
+ unsigned n, int is_mp)
 {
struct rte_mempool_cache *cache;
uint32_t index;
@@ -1016,7 +1016,7 @@ ring_enqueue:


 /**
- * Put several objects back in the mempool (multi-producers safe).
+ * Put several objects back in the mempool.
  *
  * @param mp
  *   A pointer to the mempool structure.
@@ -1024,16 +1024,37 @@ ring_enqueue:
  *   A pointer to a table of void * pointers (objects).
  * @param n
  *   The number of objects to add in the mempool from the obj_table.
+ * @param is_mp
+ *   Mono-producer (0) or multi-producers (1).
  */
 static inline void __attribute__((always_inline))
+rte_mempool_generic_put(struct rte_mempool *mp, void * const *obj_table,
+   unsigned n, int is_mp)
+{
+   __mempool_check_cookies(mp, obj_table, n, 0);
+   __mempool_generic_put(mp, obj_table, n, is_mp);
+}
+
+/**
+ * @deprecated
+ * Put several objects back in the mempool (multi-producers safe).
+ *
+ * @param mp
+ *   A pointer to the mempool structure.
+ * @param obj_table
+ *   A pointer to a table of void * pointers (objects).
+ * @param n
+ *   The number of objects to add in the mempool from the obj_table.
+ */
+__rte_deprecated static inline void __attribute__((always_inline))
 rte_mempool_mp_put_bulk(struct rte_mempool *mp, void * const *obj_table,
unsigned n)
 {
-   __mempool_check_cookies(mp, obj_table, n, 0);
-   __mempool_put_bulk(mp, obj_table, n, 1);
+   rte_mempool_generic_put(mp, obj_table, n, 1);
 }

 /**
+ * @deprecated
  * Put several objects back in the mempool (NOT multi-producers safe).
  *
  * @param mp
@@ -1043,12 +1064,11 @@ 

[dpdk-dev] [PATCH v4 0/3] mempool: user-owned mempool caches

[Olivier Matz]

Updated version of the user-owned cache patchset.  It applies on top of
the latest external mempool manager patches from David Hunt [1].

[1] http://dpdk.org/ml/archives/dev/2016-June/041479.html

v4 changes:

 * Fix compilation with shared libraries
 * Add a GOTO_ERR() macro to factorize code in test_mempool.c
 * Change title of patch 2 to conform to check-git-log.sh

v3 changes:

 * Deprecate specific mempool API calls instead of removing them.
 * Split deprecation into a separate commit to limit noise.
 * Fix cache flush by setting cache->len = 0 and make it inline.
 * Remove cache->size == 0 checks and ensure size != 0 at creation.
 * Fix tests to check if cache creation succeeded.
 * Fix tests to free allocated resources on error.

The mempool cache is only available to EAL threads as a per-lcore
resource. Change this so that the user can create and provide their own
cache on mempool get and put operations. This works with non-EAL threads
too.

Also, deprecate the explicit {mp,sp}_put and {mc,sc}_get calls and
re-route them through the new generic calls. Minor cleanup to pass the
mempool bit flags instead of using specific is_mp and is_mc. The old
cache-oblivious API calls use the per-lcore default local cache. The
mempool and mempool_perf tests are also updated to handle the
user-owned cache case.

Introduced API calls:

rte_mempool_cache_create(size, socket_id)
rte_mempool_cache_free(cache)
rte_mempool_cache_flush(cache, mp)
rte_mempool_default_cache(mp, lcore_id)

rte_mempool_generic_put(mp, obj_table, n, cache, flags)
rte_mempool_generic_get(mp, obj_table, n, cache, flags)

Deprecated API calls:

rte_mempool_mp_put_bulk(mp, obj_table, n)
rte_mempool_sp_put_bulk(mp, obj_table, n)
rte_mempool_mp_put(mp, obj)
rte_mempool_sp_put(mp, obj)
rte_mempool_mc_get_bulk(mp, obj_table, n)
rte_mempool_sc_get_bulk(mp, obj_table, n)
rte_mempool_mc_get(mp, obj_p)
rte_mempool_sc_get(mp, obj_p)


Lazaros Koromilas (3):
  mempool: deprecate specific get/put functions
  mempool: use bit flags to set multi consumers or producers
  mempool: allow for user-owned mempool caches

 app/test/test_mempool.c|  85 +++---
 app/test/test_mempool_perf.c   |  70 ++--
 lib/librte_mempool/rte_mempool.c   |  66 +++-
 lib/librte_mempool/rte_mempool.h   | 256 +
 lib/librte_mempool/rte_mempool_version.map |   4 +
 5 files changed, 371 insertions(+), 110 deletions(-)

-- 
2.8.1

[dpdk-dev] [PATCH] ixgbe: fix compilation when offload flags disabled

[Olivier Matz]

The ixgbe driver does not compile if CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=n
because the macro has not the proper number of parameters.

Fixes: b37b528d957c ("mbuf: add new Rx flags for stripped VLAN")
Reported-by: Amin Tootoonchian 
Signed-off-by: Olivier Matz 
---
 drivers/net/ixgbe/ixgbe_rxtx_vec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c 
b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
index 12190d2..6989fc3 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
@@ -196,7 +196,9 @@ desc_to_olflags_v(__m128i descs[4], uint8_t vlan_flags,
rx_pkts[3]->ol_flags = vol.e[3];
 }
 #else
-#define desc_to_olflags_v(desc, rx_pkts) do {} while (0)
+#define desc_to_olflags_v(desc, vlan_flags, rx_pkts) do { \
+   RTE_SET_USED(vlan_flags); \
+   } while (0)
 #endif

 /*
-- 
2.8.1

[dpdk-dev] [PATCH v2 2/2] fix building with clang-3.8.0 compiler

[Bruce Richardson]

On Mon, Jun 27, 2016 at 05:29:59PM +0100, Wiles, Keith wrote:
> On 6/27/16, 7:58 AM, "dev on behalf of Wiles, Keith"  on behalf of keith.wiles at intel.com> wrote:
> 
> >
> >On 6/27/16, 3:46 AM, "Richardson, Bruce"  
> >wrote:
> >
> >>On Sun, Jun 26, 2016 at 10:54:12AM -0500, Keith Wiles wrote:
> >>> Latest clang compiler 3.8.0 on latest update of Ubuntu
> >>> creates a few more warnings on -Warray-bounds and extra
> >>> () around 'if' expressions.
> >>> 
> >>> Signed-off-by: Keith Wiles 
> >>> ---
> >>>  app/test-pmd/Makefile| 3 +++
> >>>  app/test/Makefile| 3 +++
> >>>  drivers/net/bonding/Makefile | 4 
> >>>  drivers/net/fm10k/Makefile   | 2 ++
> >>>  drivers/net/i40e/Makefile| 2 ++
> >>>  lib/librte_cmdline/Makefile  | 6 ++
> >>>  lib/librte_eal/linuxapp/eal/Makefile | 8 
> >>>  7 files changed, 28 insertions(+)
> >>> 
> >>All the fixes in this patch seem to be just disabling the compiler 
> >>warnings, which
> >>should really be the last resort in cases like this. Can some of the issues 
> >>be
> >>fixed by actually fixing the issues in the code?
> >
> >I did look at the code to fix the problem, because I could not see one:
> >
> >/work/home/rkwiles/projects/intel/dpdk/app/test-pmd/cmdline.c:3357:2140: 
> >error: array index 3 is past the end of the array (which contains 3 
> >elements) [-Werror,-Warray-bounds]
> >  if (!__extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p 
> > (res->proto) && __builtin_constant_p ("ip") && (__s1_len = __builtin_strlen 
> > (res->proto), __s2_len = __builtin_strlen ("ip"), (!((size_t)(const void 
> > *)((res->proto) + 1) - (size_t)(const void *)(res->proto) == 1) || __s1_len 
> > >= 4) && (!((size_t)(const void *)(("ip") + 1) - (size_t)(const void 
> > *)("ip") == 1) || __s2_len >= 4)) ? __builtin_strcmp (res->proto, "ip") : 
> > (__builtin_constant_p (res->proto) && ((size_t)(const void *)((res->proto) 
> > + 1) - (size_t)(const void *)(res->proto) == 1) && (__s1_len = 
> > __builtin_strlen (res->proto), __s1_len < 4) ? (__builtin_constant_p ("ip") 
> > && ((size_t)(const void *)(("ip") + 1) - (size_t)(const void *)("ip") == 1) 
> > ? __builtin_strcmp (res->proto, "ip") : (__extension__ ({ const unsigned 
> > char *__s2 = (const unsigned char *) (const char *) ("ip"); int __result = 
> > (((const unsigned char *) (const char *) (res->proto))[0] - __s2[0]); if 
> > (__s1_len > 0 && __result == 0) { __result = (((const unsigned char *) 
> > (const char *) (res->proto))[1] - __s2[1]); if (__s1_len > 1 && __result == 
> > 0) { __result = (((const unsigned char *) (const char *) (res->proto))[2] - 
> > __s2[2]); if (__s1_len > 2 && __result == 0) __result = (((const unsigned 
> > char *) (const char *) (res->proto))[3] - __s2[3]); } } __result; }))) : 
> > (__builtin_constant_p ("ip") && ((size_t)(const void *)(("ip") + 1) - 
> > (size_t)(const void *)("ip") == 1) && (__s2_len = __builtin_strlen ("ip"), 
> > __s2_len < 4) ? (__builtin_constant_p (res->proto) && ((size_t)(const void 
> > *)((res->proto) + 1) - (size_t)(const void *)(res->proto) == 1) ? 
> > __builtin_strcmp (res->proto, "ip") : (- (__extension__ ({ const unsigned 
> > char *__s2 = (const unsigned char *) (const char *) (res->proto); int 
> > __result = (((const unsigned char *) (const char *) ("ip"))[0] - __s2[0]); 
> > if (__s2_len > 0 && __result == 0) { __result = (((const unsigned char *) 
> > (const char *) ("ip"))[1] - __s2[1]); if (__s2_len > 1 && __result == 0) { 
> > __result = (((const unsigned char *) (const char *) ("ip"))[2] - __s2[2]); 
> > if (__s2_len > 2 && __result == 0) __result = (((const unsigned char *) 
> > (const char *) ("ip"))[3] - __s2[3]); } } __result; } : 
> > __builtin_strcmp (res->proto, "ip"; })) {
> >
> >Here is the line of code for that one:
> >if (!strcmp(res->proto, "ip")) {
> >
> >The ?Wno-parenthese-equality problem gives the output here:
> >
> >/work/home/rkwiles/projects/intel/dpdk/lib/librte_cmdline/cmdline_cirbuf.c:288:19:
> > error: equality comparison with extraneous parentheses 
> >[-Werror,-Wparentheses-equality]
> > if (((cbuf)->len == 0)) {
> >
> >The line is:
> >
> >if (CIRBUF_IS_EMPTY(cbuf)) {
> >
> >This one is in cmdline_cirbuf.h, which can be changed, but I do not think we 
> >need to remove the parenthese.
> >
> >I will look at some of other solution, so I rejected the patch.
> 
> I found the problem to the compile errors I am seeing with building with 
> clang and shared libraries.
> 
> The x86_64-linux-gnu/bits/string2.h header file if getting included from 
> string.h, but this would be mean __GNUC__ is defined and this is the clang 
> compiler. After much investigation it turns out ?ccache? is the problem here. 
> If ccache is enabled with clang builds the __GNUC__ is defined some how, I 
> never did find the location.
> 
> Just a warning it appears ?ccache? for caching object files is not compatible 
> with DPDK 

[dpdk-dev] [PATCH] ixgbe: fix unused value

[Bruce Richardson]

On Mon, Jun 27, 2016 at 05:29:35PM +0100, Bruce Richardson wrote:
> On Thu, Jun 02, 2016 at 06:01:22PM +0200, Daniel Mrzyglod wrote:
> > An assigned value that is never used may represent unnecessary computation,
> > an incorrect algorithm, or possibly the need for cleanup or refactoring.
> > 
> > In reassemble_packets: A value assigned to a variable is never used.
> > 
> > Fixes: cf4b4708a88a ("ixgbe: improve slow-path perf with vector scattered 
> > Rx")
> > Coverity ID 13335
> > 
> > Signed-off-by: Daniel Mrzyglod 
> > ---
> Fix now needs to be applied to ixgbe_rxtx_vec_common.h since the ixgbe vector
> rework, but since it's only a one-line change it's easy enough to fix on 
> apply.
> 
> Acked-by: Bruce Richardson 
> 
Applied to dpdk-next-net/rel_16_07 with updated commit message.

/Bruce

[dpdk-dev] [PATCH 4/4] virtio: add neon support

[Jerin Jacob]

Added neon based Rx vector implementation for virtio.
Selected neon based virtio implementation for ARM64 as
default and updated the MAINTAINERS file.

Signed-off-by: Jerin Jacob 
---
 MAINTAINERS  |   1 +
 config/defconfig_arm64-armv8a-linuxapp-gcc   |   1 -
 doc/guides/rel_notes/release_16_07.rst   |   2 +
 drivers/net/virtio/virtio_rxtx.c |   2 +-
 drivers/net/virtio/virtio_rxtx_simple.c  |   2 +
 drivers/net/virtio/virtio_rxtx_simple_neon.h | 238 +++
 6 files changed, 244 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/virtio/virtio_rxtx_simple_neon.h

diff --git a/MAINTAINERS b/MAINTAINERS
index f6c0d3d..2bb12aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -142,6 +142,7 @@ F: lib/librte_eal/common/include/arch/arm/*_64.h
 F: lib/librte_acl/acl_run_neon.*
 F: lib/librte_lpm/rte_lpm_neon.h
 F: lib/librte_hash/rte*_arm64.h
+F: drivers/net/virtio/virtio_rxtx_simple_neon.h

 EZchip TILE-Gx
 M: Zhigang Lu 
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 95ed30e..a786562 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -48,6 +48,5 @@ CONFIG_RTE_IXGBE_INC_VECTOR=n
 CONFIG_RTE_LIBRTE_IVSHMEM=n
 CONFIG_RTE_LIBRTE_FM10K_PMD=n
 CONFIG_RTE_LIBRTE_I40E_PMD=n
-CONFIG_RTE_LIBRTE_VIRTIO_INC_VECTOR=n

 CONFIG_RTE_SCHED_VECTOR=n
diff --git a/doc/guides/rel_notes/release_16_07.rst 
b/doc/guides/rel_notes/release_16_07.rst
index 2694f50..3187a33 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -118,6 +118,8 @@ New Features
   * Root privilege is a must for sorting hugepages by physical address.
   * Can only be used with vhost user backend.

+* **Virtio NEON support for ARM.**
+
 Resolved Issues
 ---

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index e9b42f3..ca25db3 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -500,7 +500,7 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
}

 #ifdef RTE_LIBRTE_VIRTIO_INC_VECTOR
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
+#if defined RTE_MACHINE_CPUFLAG_SSSE3 || defined RTE_MACHINE_CPUFLAG_NEON
struct virtio_hw *hw = dev->data->dev_private;
/* Use simple rx/tx func if single segment and no offloads */
if ((tx_conf->txq_flags & VIRTIO_SIMPLE_FLAGS) == VIRTIO_SIMPLE_FLAGS &&
diff --git a/drivers/net/virtio/virtio_rxtx_simple.c 
b/drivers/net/virtio/virtio_rxtx_simple.c
index ca87605..e5dc010 100644
--- a/drivers/net/virtio/virtio_rxtx_simple.c
+++ b/drivers/net/virtio/virtio_rxtx_simple.c
@@ -131,6 +131,8 @@ virtio_rxq_rearm_vec(struct virtnet_rx *rxvq)

 #ifdef RTE_MACHINE_CPUFLAG_SSSE3
 #include "virtio_rxtx_simple_sse.h"
+#elif RTE_MACHINE_CPUFLAG_NEON
+#include "virtio_rxtx_simple_neon.h"
 #endif

 #define VIRTIO_TX_FREE_THRESH 32
diff --git a/drivers/net/virtio/virtio_rxtx_simple_neon.h 
b/drivers/net/virtio/virtio_rxtx_simple_neon.h
new file mode 100644
index 000..41f347d
--- /dev/null
+++ b/drivers/net/virtio/virtio_rxtx_simple_neon.h
@@ -0,0 +1,238 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright (C) Cavium networks Ltd. 2016
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Cavium networks nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 

[dpdk-dev] [PATCH 3/4] virtio: move SSE based Rx implementation to separate file

[Jerin Jacob]

split out SSE instruction based virtio simple rx
implementation to a separate file

Signed-off-by: Jerin Jacob 
---
 drivers/net/virtio/virtio_rxtx_simple.c | 166 +---
 drivers/net/virtio/virtio_rxtx_simple_sse.h | 225 
 2 files changed, 226 insertions(+), 165 deletions(-)
 create mode 100644 drivers/net/virtio/virtio_rxtx_simple_sse.h

diff --git a/drivers/net/virtio/virtio_rxtx_simple.c 
b/drivers/net/virtio/virtio_rxtx_simple.c
index 67430da..ca87605 100644
--- a/drivers/net/virtio/virtio_rxtx_simple.c
+++ b/drivers/net/virtio/virtio_rxtx_simple.c
@@ -130,171 +130,7 @@ virtio_rxq_rearm_vec(struct virtnet_rx *rxvq)
 }

 #ifdef RTE_MACHINE_CPUFLAG_SSSE3
-
-#include 
-
-/* virtio vPMD receive routine, only accept(nb_pkts >= 
RTE_VIRTIO_DESC_PER_LOOP)
- *
- * This routine is for non-mergeable RX, one desc for each guest buffer.
- * This routine is based on the RX ring layout optimization. Each entry in the
- * avail ring points to the desc with the same index in the desc ring and this
- * will never be changed in the driver.
- *
- * - nb_pkts < RTE_VIRTIO_DESC_PER_LOOP, just return no packet
- */
-uint16_t
-virtio_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
-   uint16_t nb_pkts)
-{
-   struct virtnet_rx *rxvq = rx_queue;
-   struct virtqueue *vq = rxvq->vq;
-   uint16_t nb_used;
-   uint16_t desc_idx;
-   struct vring_used_elem *rused;
-   struct rte_mbuf **sw_ring;
-   struct rte_mbuf **sw_ring_end;
-   uint16_t nb_pkts_received;
-   __m128i shuf_msk1, shuf_msk2, len_adjust;
-
-   shuf_msk1 = _mm_set_epi8(
-   0xFF, 0xFF, 0xFF, 0xFF,
-   0xFF, 0xFF, /* vlan tci */
-   5, 4,   /* dat len */
-   0xFF, 0xFF, 5, 4,   /* pkt len */
-   0xFF, 0xFF, 0xFF, 0xFF  /* packet type */
-
-   );
-
-   shuf_msk2 = _mm_set_epi8(
-   0xFF, 0xFF, 0xFF, 0xFF,
-   0xFF, 0xFF, /* vlan tci */
-   13, 12, /* dat len */
-   0xFF, 0xFF, 13, 12, /* pkt len */
-   0xFF, 0xFF, 0xFF, 0xFF  /* packet type */
-   );
-
-   /* Subtract the header length.
-   *  In which case do we need the header length in used->len ?
-   */
-   len_adjust = _mm_set_epi16(
-   0, 0,
-   0,
-   (uint16_t)-vq->hw->vtnet_hdr_size,
-   0, (uint16_t)-vq->hw->vtnet_hdr_size,
-   0, 0);
-
-   if (unlikely(nb_pkts < RTE_VIRTIO_DESC_PER_LOOP))
-   return 0;
-
-   nb_used = VIRTQUEUE_NUSED(vq);
-
-   rte_compiler_barrier();
-
-   if (unlikely(nb_used == 0))
-   return 0;
-
-   nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_VIRTIO_DESC_PER_LOOP);
-   nb_used = RTE_MIN(nb_used, nb_pkts);
-
-   desc_idx = (uint16_t)(vq->vq_used_cons_idx & (vq->vq_nentries - 1));
-   rused = >vq_ring.used->ring[desc_idx];
-   sw_ring  = >sw_ring[desc_idx];
-   sw_ring_end = >sw_ring[vq->vq_nentries];
-
-   _mm_prefetch((const void *)rused, _MM_HINT_T0);
-
-   if (vq->vq_free_cnt >= RTE_VIRTIO_VPMD_RX_REARM_THRESH) {
-   virtio_rxq_rearm_vec(rxvq);
-   if (unlikely(virtqueue_kick_prepare(vq)))
-   virtqueue_notify(vq);
-   }
-
-   for (nb_pkts_received = 0;
-   nb_pkts_received < nb_used;) {
-   __m128i desc[RTE_VIRTIO_DESC_PER_LOOP / 2];
-   __m128i mbp[RTE_VIRTIO_DESC_PER_LOOP / 2];
-   __m128i pkt_mb[RTE_VIRTIO_DESC_PER_LOOP];
-
-   mbp[0] = _mm_loadu_si128((__m128i *)(sw_ring + 0));
-   desc[0] = _mm_loadu_si128((__m128i *)(rused + 0));
-   _mm_storeu_si128((__m128i *)_pkts[0], mbp[0]);
-
-   mbp[1] = _mm_loadu_si128((__m128i *)(sw_ring + 2));
-   desc[1] = _mm_loadu_si128((__m128i *)(rused + 2));
-   _mm_storeu_si128((__m128i *)_pkts[2], mbp[1]);
-
-   mbp[2] = _mm_loadu_si128((__m128i *)(sw_ring + 4));
-   desc[2] = _mm_loadu_si128((__m128i *)(rused + 4));
-   _mm_storeu_si128((__m128i *)_pkts[4], mbp[2]);
-
-   mbp[3] = _mm_loadu_si128((__m128i *)(sw_ring + 6));
-   desc[3] = _mm_loadu_si128((__m128i *)(rused + 6));
-   _mm_storeu_si128((__m128i *)_pkts[6], mbp[3]);
-
-   pkt_mb[1] = _mm_shuffle_epi8(desc[0], shuf_msk2);
-   pkt_mb[0] = _mm_shuffle_epi8(desc[0], shuf_msk1);
-   pkt_mb[1] = _mm_add_epi16(pkt_mb[1], len_adjust);
-   pkt_mb[0] = _mm_add_epi16(pkt_mb[0], len_adjust);
-   _mm_storeu_si128((void *)_pkts[1]->rx_descriptor_fields1,
-   pkt_mb[1]);
-   _mm_storeu_si128((void *)_pkts[0]->rx_descriptor_fields1,
-   pkt_mb[0]);
-
-   pkt_mb[3] = _mm_shuffle_epi8(desc[1], 

[dpdk-dev] [PATCH 2/4] virtio: introduce RTE_LIBRTE_VIRTIO_INC_VECTOR

[Jerin Jacob]

like other PMD drivers, introduce RTE_LIBRTE_VIRTIO_INC_VECTOR
for vector based handler selection in virtio

Enabled by default in common config and disabled for non X86
platforms

Signed-off-by: Jerin Jacob 
---
 config/common_base  | 1 +
 config/defconfig_arm-armv7a-linuxapp-gcc| 1 +
 config/defconfig_arm64-armv8a-linuxapp-gcc  | 1 +
 config/defconfig_ppc_64-power8-linuxapp-gcc | 1 +
 config/defconfig_tile-tilegx-linuxapp-gcc   | 1 +
 drivers/net/virtio/virtio_rxtx.c| 2 ++
 6 files changed, 7 insertions(+)

diff --git a/config/common_base b/config/common_base
index 3a04fba..f6ce168 100644
--- a/config/common_base
+++ b/config/common_base
@@ -267,6 +267,7 @@ CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
 CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
 CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
 CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
+CONFIG_RTE_LIBRTE_VIRTIO_INC_VECTOR=y

 #
 # Compile burst-oriented VMXNET3 PMD driver
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
b/config/defconfig_arm-armv7a-linuxapp-gcc
index bde6acd..a249ad5 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -75,3 +75,4 @@ CONFIG_RTE_LIBRTE_VMXNET3_PMD=n
 CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
 CONFIG_RTE_LIBRTE_PMD_BNX2X=n
 CONFIG_RTE_LIBRTE_QEDE_PMD=n
+CONFIG_RTE_LIBRTE_VIRTIO_INC_VECTOR=n
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index a786562..95ed30e 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -48,5 +48,6 @@ CONFIG_RTE_IXGBE_INC_VECTOR=n
 CONFIG_RTE_LIBRTE_IVSHMEM=n
 CONFIG_RTE_LIBRTE_FM10K_PMD=n
 CONFIG_RTE_LIBRTE_I40E_PMD=n
+CONFIG_RTE_LIBRTE_VIRTIO_INC_VECTOR=n

 CONFIG_RTE_SCHED_VECTOR=n
diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc 
b/config/defconfig_ppc_64-power8-linuxapp-gcc
index bef8f49..1eca73a 100644
--- a/config/defconfig_ppc_64-power8-linuxapp-gcc
+++ b/config/defconfig_ppc_64-power8-linuxapp-gcc
@@ -51,6 +51,7 @@ CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
 CONFIG_RTE_LIBRTE_IXGBE_PMD=n
 CONFIG_RTE_LIBRTE_I40E_PMD=n
 CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
+CONFIG_RTE_LIBRTE_VIRTIO_INC_VECTOR=n
 CONFIG_RTE_LIBRTE_VMXNET3_PMD=n
 CONFIG_RTE_LIBRTE_PMD_BOND=n
 CONFIG_RTE_LIBRTE_ENIC_PMD=n
diff --git a/config/defconfig_tile-tilegx-linuxapp-gcc 
b/config/defconfig_tile-tilegx-linuxapp-gcc
index 5a50793..0d6fe1e 100644
--- a/config/defconfig_tile-tilegx-linuxapp-gcc
+++ b/config/defconfig_tile-tilegx-linuxapp-gcc
@@ -59,6 +59,7 @@ CONFIG_RTE_LIBRTE_IXGBE_PMD=n
 CONFIG_RTE_LIBRTE_I40E_PMD=n
 CONFIG_RTE_LIBRTE_FM10K_PMD=n
 CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
+CONFIG_RTE_LIBRTE_VIRTIO_INC_VECTOR=n
 CONFIG_RTE_LIBRTE_VMXNET3_PMD=n
 CONFIG_RTE_LIBRTE_ENIC_PMD=n

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 63b53f7..e9b42f3 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -499,6 +499,7 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
return -EINVAL;
}

+#ifdef RTE_LIBRTE_VIRTIO_INC_VECTOR
 #ifdef RTE_MACHINE_CPUFLAG_SSSE3
struct virtio_hw *hw = dev->data->dev_private;
/* Use simple rx/tx func if single segment and no offloads */
@@ -510,6 +511,7 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
hw->use_simple_rxtx = 1;
}
 #endif
+#endif

ret = virtio_dev_queue_setup(dev, VTNET_TQ, queue_idx, vtpci_queue_idx,
nb_desc, socket_id, (void **));
-- 
2.5.5

[dpdk-dev] [PATCH 1/4] virtio: Fix compile time dependency of use_simple_rxtx usage

[Jerin Jacob]

Removed unnecessary compile time dependency on "use_simple_rxtx".

Signed-off-by: Jerin Jacob 
---
 drivers/net/virtio/Makefile |  3 ---
 drivers/net/virtio/virtio_pci.h |  1 +
 drivers/net/virtio/virtio_rxtx.c| 28 +---
 drivers/net/virtio/virtio_rxtx.h|  3 +--
 drivers/net/virtio/virtio_rxtx_simple.c |  8 ++--
 drivers/net/virtio/virtio_user_ethdev.c |  1 +
 6 files changed, 18 insertions(+), 26 deletions(-)

diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile
index 43de46c..114d40e 100644
--- a/drivers/net/virtio/Makefile
+++ b/drivers/net/virtio/Makefile
@@ -50,10 +50,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtqueue.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_pci.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_ethdev.c
-
-ifeq ($(findstring 
RTE_MACHINE_CPUFLAG_SSSE3,$(CFLAGS)),RTE_MACHINE_CPUFLAG_SSSE3)
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple.c
-endif

 ifeq ($(CONFIG_RTE_VIRTIO_USER),y)
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_user/vhost_user.c
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index dd7693f..b8295a7 100644
--- a/drivers/net/virtio/virtio_pci.h
+++ b/drivers/net/virtio/virtio_pci.h
@@ -253,6 +253,7 @@ struct virtio_hw {
uint8_t use_msix;
uint8_t started;
uint8_t modern;
+   uint8_t use_simple_rxtx;
uint8_t mac_addr[ETHER_ADDR_LEN];
uint32_tnotify_off_multiplier;
uint8_t *isr;
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index a27208e..63b53f7 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -67,10 +67,6 @@
 #define VIRTIO_SIMPLE_FLAGS ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
ETH_TXQ_FLAGS_NOOFFLOADS)

-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-static int use_simple_rxtx;
-#endif
-
 static void
 vq_ring_free_chain(struct virtqueue *vq, uint16_t desc_idx)
 {
@@ -333,6 +329,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
 */
uint16_t i;
uint16_t desc_idx;
+   struct virtio_hw *hw = dev->data->dev_private;

PMD_INIT_FUNC_TRACE();

@@ -353,8 +350,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
nbufs = 0;
error = ENOSPC;

-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-   if (use_simple_rxtx) {
+   if (hw->use_simple_rxtx) {
for (desc_idx = 0; desc_idx < vq->vq_nentries;
 desc_idx++) {
vq->vq_ring.avail->ring[desc_idx] = desc_idx;
@@ -362,7 +358,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
VRING_DESC_F_WRITE;
}
}
-#endif
+
memset(>fake_mbuf, 0, sizeof(rxvq->fake_mbuf));
for (desc_idx = 0; desc_idx < RTE_PMD_VIRTIO_RX_MAX_BURST;
 desc_idx++) {
@@ -378,12 +374,11 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
/**
* Enqueue allocated buffers*
***/
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-   if (use_simple_rxtx)
+   if (hw->use_simple_rxtx)
error = 
virtqueue_enqueue_recv_refill_simple(vq, m);
else
-#endif
error = virtqueue_enqueue_recv_refill(vq, m);
+
if (error) {
rte_pktmbuf_free(m);
break;
@@ -404,8 +399,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
struct virtqueue *vq = txvq->vq;

virtio_dev_vring_start(vq);
-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-   if (use_simple_rxtx) {
+   if (hw->use_simple_rxtx) {
uint16_t mid_idx  = vq->vq_nentries >> 1;

for (desc_idx = 0; desc_idx < mid_idx; desc_idx++) {
@@ -426,7 +420,7 @@ virtio_dev_rxtx_start(struct rte_eth_dev *dev)
 desc_idx++)
vq->vq_ring.avail->ring[desc_idx] = desc_idx;
}
-#endif
+
VIRTQUEUE_DUMP(vq);
}
 }
@@ -456,9 +450,7 @@ virtio_dev_rx_queue_setup(struct rte_eth_dev *dev,

dev->data->rx_queues[queue_idx] = rxvq;

-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
virtio_rxq_vec_setup(rxvq);
-#endif

return 0;
 }
@@ -494,9 +486,6 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
 {
uint8_t vtpci_queue_idx = 2 * queue_idx + VTNET_SQ_TQ_QUEUE_IDX;

-#ifdef RTE_MACHINE_CPUFLAG_SSSE3
-   struct virtio_hw *hw = dev->data->dev_private;
-#endif
struct virtnet_tx *txvq;

[dpdk-dev] [PATCH 0/4] Virtio NEON support for ARM

[Jerin Jacob]

This patchset includes,

1) General cleanup on compile time dependency of use_simple_rxtx with 
RTE_MACHINE_CPUFLAG_SSSE3
2) Added NEON support for optimized Rx handling

This patchset is based on dpdk-next-virtio/master at 
a1d8bd4911b28e32c35f16ab2ff3e22180d1f1d7

Jerin Jacob (4):
  virtio: Fix compile time dependency of use_simple_rxtx usage
  virtio: introduce RTE_LIBRTE_VIRTIO_INC_VECTOR
  virtio: move SSE based Rx implementation to separate file
  virtio: add neon support

 MAINTAINERS  |   1 +
 config/common_base   |   1 +
 config/defconfig_arm-armv7a-linuxapp-gcc |   1 +
 config/defconfig_ppc_64-power8-linuxapp-gcc  |   1 +
 config/defconfig_tile-tilegx-linuxapp-gcc|   1 +
 doc/guides/rel_notes/release_16_07.rst   |   2 +
 drivers/net/virtio/Makefile  |   3 -
 drivers/net/virtio/virtio_pci.h  |   1 +
 drivers/net/virtio/virtio_rxtx.c |  32 ++--
 drivers/net/virtio/virtio_rxtx.h |   3 +-
 drivers/net/virtio/virtio_rxtx_simple.c  | 168 +--
 drivers/net/virtio/virtio_rxtx_simple_neon.h | 238 +++
 drivers/net/virtio/virtio_rxtx_simple_sse.h  | 225 +
 drivers/net/virtio/virtio_user_ethdev.c  |   1 +
 14 files changed, 490 insertions(+), 188 deletions(-)
 create mode 100644 drivers/net/virtio/virtio_rxtx_simple_neon.h
 create mode 100644 drivers/net/virtio/virtio_rxtx_simple_sse.h

-- 
2.5.5

[dpdk-dev] [PATCH v4 1/2] ethdev: remove get_reg_length callback

[Thomas Monjalon]

2016-06-23 15:26, zr at semihalf.com:
> From: Zyta Szpak 
> 
> Version 4 of fixing the assumption of that device registers
> are always 32 bits long. rte_eth_dev_get_reg_length and
> rte_eth_dev_get_reg_info callbacks did not provide register size
> to the app in any way. It is needed to allocate proper number
> of bytes before retrieving registers content with
> rte_eth_dev_get_reg. This commit remove rte_eth_dev_get_reg_length
> callback and adds width parameter to reg_info struct which makes
> it possible to call rte_eth_dev_get_reg_info to get attributes
> first. The drivers using this callback fill width and length
> when call to function made with data=NULL.
> 
> Signed-off-by: Zyta Szpak 

Please do not mention patch revision in the commit log.
However you can add a changelog below the three dashes (with --annotate).
And please use --in-reply-to to keep revisions in the same thread.
Thanks

[dpdk-dev] [PATCH v2 0/7] fix dependencies

[Thomas Monjalon]

> Panu Matilainen (3):
>   pipeline: fix truncated dependency list
>   pdump: fix missing dependency on libpthread
>   mk: check shared library dependencies
> 
> Thomas Monjalon (4):
>   mk: remove traces of combined library
>   mk: fix external library link
>   mk: fix internal dependencies
>   mk: fix external dependencies of crypto drivers

Applied

[dpdk-dev] [PATCH] mempool: fix symbol export

[Thomas Monjalon]

> > Every new symbols in release 16.07 are exported with the version
> > string DPDK_16.07.
> > Also remove the empty local: section which is not needed because
> > inherited from the DPDK_2.0 block.
> > 
> > Signed-off-by: Thomas Monjalon 
> 
> Good catch, thanks Thomas
> Acked-by: Olivier Matz 

Applied

[dpdk-dev] [PATCH 2/4] virtio: introduce RTE_LIBRTE_VIRTIO_INC_VECTOR

[Thomas Monjalon]

2016-06-27 20:18, Jerin Jacob:
> On Mon, Jun 27, 2016 at 04:19:57PM +0200, Thomas Monjalon wrote:
> > 2016-06-27 17:24, Jerin Jacob:
> > > --- a/config/common_base
> > > +++ b/config/common_base
> > > @@ -267,6 +267,7 @@ CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
> > >  CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
> > >  CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
> > >  CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
> > > +CONFIG_RTE_LIBRTE_VIRTIO_INC_VECTOR=y
> > 
> > I don't remember what means INC_VECTOR?
> > Why a config option is needed for vector implementations?
> 
> I thought of adding additional configuration option(INC_VECTOR) _apart_ from
> cpu flag based scheme in the patch because even though if a given platform
> has cpu instruction support, in some platforms scalar version may
> perform well wrt vector version(based on instruction latency, emulation 
> required or not
> etc). So a top level flag INC_VECTOR, can override the vector selection
> for a given platform if required.

Isn't it a runtime driver option needed to disable vector virtio?

> Regarding INC_VECTOR(INC in vector configuration name, I have no idea, I
> followed the existing flags)
> $ grep "INC_VECTOR" config/common_base
> CONFIG_RTE_IXGBE_INC_VECTOR=y
> CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=y
> CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y

If the flag is really needed I would suggest VIRTIO_VECTOR.

[dpdk-dev] [PATCH] scripts: add verbose option in build test help

[Thomas Monjalon]

2016-06-24 12:18, Thomas Monjalon:
> The verbose option was available but not advertised.
> 
> Fixes: 6e38dfe21389 ("scripts: add verbose test build option")
> 
> Signed-off-by: Thomas Monjalon 

Applied

[dpdk-dev] [PATCH] scripts: relax line length check for fixed commit

[Thomas Monjalon]

2016-06-25 13:59, Wiles, Keith:
> On 6/24/16, 4:30 AM, "dev on behalf of Bruce Richardson"  dpdk.org on behalf of bruce.richardson at intel.com> wrote:
> 
> >On Fri, Jun 24, 2016 at 12:44:18AM +0200, Thomas Monjalon wrote:
> >> It is better to keep the line "Fixes:" longer than 75 characters
> >> than splitting.
> >> 
> >> Signed-off-by: Thomas Monjalon 
> >
> >Definite +1
> 
> Yes, +2 for me.

Applied

[dpdk-dev] [PATCH v2 2/2] fix building with clang-3.8.0 compiler

[Wiles, Keith]

On 6/27/16, 11:40 AM, "Richardson, Bruce"  wrote:

>On Mon, Jun 27, 2016 at 05:29:59PM +0100, Wiles, Keith wrote:
>> On 6/27/16, 7:58 AM, "dev on behalf of Wiles, Keith" > dpdk.org on behalf of keith.wiles at intel.com> wrote:
>> 
>> >
>> >On 6/27/16, 3:46 AM, "Richardson, Bruce"  
>> >wrote:
>> >
>> >>On Sun, Jun 26, 2016 at 10:54:12AM -0500, Keith Wiles wrote:
>> >>> Latest clang compiler 3.8.0 on latest update of Ubuntu
>> >>> creates a few more warnings on -Warray-bounds and extra
>> >>> () around 'if' expressions.
>> >>> 
>> >>> Signed-off-by: Keith Wiles 
>> >>> ---
>> >>>  app/test-pmd/Makefile| 3 +++
>> >>>  app/test/Makefile| 3 +++
>> >>>  drivers/net/bonding/Makefile | 4 
>> >>>  drivers/net/fm10k/Makefile   | 2 ++
>> >>>  drivers/net/i40e/Makefile| 2 ++
>> >>>  lib/librte_cmdline/Makefile  | 6 ++
>> >>>  lib/librte_eal/linuxapp/eal/Makefile | 8 
>> >>>  7 files changed, 28 insertions(+)
>> >>> 
>> >>All the fixes in this patch seem to be just disabling the compiler 
>> >>warnings, which
>> >>should really be the last resort in cases like this. Can some of the 
>> >>issues be
>> >>fixed by actually fixing the issues in the code?
>> >
>> >I did look at the code to fix the problem, because I could not see one:
>> >
>> >/work/home/rkwiles/projects/intel/dpdk/app/test-pmd/cmdline.c:3357:2140: 
>> >error: array index 3 is past the end of the array (which contains 3 
>> >elements) [-Werror,-Warray-bounds]
>> >  if (!__extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p 
>> > (res->proto) && __builtin_constant_p ("ip") && (__s1_len = 
>> > __builtin_strlen (res->proto), __s2_len = __builtin_strlen ("ip"), 
>> > (!((size_t)(const void *)((res->proto) + 1) - (size_t)(const void 
>> > *)(res->proto) == 1) || __s1_len >= 4) && (!((size_t)(const void *)(("ip") 
>> > + 1) - (size_t)(const void *)("ip") == 1) || __s2_len >= 4)) ? 
>> > __builtin_strcmp (res->proto, "ip") : (__builtin_constant_p (res->proto) 
>> > && ((size_t)(const void *)((res->proto) + 1) - (size_t)(const void 
>> > *)(res->proto) == 1) && (__s1_len = __builtin_strlen (res->proto), 
>> > __s1_len < 4) ? (__builtin_constant_p ("ip") && ((size_t)(const void 
>> > *)(("ip") + 1) - (size_t)(const void *)("ip") == 1) ? __builtin_strcmp 
>> > (res->proto, "ip") : (__extension__ ({ const unsigned char *__s2 = (const 
>> > unsigned char *) (const char *) ("ip"); int __result = (((const unsigned 
>> > char *) (const char *) (res->proto))[0] - __s2[0]); if (__s1_len > 0 && 
>> > __result == 0) { __result = (((const unsigned char *) (const char *) 
>> > (res->proto))[1] - __s2[1]); if (__s1_len > 1 && __result == 0) { __result 
>> > = (((const unsigned char *) (const char *) (res->proto))[2] - __s2[2]); if 
>> > (__s1_len > 2 && __result == 0) __result = (((const unsigned char *) 
>> > (const char *) (res->proto))[3] - __s2[3]); } } __result; }))) : 
>> > (__builtin_constant_p ("ip") && ((size_t)(const void *)(("ip") + 1) - 
>> > (size_t)(const void *)("ip") == 1) && (__s2_len = __builtin_strlen ("ip"), 
>> > __s2_len < 4) ? (__builtin_constant_p (res->proto) && ((size_t)(const void 
>> > *)((res->proto) + 1) - (size_t)(const void *)(res->proto) == 1) ? 
>> > __builtin_strcmp (res->proto, "ip") : (- (__extension__ ({ const unsigned 
>> > char *__s2 = (const unsigned char *) (const char *) (res->proto); int 
>> > __result = (((const unsigned char *) (const char *) ("ip"))[0] - __s2[0]); 
>> > if (__s2_len > 0 && __result == 0) { __result = (((const unsigned char *) 
>> > (const char *) ("ip"))[1] - __s2[1]); if (__s2_len > 1 && __result == 0) { 
>> > __result = (((const unsigned char *) (const char *) ("ip"))[2] - __s2[2]); 
>> > if (__s2_len > 2 && __result == 0) __result = (((const unsigned char *) 
>> > (const char *) ("ip"))[3] - __s2[3]); } } __result; } : 
>> > __builtin_strcmp (res->proto, "ip"; })) {
>> >
>> >Here is the line of code for that one:
>> >if (!strcmp(res->proto, "ip")) {
>> >
>> >The ?Wno-parenthese-equality problem gives the output here:
>> >
>> >/work/home/rkwiles/projects/intel/dpdk/lib/librte_cmdline/cmdline_cirbuf.c:288:19:
>> > error: equality comparison with extraneous parentheses 
>> >[-Werror,-Wparentheses-equality]
>> > if (((cbuf)->len == 0)) {
>> >
>> >The line is:
>> >
>> >if (CIRBUF_IS_EMPTY(cbuf)) {
>> >
>> >This one is in cmdline_cirbuf.h, which can be changed, but I do not think 
>> >we need to remove the parenthese.
>> >
>> >I will look at some of other solution, so I rejected the patch.
>> 
>> I found the problem to the compile errors I am seeing with building with 
>> clang and shared libraries.
>> 
>> The x86_64-linux-gnu/bits/string2.h header file if getting included from 
>> string.h, but this would be mean __GNUC__ is defined and this is the clang 
>> compiler. After much investigation it turns out ?ccache? is the problem 
>> here. If ccache is enabled with clang builds the 

[dpdk-dev] [PATCH v5 0/5] fix issues in packet capture framework

[Thomas Monjalon]

> Reshma Pattan (5):
>   pdump: fix default socket path
>   pdump: check getenv return value
>   pdump: fix string overflow
>   app/pdump: fix string overflow
>   app/pdump: fix type casting of ring size

Applied, thanks

[dpdk-dev] [PATCH] app/test: avoid freeing mbufs twice in qat test

[Thomas Monjalon]

> > Test_multi_session was freeing mbufs used in the multiple sessions created
> > and setting obuf to NULL after it, but ibuf was not being set to NULL, and
> > therefore, it was being freed again (ibuf and obuf are pointing at the same
> > address), in the ut_teardown() function.
> > 
> > Fixes: 1b9cb73ecef1 ("app/test: fix qat autotest failure")
> > 
> > Signed-off-by: Pablo de Lara 
> Acked-by: Deepak K Jain 

Applied, thanks

[dpdk-dev] [PATCH v2] mbuf:rearrange mbuf to be more mbuf chain friendly

[Thomas Monjalon]

2016-06-27 13:06, Wiles, Keith:
> 
> On 6/27/16, 4:05 AM, "Thomas Monjalon"  wrote:
> 
> >2016-06-27 10:27, Olivier Matz:
> >> On 06/27/2016 10:21 AM, Ananyev, Konstantin wrote:
> >> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Keith Wiles
> >> >> Move the next pointer to the first cacheline of the rte_mbuf structure
> >> >> and move the offload values to the second cacheline to give better
> >> >> performance to applications using chained mbufs.
> >> >>
> >> >> Enabled by a configuration option CONFIG_RTE_MBUF_CHAIN_FRIENDLY default
> >> >> is set to No.
> >> > 
> >> > First, it would make ixgbe and i40e vector RX functions to work 
> >> > incorrectly.
> >> > Second, I don't think we can afford to allow people swap mbuf fields in 
> >> > the way they like.
> >> > Otherwise we'll end-up with totally unmaintainable code pretty soon.
> >> > So NACK.  
> >> 
> >> +1
> >
> >To be more precise, the arrangement of fields in rte_mbuf is open
> >to debate and changes.
> >There is a recent discussion here:
> > http://dpdk.org/ml/archives/dev/2016-May/039483.html
> >
> >I think we must try to improve few things in mbuf during the 16.11 cycle.
> >But it must not be allowed to have a build option to adapt this structure
> >or any other API. There is only one DPDK API for a given version.
> 
> I just received a private email thread on this one and it appears it is not a 
> big of a problem as was stated before. ? So yes we can reject this one.
> 
> Someone rejected these in patchwork already, which I expected I would be the 
> one to reject the patches. Is this not the case? I understand if the patch 
> just hangs round, but I would have expected after the list rejected the patch 
> I would be the one to reject the patches. I try to keep up with my patches 
> and rejecting a patch before I have a chance to do so seems a bit harsh to me.

Yes it's me, sorry I've been quick when I've seen the first 2 comments.

[dpdk-dev] [PATCH v2 2/2] fix building with clang-3.8.0 compiler

[Wiles, Keith]

On 6/27/16, 7:58 AM, "dev on behalf of Wiles, Keith"  wrote:

>
>On 6/27/16, 3:46 AM, "Richardson, Bruce"  wrote:
>
>>On Sun, Jun 26, 2016 at 10:54:12AM -0500, Keith Wiles wrote:
>>> Latest clang compiler 3.8.0 on latest update of Ubuntu
>>> creates a few more warnings on -Warray-bounds and extra
>>> () around 'if' expressions.
>>> 
>>> Signed-off-by: Keith Wiles 
>>> ---
>>>  app/test-pmd/Makefile| 3 +++
>>>  app/test/Makefile| 3 +++
>>>  drivers/net/bonding/Makefile | 4 
>>>  drivers/net/fm10k/Makefile   | 2 ++
>>>  drivers/net/i40e/Makefile| 2 ++
>>>  lib/librte_cmdline/Makefile  | 6 ++
>>>  lib/librte_eal/linuxapp/eal/Makefile | 8 
>>>  7 files changed, 28 insertions(+)
>>> 
>>All the fixes in this patch seem to be just disabling the compiler warnings, 
>>which
>>should really be the last resort in cases like this. Can some of the issues be
>>fixed by actually fixing the issues in the code?
>
>I did look at the code to fix the problem, because I could not see one:
>
>/work/home/rkwiles/projects/intel/dpdk/app/test-pmd/cmdline.c:3357:2140: 
>error: array index 3 is past the end of the array (which contains 3 elements) 
>[-Werror,-Warray-bounds]
>  if (!__extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p 
> (res->proto) && __builtin_constant_p ("ip") && (__s1_len = __builtin_strlen 
> (res->proto), __s2_len = __builtin_strlen ("ip"), (!((size_t)(const void 
> *)((res->proto) + 1) - (size_t)(const void *)(res->proto) == 1) || __s1_len 
> >= 4) && (!((size_t)(const void *)(("ip") + 1) - (size_t)(const void *)("ip") 
> == 1) || __s2_len >= 4)) ? __builtin_strcmp (res->proto, "ip") : 
> (__builtin_constant_p (res->proto) && ((size_t)(const void *)((res->proto) + 
> 1) - (size_t)(const void *)(res->proto) == 1) && (__s1_len = __builtin_strlen 
> (res->proto), __s1_len < 4) ? (__builtin_constant_p ("ip") && ((size_t)(const 
> void *)(("ip") + 1) - (size_t)(const void *)("ip") == 1) ? __builtin_strcmp 
> (res->proto, "ip") : (__extension__ ({ const unsigned char *__s2 = (const 
> unsigned char *) (const char *) ("ip"); int __result = (((const unsigned char 
> *) (const char *) (res->proto))[0] - __s2[0]); if (__s1_len > 0 && __result 
> == 0) { __result = (((const unsigned char *) (const char *) (res->proto))[1] 
> - __s2[1]); if (__s1_len > 1 && __result == 0) { __result = (((const unsigned 
> char *) (const char *) (res->proto))[2] - __s2[2]); if (__s1_len > 2 && 
> __result == 0) __result = (((const unsigned char *) (const char *) 
> (res->proto))[3] - __s2[3]); } } __result; }))) : (__builtin_constant_p 
> ("ip") && ((size_t)(const void *)(("ip") + 1) - (size_t)(const void *)("ip") 
> == 1) && (__s2_len = __builtin_strlen ("ip"), __s2_len < 4) ? 
> (__builtin_constant_p (res->proto) && ((size_t)(const void *)((res->proto) + 
> 1) - (size_t)(const void *)(res->proto) == 1) ? __builtin_strcmp (res->proto, 
> "ip") : (- (__extension__ ({ const unsigned char *__s2 = (const unsigned char 
> *) (const char *) (res->proto); int __result = (((const unsigned char *) 
> (const char *) ("ip"))[0] - __s2[0]); if (__s2_len > 0 && __result == 0) { 
> __result = (((const unsigned char *) (const char *) ("ip"))[1] - __s2[1]); if 
> (__s2_len > 1 && __result == 0) { __result = (((const unsigned char *) (const 
> char *) ("ip"))[2] - __s2[2]); if (__s2_len > 2 && __result == 0) __result = 
> (((const unsigned char *) (const char *) ("ip"))[3] - __s2[3]); } } __result; 
> } : __builtin_strcmp (res->proto, "ip"; })) {
>
>Here is the line of code for that one:
>if (!strcmp(res->proto, "ip")) {
>
>The ?Wno-parenthese-equality problem gives the output here:
>
>/work/home/rkwiles/projects/intel/dpdk/lib/librte_cmdline/cmdline_cirbuf.c:288:19:
> error: equality comparison with extraneous parentheses 
>[-Werror,-Wparentheses-equality]
> if (((cbuf)->len == 0)) {
>
>The line is:
>
>if (CIRBUF_IS_EMPTY(cbuf)) {
>
>This one is in cmdline_cirbuf.h, which can be changed, but I do not think we 
>need to remove the parenthese.
>
>I will look at some of other solution, so I rejected the patch.

I found the problem to the compile errors I am seeing with building with clang 
and shared libraries.

The x86_64-linux-gnu/bits/string2.h header file if getting included from 
string.h, but this would be mean __GNUC__ is defined and this is the clang 
compiler. After much investigation it turns out ?ccache? is the problem here. 
If ccache is enabled with clang builds the __GNUC__ is defined some how, I 
never did find the location.

Just a warning it appears ?ccache? for caching object files is not compatible 
with DPDK builds ? in all cases.

>
>
>>
>>/Bruce
>>
>
>
>
>

[dpdk-dev] [PATCH v3 4/5] testpmd: handle all rxqs in rss setup

[Nélio Laranjeiro]

On Tue, Jun 14, 2016 at 07:08:05PM -0400, Zhihong Wang wrote:
> This patch removes constraints in rxq handling when multiqueue is enabled
> to handle all the rxqs.
> 
> Current testpmd forces a dedicated core for each rxq, some rxqs may be
> ignored when core number is less than rxq number, and that causes confusion
> and inconvenience.
> 
> One example: One Red Hat engineer was doing multiqueue test, there're 2
> ports in guest each with 4 queues, and testpmd was used as the forwarding
> engine in guest, as usual he used 1 core for forwarding, as a results he
> only saw traffic from port 0 queue 0 to port 1 queue 0, then a lot of
> emails and quite some time are spent to root cause it, and of course it's
> caused by this unreasonable testpmd behavior.  
> 
> Moreover, even if we understand this behavior, if we want to test the
> above case, we still need 8 cores for a single guest to poll all the
> rxqs, obviously this is too expensive.
> 
> We met quite a lot cases like this, one recent example:
> http://openvswitch.org/pipermail/dev/2016-June/072110.html
> 
> 
> Signed-off-by: Zhihong Wang 
> ---
>  app/test-pmd/config.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> index ede7c78..4719a08 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -1199,19 +1199,13 @@ rss_fwd_config_setup(void)
>   cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>   cur_fwd_config.nb_fwd_streams =
>   (streamid_t) (nb_q * cur_fwd_config.nb_fwd_ports);
> - if (cur_fwd_config.nb_fwd_streams > cur_fwd_config.nb_fwd_lcores)
> - cur_fwd_config.nb_fwd_streams =
> - (streamid_t)cur_fwd_config.nb_fwd_lcores;
> - else
> - cur_fwd_config.nb_fwd_lcores =
> - (lcoreid_t)cur_fwd_config.nb_fwd_streams;
>  
>   /* reinitialize forwarding streams */
>   init_fwd_streams();
>  
>   setup_fwd_config_of_each_lcore(_fwd_config);
>   rxp = 0; rxq = 0;
> - for (lc_id = 0; lc_id < cur_fwd_config.nb_fwd_lcores; lc_id++) {
> + for (lc_id = 0; lc_id < cur_fwd_config.nb_fwd_streams; lc_id++) {
>   struct fwd_stream *fs;
>  
>   fs = fwd_streams[lc_id];
> -- 
> 2.5.0

Hi Zhihong,

It seems this commits introduce a bug in pkt_burst_transmit(), this only
occurs when the number of cores present in the coremask is greater than
the number of queues i.e. coremask=0xffe --txq=4 --rxq=4.

  Port 0 Link Up - speed 4 Mbps - full-duplex
  Port 1 Link Up - speed 4 Mbps - full-duplex
  Done
  testpmd> start tx_first
io packet forwarding - CRC stripping disabled - packets/burst=64
nb forwarding cores=10 - nb forwarding ports=2
RX queues=4 - RX desc=256 - RX free threshold=0
RX threshold registers: pthresh=0 hthresh=0 wthresh=0
TX queues=4 - TX desc=256 - TX free threshold=0
TX threshold registers: pthresh=0 hthresh=0 wthresh=0
TX RS bit threshold=0 - TXQ flags=0x0
  Segmentation fault (core dumped)


If I start testpmd with a coremask with at most as many cores as queues,
everything works well (i.e. coremask=0xff0, or 0xf00).

Are you able to reproduce the same issue?
Note: It only occurs on dpdk/master branch (commit f2bb7ae1d204).

Regards,

-- 
N?lio Laranjeiro
6WIND

[dpdk-dev] [PATCH 2/4] virtio: introduce RTE_LIBRTE_VIRTIO_INC_VECTOR

[Thomas Monjalon]

2016-06-27 17:24, Jerin Jacob:
> --- a/config/common_base
> +++ b/config/common_base
> @@ -267,6 +267,7 @@ CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
>  CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
>  CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
>  CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
> +CONFIG_RTE_LIBRTE_VIRTIO_INC_VECTOR=y

I don't remember what means INC_VECTOR?
Why a config option is needed for vector implementations?

[dpdk-dev] [PATCH] e1000/base: Add missing braces to the 'if' statements

[Bruce Richardson]

On Fri, Jun 24, 2016 at 08:31:05AM +, Lu, Wenzhuo wrote:
> Hi Thomas, Markos,
> 
> 
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Friday, June 24, 2016 3:13 PM
> > To: Lu, Wenzhuo
> > Cc: dev at dpdk.org; Markos Chandras
> > Subject: Re: [dpdk-dev] [PATCH] e1000/base: Add missing braces to the 'if'
> > statements
> > 
> > 2016-06-24 00:43, Lu, Wenzhuo:
> > > Thanks for this patch. But normally the code in the base directory is 
> > > synced
> > from the kernel driver. So we don't change it if there's no critical issue. 
> > It's easy
> > for us to maintain it. Thanks.
> > 
> > I think a build error is critical enough.
> OK. The change itself looks fine to me.

Applied to dpdk-next-net/rel_16_07

/Bruce

[dpdk-dev] [PATCH] e1000/base: Add missing braces to the 'if' statements

[Bruce Richardson]

On Thu, Jun 23, 2016 at 10:25:52AM +0100, Markos Chandras wrote:
> Add the missing braces to the 'if' statements to fix the misleading
> identation. This also fixes the following build errors when building
> with gcc >= 6:
> 
> drivers/net/e1000/base/e1000_phy.c:4156:2:
> error: this 'if' clause does not guard... [-Werror=misleading-indentation]
> if (locked)
> ^~
> 
> drivers/net/e1000/base/e1000_phy.c:4158:3:
> note: ...this statement, but the latter is misleadingly indented as if it is 
> guarded by the 'if'
> if (!ready)
> ^~
> 
> drivers/net/e1000/base/e1000_phy.c: In function 'e1000_write_phy_reg_mphy':
> drivers/net/e1000/base/e1000_phy.c:4221:2:
> error: this 'if' clause does not guard... [-Werror=misleading-indentation]
> if (locked)
> ^~
> 
> drivers/net/e1000/base/e1000_phy.c:4223:3:
> note: ...this statement, but the latter is misleadingly indented as if it is 
> guarded by the 'if'
> if (!ready)
> ^~
> 
> Signed-off-by: Markos Chandras 
> ---

Any particular compiler flags needed to reproduce this issue? Compiling with
gcc6.1 I don't see any errors reported.

/Bruce

[dpdk-dev] [PATCH v4 00/29] ixgbe/base: update base driver

[Bruce Richardson]

On Thu, Jun 23, 2016 at 03:22:08PM +0800, Beilei Xing wrote:
> Update base driver for ixgbe, mainly work on new features and bug fixes.
> 
> v4 changes:
>  Update some commit logs.
>  Merge related patched.
> v3 changes:
>  Fix some commit log issues.
> 
Applied to dpdk-next-net/rel_16_07

/Bruce

[dpdk-dev] [PATCH v14 2/2] i40e: add floating VEB support in i40e

[Zhe Tao]

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

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

The floating VEB feature is only available for the FW version which
newer than 5.0 (FW major version number > 5).

Signed-off-by: Zhe Tao 
---
 doc/guides/nics/i40e.rst   |  27 
 doc/guides/rel_notes/release_16_07.rst |   4 ++
 drivers/net/i40e/i40e_ethdev.c | 112 ++---
 drivers/net/i40e/i40e_ethdev.h |   2 +
 drivers/net/i40e/i40e_pf.c |  12 +++-
 5 files changed, 134 insertions(+), 23 deletions(-)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 934eb02..1ce60ab 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -366,3 +366,30 @@ Delete all flow director rules on a port:

testpmd> flush_flow_director 0

+Floating VEB
+~
+FVL can support floating VEB feature.
+
+The floating VEB means the VEB doesn't has some uplink connection to the 
outside
+world, so all the switching belong to this VEB cannot go to outside, the
+security can be assured. Because the floating VEB doesn't need to connect to
+the MAC port, so when the physical port link is down, all the switching within
+this VEB still works fine, but for legacy VEB when the physical port is down
+the VEB cannot forward packets anymore.
+
+With this feature, VFs can communicate with each other, but cannot access
+outside network. When PF is down, and VFs can still forward pkts between each
+other.
+
+To enable this feature, the user should pass a devargs parameter to the EAL
+like "-w 84:00.0,enable_floating_veb=1", and then the PMD will use the floating
+VEB feature for all the VFs created by this PF device.
+Also you can specify which VF need to connect to this floating veb using
+"floating_veb_list".
+Like "-w 84:00.0,enable_floating_veb=1,floating_veb_list=1/3-4", means VF1, 
VF3,
+VF4 connect to the floating VEB, other VFs connect to the legacy VEB.The "/"
+is used for delimiter of the floating VEB list.
+
+The current implementation only support one floating VEB and one legacy
+VEB. VF can connect to floating VEB or legacy VEB according to the
+configuration.
diff --git a/doc/guides/rel_notes/release_16_07.rst 
b/doc/guides/rel_notes/release_16_07.rst
index 30e78d4..1752c40 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -47,6 +47,10 @@ New Features
   * Dropped specific Xen Dom0 code.
   * Dropped specific anonymous mempool code in testpmd.

+* **Added floating VEB support for i40e PF driver.**
+
+  More details please see floating VEB part in the document
+  doc/guides/nics/i40e.rst.

 Resolved Issues
 ---
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 553ef56..b6abd1c 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3878,21 +3878,27 @@ i40e_veb_release(struct i40e_veb *veb)
struct i40e_vsi *vsi;
struct i40e_hw *hw;

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

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

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

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

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

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

veb->associate_vsi = vsi;
+   veb->associate_pf = pf;
TAILQ_INIT(>head);
-   veb->uplink_seid = vsi->uplink_seid;
+   

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

[Zhe Tao]

Add the new floating related argument option in the devarg.
Using this parameter, all the applications can decide whether to use legacy
VEB/VEPA or floating VEB.
To enable this feature, the user should pass a devargs parameter to the
EAL like "-w 84:00.0,enable_floating_veb=1", and the application will
tell PMD whether to use the floating VEB feature or not.
Once the floating VEB feature is enabled, all the VFs created by
this PF device are connected to the floating VEB.

All the VEB/VEPA concepts are not specific for FVL, they are defined in
the 802.1Qbg spec. But the floating VEB concept is from i40e data sheet.

The standard VEB definition in 1Qbg is a bridge which has a uplink port
to the outside world (maybe another bridge), but floating means this
special VEB has no uplink port to the outside.

For floating VEB, it has two major difference comparing to
the standard VEB:
1. doesn't has a up link connection which means
the traffic cannot go to outside world.
2. doesn't need to connect to the physical port which means
when the physical link is down the floating VEB can still works
fine.

Signed-off-by: Zhe Tao 
---
 drivers/net/i40e/i40e_ethdev.c | 160 +
 drivers/net/i40e/i40e_ethdev.h |  10 +++
 2 files changed, 170 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 24777d5..553ef56 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -63,6 +63,9 @@
 #include "i40e_pf.h"
 #include "i40e_regs.h"

+#define ETH_I40E_FLOATING_VEB_ARG  "enable_floating_veb"
+#define ETH_I40E_FLOATING_VEB_LIST_ARG "floating_veb_list"
+
 #define I40E_CLEAR_PXE_WAIT_MS 200

 /* Maximun number of capability elements */
@@ -751,6 +754,161 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf *pf)
 }

 static int
+floating_veb_list_handler(__rte_unused const char *key,
+ const char *floating_veb_value,
+ void *opaque)
+{
+   int idx = 0;
+   unsigned count = 0;
+   char *end = NULL;
+   int min, max;
+   bool *vf_floating_veb = opaque;
+
+   while (isblank(*floating_veb_value))
+   floating_veb_value++;
+
+   /* Reset floating VEB configuration for VFs */
+   for (idx = 0; idx < I40E_MAX_VF; idx++)
+   vf_floating_veb[idx] = false;
+
+   min = I40E_MAX_VF;
+   do {
+   while (isblank(*floating_veb_value))
+   floating_veb_value++;
+   if (*floating_veb_value == '\0')
+   return -1;
+   errno = 0;
+   idx = strtoul(floating_veb_value, , 10);
+   if (errno || end == NULL)
+   return -1;
+   while (isblank(*end))
+   end++;
+   if (*end == '-') {
+   min = idx;
+   } else if ((*end == '/') || (*end == '\0')) {
+   max = idx;
+   if (min == I40E_MAX_VF)
+   min = idx;
+   if (max >= I40E_MAX_VF)
+   max = I40E_MAX_VF - 1;
+   for (idx = min; idx <= max; idx++) {
+   vf_floating_veb[idx] = true;
+   count++;
+   }
+   min = I40E_MAX_VF;
+   } else {
+   return -1;
+   }
+   floating_veb_value = end + 1;
+   } while (*end != '\0');
+
+   if (count == 0)
+   return -1;
+
+   return 0;
+}
+
+static void
+config_vf_floating_veb(struct rte_devargs *devargs,
+  uint16_t floating_veb,
+  bool *vf_floating_veb)
+{
+   struct rte_kvargs *kvlist;
+   int i;
+   const char *floating_veb_list = ETH_I40E_FLOATING_VEB_LIST_ARG;
+
+   if (floating_veb == false)
+   return;
+   /* All the VFs attach to the floating VEB by default
+* when the floating VEB is enabled.
+*/
+   for (i = 0; i < I40E_MAX_VF; i++)
+   vf_floating_veb[i] = true;
+
+   if (devargs == NULL)
+   return;
+
+   kvlist = rte_kvargs_parse(devargs->args, NULL);
+   if (kvlist == NULL)
+   return;
+
+   if (!rte_kvargs_count(kvlist, floating_veb_list)) {
+   rte_kvargs_free(kvlist);
+   return;
+   }
+   /* When the floating_veb_list parameter exists, all the VFs
+* will attach to the legacy VEB firstly, then configure VFs
+* to the floating VEB according to the floating_veb_list.
+*/
+   if (rte_kvargs_process(kvlist, floating_veb_list,
+  floating_veb_list_handler,
+  vf_floating_veb) < 0) {
+   rte_kvargs_free(kvlist);
+   return;
+   }
+   

[dpdk-dev] [PATCH v14 0/2] i40e: add floating VEB support for i40e

[Zhe Tao]

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

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

This floating VEB only take effects on the specific version F/W which newer
than 5.0.

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

 doc/guides/nics/i40e.rst   |  27 
 doc/guides/rel_notes/release_16_07.rst |   4 +
 drivers/net/i40e/i40e_ethdev.c | 272 ++---
 drivers/net/i40e/i40e_ethdev.h |  12 ++
 drivers/net/i40e/i40e_pf.c |  12 +-
 5 files changed, 304 insertions(+), 23 deletions(-)

V2: Added the release notes and changed commit log. 
V3: Changed the VSI release operation. 
V4: Added the FW version check otherwise it will cause the segment fault.
V5: Edited the code for new share code APIs
V6: Changed the floating VEB configuration method 
V7: Added global reset for i40e 
V8: removed global reset and added floating VEB extension support 
V9: Added floating VEB related explanation into commit log 
V10: Changed third patch commit log 
V11: Fixed the issues reported by check-git-log.sh 
V12: Changed the floating VEB VF bitmask to VF list 
V13: Changed some internal functions'names to make it more clear 
V14: Changed some internal variable names 

-- 
2.1.4

[dpdk-dev] [RFC] librte_vhost: Add unix domain socket fd registration

[Aaron Conole]

Yuanhan Liu  writes:

> On Fri, Jun 24, 2016 at 08:23:52AM -0400, Aaron Conole wrote:
>> Is there still merit to this patch, given above?  If so, I'd finish my
>> integration and testing work and submit it formally.
>
> Sorry, I don't see the strong need of this patch (at least so far),
> judging that vhost-user as the client could solve the issue your
> patch meant to resolve.

Okay, thanks so much for the review and consideration, Yuanhan!

-Aaron

[dpdk-dev] dpdk config on VM

[Raja Jayapal]

Hi All,

I am tyrying to install dpdk on ubuntu and test the applications.
I have successfully installed dpdk on Host as per the instruction guide , but 
little bit confused on how to bind it with VM.

VM1(TrafficGen)--Host(DPDK)--VM2(Receiver)

Do we need to install ovs to test the flows for the above scenarios?.
I did search a lot, but didnt get clear idea like how to do config on VM side.
Please point out some config/installation guide for the same.


Thanks in Advance,
Raja
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

[dpdk-dev] [PATCH v7 22/25] mlx5: work around spurious compilation errors

[Adrien Mazarguil]

On Mon, Jun 27, 2016 at 01:12:15PM +0100, Bruce Richardson wrote:
> On Fri, Jun 24, 2016 at 03:18:01PM +0200, Nelio Laranjeiro wrote:
> > From: Adrien Mazarguil 
> > 
> > Since commit "mlx5: resurrect Tx gather support", older GCC versions (such
> > as 4.8.5) may complain about the following:
> > 
> >  mlx5_rxtx.c: In function `mlx5_tx_burst':
> >  mlx5_rxtx.c:705:25: error: `wqe' may be used uninitialized in this
> >  function [-Werror=maybe-uninitialized]
> > 
> >  mlx5_rxtx.c: In function `mlx5_tx_burst_inline':
> >  mlx5_rxtx.c:864:25: error: `wqe' may be used uninitialized in this
> >  function [-Werror=maybe-uninitialized]
> > 
> > In both cases, this code cannot be reached when wqe is not initialized.
> > 
> > Considering older GCC versions are still widely used, work around this
> > issue by initializing wqe preemptively, even if it should not be necessary.
> > 
> > Signed-off-by: Adrien Mazarguil 
> 
> Since the previous patch is known to break the build on older compilers, I 
> think
> it would be better to merge this patch into the previous to prevent the break
> from occurring in the first place. That will help with any future git-bisects
> that people run.

Makes sense, in fact I only kept it separate to decribe why setting these
variables was necessary, in case someone wondered.

> If there is no objection, and no other issues appear requiring a new rev of
> this patchset, I'll merge patches 21 and 22 on apply.

That's fine by me.

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v7 17/25] mlx5: add support for inline send

[Nélio Laranjeiro]

On Mon, Jun 27, 2016 at 01:17:42PM +0100, Bruce Richardson wrote:
> On Fri, Jun 24, 2016 at 03:17:56PM +0200, Nelio Laranjeiro wrote:
> > From: Yaacov Hazan 
> > 
> > Implement send inline feature which copies packet data directly into WQEs
> > for improved latency. The maximum packet size and the minimum number of Tx
> > queues to qualify for inline send are user-configurable.
> > 
> 
> WQE?

WQE is a Work Queue Entry.

-- 
N?lio Laranjeiro
6WIND

[dpdk-dev] [PATCH v14 0/2] i40e: add floating VEB support for i40e

[Ferruh Yigit]

On 6/27/2016 8:20 AM, Zhe Tao wrote:
> This patch-set add the support for floating VEB in i40e.
> All the VFs VSIs can decide whether to connect to the legacy VEB/VEPA or
> the floating VEB. When connect to the floating VEB a new floating VEB is
> created. Now all the VFs need to connect to floating VEB or legacy VEB,
> cannot connect to both of them. The PF and VMDQ,FD VSIs connect to
> the old legacy VEB/VEPA.
> 
> All the VEB/VEPA concepts are not specific for FVL, they are defined in the
> 802.1Qbg spec.
> 
> This floating VEB only take effects on the specific version F/W which newer
> than 5.0.
> 
> Zhe Tao (2):
>   i40e: support floating VEB config
>   i40e: add floating VEB support in i40e

Series reviewed-by: Ferruh Yigit 

[dpdk-dev] [PATCH] ixgbe:enable configuration for old ptype behavior

[Zoltan Kiss]

Hi,

On 27/06/16 09:00, Ananyev, Konstantin wrote:
>> The default behavior is to NOT support the old ptype behavior,
>> but enabling the configuration option the old ptype style
>> can be supported.
>>
>> Add support for old behaviour until we have a cleaner solution using
>> a configuration option CONFIG_RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOUR,
>> which is defaulted to not set.
>
> I think it was explained why we had to diable ptype recognition for vRX, 
> please see here:
> http://dpdk.org/browse/dpdk/commit/drivers/net/ixgbe/ixgbe_rxtx_vec.c?id=d9a2009a81089093645fea2e04b51dd37edf3e6f
> I think that introducing a compile time option to re-enable incomplete
> and not fully correct functionality is a very bad approach.

Btw. I wanted to ask, is there a plan to fix vector RX to set ptype?



> So NACK.
> Konstantin
>
>>
>> Signed-off-by: Keith Wiles 
>> ---
>>   config/common_base |  2 ++
>>   drivers/net/ixgbe/ixgbe_ethdev.c   |  6 +
>>   drivers/net/ixgbe/ixgbe_rxtx_vec.c | 52 
>> +++---
>>   3 files changed, 57 insertions(+), 3 deletions(-)
>>
>> diff --git a/config/common_base b/config/common_base
>> index bdde2e7..05e69bc 100644
>> --- a/config/common_base
>> +++ b/config/common_base
>> @@ -160,6 +160,8 @@ CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
>>   CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
>>   CONFIG_RTE_IXGBE_INC_VECTOR=y
>>   CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
>> +# Enable to restore old ptype behavior
>> +CONFIG_RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOR=n
>>
>>   #
>>   # Compile burst-oriented I40E PMD driver
>> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
>> b/drivers/net/ixgbe/ixgbe_ethdev.c
>> index e11a431..068b92b 100644
>> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
>> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
>> @@ -3076,7 +3076,13 @@ 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 ||
>> +#ifdef RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOR
>> +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)
>> +#else
>>  dev->rx_pkt_burst == ixgbe_recv_pkts_bulk_alloc)
>> +#endif
>>  return ptypes;
>>  return NULL;
>>   }
>> diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c 
>> b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
>> index 12190d2..2e0d50b 100644
>> --- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
>> +++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
>> @@ -228,6 +228,10 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct 
>> rte_mbuf **rx_pkts,
>>  );
>>  __m128i dd_check, eop_check;
>>  uint8_t vlan_flags;
>> +#ifdef RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOR
>> +__m128i desc_mask = _mm_set_epi32(0x, 0x,
>> +  0x, 0x07F0);
>> +#endif
>>
>>  /* nb_pkts shall be less equal than RTE_IXGBE_MAX_RX_BURST */
>>  nb_pkts = RTE_MIN(nb_pkts, RTE_IXGBE_MAX_RX_BURST);
>> @@ -268,8 +272,14 @@ _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 */
>> +#ifdef RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOR
>> +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 */
>> +#else
>>  0xFF, 0xFF,  /* skip 32 bit pkt_type */
>>  0xFF, 0xFF
>> +#endif
>>  );
>>
>>  /* Cache is empty -> need to scan the buffer rings, but first move
>> @@ -291,6 +301,9 @@ _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) {
>> +#ifdef RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOR
>> +__m128i descs0[RTE_IXGBE_DESCS_PER_LOOP];
>> +#endif
>>  __m128i descs[RTE_IXGBE_DESCS_PER_LOOP];
>>  __m128i pkt_mb1, pkt_mb2, pkt_mb3, pkt_mb4;
>>  __m128i zero, staterr, sterr_tmp1, sterr_tmp2;
>> @@ -301,18 +314,30 @@ _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 */
>> +#ifdef RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOR
>> +descs0[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));
>> +#else
>>  descs[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));
>> -
>> +#endif
>>  /* B.2 copy 2 mbuf point into rx_pkts  */
>>

[dpdk-dev] [PATCH 2/3] cmdline: remove duplicated symbols from .map

[Ferruh Yigit]

Fixes: 9d41beed24b0 ("lib: provide initial versioning")
Signed-off-by: Ferruh Yigit 
---
 lib/librte_cmdline/rte_cmdline_version.map | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/librte_cmdline/rte_cmdline_version.map 
b/lib/librte_cmdline/rte_cmdline_version.map
index c9fc18a..04bcb38 100644
--- a/lib/librte_cmdline/rte_cmdline_version.map
+++ b/lib/librte_cmdline/rte_cmdline_version.map
@@ -50,7 +50,6 @@ DPDK_2.0 {
cmdline_token_num_ops;
cmdline_token_portlist_ops;
cmdline_token_string_ops;
-   cmdline_token_string_ops;
cmdline_write_char;
rdline_add_history;
rdline_char_in;
-- 
2.5.5

[dpdk-dev] [PATCH 1/3] ethdev: remove duplicated symbols from .map

[Ferruh Yigit]

Fixes: 19b16e2f6442 ("ethdev: add vlan type when setting ether type")
Signed-off-by: Ferruh Yigit 
---
 lib/librte_ether/rte_ether_version.map | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/librte_ether/rte_ether_version.map 
b/lib/librte_ether/rte_ether_version.map
index 97ed0b0..e1ccebe 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -66,7 +66,6 @@ DPDK_2.2 {
rte_eth_dev_set_vf_rxmode;
rte_eth_dev_set_vf_tx;
rte_eth_dev_set_vf_vlan_filter;
-   rte_eth_dev_set_vlan_ether_type;
rte_eth_dev_set_vlan_offload;
rte_eth_dev_set_vlan_pvid;
rte_eth_dev_set_vlan_strip_on_queue;
-- 
2.5.5

[dpdk-dev] [PATCH 1/3] ethdev: remove duplicated symbols from .map

[Ferruh Yigit]

On 6/27/2016 1:57 PM, y at ecsmtp.ir.intel.com wrote:
> From: Ferruh Yigit 
> 
> Fixes: 19b16e2f6442 ("ethdev: add vlan type when setting ether type")
> Signed-off-by: Ferruh Yigit 

Send from wrong e-mail address, although patches looks OK, I don't see
them in patchwork and will send again.

Regards,
ferruh

[dpdk-dev] [PATCH] vhost: fix missing flag reset on stop

[Yuanhan Liu]

Commit 550c9d27d143 ("vhost: set/reset device flags internally") moves
the VIRTIO_DEV_RUNNING set/reset to vhost lib. But I missed one reset
on stop; here fixes it.

Fixes: 550c9d27d143 ("vhost: set/reset device flags internally")

Reported-by: Loftus Ciara 
Signed-off-by: Yuanhan Liu 
---
 lib/librte_vhost/vhost_user/virtio-net-user.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/librte_vhost/vhost_user/virtio-net-user.c 
b/lib/librte_vhost/vhost_user/virtio-net-user.c
index a6a48dc..e7c4347 100644
--- a/lib/librte_vhost/vhost_user/virtio-net-user.c
+++ b/lib/librte_vhost/vhost_user/virtio-net-user.c
@@ -317,8 +317,10 @@ user_get_vring_base(int vid, struct vhost_vring_state 
*state)
if (dev == NULL)
return -1;
/* We have to stop the queue (virtio) if it is running. */
-   if (dev->flags & VIRTIO_DEV_RUNNING)
+   if (dev->flags & VIRTIO_DEV_RUNNING) {
+   dev->flags &= ~VIRTIO_DEV_RUNNING;
notify_ops->destroy_device(vid);
+   }

/* Here we are safe to get the last used index */
vhost_get_vring_base(vid, state->index, state);
-- 
1.9.0

[dpdk-dev] [PATCH v2] doc: update vhost guide

[Yuanhan Liu]

Mainly on updating vhost-user part: we now support client mode.
Also refine some words, and add a bit more explanation.

And made an emphatic statement that you are suggested to use vhost-user
instead of vhost-cuse, because we have enhanced vhost-user a lot since
v2.2 (Actually, I doubt there are any people still using vhost-cuse)

[John McNamara: rewords, better formats]
Signed-off-by: Yuanhan Liu 
---
 doc/guides/prog_guide/vhost_lib.rst | 223 +---
 1 file changed, 156 insertions(+), 67 deletions(-)

diff --git a/doc/guides/prog_guide/vhost_lib.rst 
b/doc/guides/prog_guide/vhost_lib.rst
index 48e1fff..14d5e67 100644
--- a/doc/guides/prog_guide/vhost_lib.rst
+++ b/doc/guides/prog_guide/vhost_lib.rst
@@ -1,5 +1,5 @@
 ..  BSD LICENSE
-Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
 All rights reserved.

 Redistribution and use in source and binary forms, with or without
@@ -31,105 +31,194 @@
 Vhost Library
 =

-The vhost library implements a user space vhost driver. It supports both 
vhost-cuse
-(cuse: user space character device) and vhost-user(user space socket server).
-It also creates, manages and destroys vhost devices for corresponding virtio
-devices in the guest. Vhost supported vSwitch could register callbacks to this
-library, which will be called when a vhost device is activated or deactivated
-by guest virtual machine.
+The vhost library implements a user space virtio net server allowing the user
+to manipulate the virtio ring directly. In another words, it allows the user
+to fetch/put packets from/to the VM virtio net device. To achieve this, a
+vhost library should be able to:
+
+* Access the guest memory:
+
+  For QEMU, this is done by using the ``-object 
memory-backend-file,share=on,...``
+  option. Which means QEMU will create a file to serve as the guest RAM.
+  The ``share=on`` option allows another process to map that file, which
+  means it can access the guest RAM.
+
+* Know all the necessary information about the vring:
+
+  Information such as where the available ring is stored. Vhost defines some
+  messages to tell the backend all the information it needs to know how to
+  manipulate the vring.
+
+Currently, there are two ways to pass these messages and as a result there are
+two Vhost implementations in DPDK: *vhost-cuse* (where the character devices
+are in user space) and *vhost-user*.
+
+Vhost-cuse creates a user space character device and hook to a function ioctl,
+so that all ioctl commands that are sent from the frontend (QEMU) will be
+captured and handled.
+
+Vhost-user creates a Unix domain socket file through which messages are
+passed.
+
+.. Note::
+
+   Since DPDK v2.2, the majority of the development effort has gone into
+   enhancing vhost-user, such as multiple queue, live migration, and
+   reconnect. Thus, it is strongly advised to use vhost-user instead of
+   vhost-cuse.
+

 Vhost API Overview
 --

-*   Vhost driver registration
+The following is an overview of the Vhost API functions:
+
+* ``rte_vhost_driver_register(path, flags)``
+
+  This function registers a vhost driver into the system. For vhost-cuse, a
+  ``/dev/path`` character device file will be created. For vhost-user server
+  mode, a Unix domain socket file ``path`` will be created.
+
+  Currently two flags are supported (these are valid for vhost-user only):
+
+  - ``RTE_VHOST_USER_CLIENT``
+
+DPDK vhost-user will act as the client when this flag is given. See below
+for an explanation.
+
+  - ``RTE_VHOST_USER_NO_RECONNECT``
+
+When DPDK vhost-user acts as the client it will keep trying to reconnect
+to the server (QEMU) until it succeeds. This is useful in two cases:
+
+* When QEMU is not started yet.
+* When QEMU restarts (for example due to a guest OS reboot).
+
+This reconnect option is enabled by default. However, it can be turned off
+by setting this flag.

-  rte_vhost_driver_register registers the vhost driver into the system.
-  For vhost-cuse, character device file will be created under the /dev 
directory.
-  Character device name is specified as the parameter.
-  For vhost-user, a Unix domain socket server will be created with the 
parameter as
-  the local socket path.
+* ``rte_vhost_driver_session_start()``

-*   Vhost session start
+  This function starts the vhost session loop to handle vhost messages. It
+  starts an infinite loop, therefore it should be called in a dedicated
+  thread.

-  rte_vhost_driver_session_start starts the vhost session loop.
-  Vhost session is an infinite blocking loop.
-  Put the session in a dedicate DPDK thread.
+* ``rte_vhost_driver_callback_register(virtio_net_device_ops)``

-*   Callback register
+  This function registers a set of callbacks, to let DPDK applications take
+  the appropriate action when some events happen. The 

[dpdk-dev] [PATCH v7 17/25] mlx5: add support for inline send

[Bruce Richardson]

On Fri, Jun 24, 2016 at 03:17:56PM +0200, Nelio Laranjeiro wrote:
> From: Yaacov Hazan 
> 
> Implement send inline feature which copies packet data directly into WQEs
> for improved latency. The maximum packet size and the minimum number of Tx
> queues to qualify for inline send are user-configurable.
> 

WQE?

[dpdk-dev] [PATCH 3/3] port: remove duplicated symbols from .map

[Dumitrescu, Cristian]

> -Original Message-
> From: Yigit, Ferruh
> Sent: Monday, June 27, 2016 2:03 PM
> To: dev at dpdk.org
> Cc: Thomas Monjalon ; Olivier Matz
> ; Dumitrescu, Cristian
> 
> Subject: [PATCH 3/3] port: remove duplicated symbols from .map
> 
> Fixes: 9d41beed24b0 ("lib: provide initial versioning")
> Signed-off-by: Ferruh Yigit 
> ---
>  lib/librte_port/rte_port_version.map | 2 --
>  1 file changed, 2 deletions(-)
> 

Acked-by: Cristian Dumitrescu 

[dpdk-dev] [PATCH v13 2/2] i40e: add floating VEB support in i40e

[Zhe Tao]

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

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

The floating VEB feature is only available for the FW version which
newer than 5.0 (FW major version number > 5).

Signed-off-by: Zhe Tao 
---
 doc/guides/nics/i40e.rst   |  27 
 doc/guides/rel_notes/release_16_07.rst |   4 ++
 drivers/net/i40e/i40e_ethdev.c | 112 ++---
 drivers/net/i40e/i40e_ethdev.h |   2 +
 drivers/net/i40e/i40e_pf.c |  12 +++-
 5 files changed, 134 insertions(+), 23 deletions(-)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 934eb02..1ce60ab 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -366,3 +366,30 @@ Delete all flow director rules on a port:

testpmd> flush_flow_director 0

+Floating VEB
+~
+FVL can support floating VEB feature.
+
+The floating VEB means the VEB doesn't has some uplink connection to the 
outside
+world, so all the switching belong to this VEB cannot go to outside, the
+security can be assured. Because the floating VEB doesn't need to connect to
+the MAC port, so when the physical port link is down, all the switching within
+this VEB still works fine, but for legacy VEB when the physical port is down
+the VEB cannot forward packets anymore.
+
+With this feature, VFs can communicate with each other, but cannot access
+outside network. When PF is down, and VFs can still forward pkts between each
+other.
+
+To enable this feature, the user should pass a devargs parameter to the EAL
+like "-w 84:00.0,enable_floating_veb=1", and then the PMD will use the floating
+VEB feature for all the VFs created by this PF device.
+Also you can specify which VF need to connect to this floating veb using
+"floating_veb_list".
+Like "-w 84:00.0,enable_floating_veb=1,floating_veb_list=1/3-4", means VF1, 
VF3,
+VF4 connect to the floating VEB, other VFs connect to the legacy VEB.The "/"
+is used for delimiter of the floating VEB list.
+
+The current implementation only support one floating VEB and one legacy
+VEB. VF can connect to floating VEB or legacy VEB according to the
+configuration.
diff --git a/doc/guides/rel_notes/release_16_07.rst 
b/doc/guides/rel_notes/release_16_07.rst
index 30e78d4..1752c40 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -47,6 +47,10 @@ New Features
   * Dropped specific Xen Dom0 code.
   * Dropped specific anonymous mempool code in testpmd.

+* **Added floating VEB support for i40e PF driver.**
+
+  More details please see floating VEB part in the document
+  doc/guides/nics/i40e.rst.

 Resolved Issues
 ---
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 553ef56..52c6b9f 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3878,21 +3878,27 @@ i40e_veb_release(struct i40e_veb *veb)
struct i40e_vsi *vsi;
struct i40e_hw *hw;

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

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

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

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

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

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

veb->associate_vsi = vsi;
+   veb->associate_pf = pf;
TAILQ_INIT(>head);
-   veb->uplink_seid = vsi->uplink_seid;
+   

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

[Zhe Tao]

Add the new floating related argument option in the devarg.
Using this parameter, all the applications can decide whether to use legacy
VEB/VEPA or floating VEB.
To enable this feature, the user should pass a devargs parameter to the
EAL like "-w 84:00.0,enable_floating_veb=1", and the application will
tell PMD whether to use the floating VEB feature or not.
Once the floating VEB feature is enabled, all the VFs created by
this PF device are connected to the floating VEB.

All the VEB/VEPA concepts are not specific for FVL, they are defined in
the 802.1Qbg spec. But the floating VEB concept is from i40e data sheet.

The standard VEB definition in 1Qbg is a bridge which has a uplink port
to the outside world (maybe another bridge), but floating means this
special VEB has no uplink port to the outside.

For floating VEB, it has two major difference comparing to
the standard VEB:
1. doesn't has a up link connection which means
the traffic cannot go to outside world.
2. doesn't need to connect to the physical port which means
when the physical link is down the floating VEB can still works
fine.

Signed-off-by: Zhe Tao 
---
 drivers/net/i40e/i40e_ethdev.c | 160 +
 drivers/net/i40e/i40e_ethdev.h |  10 +++
 2 files changed, 170 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 24777d5..553ef56 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -63,6 +63,9 @@
 #include "i40e_pf.h"
 #include "i40e_regs.h"

+#define ETH_I40E_FLOATING_VEB_ARG  "enable_floating_veb"
+#define ETH_I40E_FLOATING_VEB_LIST_ARG "floating_veb_list"
+
 #define I40E_CLEAR_PXE_WAIT_MS 200

 /* Maximun number of capability elements */
@@ -751,6 +754,161 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf *pf)
 }

 static int
+floating_veb_list_handler(__rte_unused const char *key,
+ const char *floating_veb_value,
+ void *opaque)
+{
+   int idx = 0;
+   unsigned count = 0;
+   char *end = NULL;
+   int min, max;
+   bool *vf_floating_veb = opaque;
+
+   while (isblank(*floating_veb_value))
+   floating_veb_value++;
+
+   /* Reset floating VEB configuration for VFs */
+   for (idx = 0; idx < I40E_MAX_VF; idx++)
+   vf_floating_veb[idx] = false;
+
+   min = I40E_MAX_VF;
+   do {
+   while (isblank(*floating_veb_value))
+   floating_veb_value++;
+   if (*floating_veb_value == '\0')
+   return -1;
+   errno = 0;
+   idx = strtoul(floating_veb_value, , 10);
+   if (errno || end == NULL)
+   return -1;
+   while (isblank(*end))
+   end++;
+   if (*end == '-') {
+   min = idx;
+   } else if ((*end == '/') || (*end == '\0')) {
+   max = idx;
+   if (min == I40E_MAX_VF)
+   min = idx;
+   if (max >= I40E_MAX_VF)
+   max = I40E_MAX_VF - 1;
+   for (idx = min; idx <= max; idx++) {
+   vf_floating_veb[idx] = true;
+   count++;
+   }
+   min = I40E_MAX_VF;
+   } else {
+   return -1;
+   }
+   floating_veb_value = end + 1;
+   } while (*end != '\0');
+
+   if (count == 0)
+   return -1;
+
+   return 0;
+}
+
+static void
+config_vf_floating_veb(struct rte_devargs *devargs,
+  uint16_t floating_veb,
+  bool *vf_floating_veb)
+{
+   struct rte_kvargs *kvlist;
+   int i;
+   const char *floating_veb_list = ETH_I40E_FLOATING_VEB_LIST_ARG;
+
+   if (floating_veb == false)
+   return;
+   /* All the VFs attach to the floating VEB by default
+* when the floating VEB is enabled.
+*/
+   for (i = 0; i < I40E_MAX_VF; i++)
+   vf_floating_veb[i] = true;
+
+   if (devargs == NULL)
+   return;
+
+   kvlist = rte_kvargs_parse(devargs->args, NULL);
+   if (kvlist == NULL)
+   return;
+
+   if (!rte_kvargs_count(kvlist, floating_veb_list)) {
+   rte_kvargs_free(kvlist);
+   return;
+   }
+   /* When the floating_veb_list parameter exists, all the VFs
+* will attach to the legacy VEB firstly, then configure VFs
+* to the floating VEB according to the floating_veb_list.
+*/
+   if (rte_kvargs_process(kvlist, floating_veb_list,
+  floating_veb_list_handler,
+  vf_floating_veb) < 0) {
+   rte_kvargs_free(kvlist);
+   return;
+   }
+   

[dpdk-dev] [PATCH v13 0/2] i40e: add floating VEB support for i40e

[Zhe Tao]

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

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

This floating VEB only take effects on the specific version F/W which newer
than 5.0.

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

 doc/guides/nics/i40e.rst   |  27 
 doc/guides/rel_notes/release_16_07.rst |   4 +
 drivers/net/i40e/i40e_ethdev.c | 272 ++---
 drivers/net/i40e/i40e_ethdev.h |  12 ++
 drivers/net/i40e/i40e_pf.c |  12 +-
 5 files changed, 304 insertions(+), 23 deletions(-)

V2: Added the release notes and changed commit log. 
V3: Changed the VSI release operation. 
V4: Added the FW version check otherwise it will cause the segment fault.
V5: Edited the code for new share code APIs
V6: Changed the floating VEB configuration method 
V7: Added global reset for i40e 
V8: removed global reset and added floating VEB extension support 
V9: Added floating VEB related explanation into commit log 
V10: Changed third patch commit log 
V11: Fixed the issues reported by check-git-log.sh 
V12: Changed the floating VEB VF bitmask to VF list 
V13: Changed some internal functions'names to make it more clear 

-- 
2.1.4

[dpdk-dev] [PATCH v7 22/25] mlx5: work around spurious compilation errors

[Bruce Richardson]

On Fri, Jun 24, 2016 at 03:18:01PM +0200, Nelio Laranjeiro wrote:
> From: Adrien Mazarguil 
> 
> Since commit "mlx5: resurrect Tx gather support", older GCC versions (such
> as 4.8.5) may complain about the following:
> 
>  mlx5_rxtx.c: In function `mlx5_tx_burst':
>  mlx5_rxtx.c:705:25: error: `wqe' may be used uninitialized in this
>  function [-Werror=maybe-uninitialized]
> 
>  mlx5_rxtx.c: In function `mlx5_tx_burst_inline':
>  mlx5_rxtx.c:864:25: error: `wqe' may be used uninitialized in this
>  function [-Werror=maybe-uninitialized]
> 
> In both cases, this code cannot be reached when wqe is not initialized.
> 
> Considering older GCC versions are still widely used, work around this
> issue by initializing wqe preemptively, even if it should not be necessary.
> 
> Signed-off-by: Adrien Mazarguil 

Since the previous patch is known to break the build on older compilers, I think
it would be better to merge this patch into the previous to prevent the break
from occurring in the first place. That will help with any future git-bisects
that people run.

If there is no objection, and no other issues appear requiring a new rev of
this patchset, I'll merge patches 21 and 22 on apply.

Regards,
/Bruce

[dpdk-dev] [PATCH] doc: update vhost guide

[Yuanhan Liu]

On Sun, Jun 26, 2016 at 08:28:12PM +, Mcnamara, John wrote:
> > -Original Message-
> > From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> > Sent: Friday, June 24, 2016 8:53 AM
> > To: dev at dpdk.org
> > Cc: Xie, Huawei ; Mcnamara, John
> > ; Thomas Monjalon  > 6wind.com>;
> > Yuanhan Liu 
> > Subject: [PATCH] doc: update vhost guide
> > 
> > Mainly on updating vhost-user part: we now support client mode.
> > Also refine some words, and add a bit more explanation.
> > 
> > And made an emphatic statement that you are suggested to use vhost-user
> > instead of vhost-cuse, because we have enhanced vhost-user a lot since
> > v2.2 (Actually, I doubt there are any people still using vhost-cuse)
> 
> Hi Yuahan,
> 
> Nice doc and updates. Some minor comments below.
> 
> 
> > +
> > +* access the guest memory
> > +
> > +  For QEMU, this is done by using **-object
> > + memory-backend-file,share=on,...**
> > +  option. Which means QEMU will create a file to serve as the guest RAM.
> > +  The **share=on** option allows another process to map that file,
> > + which  means it can access the guest RAM.
> 
> Fixed width quotes `` `` would be better here than bold ** **.
> 
> 
> > +Currently, there are two ways to pass those messages. That results to
> > +we have two implementations: vhost-cuse (character devices in user
> > +space) and vhost-user. Vhost-cuse creates a user space char dev and
> > +hook a function ioctl, so that all ioctl commands (that represent those
> > +messages) sent from the frontend (QEMU) will be captured and handled.
> > +While vhost-user creates a Unix domain socket file, through which those
> > messages are passed.
> 
> Probably better to separate the vhost-cuse and vhost-user into 2 paragraphs
> to make the text clearer.
> 
> Also, it is probably better to standardize on using a hyphen in vhost-cuse
> and vhost-user throughout the doc; there are cases with and without.

Yes, we should.

> 
> > +Note that since DPDK v2.2, we have spent a lot of efforts on enhancing
> > +vhost-user, such as multiple queue, live migration, reconnect, etc.
> > +Thus, **you are encouraged to use vhost-user instead of vhost-cuse**.
> 
> In general I prefer to use a simple "Note" in the text, like this, rather
> that the RST Note:: directive which creates a more distinctive but usually
> unnecessary callout box. However in this case it is probably worth having
> this recommendation displayed prominently. Something like the following:
> 
> .. Note::
> 
>Since DPDK v2.2, the majority of the development effort has gone into
>enhancing vhost-user, such as multiple queue, live migration, and
>reconnect. Thus, it is strongly advised to use vhost-user instead of
>vhost-cuse.

Much better! I also like the reword a lot.

> 
> >   * VHOST_SET_LOG_FD
> >   * VHOST_SET_VRING_ERR
> 
> Probably best to prefix this list with a sentence that explains what they
> are.

Yes, indeed. But I was thinking to defer this task to some point that I
could have plenty time to think about how to rewrite the vhost and vhost
example doc properly.

So far, it's just a short update.

> Something like:
> 
> The supported vhost messages are:
> 
> * ``VHOST_SET_MEM_TABLE``
> * ``VHOST_SET_VRING_KICK``
> * ``VHOST_SET_VRING_CALL``
> * ``VHOST_SET_LOG_FD``
> * ``VHOST_SET_VRING_ERR``
> 
> Also, use fixed width quotes here and elsewhere for function or variable
> names coming from code.
> 
> I will send you on some other suggestions.

Thanks a lot for the suggestions.

--yliu

[dpdk-dev] [PATCH v7 15/25] mlx5: handle Rx CQE compression

[Bruce Richardson]

On Fri, Jun 24, 2016 at 03:17:54PM +0200, Nelio Laranjeiro wrote:
> Mini (compressed) CQEs are returned by the NIC when PCI back pressure is
> detected, in which case the first CQE64 contains common packet information
> followed by a number of CQE8 providing the rest, followed by a matching
> number of empty CQE64 entries to be used by software for decompression.
> 
What does CQE stand for "compressed queue entry" or something else. As I've 
asked
others submitting driver patches, please explain out all acronyms used in the
commit message. 

A good rule of thumb is - if it's not checked for capitalization in the
check-git-log.sh script, it's uncommon and needs to be expanded out in commit
messages.

/Bruce

[dpdk-dev] [PATCH] app/test: fix PCI class probing

[Thomas Monjalon]

2016-06-24 14:34, Thomas Monjalon:
> The PCI test was failing because some fake devices had no PCI class.
> 
> Fixes: 1dbba1650c89 ("app/test: remove real PCI ids")
> 
> Signed-off-by: Thomas Monjalon 

Applied

[dpdk-dev] [PATCH] app/test: avoid freeing mbuf twice

[Thomas Monjalon]

2016-06-25 17:11, Pablo de Lara:
> In cryptodev tests, when input and output buffers were the same,
> the mbuf was being freed twice, causing refcnt_atomic to be negative.
> 
> Fixes: 202d375c60bc ("app/test: add cryptodev unit and performance tests")
> 
> Signed-off-by: Pablo de Lara 

Applied, thanks

[dpdk-dev] [PATCH] app/test: avoid freeing mbufs twice in qat test

[Jain, Deepak K]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Monday, June 27, 2016 1:41 PM
> To: dev at dpdk.org
> Cc: De Lara Guarch, Pablo 
> Subject: [dpdk-dev] [PATCH] app/test: avoid freeing mbufs twice in qat test
> 
> Test_multi_session was freeing mbufs used in the multiple sessions created
> and setting obuf to NULL after it, but ibuf was not being set to NULL, and
> therefore, it was being freed again (ibuf and obuf are pointing at the same
> address), in the ut_teardown() function.
> 
> Fixes: 1b9cb73ecef1 ("app/test: fix qat autotest failure")
> 
> Signed-off-by: Pablo de Lara 
> ---
>  app/test/test_cryptodev.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> --
> 2.5.0
Acked-by: Deepak K Jain 

[dpdk-dev] [PATCH] app/test: fix for icc compilation error

[Thomas Monjalon]

> > Icc complains about variable may be used without setting.
> >
> > Fixes: 97fe6461c7cbfb ("app/test: add SNOW 3G performance test)
> >
> > Signed-off-by: Deepak Kumar Jain 
> Acked-by: John Griffin 

Applied, thanks

[dpdk-dev] Crypto API use error

[amartya....@wipro.com]

Hi,

I am trying to run one sample application with crypto library with DPDK 16.04 
from below path in VM:
dpdk-16.04/examples/l2fwd-crypto

I have followed below link:
http://dpdk.org/doc/guides-16.04/cryptodevs/aesni_mb.html

Command use:
./build/l2fwd-crypto -c 0x1 -n 4 --vdev "cryptodev_aesni_mb_pmd" --vdev 
"cryptodev_aesni_mb_pmd" -- -p 0x1 --chain CIPHER_HASH --cipher_op ENCRYPT 
--cipher_algo AES_CBC --cipher_key 
00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f --auth_op GENERATE --auth_algo 
SHA1_HMAC --auth_key 10:11:12:13:14:15:16:17:18:19:1a:1b:1c:1d:1e:1f

I am getting below error:
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 1 lcore(s)
EAL: Probing VFIO support...
EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or directory)
EAL: VFIO modules not loaded, skipping VFIO support...
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0x1e0 bytes
EAL: Virtual area found at 0x7fa6bd20 (size = 0x1e0)
EAL: Ask a virtual area of 0x3e20 bytes
EAL: Virtual area found at 0x7fa67ee0 (size = 0x3e20)
EAL: Ask a virtual area of 0x3fc0 bytes
EAL: Virtual area found at 0x7fa63f00 (size = 0x3fc0)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7fa63ec0 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7fa63e80 (size = 0x20)
EAL: Requesting 1024 pages of size 2MB from socket 0
EAL: TSC frequency is ~1995189 KHz
EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable 
clock cycles !
EAL: Master lcore 0 is ready (tid=c11ca8c0;cpuset=[0])
EAL: no driver found for cryptodev_aesni_mb_pmd
EAL: failed to initialize cryptodev_aesni_mb_pmd device
PANIC in rte_eal_init():
Cannot init pmd devices
6: [./build/l2fwd-crypto() [0x42e0a3]]
5: [/lib64/libc.so.6(__libc_start_main+0xf0) [0x7fa6c02ebfe0]]
4: [./build/l2fwd-crypto(main+0x2f) [0x42b2cf]]
3: [./build/l2fwd-crypto(rte_eal_init+0xdc0) [0x49f920]]
2: [./build/l2fwd-crypto(__rte_panic+0xc9) [0x425008]]
1: [./build/l2fwd-crypto(rte_dump_stack+0x18) [0x4a6748]]
Aborted (core dumped)

What could be the cause for it and how to resolve this problem?

Thanks,
Amartya




The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com

[dpdk-dev] [PATCH] kni: fix compilation with gcc 6.1

[Thomas Monjalon]

2016-06-24 09:28, Ferruh Yigit:
> On 6/23/2016 3:38 PM, Pablo de Lara wrote:
> > Using gcc 6.1, in some cases, kni fails to compile
> > because of unused variables:
> > 
> > build/lib/librte_eal/linuxapp/kni/ixgbe_main.c:82:19:
> > error: ?ixgbe_copyright?
> > defined but not used [-Werror=unused-const-variable=]
> > static const char ixgbe_copyright[] =
> >^~~
> > 
> > build/lib/librte_eal/linuxapp/kni/ixgbe_main.c:62:19:
> > error: ?ixgbe_driver_string?
> > defined but not used [-Werror=unused-const-variable=]
> > static const char ixgbe_driver_string[] =
> > 
> > Fixes: 3fc5ca2f6352 ("kni: initial import")
> > 
> > Signed-off-by: Pablo de Lara 
> 
> Acked-by: Ferruh Yigit 

Applied, thanks

[dpdk-dev] [PATCH v2 5/7] mk: fix external dependencies of crypto drivers

[Panu Matilainen]

On 06/26/2016 07:42 PM, Thomas Monjalon wrote:
> When linking drivers as shared libraries, the dependencies need
> to be marked as DT_NEEDED entries.
>
> The crypto dependencies (libsso and libIPSec) are static libraries.
> To make them linked in the shared PMDs, the code must relocatable:
> - libIPSec_MB.a must be built with -fPIC
> - libsso_kasumi.a must be built with KASUMI_CFLAGS=-DKASUMI_C
>
> Fixes: 924e84f87306 ("aesni_mb: add driver for multi buffer based crypto")
> Fixes: eec136f3c54f ("aesni_gcm: add driver for AES-GCM crypto operations")
> Fixes: 3aafc423cf4d ("snow3g: add driver for SNOW 3G library")
> Fixes: 2773c86d061a ("crypto/kasumi: add driver for KASUMI library")
>
> Signed-off-by: Thomas Monjalon 
> ---
>  drivers/crypto/aesni_gcm/Makefile | 3 ++-
>  drivers/crypto/aesni_mb/Makefile  | 3 ++-
>  drivers/crypto/kasumi/Makefile| 3 ++-
>  drivers/crypto/snow3g/Makefile| 3 ++-
>  4 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/crypto/aesni_gcm/Makefile 
> b/drivers/crypto/aesni_gcm/Makefile
> index ab5d2ed..5898cae 100644
> --- a/drivers/crypto/aesni_gcm/Makefile
> +++ b/drivers/crypto/aesni_gcm/Makefile
> @@ -49,9 +49,10 @@ LIBABIVER := 1
>  # versioning export map
>  EXPORT_MAP := rte_pmd_aesni_gcm_version.map
>
> -# external library include paths
> +# external library dependencies
>  CFLAGS += -I$(AESNI_MULTI_BUFFER_LIB_PATH)
>  CFLAGS += -I$(AESNI_MULTI_BUFFER_LIB_PATH)/include
> +LDLIBS += -L$(AESNI_MULTI_BUFFER_LIB_PATH) -lIPSec_MB
>  LDLIBS += -lcrypto
>
>  # library source files
> diff --git a/drivers/crypto/aesni_mb/Makefile 
> b/drivers/crypto/aesni_mb/Makefile
> index 348a8bd..d3994cc 100644
> --- a/drivers/crypto/aesni_mb/Makefile
> +++ b/drivers/crypto/aesni_mb/Makefile
> @@ -49,9 +49,10 @@ LIBABIVER := 1
>  # versioning export map
>  EXPORT_MAP := rte_pmd_aesni_version.map
>
> -# external library include paths
> +# external library dependencies
>  CFLAGS += -I$(AESNI_MULTI_BUFFER_LIB_PATH)
>  CFLAGS += -I$(AESNI_MULTI_BUFFER_LIB_PATH)/include
> +LDLIBS += -L$(AESNI_MULTI_BUFFER_LIB_PATH) -lIPSec_MB
>
>  # library source files
>  SRCS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += rte_aesni_mb_pmd.c
> diff --git a/drivers/crypto/kasumi/Makefile b/drivers/crypto/kasumi/Makefile
> index 72b1ca4..9fb0be8 100644
> --- a/drivers/crypto/kasumi/Makefile
> +++ b/drivers/crypto/kasumi/Makefile
> @@ -49,10 +49,11 @@ LIBABIVER := 1
>  # versioning export map
>  EXPORT_MAP := rte_pmd_kasumi_version.map
>
> -# external library include paths
> +# external library dependencies
>  CFLAGS += -I$(LIBSSO_KASUMI_PATH)
>  CFLAGS += -I$(LIBSSO_KASUMI_PATH)/include
>  CFLAGS += -I$(LIBSSO_KASUMI_PATH)/build
> +LDLIBS += -L$(LIBSSO_KASUMI_PATH)/build -lsso_kasumi
>
>  # library source files
>  SRCS-$(CONFIG_RTE_LIBRTE_PMD_KASUMI) += rte_kasumi_pmd.c
> diff --git a/drivers/crypto/snow3g/Makefile b/drivers/crypto/snow3g/Makefile
> index 582907f..bea6760 100644
> --- a/drivers/crypto/snow3g/Makefile
> +++ b/drivers/crypto/snow3g/Makefile
> @@ -49,10 +49,11 @@ LIBABIVER := 1
>  # versioning export map
>  EXPORT_MAP := rte_pmd_snow3g_version.map
>
> -# external library include paths
> +# external library dependencies
>  CFLAGS += -I$(LIBSSO_SNOW3G_PATH)
>  CFLAGS += -I$(LIBSSO_SNOW3G_PATH)/include
>  CFLAGS += -I$(LIBSSO_SNOW3G_PATH)/build
> +LDLIBS += -L$(LIBSSO_SNOW3G_PATH)/build -lsso_snow3g
>
>  # library source files
>  SRCS-$(CONFIG_RTE_LIBRTE_PMD_SNOW3G) += rte_snow3g_pmd.c
>

LDLIBS should only contain the actual libraries, everything else 
including -L  should go to LDFLAGS. The rule is not honored in 
dpdk at all currently and nothing depends on that, so it doesn't really 
matter. Just thought to mention it since this adds several new instances 
of mixed usage.

- Panu -

[dpdk-dev] [PATCH v4 2/2] examples/ethtool: use rte_eth_dev_get_reg_info for reg params

[Remy Horton]

On 23/06/2016 14:26, zr at semihalf.com wrote:
> From: Zyta Szpak 
>
> Version 4 of fixing the fixed register width assumption.
> The app was allocating too little space for 64-bit registers
> which resulted in memory corruption. This commit resolves
> this by getting the number of registers and size of register
> by rte_eth_dev_get_reg_info function called first time
> with data=NULL.
>
> Signed-off-by: Zyta Szpak 

Acked-by: Remy Horton 

[dpdk-dev] [PATCH v4 1/2] ethdev: remove get_reg_length callback

[Remy Horton]

Morning,


On 23/06/2016 14:26, zr at semihalf.com wrote:
> From: Zyta Szpak 
>
> Version 4 of fixing the assumption of that device registers
> are always 32 bits long. rte_eth_dev_get_reg_length and
> rte_eth_dev_get_reg_info callbacks did not provide register size
> to the app in any way. It is needed to allocate proper number
> of bytes before retrieving registers content with
> rte_eth_dev_get_reg. This commit remove rte_eth_dev_get_reg_length
> callback and adds width parameter to reg_info struct which makes
> it possible to call rte_eth_dev_get_reg_info to get attributes
> first. The drivers using this callback fill width and length
> when call to function made with data=NULL.

I think this would read better as a commit message:

Removes hard-coded assumption that device registers are always 32 bits 
wide. The rte_eth_dev_get_reg_length and rte_eth_dev_get_reg_info 
callbacks did not provide register size to the app in any way, which is 
needed to allocate correct number of bytes before retrieving registers 
using rte_eth_dev_get_reg.

This commit changes rte_eth_dev_get_reg_info so that it can be used to 
retrieve both the number of registers and their width, and removes the 
now-redundant rte_eth_dev_get_reg_length.


> -/**
> - * Retrieve device registers and register attributes
> + * Retrieve device registers and register attributes (nb of regs and reg 
> size)
>   *
>   * @param port_id
>   *   The port identifier of the Ethernet device.

Need detail regarding how *info->data affects function behaviour. 
Something along the lines of:

/**
  * Retrieve device registers and register attributes (number of
  * registers and register size)
  *
  * @param port_id
  *   The port identifier of the Ethernet device.
  * @param info
  *   Pointer to rte_dev_reg_info structure to fill in. If info->data is
  *   NULL the function fills in the width and length fields. If non-NULL
  *   the registers are put into the buffer pointed at by the data field.

Program code itself looks good to me.

..Remy

[dpdk-dev] [PATCH v2 3/7] pipeline: fix truncated dependency list

[Thomas Monjalon]

2016-06-27 09:20, Dumitrescu, Cristian:
> As discussed in some other email thread, it would also make sense to replace 
> the ':=' operator with '+=' operator in Makefile of rte_port and rte_table as 
> well, do you want us to send a separate patch for this?

It's a cosmetic change.
Yes you can send a patch.

[dpdk-dev] [PATCH v2] mbuf:rearrange mbuf to be more mbuf chain friendly

[Thomas Monjalon]

2016-06-27 10:27, Olivier Matz:
> On 06/27/2016 10:21 AM, Ananyev, Konstantin wrote:
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Keith Wiles
> >> Move the next pointer to the first cacheline of the rte_mbuf structure
> >> and move the offload values to the second cacheline to give better
> >> performance to applications using chained mbufs.
> >>
> >> Enabled by a configuration option CONFIG_RTE_MBUF_CHAIN_FRIENDLY default
> >> is set to No.
> > 
> > First, it would make ixgbe and i40e vector RX functions to work incorrectly.
> > Second, I don't think we can afford to allow people swap mbuf fields in the 
> > way they like.
> > Otherwise we'll end-up with totally unmaintainable code pretty soon.
> > So NACK.  
> 
> +1

To be more precise, the arrangement of fields in rte_mbuf is open
to debate and changes.
There is a recent discussion here:
http://dpdk.org/ml/archives/dev/2016-May/039483.html

I think we must try to improve few things in mbuf during the 16.11 cycle.
But it must not be allowed to have a build option to adapt this structure
or any other API. There is only one DPDK API for a given version.

[dpdk-dev] [PATCH v2 2/2] fix building with clang-3.8.0 compiler

[Thomas Monjalon]

2016-06-26 10:54, Keith Wiles:
> Latest clang compiler 3.8.0 on latest update of Ubuntu
> creates a few more warnings on -Warray-bounds and extra
> () around 'if' expressions.

The goal of compiler checks is to fix the code.
Why disabling these checks instead of fixing the code?
If they are false positive, they need to be justified and
limited to some compiler versions.

[dpdk-dev] backtracing from within the code

[Matt Laswell]

I've done something similar to what's described in the link below.  But
it's worth pointing out that it's using printf() inside a signal handler,
which isn't safe. If your use case is catching SIGSEGV, for example,
solutions built on printf() will usually work, but can deadlock.  One way
around the problem is to call write() directly, passing it stdout's file
handle.

For example, I have this in my code:
#define WRITE_STRING(fd, s) write (fd, s, strlen (s))

In my signal handlers, I use the above like this:
WRITE_STRING(STDOUT_FILENO, "Stack trace:\n");

This approach is a little bit more cumbersome to code, but safer.

The last time that I looked the DPDK rte_dump_stack() is using vfprintf(),
which isn't safe in a signal handler.  However, it's been several DPDK
releases since I peeked at the details.

--
Matt Laswell
Principal Software Engineer
infinite io, inc.
laswell at infinite.io


On Sat, Jun 25, 2016 at 9:07 AM, Rosen, Rami  wrote:

> Hi,
> If you are willing to skip static methods and use the GCC backtrace, you
> can
> try this example (it worked for me, but it was quite a time ago):
> http://www.helicontech.co.il/?id=linuxbt
>
> Regards,
> Rami Rosen
> Intel Corporation
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Friday, June 24, 2016 8:46 PM
> To: Thomas Monjalon 
> Cc: Catalin Vasile ; dev at dpdk.org; Dumitrescu,
> Cristian 
> Subject: Re: [dpdk-dev] backtracing from within the code
>
> On Fri, 24 Jun 2016 12:05:26 +0200
> Thomas Monjalon  wrote:
>
> > 2016-06-24 09:25, Dumitrescu, Cristian:
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Catalin Vasile
> > > > I'm trying to add a feature to DPDK and I'm having a hard time
> printing a
> > > > backtrace.
> > > > I tried using this[1] functions for printing, but it does not print
> more than one
> > > > function. Maybe it lacks the symbols it needs.
> > [...]
> > > It eventually calls rte_dump_stack() in file
> lib/lirte_eal/linuxapp/eal/eal_debug.c, which calls backtrace(), which is
> probably what you are looking for.
> >
> > Example:
> > 5: [build/app/testpmd(_start+0x29) [0x416f69]]
> > 4: [/usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7eff3b757610]]
> > 3: [build/app/testpmd(main+0x2ff) [0x416b3f]]
> > 2: [build/app/testpmd(init_port_config+0x88) [0x419a78]]
> > 1: [build/lib/librte_eal.so.2.1(rte_dump_stack+0x18) [0x7eff3c126488]]
> >
> > Please tell us if you have some cases where rte_dump_stack() does not
> work.
> > I do not remember what are the constraints to have it working.
> > Your binary is not stripped?
>
> The GCC backtrace doesn't work well because it can't find static functions.
> I ended up using libunwind to get a better back trace.
>

[dpdk-dev] [PATCH v2] mbuf:rearrange mbuf to be more mbuf chain friendly

[Olivier Matz]

On 06/27/2016 10:21 AM, Ananyev, Konstantin wrote:
> 
> 
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Keith Wiles
>> Sent: Saturday, June 25, 2016 4:56 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH v2] mbuf:rearrange mbuf to be more mbuf chain 
>> friendly
>>
>> Move the next pointer to the first cacheline of the rte_mbuf structure
>> and move the offload values to the second cacheline to give better
>> performance to applications using chained mbufs.
>>
>> Enabled by a configuration option CONFIG_RTE_MBUF_CHAIN_FRIENDLY default
>> is set to No.
> 
> First, it would make ixgbe and i40e vector RX functions to work incorrectly.
> Second, I don't think we can afford to allow people swap mbuf fields in the 
> way they like.
> Otherwise we'll end-up with totally unmaintainable code pretty soon.
> So NACK.  

+1

[dpdk-dev] [PATCH v3] cryptodev: uninline parameter parsing

[De Lara Guarch, Pablo]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Sunday, June 26, 2016 5:34 PM
> To: Doherty, Declan; De Lara Guarch, Pablo
> Cc: dev at dpdk.org
> Subject: [PATCH v3] cryptodev: uninline parameter parsing
> 
> There is no need to have this parsing inlined in the header.
> It brings kvargs dependency to every crypto drivers.
> The functions are moved into rte_cryptodev.c.
> 
> Signed-off-by: Thomas Monjalon 

Acked-by: Pablo de Lara 

[dpdk-dev] [PATCH v2 2/2] fix building with clang-3.8.0 compiler

[Bruce Richardson]

On Sun, Jun 26, 2016 at 10:54:12AM -0500, Keith Wiles wrote:
> Latest clang compiler 3.8.0 on latest update of Ubuntu
> creates a few more warnings on -Warray-bounds and extra
> () around 'if' expressions.
> 
> Signed-off-by: Keith Wiles 
> ---
>  app/test-pmd/Makefile| 3 +++
>  app/test/Makefile| 3 +++
>  drivers/net/bonding/Makefile | 4 
>  drivers/net/fm10k/Makefile   | 2 ++
>  drivers/net/i40e/Makefile| 2 ++
>  lib/librte_cmdline/Makefile  | 6 ++
>  lib/librte_eal/linuxapp/eal/Makefile | 8 
>  7 files changed, 28 insertions(+)
> 
All the fixes in this patch seem to be just disabling the compiler warnings, 
which
should really be the last resort in cases like this. Can some of the issues be
fixed by actually fixing the issues in the code?

/Bruce

[dpdk-dev] example/l2fwd-crypto: maybe an issue?

[Declan Doherty]

On 23/06/16 06:30, Xuelin Shi wrote:
> Hi,
>
> Do we have assumption each core will have a separate crypto device?
>
> I have only one crypto device with several queues which are shared by 
> multi-cores.
>
> As I run the l2fwd-crypto, only one cparam is valid and has a  good dev_id.
> The other cparam is crashing.
>
> The reason is the other qconf assoicated with the core is not initializing 
> the dev_id
> since only one crypto device is available.
>
> Thanks,
> Forrest
>

Hey Forrest, yes we made the assumption of one device per core the 
application, we just default to using queue pair 0 of each crypto 
device. It shouldn't be to much work to modify the main() and 
initialize_cryptodevs() to instead allocate a cryptodev and queue pair 
to each set of cparams. If you are using software crypto PMDs such as 
the AESNI_MB PMD the simplest approach is just to create multiple 
devices using the EAL options.

Regards
Declan

[dpdk-dev] [PATCH] bnxt: Add Cumulus+ PCI ID

[Bruce Richardson]

On Fri, Jun 24, 2016 at 01:31:37PM -0500, Ajit Khaparde wrote:
> On Fri, Jun 24, 2016 at 6:59 AM, Bruce Richardson <
> bruce.richardson at intel.com> wrote:
> 
> > On Tue, Jun 21, 2016 at 04:58:20PM -0500, Ajit Khaparde wrote:
> > > This patch adds support for Cumulus+ Ethernet adapters.
> > > These Cumulus+ Ethernet adapters support 10Gb/25Gb/40Gb/50Gb speeds.
> > >
> > > Signed-off-by: Ajit Khaparde 
> >
> > Applied to dpdk-next-net/rel_16_07
> >
> ?Thanks Bruce. At what point in time will the changes under rel_16_07
> be available in the dpdk tree?
> git://dpdk.org/dpdk
> 
That's more a question for Thomas than for me, since he is the one who pulls
next-net into the mainline. However, from discussions with Thomas, it should be
fairly soon, hopefully today or tomorrow.

/Bruce

[dpdk-dev] [PATCH v2] doc: update vhost guide

[Mcnamara, John]

> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> Sent: Monday, June 27, 2016 6:20 AM
> To: dev at dpdk.org
> Cc: Xie, Huawei ; Mcnamara, John
> ; Thomas Monjalon ;
> Yuanhan Liu 
> Subject: [PATCH v2] doc: update vhost guide
> 
> Mainly on updating vhost-user part: we now support client mode.
> Also refine some words, and add a bit more explanation.
> 
> And made an emphatic statement that you are suggested to use vhost-user
> instead of vhost-cuse, because we have enhanced vhost-user a lot since
> v2.2 (Actually, I doubt there are any people still using vhost-cuse)
> 
> [John McNamara: rewords, better formats]
> Signed-off-by: Yuanhan Liu 

Acked-by: John McNamara 

[dpdk-dev] [PATCH v2 3/7] pipeline: fix truncated dependency list

[Dumitrescu, Cristian]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Sunday, June 26, 2016 5:42 PM
> To: Panu Matilainen 
> Cc: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 3/7] pipeline: fix truncated dependency list
> 
> From: Panu Matilainen 
> 
> In other libraries, dependency list is always appended to, but
> in commit 6cbf4f75e059 it with an assignment. This causes the
> librte_eal dependency added in commit 6cbf4f75e059 to get discarded,
> resulting in missing dependency on librte_eal.
> 

Acked-by: Cristian Dumitrescu 


Hi Thomas,

As discussed in some other email thread, it would also make sense to replace 
the ':=' operator with '+=' operator in Makefile of rte_port and rte_table as 
well, do you want us to send a separate patch for this?

Thanks,
Cristian

[dpdk-dev] [PATCH] ip_pipeline: add Python script file for creating visual diagram of IP pipeline config file

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jasvinder Singh
> Sent: Thursday, June 23, 2016 6:50 PM
> To: dev at dpdk.org
> Cc: Dumitrescu, Cristian 
> Subject: [dpdk-dev] [PATCH] ip_pipeline: add Python script file for
> creating visual diagram of IP pipeline config file
> 
> This commit adds Python script for generating diagram of the application
> configuration file. This script requires graphviz package to be installed
> on the machine. The input config file is translated to an output file in
> DOT syntax, which is then used to create the image file using graphviz.
> 
> To run the script, following command is used;
> 
> ./diagram-generator.py -f 
> 

Hi,

That is useful tool. The output looks very good.


> +if os.system("which dot"):
> +print dot_not_found_msg

The dot_not_found_msg variable isn't defined. It should be uppercase.


Also, it would be worth making the script Python 3 compliant since more
and more distros have that as the default.

John

[dpdk-dev] [PATCH v2] mbuf:rearrange mbuf to be more mbuf chain friendly

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Keith Wiles
> Sent: Saturday, June 25, 2016 4:56 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] mbuf:rearrange mbuf to be more mbuf chain 
> friendly
> 
> Move the next pointer to the first cacheline of the rte_mbuf structure
> and move the offload values to the second cacheline to give better
> performance to applications using chained mbufs.
> 
> Enabled by a configuration option CONFIG_RTE_MBUF_CHAIN_FRIENDLY default
> is set to No.

First, it would make ixgbe and i40e vector RX functions to work incorrectly.
Second, I don't think we can afford to allow people swap mbuf fields in the way 
they like.
Otherwise we'll end-up with totally unmaintainable code pretty soon.
So NACK.  

Konstantin

> 
> Signed-off-by: Keith Wiles 
> ---
>  config/common_base |  2 +
>  .../linuxapp/eal/include/exec-env/rte_kni_common.h |  8 +++
>  lib/librte_mbuf/rte_mbuf.h | 67 
> +++---
>  3 files changed, 56 insertions(+), 21 deletions(-)
> 
> diff --git a/config/common_base b/config/common_base
> index 379a791..f7c624e 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -405,6 +405,8 @@ CONFIG_RTE_LIBRTE_MBUF_DEBUG=n
>  CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS="ring_mp_mc"
>  CONFIG_RTE_MBUF_REFCNT_ATOMIC=y
>  CONFIG_RTE_PKTMBUF_HEADROOM=128
> +# Set to y if needing to be mbuf chain friendly.
> +CONFIG_RTE_MBUF_CHAIN_FRIENDLY=n
> 
>  #
>  # Compile librte_timer
> diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h 
> b/lib/librte_eal/linuxapp/eal/include/exec-
> env/rte_kni_common.h
> index 2acdfd9..44d65cd 100644
> --- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> @@ -120,11 +120,19 @@ struct rte_kni_mbuf {
>   char pad2[4];
>   uint32_t pkt_len;   /**< Total pkt len: sum of all segment 
> data_len. */
>   uint16_t data_len;  /**< Amount of data in segment buffer. */
> +#ifdef RTE_MBUF_CHAIN_FRIENDLY
> + char pad3[8];
> + void *next;
> 
>   /* fields on second cache line */
> + char pad4[16] __attribute__((__aligned__(RTE_CACHE_LINE_MIN_SIZE)));
> + void *pool;
> +#else
> + /* fields on second cache line */
>   char pad3[8] __attribute__((__aligned__(RTE_CACHE_LINE_MIN_SIZE)));
>   void *pool;
>   void *next;
> +#endif
>  };
> 
>  /*
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 15e3a10..6e6ba0e 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -765,6 +765,28 @@ typedef uint8_t  MARKER8[0];  /**< generic marker with 
> 1B alignment */
>  typedef uint64_t MARKER64[0]; /**< marker that allows us to overwrite 8 bytes
> * with a single assignment */
> 
> +typedef union {
> + uint32_t rss; /**< RSS hash result if RSS enabled */
> + struct {
> + union {
> + struct {
> + uint16_t hash;
> + uint16_t id;
> + };
> + uint32_t lo;
> + /**< Second 4 flexible bytes */
> + };
> + uint32_t hi;
> + /**< First 4 flexible bytes or FD ID, dependent on
> + PKT_RX_FDIR_* flag in ol_flags. */
> + } fdir;   /**< Filter identifier if FDIR enabled */
> + struct {
> + uint32_t lo;
> + uint32_t hi;
> + } sched;  /**< Hierarchical scheduler */
> + uint32_t usr; /**< User defined tags. See rte_distributor_process() 
> */
> +} rss_hash_t;
> +
>  /**
>   * The generic rte_mbuf, containing a packet mbuf.
>   */
> @@ -824,28 +846,31 @@ struct rte_mbuf {
>   uint16_t data_len;/**< Amount of data in segment buffer. */
>   /** VLAN TCI (CPU order), valid if PKT_RX_VLAN_STRIPPED is set. */
>   uint16_t vlan_tci;
> +#ifdef RTE_MBUF_CHAIN_FRIENDLY
> + /*
> +  * Move offload into the second cache line and next in the first.
> +  * Better performance for applications using chained mbufs to have
> +  * the next pointer in the first cache line.
> +  * If you change this structure, you must change the user-mode
> +  * version in rte_kni_common.h to match the new layout.
> +  */
> + uint32_t seqn; /**< Sequence number. See also rte_reorder_insert() */
> + uint16_t vlan_tci_outer;  /**< Outer VLAN Tag Control Identifier (CPU 
> order) */
> + struct rte_mbuf *next;/**< Next segment of scattered packet. */
> +
> + /* second cache line - fields only used in slow path or on TX */
> + MARKER cacheline1 __rte_cache_min_aligned;
> +
> + rss_hash_t hash;  /**< hash information */
> 
>   union {
> - uint32_t rss; /**< RSS hash result if RSS enabled */
> - 

[dpdk-dev] [PATCH v3] cryptodev: uninline parameter parsing

[Thomas Monjalon]

> > There is no need to have this parsing inlined in the header.
> > It brings kvargs dependency to every crypto drivers.
> > The functions are moved into rte_cryptodev.c.
> > 
> > Signed-off-by: Thomas Monjalon 
> 
> Acked-by: Pablo de Lara 

Applied

[dpdk-dev] [PATCH] ixgbe:enable configuration for old ptype behavior

[Ananyev, Konstantin]

> The default behavior is to NOT support the old ptype behavior,
> but enabling the configuration option the old ptype style
> can be supported.
> 
> Add support for old behaviour until we have a cleaner solution using
> a configuration option CONFIG_RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOUR,
> which is defaulted to not set.

I think it was explained why we had to diable ptype recognition for vRX, please 
see here:
http://dpdk.org/browse/dpdk/commit/drivers/net/ixgbe/ixgbe_rxtx_vec.c?id=d9a2009a81089093645fea2e04b51dd37edf3e6f
I think that introducing a compile time option to re-enable incomplete
and not fully correct functionality is a very bad approach.
So NACK.
Konstantin  

> 
> Signed-off-by: Keith Wiles 
> ---
>  config/common_base |  2 ++
>  drivers/net/ixgbe/ixgbe_ethdev.c   |  6 +
>  drivers/net/ixgbe/ixgbe_rxtx_vec.c | 52 
> +++---
>  3 files changed, 57 insertions(+), 3 deletions(-)
> 
> diff --git a/config/common_base b/config/common_base
> index bdde2e7..05e69bc 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -160,6 +160,8 @@ CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
>  CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
>  CONFIG_RTE_IXGBE_INC_VECTOR=y
>  CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
> +# Enable to restore old ptype behavior
> +CONFIG_RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOR=n
> 
>  #
>  # Compile burst-oriented I40E PMD driver
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index e11a431..068b92b 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -3076,7 +3076,13 @@ 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 ||
> +#ifdef RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOR
> + 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)
> +#else
>   dev->rx_pkt_burst == ixgbe_recv_pkts_bulk_alloc)
> +#endif
>   return ptypes;
>   return NULL;
>  }
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c 
> b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
> index 12190d2..2e0d50b 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
> @@ -228,6 +228,10 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct 
> rte_mbuf **rx_pkts,
>   );
>   __m128i dd_check, eop_check;
>   uint8_t vlan_flags;
> +#ifdef RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOR
> + __m128i desc_mask = _mm_set_epi32(0x, 0x,
> +   0x, 0x07F0);
> +#endif
> 
>   /* nb_pkts shall be less equal than RTE_IXGBE_MAX_RX_BURST */
>   nb_pkts = RTE_MIN(nb_pkts, RTE_IXGBE_MAX_RX_BURST);
> @@ -268,8 +272,14 @@ _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 */
> +#ifdef RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOR
> + 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 */
> +#else
>   0xFF, 0xFF,  /* skip 32 bit pkt_type */
>   0xFF, 0xFF
> +#endif
>   );
> 
>   /* Cache is empty -> need to scan the buffer rings, but first move
> @@ -291,6 +301,9 @@ _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) {
> +#ifdef RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOR
> + __m128i descs0[RTE_IXGBE_DESCS_PER_LOOP];
> +#endif
>   __m128i descs[RTE_IXGBE_DESCS_PER_LOOP];
>   __m128i pkt_mb1, pkt_mb2, pkt_mb3, pkt_mb4;
>   __m128i zero, staterr, sterr_tmp1, sterr_tmp2;
> @@ -301,18 +314,30 @@ _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 */
> +#ifdef RTE_IXGBE_ENABLE_OLD_PTYPE_BEHAVIOR
> + descs0[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));
> +#else
>   descs[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));
> -
> +#endif
>   /* B.2 copy 2 mbuf point into rx_pkts  */
>   _mm_storeu_si128((__m128i *)_pkts[pos], mbp1);
> 
>   /* B.1 load 1 mbuf point */
>   mbp2 = _mm_loadu_si128((__m128i *)_ring[pos+2]);
> 
> +#ifdef 

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

[Zhe Tao]

On Fri, Jun 24, 2016 at 12:14:14PM +0100, Ferruh Yigit wrote:
> Hi Zhe,
> 
> On 6/24/2016 9:29 AM, Zhe Tao wrote:
> > Add the new floating VEB related arguments option in the devarg.
> > Using this parameter, all the applications can decide whether to use legacy
> > VEB/VEPA or floating VEB.
> > To enable this feature, the user should pass a devargs parameter to the
> > EAL like "-w 84:00.0,enable_floating_veb=1", and the application will
> > tell PMD whether to use the floating VEB feature or not.
> Is providing the enable_floating_veb=1 devarg enough, or should
> application call an driver API to enable this feature, if so documenting
> what application needs to do helps app developers.
yes only provide the devarg is enough, the APP don't need to modify.
> 
> > Once the floating VEB feature is enabled, all the VFs created by
> > this PF device are connected to the floating VEB.
> Technically there can be multiple floating VEBs, right? And with this
> param only one floating VEB created and all VFs connected to it. Is
> there any use case to create multiple VEBs with selective VFs connected
> to them?
discuss this feature internally with Walter and FAE team, have an agreement
for this release we only implement one floating VEB.
> 
> > 
> > Also user can specify which VF need to connect to this floating veb using
> > "floating_veb_list".
> > Like "-w 84:00.0,enable_floating_veb=1,floating_veb_list=1/3-4", means VF1, 
> > VF3,
> > VF4 connect to the floating VEB, other VFs connect to the legacy VEB.The "/"
> > is used for delimiter of the floating VEB list.
> Is there a use case to change VF VEB connection on runtime?
maybe there is a case, but from the customer requirement, we only support the 
static
configuration for floating VEB.

> 
> > 
> > All the VEB/VEPA concepts are not specific for FVL, they are defined in
> > the 802.1Qbg spec.
> > 
> > But for floating VEB, it has two major difference.
> > 1. doesn't has a up link connection which means
> > the traffic cannot go to outside world.
> > 2. doesn't need to connect to the physical port which means
> > when the physical link is down the floating VEB can still works
> > fine.
> > 
> > Signed-off-by: Zhe Tao 
> > ---
> 
> ...
> 
> >  
> > +static int vf_floating_veb_handler(__rte_unused const char *key,
> What about floating_veb_list_handler, to be consistent with argument name?
> 
> > +  const char *floating_veb_value,
> > +  void *opaque)
> > +{
> > +   int idx = 0;
> > +   bool floating_veb; /* The flag to use the floating VEB */
> > +   /* The floating enable flag for the specific VF */
> > +   bool vf_floating_veb[I40E_MAX_VF];
> what about floating_veb_list, to be consistent with argument name?
> 
> >  };
> >  
> >  enum pending_msg {
> > 
All the comments in the code is great, I changed the code according to your
comments,
thanks again
Zhe 

[dpdk-dev] [PATCH v2 1/2] i40e: fix problematic dereference

[Helin Zhang]

It fixes the issue reported by Coverity of 'Dereference before
null check', by deleting null checks as they are not necessary
at all, or move null checks before where uses it.

Coverity ID 119267: Dereference before null check.
Coverity ID 13301: Dereference before null check.
Coverity ID 13294: Dereference before null check.
Coverity ID 13299: Dereference before null check.
Coverity ID 13298: Dereference before null check.

Fixes: 8e109464c022 ("i40e: allow vector Rx and Tx usage")
Fixes: a778a1fa2e4e ("i40e: set up and initialize flow director")
Fixes: a778a1fa2e4e ("i40e: set up and initialize flow director")
Fixes: 4861cde46116 ("i40e: new poll mode driver")

Signed-off-by: Helin Zhang 
---
 drivers/net/i40e/i40e_pf.c   |  5 +++--
 drivers/net/i40e/i40e_rxtx.c | 12 
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
index 5afd61a..1bd599b 100644
--- a/drivers/net/i40e/i40e_pf.c
+++ b/drivers/net/i40e/i40e_pf.c
@@ -123,7 +123,7 @@ int
 i40e_pf_host_vf_reset(struct i40e_pf_vf *vf, bool do_hw_reset)
 {
uint32_t val, i;
-   struct i40e_hw *hw = I40E_PF_TO_HW(vf->pf);
+   struct i40e_hw *hw;
uint16_t vf_id, abs_vf_id, vf_msix_num;
int ret;
struct i40e_virtchnl_queue_select qsel;
@@ -131,6 +131,7 @@ i40e_pf_host_vf_reset(struct i40e_pf_vf *vf, bool 
do_hw_reset)
if (vf == NULL)
return -EINVAL;

+   hw = I40E_PF_TO_HW(vf->pf);
vf_id = vf->vf_idx;
abs_vf_id = vf_id + hw->func_caps.vf_base_id;

@@ -913,7 +914,7 @@ i40e_pf_host_handle_vf_msg(struct rte_eth_dev *dev,
/* AdminQ will pass absolute VF id, transfer to internal vf id */
uint16_t vf_id = abs_vf_id - hw->func_caps.vf_base_id;

-   if (!dev || vf_id > pf->vf_num - 1 || !pf->vfs) {
+   if (vf_id > pf->vf_num - 1 || !pf->vfs) {
PMD_DRV_LOG(ERR, "invalid argument");
return;
}
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 049a813..7bb0aa9 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -2614,8 +2614,8 @@ i40e_rx_queue_release_mbufs(struct i40e_rx_queue *rxq)
return;
}

-   if (!rxq || !rxq->sw_ring) {
-   PMD_DRV_LOG(DEBUG, "Pointer to rxq or sw_ring is NULL");
+   if (!rxq->sw_ring) {
+   PMD_DRV_LOG(DEBUG, "Pointer to sw_ring is NULL");
return;
}

@@ -3002,13 +3002,15 @@ i40e_fdir_setup_tx_resources(struct i40e_pf *pf)
struct i40e_tx_queue *txq;
const struct rte_memzone *tz = NULL;
uint32_t ring_size;
-   struct rte_eth_dev *dev = pf->adapter->eth_dev;
+   struct rte_eth_dev *dev;

if (!pf) {
PMD_DRV_LOG(ERR, "PF is not available");
return I40E_ERR_BAD_PTR;
}

+   dev = pf->adapter->eth_dev;
+
/* Allocate the TX queue data structure. */
txq = rte_zmalloc_socket("i40e fdir tx queue",
  sizeof(struct i40e_tx_queue),
@@ -3056,13 +3058,15 @@ i40e_fdir_setup_rx_resources(struct i40e_pf *pf)
struct i40e_rx_queue *rxq;
const struct rte_memzone *rz = NULL;
uint32_t ring_size;
-   struct rte_eth_dev *dev = pf->adapter->eth_dev;
+   struct rte_eth_dev *dev;

if (!pf) {
PMD_DRV_LOG(ERR, "PF is not available");
return I40E_ERR_BAD_PTR;
}

+   dev = pf->adapter->eth_dev;
+
/* Allocate the RX queue data structure. */
rxq = rte_zmalloc_socket("i40e fdir rx queue",
  sizeof(struct i40e_rx_queue),
-- 
2.5.0

[dpdk-dev] [PATCH v2 0/2] fix coverity issues

[Helin Zhang]

It fixes several problematic dereference issues and missing
break issue reported by Coverity.

Helin Zhang (2):
  i40e: fix problematic dereference
  i40e: fix missing break in switch

 drivers/net/i40e/i40e_pf.c   | 11 +--
 drivers/net/i40e/i40e_rxtx.c | 12 
 2 files changed, 13 insertions(+), 10 deletions(-)

-- 
2.5.0