[dpdk-dev] [PATCH v2] mk: replace the combined library with a linker script

[Thomas Monjalon]

From: Panu Matilainen 

The physically linked-together combined library has been an increasing
source of problems, as was predicted when library and symbol versioning
was introduced. Replace the complex and fragile construction with a
simple linker script which achieves the same without all the problems,
remove the related kludges from eg mlx drivers.

Since creating the linker script is practically zero cost, remove the
config option and just create it always.

Based on a patch by Sergio Gonzales Monroy, linker script approach
initially suggested by Neil Horman.

Suggested-by: Sergio Gonzalez Monroy 
Suggested-by: Neil Horman 
Signed-off-by: Panu Matilainen 
Signed-off-by: Thomas Monjalon 
---
v2:
- move RTE_LIBNAME assignment rte.vars.mk to rte.combinedlib.mk
- update crypto
- update doc
- update rte.app.mk
- update test-build.sh

 config/common_bsdapp |   5 --
 config/common_linuxapp   |   5 --
 doc/guides/contributing/patches.rst  |  12 ++-
 doc/guides/nics/mlx4.rst |   5 --
 doc/guides/nics/mlx5.rst |   5 --
 drivers/crypto/Makefile  |   3 +-
 drivers/net/Makefile |   1 -
 drivers/net/mlx4/Makefile|   6 --
 drivers/net/mlx5/Makefile|   6 --
 lib/Makefile |   1 -
 mk/rte.app.mk|  17 +---
 drivers/crypto/Makefile => mk/rte.combinedlib.mk |  28 +-
 mk/rte.lib.mk|  16 
 mk/rte.sdkbuild.mk   |   4 +-
 mk/rte.sharelib.mk   | 105 ---
 mk/rte.vars.mk   |   2 -
 scripts/test-build.sh|   7 +-
 17 files changed, 36 insertions(+), 192 deletions(-)
 copy drivers/crypto/Makefile => mk/rte.combinedlib.mk (81%)
 delete mode 100644 mk/rte.sharelib.mk

diff --git a/config/common_bsdapp b/config/common_bsdapp
index 696382c..7df5ac6 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -74,11 +74,6 @@ CONFIG_RTE_ARCH_STRICT_ALIGN=n
 CONFIG_RTE_BUILD_SHARED_LIB=n

 #
-# Combine to one single library
-#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
-
-#
 # Use newest code breaking previous ABI
 #
 CONFIG_RTE_NEXT_ABI=y
diff --git a/config/common_linuxapp b/config/common_linuxapp
index f1638db..26df137 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -74,11 +74,6 @@ CONFIG_RTE_ARCH_STRICT_ALIGN=n
 CONFIG_RTE_BUILD_SHARED_LIB=n

 #
-# Combine to one single library
-#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
-
-#
 # Use newest code breaking previous ABI
 #
 CONFIG_RTE_NEXT_ABI=y
diff --git a/doc/guides/contributing/patches.rst 
b/doc/guides/contributing/patches.rst
index 5dd8f79..3ebe95b 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -267,7 +267,7 @@ Checking Compilation
 Compilation of patches and changes should be tested using the the 
``test-build.sh`` script in the ``scripts``
 directory of the DPDK repo::

-  scripts/test-build.sh x86_64-native-linuxapp-gcc+next+shared+combined
+  scripts/test-build.sh x86_64-native-linuxapp-gcc+next+shared

 The script usage is::

@@ -283,10 +283,8 @@ Where:
 Examples of configs are::

x86_64-native-linuxapp-gcc
-   x86_64-native-linuxapp-gcc+next+shared+combined
-   x86_64-native-linuxapp-gcc+shared+next
-   x86_64-native-linuxapp-clang+shared+combined
-   i686-native-linuxapp-gcc+combined
+   x86_64-native-linuxapp-gcc+next+shared
+   x86_64-native-linuxapp-clang+shared

 The builds can be modifies via the following environmental variables:

@@ -302,8 +300,8 @@ These can be set from the command line or in the config 
files shown above in the
 The recommended configurations and options to test compilation prior to 
submitting patches are::

x86_64-native-linuxapp-gcc+shared+next
-   x86_64-native-linuxapp-clang+shared+combined
-   i686-native-linuxapp-gcc+combined
+   x86_64-native-linuxapp-clang+shared
+   i686-native-linuxapp-gcc

export DPDK_DEP_ZLIB=y
export DPDK_DEP_PCAP=y
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index 7757013..49f4626 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -47,11 +47,6 @@ There is also a `section dedicated to this poll mode driver
be enabled manually by setting ``CONFIG_RTE_LIBRTE_MLX4_PMD=y`` and
recompiling DPDK.

-.. warning::
-
-   ``CONFIG_RTE_BUILD_COMBINE_LIBS`` with ``CONFIG_RTE_BUILD_SHARED_LIB``
-   is not supported and thus the compilation will fail with this configuration.
-
 Implementation details
 --

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index b2a12ce..66794e6 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -48,11 +48,6 @@ There is also a `section dedicated to this 

[dpdk-dev] [PATCH] eal: Initial implementation of PQoS EAL extension

[Kantecki, Tomasz]

> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> If there is nothing specific in DPDK for PQos, why writing an example in
> DPDK?
The example makes it much easier to use the technology with DPDK.

> Maybe the example should be better in the library itself.
The library in question (https://github.com/01org/intel-cmt-cat) has a couple 
of examples but none of them refers to DPDK.

> I suggest to mention the library in
> doc/guides/linux_gsg/nic_perf_intel_platform.rst
Ok it can be added to this document. Does it imply -1 for the sample code idea?

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

[dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script

[Thomas Monjalon]

Hi,

I'm reviving this old thread.
My understanding is that everybody prefer the linker script
than the current combined library which had neither symbol versioning
nor library dependency informations.

Comments below:

2015-11-24 16:31, Panu Matilainen:
> The physically linked-together combined library has been an increasing
> source of problems, as was predicted when library and symbol versioning
> was introduced. Replace the complex and fragile construction with a
> simple linker script which achieves the same without all the problems,
> remove the related kludges from eg mlx drivers.
> 
> Since creating the linker script is practically zero cost, remove the
> config option and just create it always.
[...]
> --- /dev/null
> +++ b/mk/rte.combinedlib.mk
> @@ -0,0 +1,57 @@
> +#   BSD LICENSE
> +#
> +#   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> +#   All rights reserved.
> +#
> +#   Redistribution and use in source and binary forms, with or without
> +#   modification, are permitted provided that the following conditions
> +#   are met:
> +#
> +# * Redistributions of source code must retain the above copyright
> +#   notice, this list of conditions and the following disclaimer.
> +# * Redistributions in binary form must reproduce the above copyright
> +#   notice, this list of conditions and the following disclaimer in
> +#   the documentation and/or other materials provided with the
> +#   distribution.
> +# * Neither the name of Intel Corporation nor the names of its
> +#   contributors may be used to endorse or promote products derived
> +#   from this software without specific prior written permission.

Why this header, Panu?
I think you should write your own copyright, and assume the linker script ;)

It needs to be rebased and some docs comments must be removed or updated.
I'll send a v2.

[dpdk-dev] including rte.app.mk from a Makefile.am

[Stefan Puiu]

Hi,

I'm working on a Linux project that uses the DPDK and (unfornately,
IMO) automake; so we have a Makefile.am where we include rte.extapp.mk
and rte.vars.mk from the DPDK, add LDLIBS to the linker

However, I've tried building against DPDK 2.2 and I'm getting linker
errors about options like '--no-as-needed', '--whole-archive' etc not
being recognized. Basically, we use libtool to link the binary, which
behind the scenes ends up calling gcc to link the binary, and gcc
doesn't know how to read linker options - they need to be prefixed
with '-Wl,..'.  I've traced this to this part of rte.app.mk:

=== DPDK 1.7.1
ifeq ($(LINK_USING_CC),1)
LDLIBS := $(call linkerprefix,$(LDLIBS))
LDFLAGS := $(call linkerprefix,$(LDFLAGS))

=== DPDK 2.2 (since DPDK 1.8, AFAICT)
ifeq ($(LINK_USING_CC),1)
O_TO_EXE = $(CC) $(CFLAGS) $(LDFLAGS_$(@)) \
-Wl,-Map=$(@).map,--cref -o $@ $(OBJS-y) $(call
linkerprefix,$(LDFLAGS)) \
$(EXTRA_LDFLAGS) $(call linkerprefix,$(LDLIBS))

Notice on 1.7.1 LDFLAGS gets the -Wl, prefix if linking with gcc; for
2.2, that doesn't happen anymore - note O_TO_EXE calls linkerprefix
explicitly for LDLIBS and LDFLAGS.

The change that removed the LDLIBS/LDFLAGS setting is 3c6a14f6, which
ironically says "mk: fix link with CC" in the title.

I've tried working around this, but apparently automake doesn't give
you too much control of what you can do; overriding LDFLAGS with
$(call linkerprefix,$(LDFLAGS) in Makefile.am doesn't work. Since
LDFLAGS is treated as a user variable by automake, it's tricky to
override it.

Now my question is: is this supposed to work? Is there any point in
trying to use the mk files from my outside project? I noticed dpdk-ovs
doesn't seem to bother with that, and just builds one library to link
against. I guess it's useful to pick up the defines that the DPDK was
built against, so inline functions in headers are properly picked up.
Are there people using the DPDK from projects using automake?

IMO, It would be nice if you could extract the CPPFLAGS/LDFLAGS etc
from the DPDK without including the mk files - maybe by running
something like 'make showvars' or something like that in the DPDK dir.
Then external projects could integrate those in their build system
without too much extra baggage.

Thanks,
Stefan.

[dpdk-dev] [dpdk-dev, v3] Implement memcmp using Intel SIMD instrinsics.

[Ravi Kerur]

On Tue, Feb 23, 2016 at 4:22 AM, Wang, Zhihong 
wrote:

> > > It'd be great if you could format this patch into a patch set with
> several
> > > little ones. :-)
> > > Also, the kernel checkpatch is very helpful.
> > > Good coding style and patch organization make it easy for in-depth
> reviews.
> > >
> > Combination of scalar and vector (32/64/128) was done to get optimal
> performance numbers. If there is enough interest in this I can work on it
> and provide an updated patch set.
>
> That'll be very helpful! Looking forward to your patch :)
> BTW, have you tested real example performance with your patch?
>

Yes it was tested with hash functions in dpdk code.I will work on it and
send updated patch. Thanks for your inputs I will incorporate them in next
patch series.

[dpdk-dev] [PATCH 4/6] qede: add driver common module

[Harish Patil]

>
>On Sat, 20 Feb 2016 07:58:31 -0800
> wrote:
>
>> +unsigned long log2_align(unsigned long n)
>> +{
>
>Common code is good, but you need to practice good function name
>hygiene on public functions to avoid any namespace clashes when
>using static linking.
>
>The application might define a function with log2_align.
>Either make the functions static, or use a common prefix for all qede
>internal functions.
>

Sure. Will fix those

[dpdk-dev] [PATCH 5/6] qede: add driver

[Harish Patil]

>>
>>
>>
>>On Tue, 23 Feb 2016 02:28:25 +
>>Harish Patil  wrote:
>>
>>> All of the checkpatch warnings had been fixed  (except one which cannot
>>>be
>>> fixed) using the checkpatch script available under DPDK scripts/
>>> directory. The linux checkpatch version is 0.32.
>>> 
>>> [root at dut4019 dpdk]# ./scripts/checkpatches.sh patches-send/*.patch
>>> 
>>> ### patches-send/0004-qede-add-driver-common-module.patch
>>> 
>>> WARNING:CAMELCASE: Avoid CamelCase: 
>>> #251: FILE: drivers/net/qede/ecore/bcm_osal.c:120:
>>> +   inflateEnd(p_hwfn->stream);
>>> 
>>> total: 0 errors, 1 warnings, 54467 lines checked
>>> 
>>> Wouldn?t that suffice?
>>
>>Maybe your version of checkpatch from kernel is older than more recent
>>version I am using (from Linux 4.4).
>>
>I had used checkpatch version 0.32 as mentioned above.
>The latest checkpatch version in net-next also shows 0.32.
>my $V = '0.32?;
>
>I see similar checkpatch related conversations going on in other threads
>in the distribution.
>Please advise.
>+Thomas
>
>Thanks,
>Harish 
>
>
>
+Thomas

[dpdk-dev] [PATCH 5/6] qede: add driver

[Harish Patil]

>
>On Tue, 23 Feb 2016 02:28:25 +
>Harish Patil  wrote:
>
>> All of the checkpatch warnings had been fixed  (except one which cannot
>>be
>> fixed) using the checkpatch script available under DPDK scripts/
>> directory. The linux checkpatch version is 0.32.
>> 
>> [root at dut4019 dpdk]# ./scripts/checkpatches.sh patches-send/*.patch
>> 
>> ### patches-send/0004-qede-add-driver-common-module.patch
>> 
>> WARNING:CAMELCASE: Avoid CamelCase: 
>> #251: FILE: drivers/net/qede/ecore/bcm_osal.c:120:
>> +   inflateEnd(p_hwfn->stream);
>> 
>> total: 0 errors, 1 warnings, 54467 lines checked
>> 
>> Wouldn?t that suffice?
>
>Maybe your version of checkpatch from kernel is older than more recent
>version I am using (from Linux 4.4).
>
I had used checkpatch version 0.32 as mentioned above.
The latest checkpatch version in net-next also shows 0.32.
my $V = '0.32?;

I see similar checkpatch related conversations going on in other threads
in the distribution.
Please advise.
+Thomas

Thanks,
Harish 

[dpdk-dev] [PATCH 4/5] mlx5: add support for flow director

[Adrien Mazarguil]

On Tue, Feb 23, 2016 at 06:14:19PM +0100, Thomas Monjalon wrote:
> 2016-02-23 15:13, Bruce Richardson:
> > On Thu, Feb 18, 2016 at 05:10:16PM +0100, Adrien Mazarguil wrote:
> > > Hi Bruce,
> > > 
> > > On Wed, Feb 17, 2016 at 05:13:44PM +, Bruce Richardson wrote:
> > > > Hi Adrien, Yaacov,
> > > > 
> > > > this patch raises a lot of warnings (17) with checkpatch. Can you 
> > > > perhaps look
> > > > to see if this number can be reduced.
> > > 
> > > We actually did it before submitting that patch, there is indeed a bunch 
> > > of
> > > remaining warnings that have been left on purpose. Not sure if we have the
> > > same configuration for checkpatch, but they should fall into the following
> > > categories:
> > > 
> > > - "WARNING: return of an errno should typically be negative" - All return
> > >   values are documented in the code. Since this PMD uses syscalls in its
> > >   control path, it uses positive errno values internally for
> > >   consistency. Public callback functions however return negative error
> > >   values.
> > > 
> > > - "WARNING: line over 80 characters" - Well, although I'm a big fan of the
> > >   80 characters limit, breaking those would have made the code harder to
> > >   read.
> > > 
> > > - "WARNING: Missing a blank line after declarations" - It's actually a
> > >   declaration through a macro, there is no missing blank line.
> > > 
> > > - "WARNING: networking block comments don't use an empty /* line" - Not 
> > > sure
> > >   if we really care? I don't particularly mind.
> > > 
> > > - "CHECK: Comparison to NULL could be written "!" - I do not mind either,
> > >   writing the full check seems clearer to me.
> > > 
> > > - "CHECK: Unnecessary parentheses around fdir_info->mask" - Looks like a
> > >   valid, although minor error.
> > > 
> > > Please tell me which of these still need to be fixed.
> > > 
> > Hi Adrien,
> > 
> > sorry for the delayed reply, I was out for a couple of days.
> > 
> > As none of the above are errors, I'm not going to mandate that they be fixed
> > before I merge in the patch, so long as you as maintainer are happy with 
> > them.
> > 
> > My request mainly came about because of the sheer number of warnings that 
> > were
> > being flagged. To keep the codebase clean requires constant discipline, so I
> > don't like seeing patches where 17 warnings are flagged. I was hoping since
> > a new rev of the set was likely anyway that some steps could be taken to 
> > reduce
> > that number.
> > 
> > Thomas, any thoughts here, since I'm still "learning the ropes" as 
> > committer. 
> > Do you have any rules-of-thumb or guidelines as regards checkpatch 
> > warnings? The
> > contributor guide only seems to cover running checkpatch, not anything about
> > what to do with the output.
> 
> I totally agree with you, Bruce.
> Everybody must make some effort to keep consistency and avoid coding style
> exceptions. Some code areas are not yet fully compliant with the rules,
> depending of their history and... their maintainers ;)
> I think we can tolerate some exceptions like for the 80 char limit.
> Some checks may be disabled after discussion (networking block comments?).

Actually you can ignore this one and NULL comparison checks - they do not
show up when using scripts/checkpatches.sh (I was previously using
checkpatch.pl directly).

I've fixed and sent updated versions of these patchsets anyway, with errno
warnings still present since it's a design decision. We can discuss it if
necessary.

> Other checks deserve to be followed more strictly (e.g. negative errno).

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] Question about patchset order.

[Thomas Monjalon]

2016-02-23 16:17, Kobylinski, MichalX:
> Hi Thomas,
> I sent in January a patch-set that extends to 24 bits a next_hop field in lpm 
> library:
> http://dpdk.org/dev/patchwork/patch/10249/
> http://dpdk.org/dev/patchwork/patch/10250/
> 
> also Jerin Jakob sent his patch-set with ARM architecture support in lpm 
> library.
> http://dpdk.org/dev/patchwork/patch/10478/
> http://dpdk.org/dev/patchwork/patch/10479/
> http://dpdk.org/dev/patchwork/patch/10480/
> 
> Could you write please, in which order do you prefer to apply these two 
> patch-sets?
> This information will be helpful to predict the risk and estimate additional 
> work.

Thanks for bringing up the LPM patches.
I would prefer to follow the advice of Bruce who has well followed
these interactions.

[dpdk-dev] [PATCH 4/5] mlx5: add support for flow director

[Thomas Monjalon]

2016-02-23 15:13, Bruce Richardson:
> On Thu, Feb 18, 2016 at 05:10:16PM +0100, Adrien Mazarguil wrote:
> > Hi Bruce,
> > 
> > On Wed, Feb 17, 2016 at 05:13:44PM +, Bruce Richardson wrote:
> > > Hi Adrien, Yaacov,
> > > 
> > > this patch raises a lot of warnings (17) with checkpatch. Can you perhaps 
> > > look
> > > to see if this number can be reduced.
> > 
> > We actually did it before submitting that patch, there is indeed a bunch of
> > remaining warnings that have been left on purpose. Not sure if we have the
> > same configuration for checkpatch, but they should fall into the following
> > categories:
> > 
> > - "WARNING: return of an errno should typically be negative" - All return
> >   values are documented in the code. Since this PMD uses syscalls in its
> >   control path, it uses positive errno values internally for
> >   consistency. Public callback functions however return negative error
> >   values.
> > 
> > - "WARNING: line over 80 characters" - Well, although I'm a big fan of the
> >   80 characters limit, breaking those would have made the code harder to
> >   read.
> > 
> > - "WARNING: Missing a blank line after declarations" - It's actually a
> >   declaration through a macro, there is no missing blank line.
> > 
> > - "WARNING: networking block comments don't use an empty /* line" - Not sure
> >   if we really care? I don't particularly mind.
> > 
> > - "CHECK: Comparison to NULL could be written "!" - I do not mind either,
> >   writing the full check seems clearer to me.
> > 
> > - "CHECK: Unnecessary parentheses around fdir_info->mask" - Looks like a
> >   valid, although minor error.
> > 
> > Please tell me which of these still need to be fixed.
> > 
> Hi Adrien,
> 
> sorry for the delayed reply, I was out for a couple of days.
> 
> As none of the above are errors, I'm not going to mandate that they be fixed
> before I merge in the patch, so long as you as maintainer are happy with them.
> 
> My request mainly came about because of the sheer number of warnings that were
> being flagged. To keep the codebase clean requires constant discipline, so I
> don't like seeing patches where 17 warnings are flagged. I was hoping since
> a new rev of the set was likely anyway that some steps could be taken to 
> reduce
> that number.
> 
> Thomas, any thoughts here, since I'm still "learning the ropes" as committer. 
> Do you have any rules-of-thumb or guidelines as regards checkpatch warnings? 
> The
> contributor guide only seems to cover running checkpatch, not anything about
> what to do with the output.

I totally agree with you, Bruce.
Everybody must make some effort to keep consistency and avoid coding style
exceptions. Some code areas are not yet fully compliant with the rules,
depending of their history and... their maintainers ;)
I think we can tolerate some exceptions like for the 80 char limit.
Some checks may be disabled after discussion (networking block comments?).
Other checks deserve to be followed more strictly (e.g. negative errno).

[dpdk-dev] [PATCH 0/6] DPDK PMD for new QLogic FastLinQ QL4xxxx 25G/40G CNAs

[Harish Patil]

>
>2016-02-22 16:47, Harish Patil:
>> >Please could you share some performance numbers?
>> 
>> We have measured ~68 MPPS @ 64B with zero drop for the 4x25G adapter
>> running bi-di RFC traffic.
>
>How many queues/cores to achieve this performance?
Using single queue/core per port. Eg:  Running L2FWD application in the
4x25G configuration shall use 4 cores with single queue pair per port.

>
>> >What is the status about the integration of this driver in other
>> >environments?
>> 
>> Not very sure what you mean here. If you are asking about linux, then
>> qede/qed kernel drivers are part of kernel.org.
>> If its about BSD then we have compile tested the current poll mode
>>driver
>> under FreeBSD (64 bit).
>
>OK, so the base driver is shared only between Linux and DPDK?
>Nothing in BSD kernels?
BSD driver also uses the common base code.

>
>> By the way, the patch 4/6 is still held up (not posted) due to size
>> restrictions.
>> Could you please allow it to be posted?
>
>It was posted but curiously out of the thread:
>   http://dpdk.org/ml/archives/dev/2016-February/033612.html

Ok thanks
>
>> 
>> 
>> This message and any attached documents contain information from the
>>sending company or its parent company(s), subsidiaries, divisions or
>>branch offices that may be confidential. If you are not the intended
>>recipient, you may not read, copy, distribute, or use this information.
>>If you have received this transmission in error, please notify the
>>sender immediately by reply e-mail and then delete this message.
>
>Please avoid this message --^
>
I have got it fixed at the exchange level. Hopefully should be fixed with
this email onwards. 

[dpdk-dev] [PATCH] eal: Initial implementation of PQoS EAL extension

[Thomas Monjalon]

2016-02-23 10:03, Kantecki, Tomasz:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > Are you OK with concept behind V2 PQoS patch as described above?
> > 
> > So you mean that PQoS don't really need some DPDK integration?
> > You just want to show how to use it with DPDK?
> 
> You are correct. The technology can be used without tight DPDK integration 
> but will require users to reach out to existing open source code.
> Based on received feedback about EAL PQoS extensions we backed off to sort of 
> a sample code.

If there is nothing specific in DPDK for PQos, why writing an example in DPDK?
Maybe the example should be better in the library itself.
I suggest to mention the library in 
doc/guides/linux_gsg/nic_perf_intel_platform.rst

[dpdk-dev] [PATCH v2 00/12] Add API to get packet type info

[Bruce Richardson]

On Fri, Jan 15, 2016 at 01:45:47PM +0800, Jianfeng Tan wrote:
> A new ether API rte_eth_dev_get_ptype_info() is added to query what
> packet type information will be provided by current pmd driver of the
> specifed port.
> 
> To achieve this, a new function pointer, dev_ptype_info_get, is added
> into struct eth_dev_ops. For those devices who do not implement it, it
> means it will not provide any ptype info.
> 
> v2:
>   - Move ptype_mask filter function from each PMDs into ether layer.
>   - Add ixgbe vPMD's ptype info.
>   - Fix code style issues.
>
Hi,

there are some outstanding comments on these patches. Can you send a V3 to
resolve them?

/Bruce

[dpdk-dev] [PATCH 2/2 v2] 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.

Signed-off-by: Zhe Tao 
---
 doc/guides/rel_notes/release_16_04.rst |  2 +
 drivers/net/i40e/Makefile  |  2 +-
 drivers/net/i40e/i40e_ethdev.c | 92 +-
 drivers/net/i40e/i40e_ethdev.h |  3 ++
 drivers/net/i40e/i40e_pf.c | 10 +++-
 5 files changed, 81 insertions(+), 28 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 5786f74..446112c 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -46,6 +46,8 @@ This section should contain new features added in this 
release. Sample format:

 * **Added vhost-user live migration support.**

+* **Added floating VEB support for FVL.**
+

 Resolved Issues
 ---
diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile
index 033ee4a..2e01d45 100644
--- a/drivers/net/i40e/Makefile
+++ b/drivers/net/i40e/Makefile
@@ -39,7 +39,7 @@ LIB = librte_pmd_i40e.a
 CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS) -DPF_DRIVER -DVF_DRIVER -DINTEGRATED_VF
 CFLAGS += -DX722_SUPPORT -DX722_A0_SUPPORT
-
+CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common
 EXPORT_MAP := rte_pmd_i40e_version.map

 LIBABIVER := 1
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index ef24122..b75d929 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3592,21 +3592,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;
 }

@@ -3618,9 +3624,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);
@@ -3632,11 +3638,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;
+   veb->uplink_seid = vsi ? vsi->uplink_seid : 0;

-   ret = i40e_aq_add_veb(hw, veb->uplink_seid, vsi->seid,
-   I40E_DEFAULT_TCMAP, false, false, >seid, NULL);
+   /* create floating veb if vsi is NULL */
+   if (vsi != NULL) {
+   ret = i40e_aq_add_veb(hw, veb->uplink_seid, vsi->seid,
+ I40E_DEFAULT_TCMAP, false, false,
+ >seid, NULL);
+   } else {
+   ret = i40e_aq_add_veb(hw, 0, 0, I40E_DEFAULT_TCMAP,
+ false, false, >seid, NULL);
+   }

if (ret != I40E_SUCCESS) {
PMD_DRV_LOG(ERR, "Add veb failed, aq_err: %d",
@@ -3688,20 +3702,21 @@ i40e_vsi_release(struct i40e_vsi *vsi)
i40e_veb_release(vsi->veb);
}

+   if (vsi->floating_veb) {
+   TAILQ_FOREACH(vsi_list, >floating_veb->head, list) {
+   if (i40e_vsi_release(vsi_list->vsi) != I40E_SUCCESS)
+   return -1;
+   TAILQ_REMOVE(>floating_veb->head, vsi_list, list);
+   }
+   i40e_veb_release(vsi->floating_veb);
+   }
+
/* Remove all macvlan filters of the VSI */
i40e_vsi_remove_all_macvlan_filter(vsi);
TAILQ_FOREACH(f, >mac_list, next)
rte_free(f);

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

[Zhe Tao]

Add the new floating related argument option in the EAL.
Using this parameter, all the samples can decide whether to use legacy VEB/VEPA,
 or floating VEB.
Even the floating argument is provided in the EAL, but this floating
feature are only support for FVL so far.

Signed-off-by: Zhe Tao 
---
 lib/librte_eal/common/eal_common_options.c | 4 
 lib/librte_eal/common/eal_internal_cfg.h   | 1 +
 lib/librte_eal/common/eal_options.h| 2 ++
 3 files changed, 7 insertions(+)

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index 29942ea..29ed7bf 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -95,6 +95,7 @@ eal_long_options[] = {
{OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM},
{OPT_VMWARE_TSC_MAP,0, NULL, OPT_VMWARE_TSC_MAP_NUM   },
{OPT_XEN_DOM0,  0, NULL, OPT_XEN_DOM0_NUM },
+   {OPT_FLOATING,  0, NULL, OPT_FLOATING_NUM },
{0, 0, NULL, 0}
 };

@@ -896,6 +897,9 @@ eal_parse_common_option(int opt, const char *optarg,
return -1;
}
break;
+   case OPT_FLOATING_NUM:
+   conf->floating = 1;
+   break;

/* don't know what to do, leave this to caller */
default:
diff --git a/lib/librte_eal/common/eal_internal_cfg.h 
b/lib/librte_eal/common/eal_internal_cfg.h
index 5f1367e..0dd303a 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -68,6 +68,7 @@ struct internal_config {
volatile unsigned xen_dom0_support; /**< support app running on Xen 
Dom0*/
volatile unsigned no_pci; /**< true to disable PCI */
volatile unsigned no_hpet;/**< true to disable HPET */
+   volatile unsigned floating;   /**< true to disable floating VEB */
volatile unsigned vmware_tsc_map; /**< true to use VMware TSC mapping

* instead of native TSC */
volatile unsigned no_shconf;  /**< true if there is no shared 
config */
diff --git a/lib/librte_eal/common/eal_options.h 
b/lib/librte_eal/common/eal_options.h
index a881c62..413c9e6 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -83,6 +83,8 @@ enum {
OPT_VMWARE_TSC_MAP_NUM,
 #define OPT_XEN_DOM0  "xen-dom0"
OPT_XEN_DOM0_NUM,
+#define OPT_FLOATING  "floating"
+   OPT_FLOATING_NUM,
OPT_LONG_MAX_NUM
 };

-- 
2.1.4

[dpdk-dev] [PATCH 0/2 v2] 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.

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

 doc/guides/rel_notes/release_16_04.rst |  2 +
 drivers/net/i40e/Makefile  |  2 +-
 drivers/net/i40e/i40e_ethdev.c | 92 ++
 drivers/net/i40e/i40e_ethdev.h |  3 +
 drivers/net/i40e/i40e_pf.c | 10 +++-
 lib/librte_eal/common/eal_common_options.c |  4 ++
 lib/librte_eal/common/eal_internal_cfg.h   |  1 +
 lib/librte_eal/common/eal_options.h|  2 +
 8 files changed, 88 insertions(+), 28 deletions(-)

V2: Added the release notes and changed commit log. 

-- 
2.1.4

[dpdk-dev] DPDK-QoS - link sharing across classes

[sreenaath vasudevan]

b) In current DPDK QoS implemention, if C1 has un-used b/w would that get
used by C0? Or is it only "lower priority class (C3, more specifically)
uses the un-used b/w from higher priority classes (C0,C1,C2) ?

[Cristian] Due to strict priority, it does not make sense to think about
higher priority classes using whatever is not used by low priority classes:
If high priority classes have traffic to send, they will always be picked
in the detriment of lower ones; when the high priority classes hit their
upper limit rate, then they are not allowed to send more, otherwise the
upper limit makes no sense. So the bandwidth reuse concept makes sense only
for low prio TCs to reuse whatever is not used from high prio TCs. Usually,
this is configured by fully provisioning TC0 .. TC2 and setting TC3 to 100%
of pipe rate, so TC3 can use its rate plus whatever gets unused by TC0 ..
TC2, so TC3 rate is between: 100% - (rate TC0 + rate TC1 + rate TC2) and
100% of pipe rate. As explained above, this can be applicable to e.g TC1 as
well when only TC0 and TC1 are actually used. So the answers to your 2
questions are: no/no.



>> Sreenaath - Let's say I have two classes TC0 and TC1 each having a
single queue. Let's say I give TC0 60% and TC1 100%. So according to DPDK's
implementation, TC1 can use 100% of the bandwidth if TC0 is inactive, while
TC0 at any time cannot exceed 60%, even if TC1 is inactive. Is that correct
? And since you mentioned that this is strict priority, according to this
implementation, high priority traffic cannot use 100% of the bw even if
there is no low priority traffic, but low priority traffic can use 100% of
the bw if there is no high priority traffic. Is my understanding correct ?
This doesn't make sense.

On Fri, Feb 19, 2016 at 7:02 AM, Dumitrescu, Cristian <
cristian.dumitrescu at intel.com> wrote:

>
>
>
>
> *From:* sreenaath vasudevan [mailto:sreenaathkv at gmail.com]
> *Sent:* Thursday, February 18, 2016 8:01 PM
> *To:* Dumitrescu, Cristian 
> *Cc:* dev at dpdk.org
> *Subject:* Re: [dpdk-dev] DPDK-QoS - link sharing across classes
>
>
>
> Hi Cristian
>
> Thanks for detailed response.
>
> Your solution works so long as I have four queues in my current
> implementation.
>
> [Cristian] Yes, I was relying on you saying you can actually group Q0 and
> Q1 together, as well as Q2 and Q3, Q4 and Q5, Q6 and Q7.
>
>
>
> Following are the two issues I have now
>
> 1. I have 8 queues in the current implementation. This means I need to map
> the existing 8 queues to two sets of 4 queues across two different classes
> (C0 and C1) in DPDK-QOs right? The problem with that approach is that queue
> weights are not relative across classes. Is there a way to work around this?
>
> [Cristian] You can, of course, change to code to implement 8 queues per
> pipe traffic class, but this is not going to be a trivial exercise. With
> the current implementation unmodified, you could simply map 4 queues to
> e.g. TC0 and 4 queues to e.g. TC1, provided that it makes sense to
> prioritize the 4 queues of TC0 as higher priority than those 4 queues
> mapped to TC1, so basically you are OK with having strict priority (up to
> an upper limit) between the 2 sets of 4 queues.
>
>
>
>
>
> 2. B/w redistribution -
>  a) The moment I map the current implementation's 8 queues across two
> different classes (say C0 and C1), would remaining b/w be distributed
> across the two classes C0 and C1? Is it true that in the current DPDK-QoS
> implementation, unused b/w gets distributed only to the last class C3?
> Would not un-used b/w from C0 come to C1?
>
> [Cristian] With 4 queues mapped to TC0 and 4 queues mapped to TC1, you can
> set TC0 rate to X% of pipe rate and TC1 rate to 100% of pipe rate. This is
> the idea behind strict priority: the sum of TC rates is usually bigger than
> 100% of pipe rate, but this is fine, as due to strict priority the lowest
> priority TC used (which in this case is TC1, not TC3, as you are not using
> TC2 and TC3 at all) only gets 100% of the pipe rate when no traffic from
> higher priority TCs exists. In this case, the extremes are: (1) TC0 demand
> is high, so TC0 uses everything up to X%, so TC1 can use a max of (100 ?
> X)% and (2) TC0 demand is zero, in which case TC1 is free to use up to 100%
> of pipe rate. So the answers to your 3 questions are: yes/no/yes.
>
>
>
>  b) In current DPDK QoS implemention, if C1 has un-used b/w would that
> get used by C0? Or is it only "lower priority class (C3, more specifically)
> uses the un-used b/w from higher priority classes (C0,C1,C2) ?
>
> [Cristian] Due to strict priority, it does not make sense to think about
> higher priority classes using whatever is not used by low priority classes:
> If high priority classes have traffic to send, they will always be picked
> in the detriment of lower ones; when the high priority classes hit their
> upper limit rate, then they are not allowed to send more, otherwise the
> upper limit makes no sense. So the 

[dpdk-dev] Question about patchset order.

[Kobylinski, MichalX]

Hi Thomas,
I sent in January a patch-set that extends to 24 bits a next_hop field in lpm 
library:
http://dpdk.org/dev/patchwork/patch/10249/
http://dpdk.org/dev/patchwork/patch/10250/

also Jerin Jakob sent his patch-set with ARM architecture support in lpm 
library.
http://dpdk.org/dev/patchwork/patch/10478/
http://dpdk.org/dev/patchwork/patch/10479/
http://dpdk.org/dev/patchwork/patch/10480/

Could you write please, in which order do you prefer to apply these two 
patch-sets?
This information will be helpful to predict the risk and estimate additional 
work.

[dpdk-dev] [PATCH v2 2/3] ring: remove duplicate fields in internal data struct

[Bruce Richardson]

On Tue, Feb 23, 2016 at 03:58:50PM +, Ferruh Yigit wrote:
> On 2/23/2016 3:26 PM, Bruce Richardson wrote:
> > On Thu, Feb 18, 2016 at 11:26:42AM +, Ferruh Yigit wrote:
> >> 1- Remove duplicate nb_rx/tx_queues fields from internals
> >>
> >> Signed-off-by: Ferruh Yigit 
> >> ---
> >>  drivers/net/ring/rte_eth_ring.c | 57 
> >> ++---
> >>  1 file changed, 25 insertions(+), 32 deletions(-)
> >>
> >> diff --git a/drivers/net/ring/rte_eth_ring.c 
> >> b/drivers/net/ring/rte_eth_ring.c
> >> index d92b088..fd87999 100644
> >> --- a/drivers/net/ring/rte_eth_ring.c
> >> +++ b/drivers/net/ring/rte_eth_ring.c
> >> @@ -59,9 +59,6 @@ struct ring_queue {
> >>  };
> >>  
> >>  struct pmd_internals {
> >> -  unsigned nb_rx_queues;
> >> -  unsigned nb_tx_queues;
> >> -
> >>struct ring_queue rx_ring_queues[RTE_PMD_RING_MAX_RX_RINGS];
> >>struct ring_queue tx_ring_queues[RTE_PMD_RING_MAX_TX_RINGS];
> >>  
> >> @@ -138,7 +135,7 @@ eth_dev_set_link_up(struct rte_eth_dev *dev)
> >>  }
> >>  
> >>  static int
> >> -eth_rx_queue_setup(struct rte_eth_dev *dev,uint16_t rx_queue_id,
> >> +eth_rx_queue_setup(struct rte_eth_dev *dev, uint16_t rx_queue_id,
> >>uint16_t nb_rx_desc __rte_unused,
> >>unsigned int socket_id __rte_unused,
> >>const struct rte_eth_rxconf *rx_conf 
> >> __rte_unused,
> >> @@ -165,40 +162,39 @@ static void
> >>  eth_dev_info(struct rte_eth_dev *dev,
> >>struct rte_eth_dev_info *dev_info)
> >>  {
> >> -  struct pmd_internals *internals = dev->data->dev_private;
> >>dev_info->driver_name = drivername;
> >>dev_info->max_mac_addrs = 1;
> >>dev_info->max_rx_pktlen = (uint32_t)-1;
> >> -  dev_info->max_rx_queues = (uint16_t)internals->nb_rx_queues;
> >> -  dev_info->max_tx_queues = (uint16_t)internals->nb_tx_queues;
> >> +  dev_info->max_rx_queues = dev->data->nb_rx_queues;
> >> +  dev_info->max_tx_queues = dev->data->nb_tx_queues;
> > 
> > I'm still not convined this is correct. What happens if a ring PMD is 
> > created
> > with 16 queues (i.e. backed by 16 rings), and then the user uses
> > rte_eth_dev_configure to only actually use 4 queues.
> 
> Right, since user explicitly set 4 queues.
> 
> > The fact that the internal
> > array still has 16 queues will be lost, 
> 
> Not lost exactly, app can re-configure with rte_eth_dev_configure() to
> use 16 queses back and it will work fine.
> 
No, it can't do that, because the vNIC is reporting that the max number of 
queues
supported is now 4, since you now set max_rx_queues = nb_rx_queues.

> > and the device will only ever report
> > 4 as the max number it can support.
> 
> I think this is same for all PMDs, and data->nb_xx_queues reports the
> number of the configured queues, not max number; and indeed for ring PMD
> max queue number is hardcoded in the config file.
Yes, it is consistent with other PMDs as it is. The variables you think are
duplicate and want to remove are the ones that track the max number of queues
to be reported out, so that the app can know how many it can use in a call
to reconfigure.

/Bruce
> 
> I guess you what you refer is "number of queues used in first
> configuration", is there a use case to save this value? And if there is
> does it make sense to application save it instead of PMD, because for
> your sample case application creates ring with rte_eth_from_ring() API,
> so app already knows the initial configured queue number.
> 
> Thanks,
> ferruh

[dpdk-dev] [PATCH v2 2/3] ring: remove duplicate fields in internal data struct

[Ferruh Yigit]

On 2/23/2016 3:26 PM, Bruce Richardson wrote:
> On Thu, Feb 18, 2016 at 11:26:42AM +, Ferruh Yigit wrote:
>> 1- Remove duplicate nb_rx/tx_queues fields from internals
>>
>> Signed-off-by: Ferruh Yigit 
>> ---
>>  drivers/net/ring/rte_eth_ring.c | 57 
>> ++---
>>  1 file changed, 25 insertions(+), 32 deletions(-)
>>
>> diff --git a/drivers/net/ring/rte_eth_ring.c 
>> b/drivers/net/ring/rte_eth_ring.c
>> index d92b088..fd87999 100644
>> --- a/drivers/net/ring/rte_eth_ring.c
>> +++ b/drivers/net/ring/rte_eth_ring.c
>> @@ -59,9 +59,6 @@ struct ring_queue {
>>  };
>>  
>>  struct pmd_internals {
>> -unsigned nb_rx_queues;
>> -unsigned nb_tx_queues;
>> -
>>  struct ring_queue rx_ring_queues[RTE_PMD_RING_MAX_RX_RINGS];
>>  struct ring_queue tx_ring_queues[RTE_PMD_RING_MAX_TX_RINGS];
>>  
>> @@ -138,7 +135,7 @@ eth_dev_set_link_up(struct rte_eth_dev *dev)
>>  }
>>  
>>  static int
>> -eth_rx_queue_setup(struct rte_eth_dev *dev,uint16_t rx_queue_id,
>> +eth_rx_queue_setup(struct rte_eth_dev *dev, uint16_t rx_queue_id,
>>  uint16_t nb_rx_desc __rte_unused,
>>  unsigned int socket_id __rte_unused,
>>  const struct rte_eth_rxconf *rx_conf 
>> __rte_unused,
>> @@ -165,40 +162,39 @@ static void
>>  eth_dev_info(struct rte_eth_dev *dev,
>>  struct rte_eth_dev_info *dev_info)
>>  {
>> -struct pmd_internals *internals = dev->data->dev_private;
>>  dev_info->driver_name = drivername;
>>  dev_info->max_mac_addrs = 1;
>>  dev_info->max_rx_pktlen = (uint32_t)-1;
>> -dev_info->max_rx_queues = (uint16_t)internals->nb_rx_queues;
>> -dev_info->max_tx_queues = (uint16_t)internals->nb_tx_queues;
>> +dev_info->max_rx_queues = dev->data->nb_rx_queues;
>> +dev_info->max_tx_queues = dev->data->nb_tx_queues;
> 
> I'm still not convined this is correct. What happens if a ring PMD is created
> with 16 queues (i.e. backed by 16 rings), and then the user uses
> rte_eth_dev_configure to only actually use 4 queues.

Right, since user explicitly set 4 queues.

> The fact that the internal
> array still has 16 queues will be lost, 

Not lost exactly, app can re-configure with rte_eth_dev_configure() to
use 16 queses back and it will work fine.

> and the device will only ever report
> 4 as the max number it can support.

I think this is same for all PMDs, and data->nb_xx_queues reports the
number of the configured queues, not max number; and indeed for ring PMD
max queue number is hardcoded in the config file.

I guess you what you refer is "number of queues used in first
configuration", is there a use case to save this value? And if there is
does it make sense to application save it instead of PMD, because for
your sample case application creates ring with rte_eth_from_ring() API,
so app already knows the initial configured queue number.

Thanks,
ferruh

[dpdk-dev] [PATCH] vhost: add missing build dependency on librte_net

[Bruce Richardson]

On Fri, Feb 19, 2016 at 09:56:04AM +0800, Yuanhan Liu wrote:
> On Thu, Feb 18, 2016 at 04:07:52PM +0200, Panu Matilainen wrote:
> > >I didn't see the author was cc'ed from my email client:
> > >
> > > Date: Thu, 18 Feb 2016 11:47:43 +0200
> > > From: Panu Matilainen 
> > > To: dev at dpdk.org
> > > Subject: [dpdk-dev] [PATCH] vhost: add missing build dependency on 
> > > librte_net
> > 
> > Hmm, indeed. But this is what git told me (happened to have the whole thing
> > in scrollback buffer):
> > 
> > [pmatilai at sopuli dpdk]$ git send-email --cc="jijiang.liu at intel.com"
> > --cc="huawei.xie at intel.com" -1
> > /tmp/ZAW8ErlHWe/0001-vhost-add-missing-build-dependency-on-librte_net.patch
> > 
> > From: Panu Matilainen 
> > To: dev at dpdk.org
> > Cc: jijiang.liu at intel.com,
> > huawei.xie at intel.com
> > Subject: [PATCH] vhost: add missing build dependency on librte_net
> > Date: Thu, 18 Feb 2016 11:47:43 +0200
> > Message-Id:
> >  > redhat.com>
> > X-Mailer: git-send-email 2.5.0
> > 
> > Send this email? ([y]es|[n]o|[q]uit|[a]ll): a
> > OK. Log says:
> > Server: smtp.corp.redhat.com
> > MAIL FROM:
> > RCPT TO:
> > RCPT TO:
> > RCPT TO:
> > From: Panu Matilainen 
> > To: dev at dpdk.org
> > Cc: jijiang.liu at intel.com,
> > huawei.xie at intel.com
> > Subject: [PATCH] vhost: add missing build dependency on librte_net
> > Date: Thu, 18 Feb 2016 11:47:43 +0200
> > Message-Id:
> >  > redhat.com>
> > X-Mailer: git-send-email 2.5.0
> > 
> > So where do the CC's vanish?
> 
> No idea. I also have met this issue __many__ times before: I made a
> group reply, with lots of people CC'ed, later I then received a copy
> (from the mailing list) with all cc list being vanished -- only
> dev at dpdk.org is left. However, I found the CC list was there while
> I checked the sent box.
> 
> I was firstly thinking it might be an issue of my email client. However,
> I also found same phenomenon from other's reply. Just not sure whether
> they removed the cc list on purpose or not, though. IIRC, this also
> happened to Bruce (CC'ed).
> 

And I thought it was just me! :-)

/Bruce

[dpdk-dev] [PATCH v2 2/3] ring: remove duplicate fields in internal data struct

[Bruce Richardson]

On Thu, Feb 18, 2016 at 11:26:42AM +, Ferruh Yigit wrote:
> 1- Remove duplicate nb_rx/tx_queues fields from internals
> 
> Signed-off-by: Ferruh Yigit 
> ---
>  drivers/net/ring/rte_eth_ring.c | 57 
> ++---
>  1 file changed, 25 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
> index d92b088..fd87999 100644
> --- a/drivers/net/ring/rte_eth_ring.c
> +++ b/drivers/net/ring/rte_eth_ring.c
> @@ -59,9 +59,6 @@ struct ring_queue {
>  };
>  
>  struct pmd_internals {
> - unsigned nb_rx_queues;
> - unsigned nb_tx_queues;
> -
>   struct ring_queue rx_ring_queues[RTE_PMD_RING_MAX_RX_RINGS];
>   struct ring_queue tx_ring_queues[RTE_PMD_RING_MAX_TX_RINGS];
>  
> @@ -138,7 +135,7 @@ eth_dev_set_link_up(struct rte_eth_dev *dev)
>  }
>  
>  static int
> -eth_rx_queue_setup(struct rte_eth_dev *dev,uint16_t rx_queue_id,
> +eth_rx_queue_setup(struct rte_eth_dev *dev, uint16_t rx_queue_id,
>   uint16_t nb_rx_desc __rte_unused,
>   unsigned int socket_id __rte_unused,
>   const struct rte_eth_rxconf *rx_conf 
> __rte_unused,
> @@ -165,40 +162,39 @@ static void
>  eth_dev_info(struct rte_eth_dev *dev,
>   struct rte_eth_dev_info *dev_info)
>  {
> - struct pmd_internals *internals = dev->data->dev_private;
>   dev_info->driver_name = drivername;
>   dev_info->max_mac_addrs = 1;
>   dev_info->max_rx_pktlen = (uint32_t)-1;
> - dev_info->max_rx_queues = (uint16_t)internals->nb_rx_queues;
> - dev_info->max_tx_queues = (uint16_t)internals->nb_tx_queues;
> + dev_info->max_rx_queues = dev->data->nb_rx_queues;
> + dev_info->max_tx_queues = dev->data->nb_tx_queues;

I'm still not convined this is correct. What happens if a ring PMD is created
with 16 queues (i.e. backed by 16 rings), and then the user uses
rte_eth_dev_configure to only actually use 4 queues. The fact that the internal
array still has 16 queues will be lost, and the device will only ever report
4 as the max number it can support.

Regards,
/Bruce

[dpdk-dev] [PATCH 0/3] null driver improvements for testability

[Paul Atkins]

On 23/02/16 15:21, Bruce Richardson wrote:
> On Thu, Feb 18, 2016 at 12:19:58PM +, Paul Atkins wrote:
>>
>> On 17/02/16 17:23, Bruce Richardson wrote:
>>> On Fri, Jan 29, 2016 at 04:47:58PM +, Paul Atkins wrote:
 Hi Thomas,

 On 29/01/16 16:31, Thomas Monjalon wrote:
> Hi Paul,
>
> 2016-01-29 16:18, Paul Atkins:
>> This patchset adds functionality to the null driver help when testing
>> a dataplane that uses dpdk.  The idea is that the the dataplane can
>> have multiple null interfaces attached, and each of theses can be
>> assigned a mac address. Packets can then be injected into the null
>> drivers by adding them to a ring, giving the application complete
>> control of the packets that arrive.  Packets that are sent by a null
>> driver can be stored on a ring, where the application can pick them up
>> and verify it is what was expected.  To allow the application to know
>> when packets have been pulled of the rx ring, counters of the number of
>> times an rx poll has been made are kept, and these can be retrieved via
>> the existing APIs.
> I have not read your code, just read this description.
> It sounds like being a ring PMD. Have you already checked it?
> https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_browse_dpdk_tree_drivers_net_ring_rte-5Feth-5Fring.c=CwICAg=IL_XqQWOjubgfqINi2jTzg=45ezphVDEm8OnEpH-fLWdXvR3RneLhhNZRDLQRgR6LY=wJLO24XFe_B0nZve6mkvocCt7fQWo3PULCTWxrC8rZk=bIWycJrY-PYgzkQsBeRfkl8JCHFcxRAHhHDrqRSzHYs=
 I hadn't seen the ring PMD. I will have a look at it and see if I can make
 it do what i need.

 thanks,
 Paul
>>> Hi Paul,
>>>
>>> any update on this. Your patches are still showing as pending in patchwork, 
>>> but
>>> if ring pmd is more what need, we can set these patches aside as unneeded, 
>>> and
>>> remove them from the patchwork merge backlog.
>> Hi Bruce,
>>
>> Sorry for the delay.  The patchset adds 3 things: assigning a mac addr to
>> the null pmd, adding the rings to the null pmd and adding xstats for how
>> many times the null pmd has been polled.  I could move to using the ring
>> pmd, but I would still need the other 2 parts (mac addr and stats).  It
>> seems like the ring pmd shouldn't really have these two extra things added,
>> but i could do that if it that is preferred over what is in the current
>> patchset.
>>
> Adding a mac address to be reported by the ring PMD should not be a problem.
> Having a stat that tracks polls might be depending on how it is done - if it
> uses an atomic, as in this patchset, it would problematic as it would add a
> severe performance hit for the SP/SC ring case. However, you could get around
> that by copying what is already done in the PMD for tracking packet counts.
>
> Overall, though, it seems that it might be worthwhile doing the work to extend
> the ring pmd rather than turning the null pmd into a second ring one.

Ok, I will make those changes and resubmit - you can mark the current 
patches as unneeded.

thanks,
Paul

>
> Regards,
> /Bruce

[dpdk-dev] [dpdk-virtio] DPDK stopped working on virtio

[Yuanhan Liu]

On Mon, Feb 22, 2016 at 11:00:28PM -0800, Clarylin L wrote:
> I am working with DPDK 2.0.?
> 
> I guess it's not DPDK code issue , but more like an environment issue (as same
> code has been working fine before. It's even working on another setup now).
> Someone might have accidentally changed my setup, and I want to find out what
> made dpdk-virtio stop working.?
> 
> Is DPDK-virtio dependent on any specific modules on the hypervisor? or are
> there any configurations on the hypervisor that would impact the functionality
> of ?virtio?

Nope, none that I can think of.

> or anything else I need to look into and check? My VM is running on
> Ubuntu KVM.

The vhost and virtio log?

--yliu
> 
> On Mon, Feb 22, 2016 at 7:50 PM, Yuanhan Liu 
> wrote:
> 
> On Mon, Feb 22, 2016 at 11:15:57AM -0800, Clarylin L wrote:
> > I am running DPDK application (testpmd) within a VM based on virtio. 
> With
> > the same hypervisor and same DPDK code, it used to work well. But it
> > stopped working since last week. The VM's port could not receive
> anything.
> > I ran tcpdump on host's physical port, bridge interface as well as vnet
> > interface, and did see packets coming in. However on VM's port there was
> > nothing.
> >
> > I ran gdb trying to debug, it hit function virtio_recv_mergeable_pkts(),
> > but nb_used=VIRTQUEUE_NUSED(rxvq) always gave 0. I guess it's because 
> the
> > queue was empty.
> >
> > I enabled the PMD debug logging and the only thing that might be an 
> issue
> > was the following part. Other than this I could not see any thing that
> > could indicate potential issues.
> >
> > Thu Feb 18 19:20:10 2016^@PMD: get_uio_dev(): Could not find uio 
> resource
> > Thu Feb 18 19:20:10 2016^@PMD: virtio_resource_init_by_ioports(): PCI
> Port
> > IO found start=0xc040 with size=0x40
> 
> That could be normal, when you don't bind the driver to igb_uio.
>
> > If someone can give any pointers that I should further look into, that'd
> be
> > very helpful. Appreciate your help!
> 
> What's the last commit you are testing? And what are the steps
> to reproduce it? I have a quick try with vhost-switch example,
> with pkts injected by IXIA; it works fine here.
> 
> Or better, mind do a git bisect? There aren't too many commits
> there. It should be a pretty fast bisect.
> 
> ? ? ? ? --yliu
> 
> 

[dpdk-dev] [PATCH 0/3] null driver improvements for testability

[Bruce Richardson]

On Thu, Feb 18, 2016 at 12:19:58PM +, Paul Atkins wrote:
> 
> 
> On 17/02/16 17:23, Bruce Richardson wrote:
> >On Fri, Jan 29, 2016 at 04:47:58PM +, Paul Atkins wrote:
> >>Hi Thomas,
> >>
> >>On 29/01/16 16:31, Thomas Monjalon wrote:
> >>>Hi Paul,
> >>>
> >>>2016-01-29 16:18, Paul Atkins:
> This patchset adds functionality to the null driver help when testing
> a dataplane that uses dpdk.  The idea is that the the dataplane can
> have multiple null interfaces attached, and each of theses can be
> assigned a mac address. Packets can then be injected into the null
> drivers by adding them to a ring, giving the application complete
> control of the packets that arrive.  Packets that are sent by a null
> driver can be stored on a ring, where the application can pick them up
> and verify it is what was expected.  To allow the application to know
> when packets have been pulled of the rx ring, counters of the number of
> times an rx poll has been made are kept, and these can be retrieved via
> the existing APIs.
> >>>I have not read your code, just read this description.
> >>>It sounds like being a ring PMD. Have you already checked it?
> >>>https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_browse_dpdk_tree_drivers_net_ring_rte-5Feth-5Fring.c=CwICAg=IL_XqQWOjubgfqINi2jTzg=45ezphVDEm8OnEpH-fLWdXvR3RneLhhNZRDLQRgR6LY=wJLO24XFe_B0nZve6mkvocCt7fQWo3PULCTWxrC8rZk=bIWycJrY-PYgzkQsBeRfkl8JCHFcxRAHhHDrqRSzHYs=
> >>I hadn't seen the ring PMD. I will have a look at it and see if I can make
> >>it do what i need.
> >>
> >>thanks,
> >>Paul
> >Hi Paul,
> >
> >any update on this. Your patches are still showing as pending in patchwork, 
> >but
> >if ring pmd is more what need, we can set these patches aside as unneeded, 
> >and
> >remove them from the patchwork merge backlog.
> 
> Hi Bruce,
> 
> Sorry for the delay.  The patchset adds 3 things: assigning a mac addr to
> the null pmd, adding the rings to the null pmd and adding xstats for how
> many times the null pmd has been polled.  I could move to using the ring
> pmd, but I would still need the other 2 parts (mac addr and stats).  It
> seems like the ring pmd shouldn't really have these two extra things added,
> but i could do that if it that is preferred over what is in the current
> patchset.
> 
Adding a mac address to be reported by the ring PMD should not be a problem.
Having a stat that tracks polls might be depending on how it is done - if it
uses an atomic, as in this patchset, it would problematic as it would add a
severe performance hit for the SP/SC ring case. However, you could get around
that by copying what is already done in the PMD for tracking packet counts.

Overall, though, it seems that it might be worthwhile doing the work to extend
the ring pmd rather than turning the null pmd into a second ring one.

Regards,
/Bruce

[dpdk-dev] [PATCH 4/5] mlx5: add support for flow director

[Bruce Richardson]

On Thu, Feb 18, 2016 at 05:10:16PM +0100, Adrien Mazarguil wrote:
> Hi Bruce,
> 
> On Wed, Feb 17, 2016 at 05:13:44PM +, Bruce Richardson wrote:
> > On Fri, Jan 29, 2016 at 11:32:01AM +0100, Adrien Mazarguil wrote:
> > > From: Yaacov Hazan 
> > > 
> > > Add support for flow director filters (RTE_FDIR_MODE_PERFECT and
> > > RTE_FDIR_MODE_PERFECT_MAC_VLAN modes).
> > > 
> > > This feature requires MLNX_OFED 3.2.
> > > 
> > > Signed-off-by: Yaacov Hazan 
> > > Signed-off-by: Adrien Mazarguil 
> > > ---
> > Hi Adrien, Yaacov,
> > 
> > this patch raises a lot of warnings (17) with checkpatch. Can you perhaps 
> > look
> > to see if this number can be reduced.
> 
> We actually did it before submitting that patch, there is indeed a bunch of
> remaining warnings that have been left on purpose. Not sure if we have the
> same configuration for checkpatch, but they should fall into the following
> categories:
> 
> - "WARNING: return of an errno should typically be negative" - All return
>   values are documented in the code. Since this PMD uses syscalls in its
>   control path, it uses positive errno values internally for
>   consistency. Public callback functions however return negative error
>   values.
> 
> - "WARNING: line over 80 characters" - Well, although I'm a big fan of the
>   80 characters limit, breaking those would have made the code harder to
>   read.
> 
> - "WARNING: Missing a blank line after declarations" - It's actually a
>   declaration through a macro, there is no missing blank line.
> 
> - "WARNING: networking block comments don't use an empty /* line" - Not sure
>   if we really care? I don't particularly mind.
> 
> - "CHECK: Comparison to NULL could be written "!" - I do not mind either,
>   writing the full check seems clearer to me.
> 
> - "CHECK: Unnecessary parentheses around fdir_info->mask" - Looks like a
>   valid, although minor error.
> 
> Please tell me which of these still need to be fixed.
> 
> -- 
Hi Adrien,

sorry for the delayed reply, I was out for a couple of days.

As none of the above are errors, I'm not going to mandate that they be fixed
before I merge in the patch, so long as you as maintainer are happy with them.

My request mainly came about because of the sheer number of warnings that were
being flagged. To keep the codebase clean requires constant discipline, so I
don't like seeing patches where 17 warnings are flagged. I was hoping since
a new rev of the set was likely anyway that some steps could be taken to reduce
that number.

Thomas, any thoughts here, since I'm still "learning the ropes" as committer. 
Do you have any rules-of-thumb or guidelines as regards checkpatch warnings? The
contributor guide only seems to cover running checkpatch, not anything about
what to do with the output.

Regards,
/Bruce

[dpdk-dev] [PATCH v4] eal: add function to check if primary proc alive

[Harry van Haaren]

This patch adds a new function to the EAL API:
int rte_eal_primary_proc_alive(const char *path);

The function indicates if a primary process is alive right now.
This functionality is implemented by testing for a write-
lock on the config file, and the function tests for a lock.

The use case for this functionality is that a secondary
process can wait until a primary process starts by polling
the function and waiting. When the primary is running, the
secondary continues to poll to detect if the primary process
has quit unexpectedly, the secondary process can detect this.

The RTE_MAGIC number is written to the shared config by the
primary process, this is the signal to the secondary process
that the EAL is set up, and ready to be used. The function
rte_eal_mcfg_complete() writes RTE_MAGIC. This has been
delayed in the EAL init proceedure, as the PCI probing in
the primary process can interfere with the secondary running.

Signed-off-by: Harry van Haaren 
---

v4:
- Rebased to git head (2.3 -> 16.04 changes)

v3:
- Fixed Copyright years

v2:
- Passing NULL as const char* uses default /var/run/.rte_config
- Moved code into /common/ instead of /linuxapp/, should work on BSD now

 doc/guides/rel_notes/release_16_04.rst  |  6 +++
 lib/librte_eal/bsdapp/eal/Makefile  |  1 +
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  1 +
 lib/librte_eal/common/eal_common_proc.c | 61 +
 lib/librte_eal/common/include/rte_eal.h | 21 -
 lib/librte_eal/linuxapp/eal/Makefile|  3 +-
 lib/librte_eal/linuxapp/eal/eal.c   |  6 +--
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |  1 +
 8 files changed, 95 insertions(+), 5 deletions(-)
 create mode 100644 lib/librte_eal/common/eal_common_proc.c

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 5786f74..8893ad5 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -62,6 +62,12 @@ This section should contain bug fixes added to the relevant 
sections. Sample for
 EAL
 ~~~

+* **Added rte_eal_primary_proc_alive() function**
+
+  A new function ``rte_eal_primary_proc_alive()`` has been added
+  to allow the user to detect if a primary process is running.
+  Use cases for this feature include fault detection, and monitoring
+  using secondary processes.

 Drivers
 ~~~
diff --git a/lib/librte_eal/bsdapp/eal/Makefile 
b/lib/librte_eal/bsdapp/eal/Makefile
index d7ca60b..1c79734 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -63,6 +63,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_alarm.c

 # from common dir
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_lcore.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_proc.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_timer.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_memzone.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_log.c
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map 
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 4f93ab7..15c0d9e 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -146,5 +146,6 @@ DPDK_2.3 {
rte_eal_pci_ioport_write;
rte_eal_pci_map_device;
rte_eal_pci_unmap_device;
+   rte_eal_primary_proc_alive;

 } DPDK_2.2;
diff --git a/lib/librte_eal/common/eal_common_proc.c 
b/lib/librte_eal/common/eal_common_proc.c
new file mode 100644
index 000..c598891
--- /dev/null
+++ b/lib/librte_eal/common/eal_common_proc.c
@@ -0,0 +1,61 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright 2016 Intel Shannon Ltd. All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE 

[dpdk-dev] [PATCH v2 3/3] app/test: add Snow3G tests

[Deepak Kumar JAIN]

Signed-off-by: Deepak Kumar JAIN 
---
 app/test/test_cryptodev.c  | 1037 +++-
 app/test/test_cryptodev.h  |3 +-
 app/test/test_cryptodev_snow3g_hash_test_vectors.h |  415 
 app/test/test_cryptodev_snow3g_test_vectors.h  |  379 +++
 4 files changed, 1831 insertions(+), 3 deletions(-)
 create mode 100644 app/test/test_cryptodev_snow3g_hash_test_vectors.h
 create mode 100644 app/test/test_cryptodev_snow3g_test_vectors.h

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 29e4b29..1983184 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -42,7 +42,8 @@

 #include "test.h"
 #include "test_cryptodev.h"
-
+#include "test_cryptodev_snow3g_test_vectors.h"
+#include "test_cryptodev_snow3g_hash_test_vectors.h"
 static enum rte_cryptodev_type gbl_cryptodev_type;

 struct crypto_testsuite_params {
@@ -68,6 +69,9 @@ struct crypto_unittest_params {
uint8_t *digest;
 };

+#define ALIGN_POW2_ROUNDUP(num, align) \
+   (((num) + (align) - 1) & ~((align) - 1))
+
 /*
  * Forward declarations.
  */
@@ -1748,6 +1752,997 @@ test_AES_CBC_HMAC_AES_XCBC_decrypt_digest_verify(void)
return TEST_SUCCESS;
 }

+/* * Snow3G Tests * */
+static int
+create_snow3g_hash_session(uint8_t dev_id,
+   const uint8_t *key, const uint8_t key_len,
+   const uint8_t aad_len, const uint8_t auth_len,
+   enum rte_crypto_auth_operation op)
+{
+   uint8_t hash_key[key_len];
+
+   struct crypto_unittest_params *ut_params = _params;
+
+   memcpy(hash_key, key, key_len);
+#ifdef RTE_APP_TEST_DEBUG
+   rte_hexdump(stdout, "key:", key, key_len);
+#endif
+   /* Setup Authentication Parameters */
+   ut_params->auth_xform.type = RTE_CRYPTO_SYM_XFORM_AUTH;
+   ut_params->auth_xform.next = NULL;
+
+   ut_params->auth_xform.auth.op = op;
+   ut_params->auth_xform.auth.algo = RTE_CRYPTO_AUTH_SNOW3G_UIA2;
+   ut_params->auth_xform.auth.key.length = key_len;
+   ut_params->auth_xform.auth.key.data = hash_key;
+   ut_params->auth_xform.auth.digest_length = auth_len;
+   ut_params->auth_xform.auth.add_auth_data_length = aad_len;
+   ut_params->sess = rte_cryptodev_sym_session_create(dev_id,
+   _params->auth_xform);
+   TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
+   return 0;
+}
+static int
+create_snow3g_cipher_session(uint8_t dev_id,
+   enum rte_crypto_cipher_operation op,
+   const uint8_t *key, const uint8_t key_len)
+{
+   uint8_t cipher_key[key_len];
+
+   struct crypto_unittest_params *ut_params = _params;
+
+   memcpy(cipher_key, key, key_len);
+
+   /* Setup Cipher Parameters */
+   ut_params->cipher_xform.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
+   ut_params->cipher_xform.next = NULL;
+
+   ut_params->cipher_xform.cipher.algo = RTE_CRYPTO_CIPHER_SNOW3G_UEA2;
+   ut_params->cipher_xform.cipher.op = op;
+   ut_params->cipher_xform.cipher.key.data = cipher_key;
+   ut_params->cipher_xform.cipher.key.length = key_len;
+
+#ifdef RTE_APP_TEST_DEBUG
+   rte_hexdump(stdout, "key:", key, key_len);
+#endif
+   /* Create Crypto session */
+   ut_params->sess = rte_cryptodev_sym_session_create(dev_id,
+   _params->
+   cipher_xform);
+   TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
+   return 0;
+}
+
+static int
+create_snow3g_cipher_operation(const uint8_t *iv, const unsigned iv_len,
+   const unsigned data_len)
+{
+   struct crypto_testsuite_params *ts_params = _params;
+   struct crypto_unittest_params *ut_params = _params;
+   unsigned iv_pad_len = 0;
+
+   /* Generate Crypto op data structure */
+   ut_params->op = rte_crypto_op_alloc(ts_params->op_mpool,
+   RTE_CRYPTO_OP_TYPE_SYMMETRIC);
+   TEST_ASSERT_NOT_NULL(ut_params->op,
+   "Failed to allocate pktmbuf offload");
+
+   /* Set crypto operation data parameters */
+   rte_crypto_op_attach_sym_session(ut_params->op, ut_params->sess);
+
+   struct rte_crypto_sym_op *sym_op = ut_params->op->sym;
+
+   /* set crypto operation source mbuf */
+   sym_op->m_src = ut_params->ibuf;
+
+   /* iv */
+   iv_pad_len = RTE_ALIGN_CEIL(iv_len, 16);
+   sym_op->cipher.iv.data = (uint8_t *)rte_pktmbuf_prepend(ut_params->ibuf
+   , iv_pad_len);
+
+   TEST_ASSERT_NOT_NULL(sym_op->cipher.iv.data, "no room to prepend iv");
+
+   memset(sym_op->cipher.iv.data, 0, iv_pad_len);
+   sym_op->cipher.iv.phys_addr = rte_pktmbuf_mtophys(ut_params->ibuf);
+   sym_op->cipher.iv.length = iv_pad_len;
+
+   rte_memcpy(sym_op->cipher.iv.data, iv, iv_len);
+   sym_op->cipher.data.length = 

[dpdk-dev] [PATCH v2 2/3] qat: add support for Snow3G

[Deepak Kumar JAIN]

Signed-off-by: Deepak Kumar JAIN 
---
 doc/guides/cryptodevs/qat.rst|  8 ++-
 doc/guides/rel_notes/release_16_04.rst   |  4 ++
 drivers/crypto/qat/qat_adf/qat_algs.h|  1 +
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 86 +---
 drivers/crypto/qat/qat_crypto.c  | 10 +++
 5 files changed, 97 insertions(+), 12 deletions(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index 1901842..b5a48ec 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -1,5 +1,5 @@
 ..  BSD LICENSE
-Copyright(c) 2015 Intel Corporation. All rights reserved.
+Copyright(c) 2015-2016 Intel Corporation. All rights reserved.

 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
@@ -47,6 +47,7 @@ Cipher algorithms:
 * ``RTE_CRYPTO_SYM_CIPHER_AES128_CBC``
 * ``RTE_CRYPTO_SYM_CIPHER_AES192_CBC``
 * ``RTE_CRYPTO_SYM_CIPHER_AES256_CBC``
+* ``RTE_CRYPTO_SYM_CIPHER_SNOW3G_UEA2``

 Hash algorithms:

@@ -54,14 +55,15 @@ Hash algorithms:
 * ``RTE_CRYPTO_AUTH_SHA256_HMAC``
 * ``RTE_CRYPTO_AUTH_SHA512_HMAC``
 * ``RTE_CRYPTO_AUTH_AES_XCBC_MAC``
+* ``RTE_CRYPTO_SYM_CIPHER_SNOW3G_UIA2``


 Limitations
 ---

 * Chained mbufs are not supported.
-* Hash only is not supported.
-* Cipher only is not supported.
+* Hash only is not supported except Snow3G UIA2.
+* Cipher only is not supported except Snow3G UEA2.
 * Only in-place is currently supported (destination address is the same as 
source address).
 * Only supports the session-oriented API implementation (session-less APIs are 
not supported).
 * Not performance tuned.
diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 123a6fd..ee59bcf 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -39,6 +39,10 @@ This section should contain new features added in this 
release. Sample format:

   Enabled virtio 1.0 support for virtio pmd driver.

+* **Added the support of Snow3g UEA2 Cipher operation for Intel Quick Assist 
Devices.**
+
+   Enabled support for Snow3g Wireless algorithm for Intel Quick Assist 
devices.
+   Support for cipher only, Hash only is also provided laong with alg-chaing 
operations.

 Resolved Issues
 ---
diff --git a/drivers/crypto/qat/qat_adf/qat_algs.h 
b/drivers/crypto/qat/qat_adf/qat_algs.h
index b73a5d0..b47dbc2 100644
--- a/drivers/crypto/qat/qat_adf/qat_algs.h
+++ b/drivers/crypto/qat/qat_adf/qat_algs.h
@@ -125,5 +125,6 @@ void qat_alg_ablkcipher_init_dec(struct 
qat_alg_ablkcipher_cd *cd,
unsigned int keylen);

 int qat_alg_validate_aes_key(int key_len, enum icp_qat_hw_cipher_algo *alg);
+int qat_alg_validate_snow3g_key(int key_len, enum icp_qat_hw_cipher_algo *alg);

 #endif
diff --git a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c 
b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
index bef444b..dd27476 100644
--- a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
+++ b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
@@ -376,7 +376,8 @@ int qat_alg_aead_session_create_content_desc_cipher(struct 
qat_session *cdesc,

PMD_INIT_FUNC_TRACE();

-   if (cdesc->qat_cmd == ICP_QAT_FW_LA_CMD_HASH_CIPHER) {
+   if (cdesc->qat_cmd == ICP_QAT_FW_LA_CMD_HASH_CIPHER &&
+   cdesc->qat_hash_alg != ICP_QAT_HW_AUTH_ALGO_SNOW_3G_UIA2) {
cipher =
(struct icp_qat_hw_cipher_algo_blk *)((char *)>cd +
sizeof(struct icp_qat_hw_auth_algo_blk));
@@ -409,13 +410,20 @@ int 
qat_alg_aead_session_create_content_desc_cipher(struct qat_session *cdesc,
else
key_convert = ICP_QAT_HW_CIPHER_KEY_CONVERT;

+   if (cdesc->qat_hash_alg == ICP_QAT_HW_AUTH_ALGO_SNOW_3G_UIA2)
+   key_convert = ICP_QAT_HW_CIPHER_KEY_CONVERT;
+
/* For Snow3G, set key convert and other bits */
if (cdesc->qat_cipher_alg == ICP_QAT_HW_CIPHER_ALGO_SNOW_3G_UEA2) {
key_convert = ICP_QAT_HW_CIPHER_KEY_CONVERT;
ICP_QAT_FW_LA_RET_AUTH_SET(header->serv_specif_flags,
ICP_QAT_FW_LA_NO_RET_AUTH_RES);
-   ICP_QAT_FW_LA_CMP_AUTH_SET(header->serv_specif_flags,
-   ICP_QAT_FW_LA_NO_CMP_AUTH_RES);
+   if (cdesc->qat_cmd == ICP_QAT_FW_LA_CMD_HASH_CIPHER)  {
+   ICP_QAT_FW_LA_RET_AUTH_SET(header->serv_specif_flags,
+   ICP_QAT_FW_LA_RET_AUTH_RES);
+   ICP_QAT_FW_LA_CMP_AUTH_SET(header->serv_specif_flags,
+   ICP_QAT_FW_LA_NO_CMP_AUTH_RES);
+   }
}

cipher->aes.cipher_config.val =
@@ -431,7 +439,6 @@ int qat_alg_aead_session_create_content_desc_cipher(struct 

[dpdk-dev] [PATCH v2 1/3] crypto: add cipher/auth only support

[Deepak Kumar JAIN]

Refactored the existing functionality into
modular form to support the cipher/auth only
functionalities.

Signed-off-by: Deepak Kumar JAIN 
---
 drivers/crypto/qat/qat_adf/qat_algs.h|  18 +-
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 210 ---
 drivers/crypto/qat/qat_crypto.c  | 137 +++
 drivers/crypto/qat/qat_crypto.h  |  10 ++
 4 files changed, 308 insertions(+), 67 deletions(-)

diff --git a/drivers/crypto/qat/qat_adf/qat_algs.h 
b/drivers/crypto/qat/qat_adf/qat_algs.h
index 76c08c0..b73a5d0 100644
--- a/drivers/crypto/qat/qat_adf/qat_algs.h
+++ b/drivers/crypto/qat/qat_adf/qat_algs.h
@@ -3,7 +3,7 @@
  *  redistributing this file, you may do so under either license.
  *
  *  GPL LICENSE SUMMARY
- *  Copyright(c) 2015 Intel Corporation.
+ *  Copyright(c) 2015-2016 Intel Corporation.
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of version 2 of the GNU General Public License as
  *  published by the Free Software Foundation.
@@ -17,7 +17,7 @@
  *  qat-linux at intel.com
  *
  *  BSD LICENSE
- *  Copyright(c) 2015 Intel Corporation.
+ *  Copyright(c) 2015-2016 Intel Corporation.
  *  Redistribution and use in source and binary forms, with or without
  *  modification, are permitted provided that the following conditions
  *  are met:
@@ -104,11 +104,15 @@ struct qat_alg_ablkcipher_cd {

 int qat_get_inter_state_size(enum icp_qat_hw_auth_algo qat_hash_alg);

-int qat_alg_aead_session_create_content_desc(struct qat_session *cd,
-   uint8_t *enckey, uint32_t enckeylen,
-   uint8_t *authkey, uint32_t authkeylen,
-   uint32_t add_auth_data_length,
-   uint32_t digestsize);
+int qat_alg_aead_session_create_content_desc_cipher(struct qat_session *cd,
+   uint8_t *enckey,
+   uint32_t enckeylen);
+
+int qat_alg_aead_session_create_content_desc_auth(struct qat_session *cdesc,
+   uint8_t *authkey,
+   uint32_t authkeylen,
+   uint32_t add_auth_data_length,
+   uint32_t digestsize);

 void qat_alg_init_common_hdr(struct icp_qat_fw_comn_req_hdr *header);

diff --git a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c 
b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
index ceaffb7..bef444b 100644
--- a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
+++ b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
@@ -3,7 +3,7 @@
  *  redistributing this file, you may do so under either license.
  *
  *  GPL LICENSE SUMMARY
- *  Copyright(c) 2015 Intel Corporation.
+ *  Copyright(c) 2015-2016 Intel Corporation.
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of version 2 of the GNU General Public License as
  *  published by the Free Software Foundation.
@@ -17,7 +17,7 @@
  *  qat-linux at intel.com
  *
  *  BSD LICENSE
- *  Copyright(c) 2015 Intel Corporation.
+ *  Copyright(c) 2015-2016 Intel Corporation.
  *  Redistribution and use in source and binary forms, with or without
  *  modification, are permitted provided that the following conditions
  *  are met:
@@ -359,15 +359,139 @@ void qat_alg_init_common_hdr(struct 
icp_qat_fw_comn_req_hdr *header)
   ICP_QAT_FW_LA_NO_UPDATE_STATE);
 }

-int qat_alg_aead_session_create_content_desc(struct qat_session *cdesc,
-   uint8_t *cipherkey, uint32_t cipherkeylen,
-   uint8_t *authkey, uint32_t authkeylen,
-   uint32_t add_auth_data_length,
-   uint32_t digestsize)
+int qat_alg_aead_session_create_content_desc_cipher(struct qat_session *cdesc,
+   uint8_t *cipherkey,
+   uint32_t cipherkeylen)
 {
-   struct qat_alg_cd *content_desc = >cd;
-   struct icp_qat_hw_cipher_algo_blk *cipher = _desc->cipher;
-   struct icp_qat_hw_auth_algo_blk *hash = _desc->hash;
+   struct icp_qat_hw_cipher_algo_blk *cipher;
+   struct icp_qat_fw_la_bulk_req *req_tmpl = >fw_req;
+   struct icp_qat_fw_comn_req_hdr_cd_pars *cd_pars = _tmpl->cd_pars;
+   struct icp_qat_fw_comn_req_hdr *header = _tmpl->comn_hdr;
+   void *ptr = _tmpl->cd_ctrl;
+   struct icp_qat_fw_cipher_cd_ctrl_hdr *cipher_cd_ctrl = ptr;
+   struct icp_qat_fw_auth_cd_ctrl_hdr *hash_cd_ctrl = ptr;
+   enum icp_qat_hw_cipher_convert key_convert;
+   uint16_t proto = ICP_QAT_FW_LA_NO_PROTO;/* no CCM/GCM/Snow3G */
+   uint16_t cipher_offset = 0;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if 

[dpdk-dev] [PATCH v2 0/3] Snow3G support for Intel Quick Assist Devices

[Deepak Kumar JAIN]

 This patchset contains fixes and refactoring for Snow3G(UEA2 and
 UIA2) wireless algorithm for Intel Quick Assist devices.

 QAT PMD previously supported only cipher/hash alg-chaining for AES/SHA.
 The code has been refactored to also support cipher-only and hash  only (for 
Snow3G only) functionality along with alg-chaining.

 Changes from v1: 

 1) Hash only fix and alg chainging fix

 2) Added hash test vectors for snow3g UIA2 functionality.

 This patchset depends on
 Cryptodev API changes 
 http://dpdk.org/ml/archives/dev/2016-February/033551.html

Deepak Kumar JAIN (3):
  crypto: add cipher/auth only support
  qat: add support for Snow3G
  app/test: add Snow3G tests

 app/test/test_cryptodev.c  | 1037 +++-
 app/test/test_cryptodev.h  |3 +-
 app/test/test_cryptodev_snow3g_hash_test_vectors.h |  415 
 app/test/test_cryptodev_snow3g_test_vectors.h  |  379 +++
 doc/guides/cryptodevs/qat.rst  |8 +-
 doc/guides/rel_notes/release_16_04.rst |4 +
 drivers/crypto/qat/qat_adf/qat_algs.h  |   19 +-
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c   |  280 +-
 drivers/crypto/qat/qat_crypto.c|  147 ++-
 drivers/crypto/qat/qat_crypto.h|   10 +
 10 files changed, 2228 insertions(+), 74 deletions(-)
 create mode 100644 app/test/test_cryptodev_snow3g_hash_test_vectors.h
 create mode 100644 app/test/test_cryptodev_snow3g_test_vectors.h

-- 
2.1.0

[dpdk-dev] [PATCH v2 0/5] add dpdk packet capture support for tcpdump

[Pattan, Reshma]

Hi,

> -Original Message-
> From: Pavel Fedin [mailto:p.fedin at samsung.com]
> Sent: Thursday, February 18, 2016 2:08 PM
> To: Pattan, Reshma ; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 0/5] add dpdk packet capture support for
> tcpdump
> 
> 
>  1. Perhaps, ability to separate queues is useful for something. But not 
> always.
> For example, what if i want to capture all the traffic which passes through 
> some
> interface (common use case)? For example, with OpenVSwitch i can have 9
> queues on my networking card. So, i have to enumerate all of them:
> (0,0)(0,1)(0,2)... It's insane and inconvenient with many queues. What if you
> could have shorthand notation, like (0) or (0,*) for this?

I will fix this in my next version of patch.

>  2. What if i don't want separate RX and TX streams either? It only prevents 
> me
> from seeing the complete picture.

Do you mean not to have separate pcap files for tx and rx? If so, I would 
prefer to keep this as it is.
Because pcap changes need to be replaced with TUN/TAP pmd once available in 
future. 

>  3. vhostuser ports are missing. Perhaps not really related to this patchset, 
> i just
> don't know how much code "server" part of vhostuser shares with normal PMDs,
> but anyway, ability to dump them too would be nice to have.
> 

I think this can be done in future i.e. when vhost as PMD is available. But as 
of now vhost is library.

>  Not directly related, but could we have some interface to tcpdump or
> wireshark? Would be good to have ability to dump packets in real time.

This  can be done in future once KNI or TUN/TAP PMDs is  available in DPDK.

Thanks,
Reshma

[dpdk-dev] [dpdk-dev, v3] Implement memcmp using Intel SIMD instrinsics.

[Wang, Zhihong]

> > It'd be great if you could format this patch into a patch set with several
> > little ones. :-)
> > Also, the kernel checkpatch is very helpful.
> > Good coding style and patch organization make it easy for in-depth reviews.
> > 
> Combination of scalar and vector (32/64/128) was done to get optimal 
> performance numbers. If there is enough interest in this I can work on it and 
> provide an updated patch set.

That'll be very helpful! Looking forward to your patch :)
BTW, have you tested real example performance with your patch?

[dpdk-dev] [PATCH v1 0/3] Add missing ethdev driver support

[Remy Horton]

On 16/02/2016 18:54, Stephen Hemminger wrote:
> On Thu, 28 Jan 2016 08:48:12 +
> Remy Horton  wrote:
>
>> Several rte_eth_dev_* functions are currently only supported
>> by the ixgbe NIC driver. This patchset adds driver support
>> for some of these functions to the i40e, virtio, and vmxnet3
>> drivers.
>
> It is good to make drivers more complete and compatible, but unless
> the virtual driver has some useful data I can't see the point of providing
> these functions in this case. The base infrastructure (rte_ethdev) should
> deal with by returning not supported error (or all zeros); rather than
> creating more code in other drivers for no real gain.

Come to the same conclusion regarding the Rx/Tx queue info functions, as 
working out how to derive the figures I could return was also baking in 
some implicit assumptions. Plan to exclude those ones from the v2.

..Remy

[dpdk-dev] [PATCH] bonding: fix crash when no slave devices

[Bernard Iremonger]

If a bonded device is created when there are no slave devices
there is loop in bond_ethdev_promiscous_enable() which results
in a segmentation fault.
I have applied a similar fix to bond_ethdev_promiscous_disable()
where a similar loop could occur.

Fixes: 2efb58cbab6e ("bond: new link bonding library")
Signed-off-by: Bernard Iremonger 
---
 drivers/net/bonding/rte_eth_bond_pmd.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c 
b/drivers/net/bonding/rte_eth_bond_pmd.c
index b63c886..78972fc 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -1870,7 +1870,8 @@ bond_ethdev_promiscuous_enable(struct rte_eth_dev 
*eth_dev)
case BONDING_MODE_TLB:
case BONDING_MODE_ALB:
default:
-   rte_eth_promiscuous_enable(internals->current_primary_port);
+   if (internals->slave_count > 0)
+   
rte_eth_promiscuous_enable(internals->current_primary_port);
}
 }

@@ -1898,7 +1899,8 @@ bond_ethdev_promiscuous_disable(struct rte_eth_dev *dev)
case BONDING_MODE_TLB:
case BONDING_MODE_ALB:
default:
-   rte_eth_promiscuous_disable(internals->current_primary_port);
+   if (internals->slave_count > 0)
+   
rte_eth_promiscuous_disable(internals->current_primary_port);
}
 }

-- 
2.6.3

[dpdk-dev] [dpdk-virtio] DPDK stopped working on virtio

[Yuanhan Liu]

On Mon, Feb 22, 2016 at 11:15:57AM -0800, Clarylin L wrote:
> I am running DPDK application (testpmd) within a VM based on virtio. With
> the same hypervisor and same DPDK code, it used to work well. But it
> stopped working since last week. The VM's port could not receive anything.
> I ran tcpdump on host's physical port, bridge interface as well as vnet
> interface, and did see packets coming in. However on VM's port there was
> nothing.
> 
> I ran gdb trying to debug, it hit function virtio_recv_mergeable_pkts(),
> but nb_used=VIRTQUEUE_NUSED(rxvq) always gave 0. I guess it's because the
> queue was empty.
> 
> I enabled the PMD debug logging and the only thing that might be an issue
> was the following part. Other than this I could not see any thing that
> could indicate potential issues.
> 
> Thu Feb 18 19:20:10 2016^@PMD: get_uio_dev(): Could not find uio resource
> Thu Feb 18 19:20:10 2016^@PMD: virtio_resource_init_by_ioports(): PCI Port
> IO found start=0xc040 with size=0x40

That could be normal, when you don't bind the driver to igb_uio.

> If someone can give any pointers that I should further look into, that'd be
> very helpful. Appreciate your help!

What's the last commit you are testing? And what are the steps
to reproduce it? I have a quick try with vhost-switch example,
with pkts injected by IXIA; it works fine here.

Or better, mind do a git bisect? There aren't too many commits
there. It should be a pretty fast bisect.

--yliu

[dpdk-dev] [PATCH] i40e: add VEB switching support for i40e

[Zhe Tao]

On Fri, Feb 19, 2016 at 01:17:41PM +0800, Wu, Jingjing wrote:
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhe Tao
> > Sent: Thursday, January 21, 2016 2:50 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH] i40e: add VEB switching support for i40e
> > 
> > VEB switching feature for i40e is used to enable the switching between the
> >  VSIs connect to the virtual bridge. The old implementation is setting the
> >  virtual bridge mode as VEPA which is port aggregation. Enable the switching
> >  ability by setting the loop back mode for the specific VSIs which connect 
> > to PF
> >  or VFs.
> 
> As I know, there is a known issue about the veb switch on older NVM version.
> I would be better to add a NVM version verification, if version > xx.xx, then 
> enable it?
> 
> Thanks
> Jingjing
> 
Great suggestion, i will add the check for it!
Thanks
Zhe Tao
> > Signed-off-by: Zhe Tao 
> > ---
> >  drivers/net/i40e/i40e_ethdev.c | 48 
> > +++---
> >  1 file changed, 40 insertions(+), 8 deletions(-)
> > 

[dpdk-dev] [PATCH v9 0/3] Add virtio support for arm/arm64

[Santosh Shukla]

Hi Thomas,

On Mon, Feb 22, 2016 at 11:11 AM, Yuanhan Liu
 wrote:
> On Sun, Feb 21, 2016 at 07:47:58PM +0530, Santosh Shukla wrote:
>> v9 patchset to support vfio infrasture for ioport, required for archs example
>> arm64/arm and x86.
>>
>>
>> For virtio inc_vector patch which is not part of v9..its under review, refer 
>> [2].
>>
>> Follow on patch history summary, refer[1]
>> [1] http://comments.gmane.org/gmane.comp.networking.dpdk.devel/32821
>> [2] http://dpdk.org/dev/patchwork/patch/10429/
>>
>> Santosh Shukla (3):
>>   eal/linux: never check iopl for arm
>>   eal/linux: vfio: ignore mapping for ioport region
>>   eal/linux: vfio: add pci ioport support
>>
>>  lib/librte_eal/linuxapp/eal/eal.c  |2 +
>>  lib/librte_eal/linuxapp/eal/eal_pci_vfio.c |   56 
>> ++--
>>  2 files changed, 46 insertions(+), 12 deletions(-)
>
> Series looks good to me:
>
> Reviewed-by: Yuanhan Liu 
>

Request to merge this series, Thanks.

[dpdk-dev] [PATCH v2 1/3] i40e: enable extended tag

[Bruce Richardson]

On Mon, Feb 22, 2016 at 11:59:43AM +0800, Helin Zhang wrote:
> PCIe feature of 'Extended Tag' is important for 40G performance.
> It adds its enabling during each port initialization, to ensure
> the high performance.
> 
> Signed-off-by: Helin Zhang 
> ---
>  doc/guides/rel_notes/release_16_04.rst |  6 
>  drivers/net/i40e/i40e_ethdev.c | 65 
> --
>  2 files changed, 68 insertions(+), 3 deletions(-)
> 
> v2:
>  - Changed the type of return value of i40e_enable_extended_tag() to 'void'.
> 
> diff --git a/doc/guides/rel_notes/release_16_04.rst 
> b/doc/guides/rel_notes/release_16_04.rst
> index 5786f74..bed5779 100644
> --- a/doc/guides/rel_notes/release_16_04.rst
> +++ b/doc/guides/rel_notes/release_16_04.rst
> @@ -46,6 +46,12 @@ This section should contain new features added in this 
> release. Sample format:
>  
>  * **Added vhost-user live migration support.**
>  
> +* **i40e: Enabled extended tag.**
> +
> +  It enabled extended tag by checking and writing corresponding PCI config
> +  space bytes, to boost the performance. In the meanwhile, it deprecated the
> +  legacy way via reading/writing sysfile supported by kernel module of 
> igb_uio.
> +

Hi Helin,

does this really need to go into the release notes? Is it a user-visible change
that affects the user experience in any way?

/Bruce

[dpdk-dev] [PATCH v3 6/6] docs: add release note for qtest virtio container support

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mcnamara, John
> Sent: Monday, February 22, 2016 3:41 PM
> To: Tetsuya Mukawa ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 6/6] docs: add release note for qtest
> virtio container support
> 

Also, could you move the v2 patchset to "Superseded".

[dpdk-dev] [PATCH v2] doc: add doc for i40e pmd driver introduction

[Mcnamara, John]

> -Original Message-
> From: Wu, Jingjing
> Sent: Tuesday, February 23, 2016 1:23 AM
> To: dev at dpdk.org
> Cc: Wu, Jingjing ; Zhang, Helin
> ; Lu, Wenzhuo ; Mcnamara,
> John 
> Subject: [PATCH v2] doc: add doc for i40e pmd driver introduction
> 
> A new doc "i40e.rst" is added to introduce i40e pmd driver.
> 
> Signed-off-by: Jingjing Wu 

Acked-by: John McNamara 

[dpdk-dev] [PATCH v3 1/4] ena: Amazon ENA documentation

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jan Medala
> Sent: Monday, February 22, 2016 7:27 PM
> To: dev at dpdk.org
> Cc: matua at amazon.com; Evgeny Schemeilin 
> Subject: [dpdk-dev] [PATCH v3 1/4] ena: Amazon ENA documentation

Hi,

Thanks for this.

For reference the DPDK Documentation Guidelines are here:

http://dpdk.org/doc/guides/contributing/documentation.html

Some general comments below:

> ---
>  doc/guides/nics/ena.rst | 238

You will need to add the new doc to the index file in the same dir
in order for it to build and be included in the overall docs:

doc/guides/nics/index.rst

You can build and test the docs as follows:

make -j doc-guides-html
firefox build/doc/html/guides/nics/ena.html

make -j doc-guides-pdf
mupdf build/doc/pdf/guides/nics.pdf


> +ENA Poll Mode Driver
> +=

The underline should be the same length as the title and should be
followed by one blank line to separate it from the text. Most titles
in the doc need to be fixed like this.


> +ENA PMD is the DPDK poll-mode driver for the Amazon Elastic Network
> +Adapter (ENA) family.

Maybe better as:

  The ENA PMD is a DPDK poll-mode driver for the Amazon Elastic
  Network Adapter (ENA) family.

Also, you should insert a short description of ENA or link to external
documentation here for people not familiar with ENA.

> +
> +Overview
> +
> +The ENA driver exposes a lightweight management interface with a
> +minimal set of memory mapped registers and extendable command set

s/extendable/an extendable/

> +through an Admin Queue.
> +
> +The driver supports a wide range of ENA adapter, is link-speed

s/adapter/adapters/


> +independent (i.e., the same driver is used for 10GbE, 25GbE, 40GbE,
> +etc.), and it negotiates and supports extendable feature set.

s/extendable/an extendable/


> +
> +Refer to ena_admin_defs.h for the list of supported Get/Set Feature
> +properties.

Use  quotes for filenames, variable, paths, etc, here and elsewhere: 
``ena_admin_defs.h``


> +This is the requested size of receive/transmit queues, while the
> actual size will be the minimum between the requested size and the maximal
> receive/transmit supported by the device.

This line, and the previous one, are very long in relation to the rest of the
lines in the document. Best to make it consistent.



> +How to build the suite?
> +---
> +The build instructions for the DPDK suite should as follows:
> +
> +By default the ENA PMD library will be built into the DPDK library.
> +
> +For configuring and using UIO and VFIO frameworks, please refer the
> +documentation that comes with DPDK suite.

I'd suggest replacing this section with something like:

Building DPDK
-

See the :ref:`DPDK Getting Started Guide for Linux ` for
instructions on how to build DPDK.

By default the ENA PMD library will be built into the DPDK library.

For configuring and using UIO and VFIO frameworks, also refer to the
"Getting Started Guide".


> +
> +Supported ENA adapters
> +
> +Current ENA PMD supports the following ENA adapters including:
> +
> +- 1d0f:ec20 - ENA VF
> +- 1d0f:1ec2 - ENA LLQ VF

Quote the addresses here:

- ``1d0f:ec20`` - ENA VF
- ``1d0f:1ec2`` - ENA LLQ VF



> +
> +Supported Operating Systems
> +---
> +Any Linux distribution fulfilling the conditions described in
> +Dependencies section of DPDK documentation.

s/DPDK/the DPDK/ and maybe add a link.


> +
> +Supported features
> +--
> +- Jumbo frames up to 9K
> +- Port Hardware Statistics
> +- IPv4/TCP/UDP checksum offload
> +- TSO offload
> +- Multiple receive and transmit queues
> +- RSS
> +- Low Latency Queue for Tx
> +
> +Known bugs and Unsupported features in this release
> +---

It would better to just call this section "Unsupported features".


> +Contact Information
> +---
> +Any questions or bugs should be reported to DPDK community and to the
> +ENA PMD
> +maintainers:
> +
> +- Jan Medala 
> +- Jakub Palider 
> +- Netanel Belgazal 
> +- Evgeny Schemeilin 

I would suggest omitting this section and just adding all of these names
to the MAINTAINERS file (if not already done in another patch).


Thanks,

John.

[dpdk-dev] [PATCH] eal: Initial implementation of PQoS EAL extension

[Kantecki, Tomasz]

> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Are you OK with concept behind V2 PQoS patch as described above?
> 
> So you mean that PQoS don't really need some DPDK integration?
> You just want to show how to use it with DPDK?

You are correct. The technology can be used without tight DPDK integration but 
will require users to reach out to existing open source code.
Based on received feedback about EAL PQoS extensions we backed off to sort of a 
sample code.

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

[dpdk-dev] [PATCH v2] doc: add doc for i40e pmd driver introduction

[Jingjing Wu]

A new doc "i40e.rst" is added to introduce i40e pmd driver.

Signed-off-by: Jingjing Wu 
---
 doc/guides/nics/i40e.rst  | 368 ++
 doc/guides/nics/index.rst |   1 +
 2 files changed, 369 insertions(+)
 create mode 100644 doc/guides/nics/i40e.rst

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
new file mode 100644
index 000..4019b41
--- /dev/null
+++ b/doc/guides/nics/i40e.rst
@@ -0,0 +1,368 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+I40E Poll Mode Driver
+==
+
+The I40E PMD (librte_pmd_i40e) provides poll mode driver support
+for the Intel X710/XL710/X722 10/40 Gbps family of adapters.
+
+
+Features
+
+
+Features of the I40E PMD are:
+
+- Multiple queues for TX and RX
+- Receiver Side Scaling (RSS)
+- MAC/VLAN filtering
+- Packet type information
+- Flow director
+- Cloud filter
+- Checksum offload
+- VLAN/QinQ stripping and inserting
+- TSO offload
+- Promiscuous mode
+- Multicast mode
+- Port hardware statistics
+- Jumbo frames
+- Link state information
+- Link flow control
+- Mirror on port, VLAN and VSI
+- Interrupt mode for RX
+- Scattered and gather for TX and RX
+- Vector Poll mode driver
+- DCB
+- VMDQ
+- SR-IOV VF
+- Hot plug
+- IEEE1588/802.1AS timestamping
+
+
+Prerequisites
+-
+
+- Identifying your adapter using `Intel Support
+  `_ and get the latest NVM/FW images.
+
+- Follow the DPDK :ref:`Getting Started Guide for Linux ` to setup 
the basic DPDK environment.
+
+- To get better performance on Intel platforms, please follow the "How to get 
best performance with NICs on Intel platforms"
+  section of the :ref:`Getting Started Guide for Linux `.
+
+
+Pre-Installation Configuration
+--
+
+Config File Options
+~~~
+
+The following options can be modified in the ``config`` file.
+Please note that enabling debugging options may affect system performance.
+
+- ``CONFIG_RTE_LIBRTE_I40E_PMD`` (default ``y``)
+
+  Toggle compilation of the ``librte_pmd_i40e`` driver.
+
+- ``CONFIG_RTE_LIBRTE_I40E_DEBUG_*`` (default ``n``)
+
+  Toggle display of generic debugging messages.
+
+- ``CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC`` (default ``y``)
+
+  Toggle bulk allocation for RX.
+
+- ``CONFIG_RTE_LIBRTE_I40E_INC_VECTOR`` (default ``n``)
+
+  Toggle the use of Vector PMD instead of normal RX/TX path.
+  To enable vPMD for RX, bulk allocation for Rx must be allowed.
+
+- ``CONFIG_RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE`` (default ``y``)
+
+  Toggle to enable RX ``olflags``.
+  This is only meaningful when Vector PMD is used.
+
+- ``CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC`` (default ``n``)
+
+  Toggle to use a 16-byte RX descriptor, by default the RX descriptor is 32 
byte.
+
+- ``CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF`` (default ``64``)
+
+  Number of queues reserved for PF.
+
+- ``CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF`` (default ``4``)
+
+  Number of queues reserved for each SR-IOV VF.
+
+- ``CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM`` (default ``4``)
+
+  Number of queues reserved for each VMDQ Pool.
+
+- ``CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL`` (default ``-1``)
+
+  Interrupt Throttling interval.
+
+
+Driver Compilation
+~~
+
+To compile the I40E PMD see :ref:`Getting Started Guide for Linux ` 
or
+:ref:`Getting Started Guide for FreeBSD ` 

[dpdk-dev] Performance degradation with multiple ports

[Arnon Warshavsky]

Hi Swamy

A somewhat similar degradation (though not with l2fwd)  was experienced by
us as described here
http://dev.dpdk.narkive.com/OL0KiHns/dpdk-dev-missing-prefetch-in-non-vector-rx-function
In our case it surfaced for not using the default configuration and working
in non-vector mode, and it behaved the same for both ixgbe and i40e.

/Arnon

On Tue, Feb 23, 2016 at 5:24 AM, SwamZ  wrote:

> Hi,
>
>  I am trying to find the maximum IO core performance with DPDK-2.2 code
> using l2fwd application. I got the following number in comparison with
> DPDK-1.7 code.
>
>
>One Port  Two ports
>
>  DPDK 2.2   14.86Mpps per port   11.8Mpps per port
>
>  DPDK 1.7   11.8Mpps per port 11.8Mpps per port
>
>
>
> Traffic rate from Router tester: 64bytes packet with 100% line rate
> (14.86Mpps per port)
>
> CPU Speed : 3.3GHz
>
> NIC   : 82599ES 10-Gigabit
>
> IO Virtualization: SR-IOV
>
> Command used: ./l2fwd -c 3 -w :02:00.1 -w :02:00.0 -- -p 3 -T 1
>
>
> Note:
>
>  - Both the ports are in same NUMA node. I got the same results with full
> CPU core as well as hyper-theraded core.
>
>  - PCIe speed is same for both the ports. Attached the lspci and other
> relevant output.
>
>  - In multiple port case, each core was receiving only 11.8Mpps. This means
> that RX is the bottleneck.
>
>
> Questions:
>
>  1) For two ports case, I am getting only 11.8Mpps per port compared to
> single port case, for which I got line rate. What could be the reason for
> this performance degradation? I was looking at the DPDK mail archive and
> found the following article similar to this and couldn?t conclude anything.
>
> http://dpdk.org/ml/archives/dev/2013-May/000115.html
>
>
>  2) Did anybody try this kind of performance test for i40E NIC?
>
>
> Thanks,
>
> Swamy
>

[dpdk-dev] [PATCH] virtio: fix rx ring descriptor starvation

[Xie, Huawei]

On 2/23/2016 12:23 AM, Tom Kiely wrote:
> Hi,
> Sorry I missed the last few messages until now. I'm happy with
> just removing the "if". Kyle, when you say you fixed it, do you mean
> that you will push the patch or have already done so ?
>Thanks,
>Tom
>
> On 02/18/2016 02:03 PM, Kyle Larose wrote:
>> On Tue, Jan 5, 2016 at 2:13 AM, Xie, Huawei 
>> wrote:
>>> On 12/17/2015 7:18 PM, Tom Kiely wrote:

 On 11/25/2015 05:32 PM, Xie, Huawei wrote:
> On 11/13/2015 5:33 PM, Tom Kiely wrote:
>> If all rx descriptors are processed while transient
>> mbuf exhaustion is present, the rx ring ends up with
>> no available descriptors. Thus no packets are received
>> on that ring. Since descriptor refill is performed post
>> rx descriptor processing, in this case no refill is
>> ever subsequently performed resulting in permanent rx
>> traffic drop.
>>
>> Signed-off-by: Tom Kiely 
>> ---
>>drivers/net/virtio/virtio_rxtx.c |6 --
>>1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/virtio/virtio_rxtx.c
>> b/drivers/net/virtio/virtio_rxtx.c
>> index 5770fa2..a95e234 100644
>> --- a/drivers/net/virtio/virtio_rxtx.c
>> +++ b/drivers/net/virtio/virtio_rxtx.c
>> @@ -586,7 +586,8 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf
>> **rx_pkts, uint16_t nb_pkts)
>>if (likely(num > DESC_PER_CACHELINE))
>>num = num - ((rxvq->vq_used_cons_idx + num) %
>> DESC_PER_CACHELINE);
>>-if (num == 0)
>> +/* Refill free descriptors even if no pkts recvd */
>> +if (num == 0 && virtqueue_full(rxvq))
> Should the return condition be that no used buffers and we have avail
> descs in avail ring, i.e,
>   num == 0 && rxvq->vq_free_cnt != rxvq->vq_nentries
>
> rather than
>   num == 0 && rxvq->vq_free_cnt == 0
 Yes we could do that but I don't see a good reason to wait until the
 vq_free_cnt == vq_nentries
 before attempting the refill. The existing code will attempt refill
 even if only 1 packet was received
 and the free count is small. To me it seems safer to extend that to
 try refill even if no packet was received
 but the free count is non-zero.
>>> The existing code attempt to refill only if 1 packet was received.
>>>
>>> If we want to refill even no packet was received, then the strict
>>> condition should be
>>>  num == 0 && rxvq->vq_free_cnt != rxvq->vq_nentries
>>>
>>> The safer condition, what you want to use,  should be
>>>  num == 0 && !virtqueue_full(...)
>>> rather than
>>>  num == 0 && virtqueue_full(...)
>>>
>>> We could simplify things a bit, just remove this check, if the
>>> following
>>> receiving code already takes care of the "num == 0" condition.
>>>
>> FWIW, I fixed this issue myself by just removing the if(num == 0)
>> checks entirely. I didn't see any benefit in short-circuiting a loop
>> which pretty much does nothing anyway when num == 0. Further, we only
>> hit this case when there's no packets to receive, which means there's
>> probably a few cycles to spare. This is even simpler.

Yes, as i said, that is the simplest fix.

>>
>>> I find virtqueue_full is confusing, maybe we could change it to some
>>> other meaningful name.
>>>
 Tom

>>return 0;
>>  num = virtqueue_dequeue_burst_rx(rxvq, rcv_pkts, len, num);
>> @@ -683,7 +684,8 @@ virtio_recv_mergeable_pkts(void *rx_queue,
>>  virtio_rmb();
>>-if (nb_used == 0)
>> +/* Refill free descriptors even if no pkts recvd */
>> +if (nb_used == 0 && virtqueue_full(rxvq))
>>return 0;
>>  PMD_RX_LOG(DEBUG, "used:%d\n", nb_used);

>
>

[dpdk-dev] [PATCH RFC 4/4] doc: add note about rte_vhost_enqueue_burst thread safety.

[Xie, Huawei]

On 2/22/2016 6:16 PM, Thomas Monjalon wrote:
> 2016-02-22 02:07, Xie, Huawei:
>> On 2/19/2016 5:05 PM, Ilya Maximets wrote:
>>> On 19.02.2016 11:36, Xie, Huawei wrote:
 On 2/19/2016 3:10 PM, Yuanhan Liu wrote:
> On Fri, Feb 19, 2016 at 09:32:43AM +0300, Ilya Maximets wrote:
>> Signed-off-by: Ilya Maximets 
>> ---
>>  doc/guides/prog_guide/thread_safety_dpdk_functions.rst | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/doc/guides/prog_guide/thread_safety_dpdk_functions.rst 
>> b/doc/guides/prog_guide/thread_safety_dpdk_functions.rst
>> index 403e5fc..13a6c89 100644
>> --- a/doc/guides/prog_guide/thread_safety_dpdk_functions.rst
>> +++ b/doc/guides/prog_guide/thread_safety_dpdk_functions.rst
>>  The mempool library is based on the DPDK lockless ring library and 
>> therefore is also multi-thread safe.
>> +rte_vhost_enqueue_burst() is also thread safe because based on lockless 
>> ring-buffer algorithm like the ring library.
> FYI, Huawei meant to make rte_vhost_enqueue_burst() not be thread-safe,
> to aligh with the usage of rte_eth_tx_burst().
>
>   --yliu
 I have a patch to remove the lockless enqueue. Unless there is strong
 reason, i prefer vhost PMD to behave like other PMDs, with no internal
 lockless algorithm. In future, for people who really need it, we could
 have dynamic/static switch to enable it.
>> Thomas, what is your opinion on this and my patch removing lockless enqueue?
> The thread safety behaviour is part of the API specification.
> If we want to enable/disable such behaviour, it must be done with an API
> function. But it would introduce a conditional statement in the fast path.
> That's why the priority must be to keep a simple and consistent behaviour
> and try to build around. An API complexity may be considered only if there
> is a real (measured) gain.

Let us put the gain aside temporarily. I would do the measurement.
Vhost is wrapped as a PMD in Tetsuya's patch. And also in DPDK OVS's
case, it is wrapped as a vport like all other physical ports. The DPDK
app/OVS will treat all ports equally. It will add complexity if the app
needs to know that some supports concurrency while some not. Since all
other PMDs doesn't support thread safety, it doesn't make sense for
vhost PMD to support that. I believe the APP will not use that behavior.
>From the API's point of view, if we previously implemented it wrongly,
we need to fix it as early as possible.

>
>

[dpdk-dev] [PATCH v6 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API

[Xie, Huawei]

On 2/22/2016 10:52 PM, Xie, Huawei wrote:
> On 2/4/2016 1:24 AM, Olivier MATZ wrote:
>> Hi,
>>
>> On 01/27/2016 02:56 PM, Panu Matilainen wrote:
>>> Since rte_pktmbuf_alloc_bulk() is an inline function, it is not part of
>>> the library ABI and should not be listed in the version map.
>>>
>>> I assume its inline for performance reasons, but then you lose the
>>> benefits of dynamic linking such as ability to fix bugs and/or improve
>>> itby just updating the library. Since the point of having a bulk API is
>>> to improve performance by reducing the number of calls required, does it
>>> really have to be inline? As in, have you actually measured the
>>> difference between inline and non-inline and decided its worth all the
>>> downsides?
>> Agree with Panu. It would be interesting to compare the performance
>> between inline and non inline to decide whether inlining it or not.
> Will update after i gathered more data. inline could show obvious
> performance difference in some cases.

Panu and Oliver:
I write a simple benchmark. This benchmark run 10M rounds, in each round
8 mbufs are allocated through bulk API, and then freed.
These are the CPU cycles measured(Intel(R) Xeon(R) CPU E5-2680 0 @
2.70GHz, CPU isolated, timer interrupt disabled, rcu offloaded).
Btw, i have removed some exceptional data, the frequency of which is
like 1/10. Sometimes observed user usage suddenly disappeared, no clue
what happened.

With 8 mbufs allocated, there is about 6% performance increase using inline.
inlinenon-inline
2780732950309416
28348536962951378072
28230153202954500888
28250600322958939912
28244998042898938284
28108597202944892796
28522294203014273296
27873085002956809852
27933372602958674900
2834762954346352
27854551842925719136
28215286242937380416
28229221362974978604
27766459202947666548
28159525722952316900
28010487402947366984
28514626722946469004

With 16 mbufs allocated, we could still observe obvious performance
difference, though only 1%-2%

inlinenon-inline
55199870845669902680
55384160965737646840
55789340645590165532
55481319725767926840
56255856965831345628
55582828765662223764
54455877685641003924
55590963205775258444
56564379885743969272
54409394045664882412
54988759685785138532
55616528085737123940
55152117165627775604
55505671405630790628
56659642805589568164
55912959005702697308

With 32/64 mbufs allocated, the deviation of the data itself would hide
the performance difference.

So we prefer using inline for performance.
>> Also, it would be nice to have a simple test function in
>> app/test/test_mbuf.c. For instance, you could update
>> test_one_pktmbuf() to take a mbuf pointer as a parameter and remove
>> the mbuf allocation from the function. Then it could be called with
>> a mbuf allocated with rte_pktmbuf_alloc() (like before) and with
>> all the mbufs of rte_pktmbuf_alloc_bulk().

Don't quite get you. Is it that we write two cases, one case allocate
mbuf through rte_pktmbuf_alloc_bulk and one use rte_pktmbuf_alloc? It is
good to have. I could do this after this patch.
>>
>> Regards,
>> Olivier
>>
>

[dpdk-dev] [PATCH v2] ixgbe: Fix disable interrupt twice

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Qiu
> Sent: Friday, January 29, 2016 1:58 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] ixgbe: Fix disable interrupt twice
> 
> Currently, ixgbe vf and pf will disable interrupt twice in stop stage and 
> uninit
> stage. It will cause an error:
> 
> testpmd> quit
> 
> Shutting down port 0...
> Stopping ports...
> Done
> Closing ports...
> EAL: Error disabling MSI-X interrupts for fd 26
> Done
> 
> Becasue the interrupt already been disabled in stop stage.
> Since it is enabled in init stage, better remove from stop stage.
> 
> Fixes: 0eb609239efd ("ixgbe: enable Rx queue interrupts for PF and VF")
> 
> Signed-off-by: Michael Qiu 
Acked-by: Helin Zhang 

> ---
>  v2 --> v1:
>  fix error in commit log word "interrupte"
> 
>  drivers/net/ixgbe/ixgbe_ethdev.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 4c4c6df..a561f8d 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -2192,9 +2192,6 @@ ixgbe_dev_stop(struct rte_eth_dev *dev)
>   /* disable interrupts */
>   ixgbe_disable_intr(hw);
> 
> - /* disable intr eventfd mapping */
> - rte_intr_disable(intr_handle);
> -
>   /* reset the NIC */
>   ixgbe_pf_reset_hw(hw);
>   hw->adapter_stopped = 0;
> @@ -3898,9 +3895,6 @@ ixgbevf_dev_stop(struct rte_eth_dev *dev)
> 
>   ixgbe_dev_clear_queues(dev);
> 
> - /* disable intr eventfd mapping */
> - rte_intr_disable(intr_handle);
> -
>   /* Clean datapath event and queue/vec mapping */
>   rte_intr_efd_disable(intr_handle);
>   if (intr_handle->intr_vec != NULL) {
> --
> 1.9.3

[dpdk-dev] [PATCH v1 1/3] drivers/net/i40e: Add ethdev functions

[Zhang, Helin]

> -Original Message-
> From: Horton, Remy
> Sent: Thursday, January 28, 2016 4:48 PM
> To: Zhang, Helin; Xie, Huawei; yongwang at vmware.com
> Cc: dev at dpdk.org
> Subject: [PATCH v1 1/3] drivers/net/i40e: Add ethdev functions
> 
> Implements driver support for dumping of EEPROM and registers, and the
> settngs of MAC address.
> 
> Signed-off-by: Remy Horton 
> ---
>  doc/guides/rel_notes/release_2_3.rst |   5 +
>  drivers/net/i40e/i40e_ethdev.c   | 130 +-
>  drivers/net/i40e/i40e_regs.h | 814
> +++
>  3 files changed, 947 insertions(+), 2 deletions(-)  create mode 100644
> drivers/net/i40e/i40e_regs.h
> 
> diff --git a/doc/guides/rel_notes/release_2_3.rst
> b/doc/guides/rel_notes/release_2_3.rst
> index 99de186..2ac48dd 100644
> --- a/doc/guides/rel_notes/release_2_3.rst
> +++ b/doc/guides/rel_notes/release_2_3.rst
> @@ -4,6 +4,11 @@ DPDK Release 2.3
>  New Features
>  
> 
> +* **i40e: Added ethdev support functions.**
> +
> +  Implemented driver functions for Register dumping, EEPROM dumping,
> + and  setting of MAC address.
> +
> 
>  Resolved Issues
>  ---
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index bf6220d..2f39358 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -1,7 +1,7 @@
>  /*-
>   *   BSD LICENSE
>   *
> - *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> + *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
>   *   All rights reserved.
>   *
>   *   Redistribution and use in source and binary forms, with or without
> @@ -61,6 +61,7 @@
>  #include "i40e_ethdev.h"
>  #include "i40e_rxtx.h"
>  #include "i40e_pf.h"
> +#include "i40e_regs.h"
> 
>  /* Maximun number of MAC addresses */
>  #define I40E_NUM_MACADDR_MAX   64
> @@ -414,6 +415,22 @@ static int i40e_dev_rx_queue_intr_enable(struct
> rte_eth_dev *dev,  static int i40e_dev_rx_queue_intr_disable(struct
> rte_eth_dev *dev,
> uint16_t queue_id);
> 
> +static int i40e_get_reg_length(struct rte_eth_dev *dev);
> +
> +static int i40e_get_regs(struct rte_eth_dev *dev,
> +  struct rte_dev_reg_info *regs);
> +
> +static int i40e_get_eeprom_length(struct rte_eth_dev *dev);
> +
> +static int i40e_get_eeprom(struct rte_eth_dev *dev,
> +struct rte_dev_eeprom_info *eeprom);
> +
> +static int i40e_set_eeprom(struct rte_eth_dev *dev,
> +struct rte_dev_eeprom_info *eeprom);
> +
> +static void i40e_set_default_mac_addr(struct rte_eth_dev *dev,
> +   struct ether_addr *mac_addr);
> +
> 
>  static const struct rte_pci_id pci_id_i40e_map[] = {  #define
> RTE_PCI_DEV_ID_DECL_I40E(vend, dev) {RTE_PCI_DEVICE(vend, dev)}, @@
> -482,6 +499,12 @@ static const struct eth_dev_ops i40e_eth_dev_ops = {
>   .timesync_adjust_time = i40e_timesync_adjust_time,
>   .timesync_read_time   = i40e_timesync_read_time,
>   .timesync_write_time  = i40e_timesync_write_time,
> + .get_reg_length   = i40e_get_reg_length,
> + .get_reg  = i40e_get_regs,
> + .get_eeprom_length= i40e_get_eeprom_length,
> + .get_eeprom   = i40e_get_eeprom,
> + .set_eeprom   = i40e_set_eeprom,
> + .mac_addr_set = i40e_set_default_mac_addr,
>  };
> 
>  /* store statistics names and its offset in stats structure */ @@ -8077,7
> +8100,6 @@ i40e_parse_dcb_configure(struct rte_eth_dev *dev,
>   return 0;
>  }
> 
> -
>  static enum i40e_status_code
>  i40e_vsi_update_queue_mapping(struct i40e_vsi *vsi,
> struct i40e_aqc_vsi_properties_data *info, @@ -
> 8532,3 +8554,107 @@ i40e_dev_rx_queue_intr_disable(struct rte_eth_dev
> *dev, uint16_t queue_id)
> 
>   return 0;
>  }
> +
> +static int i40e_get_reg_length(__rte_unused struct rte_eth_dev *dev) {
> + int idx_group = 0;
> + int idx_entry;
> + int count = 0;
> + const struct reg_info *reg_group;
> +
> + while ((reg_group = i40e_regs[idx_group++])) {
> + idx_entry = 0;
> + while ((reg_group[idx_entry].count))
> + count += reg_group[idx_entry++].count + 1;
> + }
> +
> + return count;
> +}
> +
> +static inline int
> +i40e_read_regs(struct i40e_hw *hw, const struct reg_info *reg,
> +uint32_t *reg_buf)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < reg->count; i++)
> + reg_buf[i] = I40E_READ_REG(hw,
> + reg->base_addr + i * reg->stride);
> + return reg->count;
> +}
>From FVL5, some registers should be read by AQ commands, otherwise it may fail 
>to
read without any warning.
Please see my patches of which registers should be read by AQ commands.
Please check i40e_osdep.h from below link. Thanks!