date:20170217

2017-02-16 15:01, Mcnamara, John:
> 
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> > Sent: Wednesday, February 15, 2017 2:55 PM
> > To: Mcnamara, John 
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v1] doc: add template release notes for
> > 17.05
> > 
> > 2017-02-15 12:38, John McNamara:
> > > +   Build the docs and view the output file to ensure the changes are
> > correct::
> > > +
> > > +  make doc-guides-html
> > > +
> > > +  firefox build/doc/html/guides/rel_notes/release_17_05.html
> > 
> > I would suggest xdg-open instead of firefox.
> > It is more open regarding chromium ;)
> 
> I generally use xdg-open, which in my case gives me midori but for the
> docs it is probably better to have something that is easily recognizable
> as a browser. Either way I'm okay if you wish to make the change inline
> during merge. Or would you prefer a V2.

Midori? Seems another interesting choice:)

Applied with this change, thanks

[dpdk-dev] DPDK Technical Board Meeting, 2017-02-15

2017-02-17 Thread Richardson, Bruce

A meeting of the DPDK technical board was held last Wednesday, 2017-02-15. 
Below are the meeting minutes.  

Please note that future meetings will be open to all to attend, as described 
below. The next meeting is planned for March 1st, and any topics to be referred 
to the tech board for discussion at that meeting should be emailed to 
techbo...@dpdk.org by February 26th at the latest.

Regards,
/Bruce

--
Attendees:
Hemant Agrawal, Konstantin Ananyev, Jan Blunck, Stephen Hemminger, Jerin Jacob, 
Yuanhan Liu, Olivier Matz, Thomas Monjalon, Bruce Richardson

Agenda and Notes:
0. General Meeting Admin
 * Bruce Richardson volunteered to chair this meeting (Meeting chair was 
previously agreed to be a rotating role.)
 * Olivier Matz volunteered to chair the next meeting
 * At each future meetings, the chair for the next meeting will be decided and 
that person also has the responsibility of preparing the meeting agenda ahead 
of time.
 * Next meeting was agreed to be at the same time in two weeks - 1st March @ 
3pm UTC (4pm France, 11pm PRC, 7am US Pacific). 
   - Olivier to send a reminder with agenda a few days in advance.

1. Welcome new members to the board, and answer any questions they had about 
technical board operations.
 * Hemant, Jan and Yuanhan were welcomed, but had no questions on tech board at 
this point.

2. Making meetings public
 * LF charter for DPDK specifies that meetings of the techboard should be public
 * Decision made to continue to hold meetings on #dpdk-board channel on IRC
 * Meetings will be announced ahead of time:
- In minutes of previous meeting
- Via separate email a couple of days before the meeting
 * Anyone interested in the board meeting can join the IRC channel and make 
their contribution.
 * Only items on the agreed agenda to be discussed. Any topics to be covered 
must be sent in advance to techbo...@dpdk.org

3. Update board charter on website
 * The website details of the Tech board is out of date, both membership and 
its mode of operation and scope
 * Thomas has already sent one proposed update out via email, in the form of 
patch to the website, and Hemant has already provided one comment
 * Thomas to send out a new draft, and all tech board members to comment or ack 
it to signal agreement.
 * Update won't be applied until all members ack. 
 * If not agreed before next meeting, should be discussed at that meeting

4. Issue of review and timely feedback
 * Discussion focused on review of patches for existing DPDK 
components/libraries
 * Agreed that patch maintainers are primarily responsible for accepting 
patches in their area, and need to ensure sufficient reviews are done
 * Once patch has been sufficiently reviewed, the maintainer should ack the 
patch
 * Any patches which have been acked by the maintainer, and which have no 
subsequent issues raised with them, should be automatically merged to the 
relevant tree after 2 weeks.
 - in case where the ack is received less than 2 weeks before a merge 
deadline, the point at which it can be automatically merged is 2 days before 
the deadline
 - To make a release, a patch must be acked by the maintainer at least 2 
days before the merge deadline.
 * If not merged at the automatic-merge deadline itself, e.g. unavoidable delay 
by committer, any subsequent feedback received should be considered "too late", 
and must be addressed by a follow-on patch, rather than via a revision of the 
original submission.
 * Trivial patches may be merged sooner, or without maintainer ack, at the tree 
committers discretion.

5. Accept and review new libraries
 * Discussion begun on this topic, but no consensus reached before time ran out
 * Most members felt this topic was closely tied to the "scope" of DPDK as a 
project
 * Discussion to continue over email, and to be discussed at the next meeting 
if not resolved before then.

Agenda Topics Not Covered:
* Community questions/issues
* Any action for some old patches/threads?

Action Summary:
* Olivier to prepare agenda for next meeting, and send out reminders
* Thomas to send revised draft of website update for tech board membership etc.

NEXT MEETING:
* 2017 - 03 - 01 @ 3pm UTC

Re: [dpdk-dev] [PATCH] maintainers: claim responsibility for Vhost-user, Virtio PMD & Vhost PMD

2017-02-17 16:49, Yuanhan Liu:
> On Fri, Feb 17, 2017 at 09:31:42AM +0100, Maxime Coquelin wrote:
> > Add myself as co-maintainer for these drivers and library.
> > 
> > Suggested-by: Yuanhan Liu 
> > Signed-off-by: Maxime Coquelin 
> 
> I think it's obvious that Maxime is done great job at reviewing
> vhost/virtio patches. So,
> 
> Acked-by: Yuanhan Liu 

Thanks Yuanhan for proposing.

Acked-by: Thomas Monjalon 

Applied, congratulations for your new responsibilities :)

[dpdk-dev] [PATCH] version: 17.05-rc0

Signed-off-by: Thomas Monjalon 
---
 lib/librte_eal/common/include/rte_version.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_version.h 
b/lib/librte_eal/common/include/rte_version.h
index 979b6c3..c84c748 100644
--- a/lib/librte_eal/common/include/rte_version.h
+++ b/lib/librte_eal/common/include/rte_version.h
@@ -61,7 +61,7 @@ extern "C" {
 /**
  * Minor version/month number i.e. the mm in yy.mm.z
  */
-#define RTE_VER_MONTH 2
+#define RTE_VER_MONTH 5
 
 /**
  * Patch level number i.e. the z in yy.mm.z
@@ -71,14 +71,14 @@ extern "C" {
 /**
  * Extra string to be appended to version number
  */
-#define RTE_VER_SUFFIX ""
+#define RTE_VER_SUFFIX "-rc"
 
 /**
  * Patch release number
  *   0-15 = release candidates
  *   16   = release
  */
-#define RTE_VER_RELEASE 16
+#define RTE_VER_RELEASE 0
 
 /**
  * Macro to compute a version number usable for comparisons
-- 
2.7.0

Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization

Hi Jan,

On Thu, 16 Feb 2017 18:26:39 +0100, Jan Blunck 
wrote:
> On Thu, Feb 16, 2017 at 2:48 PM, Olivier Matz
>  wrote:
> > On Mon, 6 Feb 2017 18:41:27 +, "Ananyev, Konstantin"
> >  wrote:  
> >> >
> >> > The main changes are:
> >> > - reorder structure to increase vector performance on some non-ia
> >> >   platforms.
> >> > - add a 64bits timestamp field in the 1st cache line  
> >>
> >> Wonder why it deserves to be in first cache line?
> >> How it differs from seqn below (pure SW stuff right now).  
> >
> > In case the timestamp is set from a NIC value, it is set in the Rx
> > path. So that's why I think it deserve to be located in the 1st
> > cache line.
> >
> > As you said, the seqn is a pure sw stuff right: it is set in a lib,
> > not in a PMD rx path.
> >  
> 
> If we talk about setting the timestamp value in the RX path this
> implicitly means software timestamps. Hardware timestamping usually
> works by letting the hardware inject sync events for coarse time
> tracking and additionally injecting fine granular per-packet ticks at
> a specific offset in the packet. Out of performance reasons I don't
> think it makes sense to extract this during the burst and write it
> into the mbuf again.

From what I've understand, at least it does not work like this for
mellanox NICs: timestamp is a metadata attached to a rx packet. But
maybe they (and other NIC vendors interrested in the feature) can
confirm or not.

> 
> The problem with timestamps is to get the abstraction right wrt the
> correction factors and the size of the tick vs. the timestamp in the
> events injected. From my perspective it would be better to extract the
> handling of timestamp data into a library with PMD specific
> implementation of the conversions. That way the normalized timestamp
> values can get extracted if they are present. The mbuf itself would
> only indicate the presence of timestamp metadata in that case.

I agree however that we need to properly define the meaning of this
field. My idea is:

- the timestamp is in nanosecond
- the reference is always the same for a given path: if the timestamp is
  set in a PMD, all the packets for this PMD will have the same
  reference, but for 2 different PMDs (or a sw lib), the reference
  would not be the same.

I think it's enough for many use cases.
We can later add helpers to compare timestamps with different
references.


Regards,
Olivier

Re: [dpdk-dev] [PATCH] version: 17.05-rc0

2017-02-17 Thread Bruce Richardson

On Fri, Feb 17, 2017 at 11:42:20AM +0100, Thomas Monjalon wrote:
> Signed-off-by: Thomas Monjalon 

Acked-by: Bruce Richardson

Re: [dpdk-dev] Coverity project created for dpdk-next-net tree

On 1/11/2017 6:57 PM, Ferruh Yigit wrote:
> On 11/21/2016 11:29 PM, Ferruh Yigit wrote:
>> Coverity project created for dpdk-next-net tree:
>> https://scan.coverity.com/projects/dpdk-next-net
>>
>> This can be useful to fix coverity issues before next-net merged into
>> master branch.
>>
>> Project is open for everyone to register and to get scan reports, there
>> will be regular scans for next-net tree.
>>
>> Specially driver maintainers, please consider registering to the project
>> and checking your driver's defect status.
>> I believe there are some false positives, it is appreciated if you can
>> identify and mark them in coverity tool.
>>
>> PS: As a reminder, a coverity project already exists for main dpdk repo:
>> https://scan.coverity.com/projects/dpdk-data-plane-development-kit
>>
> 
> Reminder of the next-net coverity project.
> Project kept up to date with new driver patches merged in.
> 
> Driver maintainers can check and fix issues introduced in next-net
> before sub-tree merged into main tree.

A new coverity scan done for next-net tree for 17.02 release:
https://scan.coverity.com/projects/dpdk-next-net?tab=overview

Driver maintainers, please consider fixing existing defects before
adding more code into 17.05 release.


Thanks,
ferruh

Re: [dpdk-dev] [PATCH] version: 17.05-rc0

On 2/17/2017 10:59 AM, Bruce Richardson wrote:
> On Fri, Feb 17, 2017 at 11:42:20AM +0100, Thomas Monjalon wrote:
>> Signed-off-by: Thomas Monjalon 
> 
> Acked-by: Bruce Richardson 

Hi Thomas,

What do you think about tagging -rc0 releases?

I find it useful for "git describe" output, but not sure if it bloats
ref list.

Thanks,
ferruh

[dpdk-dev] decision process to accept new libraries

2017-02-17 10:22, Richardson, Bruce:
> 4. Issue of review and timely feedback
>  * Discussion focused on review of patches for existing DPDK 
> components/libraries
>  * Agreed that patch maintainers are primarily responsible for accepting 
> patches in their area, and need to ensure sufficient reviews are done
>  * Once patch has been sufficiently reviewed, the maintainer should ack the 
> patch
>  * Any patches which have been acked by the maintainer, and which have no 
> subsequent issues raised with them, should be automatically merged to the 
> relevant tree after 2 weeks.
>  - in case where the ack is received less than 2 weeks before a merge 
> deadline, the point at which it can be automatically merged is 2 days before 
> the deadline
>  - To make a release, a patch must be acked by the maintainer at least 2 
> days before the merge deadline.
>  * If not merged at the automatic-merge deadline itself, e.g. unavoidable 
> delay by committer, any subsequent feedback received should be considered 
> "too late", and must be addressed by a follow-on patch, rather than via a 
> revision of the original submission.
>  * Trivial patches may be merged sooner, or without maintainer ack, at the 
> tree committers discretion.

That's really good to have more rules like the one above.
It will make the process clearer to everyone,
and hopefully will speed up our workflow.

> 5. Accept and review new libraries
>  * Discussion begun on this topic, but no consensus reached before time ran 
> out
>  * Most members felt this topic was closely tied to the "scope" of DPDK as a 
> project
>  * Discussion to continue over email, and to be discussed at the next meeting 
> if not resolved before then.

Let's discuss this important topic.

Deciding to add a library is about deciding the scope of the project.
However I think we do not need to define the DPDK scope now,
but we can define a process to help in scope decisions.
It is a first step which will help us to progress later in scope discussions.

Below are 3 separate (and related) topics to discuss.
Please let's target a decision for the first item only.

1/
I suggest that each new library must be developed in a separate repository
on dpdk.org. Then it can be asked to integrate it in the main project/repo.
Such discussion must happen on the mailing list and the techboard will vote
for the integration of the *existing* library.
I suggest such vote should be done by majority as stated in the LF charter.

2/
We could imagine the same kind of process for removal,
i.e. moving a library or an app outside of DPDK in a separate repository.
If there is a public request with enough discussion, the techboard could vote
for moving some DPDK parts in a separate repository.
The committer would be a volunteer or the current maintainer of the code.
A dedicated mailing-list will be created for the new project.

3/
Why a project scope should be defined?
I think it is important to agree on the long-term goal of defining a scope.
My view on the goal for the main DPDK project (git://dpdk.org/dpdk):
- a consistent set of libraries
- a good quality in every libraries
- contributors interested in every libraries (no community segmentation)
- contributors able to understand every libraries
In less words, a clear project by a strong community of contributors.

Re: [dpdk-dev] [PATCH] version: 17.05-rc0

2017-02-17 10:59, Bruce Richardson:
> On Fri, Feb 17, 2017 at 11:42:20AM +0100, Thomas Monjalon wrote:
> > Signed-off-by: Thomas Monjalon 
> 
> Acked-by: Bruce Richardson 

Applied, let's start the 17.05 cycle :)

Re: [dpdk-dev] [PATCH] version: 17.05-rc0

2017-02-17 11:15, Ferruh Yigit:
> What do you think about tagging -rc0 releases?
> 
> I find it useful for "git describe" output, but not sure if it bloats
> ref list.

You're right, it could be useful for "git describe".
Unfortunately it would create a snapshot in the cgit view:
http://dpdk.org/browse/dpdk/refs/

Re: [dpdk-dev] [PATCHv7 00/47] NXP DPAA2 PMD

On 2/16/2017 1:27 PM, Bruce Richardson wrote:
> On Thu, Feb 16, 2017 at 08:22:49AM -0500, Neil Horman wrote:
>> On Thu, Feb 16, 2017 at 06:08:59AM +0530, Hemant Agrawal wrote:
>>> The patch series adds NXP’s QorIQ-Layerscape DPAA2 Architecture based
>>> fsl-mc bus driver and network SoC PMD.  This version of the driver
>>> supports NXP LS208xA, LS204xA and LS108x families Network SoCs.
>>>
>>> DPAA2, or Data Path Acceleration Architecture, is a hardware architecture
>>> designed for high-speed network packet processing. It uses a bus name
>>> ‘fsl-mc’, part of Linux Kernel Staging tree [1], for resource management.
>>>
>>> A brief description of architecture is given below; detailed description
>>> is part of the documentation in the patches itself.
>>>
>>> DPAA2 contains hardware component called the Management Complex (or MC).
>>> It manages the DPAA2 hardware resources.  The MC provides an object-based
>>> abstraction for software drivers to use the DPAA2 hardware.
>>>
>>> Some of the key objects are:
>>> - DPNI, which refers to the network interface object.
>>> - DPBP, which refers to HW based memory pool object
>>> - DPIO, refers to processing context for accessing QBMAN
>>>
>>> Besides the MC, DPAA2 also includes a Hardware based Queue and Buffer 
>>> Manager
>>> called QBMAN. Prime responsibility of QBMAN is to allow lockless access to
>>> software/user-space to the queues and buffers implemented in the hardware.
>>>
>>> The patch series could be logically structured into following sub-areas:
>>> 1. Make file changes for crc in armv8 core machine type and driver 
>>> dependency
>>> 2. Common dpaa2 hw accelerator drivers for QBMAN.
>>> 3. Indroducing fsl-mc bus as rte_bus, it's componenets.
>>> 4. Introducing dpaa2 pmd driver
>>> 5. Introducing dpaa2 mempool 
>>> 6. Support for DPAA2 Ethernet Device (ethdev)
>>> 7. Additional functionality in DPAA2 ethdev.
>>>
>>> The following design decisions are made during development:
>>>
>>> 1. DPAA2 implements a new bus called "fsl-mc" and some common accelerator 
>>> drivers.
>>>These drivers will be shared with dpaa2 based crypto drivers.
>>>
>>> 2. DPAA2 implements the HW mempool offload with DPBP object.
>>>  - The new pool is being configured using compile time option and pool name
>>>as "dpaa2".
>>>
>>> 3. It maintains per lcore DPIO objects and affine the DPIO instance to the
>>>processing threads accessing the QBMAN HW.
>>>
>>> Prerequisites:
>>>  - For running the PMD, NXP's SoC (board) and SDK (software/BSP) is 
>>> required.
>>>Information about obtaining relevant software is available in the docs
>>>as part of the patch.
>>
>> NAK.  The SDK requires registration to obtain, and appears to be non-open
>> source.  This driver is unmaintainable given that.
>>
> Hi Hemant,
> 
> can you perhaps clarify things here. What is the requirement to:
> * build the driver/DPDK for the platform
> * run applications using DPDK on the platform
> 
> Also what is the license/availability for those requirements.

Hi Bruce, Hemant, Neil, Thomas,

I did able to compile the driver without the SDK. It looks like that SDK
is a runtime dependency.

What is the DPDK requirement here?
If it is not breaking the build, this PMD provides it.

Thanks,
ferruh

Re: [dpdk-dev] [PATCH] maintainers: claim responsibility for Vhost-user, Virtio PMD & Vhost PMD

2017-02-17 Thread Maxime Coquelin




On 02/17/2017 11:35 AM, Thomas Monjalon wrote:

2017-02-17 16:49, Yuanhan Liu:

On Fri, Feb 17, 2017 at 09:31:42AM +0100, Maxime Coquelin wrote:

Add myself as co-maintainer for these drivers and library.

Suggested-by: Yuanhan Liu 
Signed-off-by: Maxime Coquelin 


I think it's obvious that Maxime is done great job at reviewing
vhost/virtio patches. So,

Acked-by: Yuanhan Liu 


Thanks Yuanhan for proposing.

Acked-by: Thomas Monjalon 

Applied, congratulations for your new responsibilities :)



Thanks Thomas :)
I'll do my best to be as good as Yuanhan in this role!

Cheers,
Maxime

[dpdk-dev] [PATCH 0/3] cryptodev: change device configuration API

This patchset changes the cryptodev library's device configuration API
and updates all crypto PMD to comply with this change.

Fan Zhang (3):
  cryptodev: change device configuration API
  crypto/scheduler: improve slave configuration
  doc: remove deprecation notice

 app/test/test_cryptodev.c  | 24 +---
 doc/guides/rel_notes/deprecation.rst   |  4 
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c   |  3 ++-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  3 ++-
 drivers/crypto/armv8/rte_armv8_pmd_ops.c   |  3 ++-
 drivers/crypto/kasumi/rte_kasumi_pmd_ops.c |  3 ++-
 drivers/crypto/null/null_crypto_pmd_ops.c  |  3 ++-
 drivers/crypto/openssl/rte_openssl_pmd_ops.c   |  3 ++-
 drivers/crypto/qat/qat_crypto.c|  5 +++--
 drivers/crypto/qat/qat_crypto.h|  3 ++-
 drivers/crypto/scheduler/scheduler_pmd_ops.c   | 20 +++-
 drivers/crypto/snow3g/rte_snow3g_pmd_ops.c |  3 ++-
 drivers/crypto/zuc/rte_zuc_pmd_ops.c   |  3 ++-
 lib/librte_cryptodev/rte_cryptodev.c   |  8 +++-
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  4 +++-
 15 files changed, 47 insertions(+), 45 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH 1/3] cryptodev: change device configuration API

This patch changes the device configuration API for rte_cryptodev_ops
function prototype, and update all cryptodev PMDs for this change.

Signed-off-by: Fan Zhang 
---
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c   | 3 ++-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 3 ++-
 drivers/crypto/armv8/rte_armv8_pmd_ops.c   | 3 ++-
 drivers/crypto/kasumi/rte_kasumi_pmd_ops.c | 3 ++-
 drivers/crypto/null/null_crypto_pmd_ops.c  | 3 ++-
 drivers/crypto/openssl/rte_openssl_pmd_ops.c   | 3 ++-
 drivers/crypto/qat/qat_crypto.c| 5 +++--
 drivers/crypto/qat/qat_crypto.h| 3 ++-
 drivers/crypto/scheduler/scheduler_pmd_ops.c   | 6 --
 drivers/crypto/snow3g/rte_snow3g_pmd_ops.c | 3 ++-
 drivers/crypto/zuc/rte_zuc_pmd_ops.c   | 3 ++-
 lib/librte_cryptodev/rte_cryptodev.c   | 8 +++-
 lib/librte_cryptodev/rte_cryptodev_pmd.h   | 4 +++-
 13 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c 
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
index 2362006..7e7e477 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
@@ -114,7 +114,8 @@ static const struct rte_cryptodev_capabilities 
aesni_gcm_pmd_capabilities[] = {
 
 /** Configure device */
 static int
-aesni_gcm_pmd_config(__rte_unused struct rte_cryptodev *dev)
+aesni_gcm_pmd_config(__rte_unused struct rte_cryptodev *dev,
+   __rte_unused struct rte_cryptodev_config *config)
 {
return 0;
 }
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c 
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
index 3d49e2a..b08bf05 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
@@ -233,7 +233,8 @@ static const struct rte_cryptodev_capabilities 
aesni_mb_pmd_capabilities[] = {
 
 /** Configure device */
 static int
-aesni_mb_pmd_config(__rte_unused struct rte_cryptodev *dev)
+aesni_mb_pmd_config(__rte_unused struct rte_cryptodev *dev,
+   __rte_unused struct rte_cryptodev_config *config)
 {
return 0;
 }
diff --git a/drivers/crypto/armv8/rte_armv8_pmd_ops.c 
b/drivers/crypto/armv8/rte_armv8_pmd_ops.c
index 2bf6475..78c0b4e 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd_ops.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd_ops.c
@@ -111,7 +111,8 @@ static const struct rte_cryptodev_capabilities
 
 /** Configure device */
 static int
-armv8_crypto_pmd_config(__rte_unused struct rte_cryptodev *dev)
+armv8_crypto_pmd_config(__rte_unused struct rte_cryptodev *dev,
+   __rte_unused struct rte_cryptodev_config *config)
 {
return 0;
 }
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c 
b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
index b9285a4..40997d6 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
@@ -89,7 +89,8 @@ static const struct rte_cryptodev_capabilities 
kasumi_pmd_capabilities[] = {
 
 /** Configure device */
 static int
-kasumi_pmd_config(__rte_unused struct rte_cryptodev *dev)
+kasumi_pmd_config(__rte_unused struct rte_cryptodev *dev,
+   __rte_unused struct rte_cryptodev_config *config)
 {
return 0;
 }
diff --git a/drivers/crypto/null/null_crypto_pmd_ops.c 
b/drivers/crypto/null/null_crypto_pmd_ops.c
index 26ff631..801b5f9 100644
--- a/drivers/crypto/null/null_crypto_pmd_ops.c
+++ b/drivers/crypto/null/null_crypto_pmd_ops.c
@@ -85,7 +85,8 @@ static const struct rte_cryptodev_capabilities 
null_crypto_pmd_capabilities[] =
 
 /** Configure device */
 static int
-null_crypto_pmd_config(__rte_unused struct rte_cryptodev *dev)
+null_crypto_pmd_config(__rte_unused struct rte_cryptodev *dev,
+   __rte_unused struct rte_cryptodev_config *config)
 {
return 0;
 }
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c 
b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index 875550c..03b053e 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -449,7 +449,8 @@ static const struct rte_cryptodev_capabilities 
openssl_pmd_capabilities[] = {
 
 /** Configure device */
 static int
-openssl_pmd_config(__rte_unused struct rte_cryptodev *dev)
+openssl_pmd_config(__rte_unused struct rte_cryptodev *dev,
+   __rte_unused struct rte_cryptodev_config *config)
 {
return 0;
 }
diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
index 43e1d00..67cb8f8 100644
--- a/drivers/crypto/qat/qat_crypto.c
+++ b/drivers/crypto/qat/qat_crypto.c
@@ -1326,10 +1326,11 @@ void qat_crypto_sym_session_init(struct rte_mempool 
*mp, void *sym_sess)
offsetof(struct rte_cryptodev_sym_session, _private);
 }
 
-int qat_dev_config(__rte_unused struct rte_cryptodev *dev)
+int qat_dev_config(__rte_unused struct rte_cryptodev *dev,
+   __rte_unused struct rte_cryptodev_config *config)
 {
PMD_I

[dpdk-dev] [PATCH 2/3] crypto/scheduler: improve slave configuration

Since the new device configuration API is updated, we can make use of
this feature to the crypto scheduler PMD to configure its slaves
automatically with the same configurations it got. As originally the
slaves have to be manually configured one by one, this patch should
help reducing the coding complexity.

Signed-off-by: Fan Zhang 
---
 app/test/test_cryptodev.c| 24 +---
 drivers/crypto/scheduler/scheduler_pmd_ops.c | 18 +-
 2 files changed, 14 insertions(+), 28 deletions(-)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 357a92e..6fe5362 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -7382,17 +7382,8 @@ test_scheduler_attach_slave_op(void)
 {
struct crypto_testsuite_params *ts_params = &testsuite_params;
uint8_t sched_id = ts_params->valid_devs[0];
-   uint32_t nb_devs, qp_id, i, nb_devs_attached = 0;
+   uint32_t nb_devs, i, nb_devs_attached = 0;
int ret;
-   struct rte_cryptodev_config config = {
-   .nb_queue_pairs = 8,
-   .socket_id = SOCKET_ID_ANY,
-   .session_mp = {
-   .nb_objs = 2048,
-   .cache_size = 256
-   }
-   };
-   struct rte_cryptodev_qp_conf qp_conf = {2048};
 
/* create 2 AESNI_MB if necessary */
nb_devs = rte_cryptodev_count_devtype(
@@ -7418,19 +7409,6 @@ test_scheduler_attach_slave_op(void)
if (info.dev_type != RTE_CRYPTODEV_AESNI_MB_PMD)
continue;
 
-   ret = rte_cryptodev_configure(i, &config);
-   TEST_ASSERT(ret == 0,
-   "Failed to configure device %u of pmd : %s", i,
-   RTE_STR(CRYPTODEV_NAME_AESNI_MB_PMD));
-
-   for (qp_id = 0; qp_id < info.max_nb_queue_pairs; qp_id++) {
-   TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
-   i, qp_id, &qp_conf,
-   rte_cryptodev_socket_id(i)),
-   "Failed to setup queue pair %u on "
-   "cryptodev %u", qp_id, i);
-   }
-
ret = rte_cryptodev_scheduler_slave_attach(sched_id,
(uint8_t)i);
 
diff --git a/drivers/crypto/scheduler/scheduler_pmd_ops.c 
b/drivers/crypto/scheduler/scheduler_pmd_ops.c
index 79be119..ea755e0 100644
--- a/drivers/crypto/scheduler/scheduler_pmd_ops.c
+++ b/drivers/crypto/scheduler/scheduler_pmd_ops.c
@@ -52,11 +52,8 @@ scheduler_pmd_config(struct rte_cryptodev *dev,
 
for (i = 0; i < sched_ctx->nb_slaves; i++) {
uint8_t slave_dev_id = sched_ctx->slaves[i].dev_id;
-   struct rte_cryptodev *slave_dev =
-   rte_cryptodev_pmd_get_dev(slave_dev_id);
 
-   ret = (*slave_dev->dev_ops->dev_configure)(slave_dev,
-   config);
+   ret = rte_cryptodev_configure(slave_dev_id, config);
if (ret < 0)
break;
}
@@ -340,11 +337,13 @@ scheduler_pmd_qp_release(struct rte_cryptodev *dev, 
uint16_t qp_id)
 /** Setup a queue pair */
 static int
 scheduler_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
-   __rte_unused const struct rte_cryptodev_qp_conf *qp_conf, int socket_id)
+   const struct rte_cryptodev_qp_conf *qp_conf, int socket_id)
 {
struct scheduler_ctx *sched_ctx = dev->data->dev_private;
struct scheduler_qp_ctx *qp_ctx;
char name[RTE_CRYPTODEV_NAME_MAX_LEN];
+   uint32_t i;
+   int ret;
 
if (snprintf(name, RTE_CRYPTODEV_NAME_MAX_LEN,
"CRYTO_SCHE PMD %u QP %u",
@@ -357,6 +356,15 @@ scheduler_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t 
qp_id,
if (dev->data->queue_pairs[qp_id] != NULL)
scheduler_pmd_qp_release(dev, qp_id);
 
+   for (i = 0; i < sched_ctx->nb_slaves; i++) {
+   uint8_t slave_id = sched_ctx->slaves[i].dev_id;
+
+   ret = rte_cryptodev_queue_pair_setup(slave_id, qp_id,
+   qp_conf, socket_id);
+   if (ret < 0)
+   return ret;
+   }
+
/* Allocate the queue pair data structure. */
qp_ctx = rte_zmalloc_socket(name, sizeof(*qp_ctx), RTE_CACHE_LINE_SIZE,
socket_id);
-- 
2.7.4

[dpdk-dev] [PATCH 3/3] doc: remove deprecation notice

Signed-off-by: Fan Zhang 
---
 doc/guides/rel_notes/deprecation.rst | 4 
 1 file changed, 4 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 9d4dfcc..3e17b20 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -119,10 +119,6 @@ Deprecation Notices
   or VHOST feature, but KNI_VHOST which is a KNI feature enabled via a compile
   time option, and disabled by default.
 
-* ABI changes are planned for 17.05 in the ``rte_cryptodev_ops`` structure.
-  A pointer to a rte_cryptodev_config structure will be added to the
-  function prototype ``cryptodev_configure_t``, as a new parameter.
-
 * cryptodev: A new parameter ``max_nb_sessions_per_qp`` will be added to
   ``rte_cryptodev_info.sym``. Some drivers may support limited number of
   sessions per queue_pair. With this new parameter application will know
-- 
2.7.4

Re: [dpdk-dev] [PATCHv7 00/47] NXP DPAA2 PMD

2017-02-17 Thread Bruce Richardson

On Fri, Feb 17, 2017 at 11:34:43AM +, Ferruh Yigit wrote:
> On 2/16/2017 1:27 PM, Bruce Richardson wrote:
> > On Thu, Feb 16, 2017 at 08:22:49AM -0500, Neil Horman wrote:
> >> On Thu, Feb 16, 2017 at 06:08:59AM +0530, Hemant Agrawal wrote:
> >>> The patch series adds NXP’s QorIQ-Layerscape DPAA2 Architecture based
> >>> fsl-mc bus driver and network SoC PMD.  This version of the driver
> >>> supports NXP LS208xA, LS204xA and LS108x families Network SoCs.
> >>>
> >>> DPAA2, or Data Path Acceleration Architecture, is a hardware architecture
> >>> designed for high-speed network packet processing. It uses a bus name
> >>> ‘fsl-mc’, part of Linux Kernel Staging tree [1], for resource management.
> >>>
> >>> A brief description of architecture is given below; detailed description
> >>> is part of the documentation in the patches itself.
> >>>
> >>> DPAA2 contains hardware component called the Management Complex (or MC).
> >>> It manages the DPAA2 hardware resources.  The MC provides an object-based
> >>> abstraction for software drivers to use the DPAA2 hardware.
> >>>
> >>> Some of the key objects are:
> >>> - DPNI, which refers to the network interface object.
> >>> - DPBP, which refers to HW based memory pool object
> >>> - DPIO, refers to processing context for accessing QBMAN
> >>>
> >>> Besides the MC, DPAA2 also includes a Hardware based Queue and Buffer 
> >>> Manager
> >>> called QBMAN. Prime responsibility of QBMAN is to allow lockless access to
> >>> software/user-space to the queues and buffers implemented in the hardware.
> >>>
> >>> The patch series could be logically structured into following sub-areas:
> >>> 1. Make file changes for crc in armv8 core machine type and driver 
> >>> dependency
> >>> 2. Common dpaa2 hw accelerator drivers for QBMAN.
> >>> 3. Indroducing fsl-mc bus as rte_bus, it's componenets.
> >>> 4. Introducing dpaa2 pmd driver
> >>> 5. Introducing dpaa2 mempool 
> >>> 6. Support for DPAA2 Ethernet Device (ethdev)
> >>> 7. Additional functionality in DPAA2 ethdev.
> >>>
> >>> The following design decisions are made during development:
> >>>
> >>> 1. DPAA2 implements a new bus called "fsl-mc" and some common accelerator 
> >>> drivers.
> >>>These drivers will be shared with dpaa2 based crypto drivers.
> >>>
> >>> 2. DPAA2 implements the HW mempool offload with DPBP object.
> >>>  - The new pool is being configured using compile time option and pool 
> >>> name
> >>>as "dpaa2".
> >>>
> >>> 3. It maintains per lcore DPIO objects and affine the DPIO instance to the
> >>>processing threads accessing the QBMAN HW.
> >>>
> >>> Prerequisites:
> >>>  - For running the PMD, NXP's SoC (board) and SDK (software/BSP) is 
> >>> required.
> >>>Information about obtaining relevant software is available in the docs
> >>>as part of the patch.
> >>
> >> NAK.  The SDK requires registration to obtain, and appears to be non-open
> >> source.  This driver is unmaintainable given that.
> >>
> > Hi Hemant,
> > 
> > can you perhaps clarify things here. What is the requirement to:
> > * build the driver/DPDK for the platform
> > * run applications using DPDK on the platform
> > 
> > Also what is the license/availability for those requirements.
> 
> Hi Bruce, Hemant, Neil, Thomas,
> 
> I did able to compile the driver without the SDK. It looks like that SDK
> is a runtime dependency.
> 
> What is the DPDK requirement here?
> If it is not breaking the build, this PMD provides it.
> 
If it builds without an SDK dependency I'd be happy enough to see this
merged into DPDK. Since I can't run it without the correct hardware, I
don't see needing the correct runtime software being a difficulty too.
So long as we can compile this, we can check for breakages in it due to
refactoring in other parts of DPDK, like we do for other drivers. As
with those other drivers, it's up to the maintainers/vendors to do the
functional checking for additional issues. Nobody is likely to have the
hardware to functionality test all drivers in DPDK anyway.

Regards,
/Bruce

Re: [dpdk-dev] [PATCHv7 00/47] NXP DPAA2 PMD

2017-02-17 Thread Vincent JARDIN


Le 17/02/2017 à 13:13, Bruce Richardson a écrit :

If it builds without an SDK dependency I'd be happy enough to see this
merged into DPDK.


+1, the patch is clean enough to be compiled.

Boards or CPUs can rely on specific SDK, firmware, etc., it is up to the 
vendors.


regards,
  Vincent

[dpdk-dev] [PATCH 1/2] mempool: remove deprecated count functions

As announced in the deprecation notice, remove these functions.

Signed-off-by: Olivier Matz 
---
 doc/guides/rel_notes/deprecation.rst   |  5 
 lib/librte_mempool/rte_mempool.c   |  6 -
 lib/librte_mempool/rte_mempool.h   | 41 --
 lib/librte_mempool/rte_mempool_version.map |  1 -
 4 files changed, 53 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 9d4dfcc..79660ec 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -87,11 +87,6 @@ Deprecation Notices
   PKT_RX_QINQ_STRIPPED, that are better described. The old flags and
   their behavior will be kept until 17.02 and will be removed in 17.05.
 
-* mempool: The functions ``rte_mempool_count`` and ``rte_mempool_free_count``
-  will be removed in 17.05.
-  They are replaced by ``rte_mempool_avail_count`` and
-  ``rte_mempool_in_use_count`` respectively.
-
 * mempool: The functions for single/multi producer/consumer are deprecated
   and will be removed in 17.05.
   It is replaced by ``rte_mempool_generic_get/put`` functions.
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 1c2aed8..40d3afd 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -997,12 +997,6 @@ rte_mempool_in_use_count(const struct rte_mempool *mp)
return mp->size - rte_mempool_avail_count(mp);
 }
 
-unsigned int
-rte_mempool_count(const struct rte_mempool *mp)
-{
-   return rte_mempool_avail_count(mp);
-}
-
 /* dump the cache status */
 static unsigned
 rte_mempool_dump_cache(FILE *f, const struct rte_mempool *mp)
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index d0f5b27..7a31685 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -1508,22 +1508,6 @@ rte_mempool_get(struct rte_mempool *mp, void **obj_p)
 unsigned int rte_mempool_avail_count(const struct rte_mempool *mp);
 
 /**
- * @deprecated
- * Return the number of entries in the mempool.
- *
- * When cache is enabled, this function has to browse the length of
- * all lcores, so it should not be used in a data path, but only for
- * debug purposes.
- *
- * @param mp
- *   A pointer to the mempool structure.
- * @return
- *   The number of entries in the mempool.
- */
-__rte_deprecated
-unsigned rte_mempool_count(const struct rte_mempool *mp);
-
-/**
  * Return the number of elements which have been allocated from the mempool
  *
  * When cache is enabled, this function has to browse the length of
@@ -1539,31 +1523,6 @@ unsigned int
 rte_mempool_in_use_count(const struct rte_mempool *mp);
 
 /**
- * @deprecated
- * Return the number of free entries in the mempool ring.
- * i.e. how many entries can be freed back to the mempool.
- *
- * NOTE: This corresponds to the number of elements *allocated* from the
- * memory pool, not the number of elements in the pool itself. To count
- * the number elements currently available in the pool, use "rte_mempool_count"
- *
- * When cache is enabled, this function has to browse the length of
- * all lcores, so it should not be used in a data path, but only for
- * debug purposes. User-owned mempool caches are not accounted for.
- *
- * @param mp
- *   A pointer to the mempool structure.
- * @return
- *   The number of free entries in the mempool.
- */
-__rte_deprecated
-static inline unsigned
-rte_mempool_free_count(const struct rte_mempool *mp)
-{
-   return rte_mempool_in_use_count(mp);
-}
-
-/**
  * Test if the mempool is full.
  *
  * When cache is enabled, this function has to browse the length of all
diff --git a/lib/librte_mempool/rte_mempool_version.map 
b/lib/librte_mempool/rte_mempool_version.map
index dee1c99..f9c0794 100644
--- a/lib/librte_mempool/rte_mempool_version.map
+++ b/lib/librte_mempool/rte_mempool_version.map
@@ -3,7 +3,6 @@ DPDK_2.0 {
 
rte_mempool_audit;
rte_mempool_calc_obj_size;
-   rte_mempool_count;
rte_mempool_create;
rte_mempool_dump;
rte_mempool_list_dump;
-- 
2.8.1

[dpdk-dev] [PATCH 2/2] mempool: remove deprecated get and put functions

As announced in the deprecation notice, remove the functions for
single/multi producer/consumer enqueue/dequeue.

Signed-off-by: Olivier Matz 
---
 doc/guides/rel_notes/deprecation.rst |   4 -
 lib/librte_mempool/rte_mempool.h | 180 ---
 2 files changed, 184 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 79660ec..642f770 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -87,10 +87,6 @@ Deprecation Notices
   PKT_RX_QINQ_STRIPPED, that are better described. The old flags and
   their behavior will be kept until 17.02 and will be removed in 17.05.
 
-* mempool: The functions for single/multi producer/consumer are deprecated
-  and will be removed in 17.05.
-  It is replaced by ``rte_mempool_generic_get/put`` functions.
-
 * ethdev: the legacy filter API, including
   ``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well
   as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR,
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 7a31685..991feaa 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -1108,46 +1108,6 @@ rte_mempool_generic_put(struct rte_mempool *mp, void * 
const *obj_table,
 }
 
 /**
- * @deprecated
- * Put several objects back in the mempool (multi-producers safe).
- *
- * @param mp
- *   A pointer to the mempool structure.
- * @param obj_table
- *   A pointer to a table of void * pointers (objects).
- * @param n
- *   The number of objects to add in the mempool from the obj_table.
- */
-__rte_deprecated
-static inline void __attribute__((always_inline))
-rte_mempool_mp_put_bulk(struct rte_mempool *mp, void * const *obj_table,
-   unsigned n)
-{
-   struct rte_mempool_cache *cache;
-   cache = rte_mempool_default_cache(mp, rte_lcore_id());
-   rte_mempool_generic_put(mp, obj_table, n, cache, 0);
-}
-
-/**
- * @deprecated
- * Put several objects back in the mempool (NOT multi-producers safe).
- *
- * @param mp
- *   A pointer to the mempool structure.
- * @param obj_table
- *   A pointer to a table of void * pointers (objects).
- * @param n
- *   The number of objects to add in the mempool from obj_table.
- */
-__rte_deprecated
-static inline void __attribute__((always_inline))
-rte_mempool_sp_put_bulk(struct rte_mempool *mp, void * const *obj_table,
-   unsigned n)
-{
-   rte_mempool_generic_put(mp, obj_table, n, NULL, MEMPOOL_F_SP_PUT);
-}
-
-/**
  * Put several objects back in the mempool.
  *
  * This function calls the multi-producer or the single-producer
@@ -1171,40 +1131,6 @@ rte_mempool_put_bulk(struct rte_mempool *mp, void * 
const *obj_table,
 }
 
 /**
- * @deprecated
- * Put one object in the mempool (multi-producers safe).
- *
- * @param mp
- *   A pointer to the mempool structure.
- * @param obj
- *   A pointer to the object to be added.
- */
-__rte_deprecated
-static inline void __attribute__((always_inline))
-rte_mempool_mp_put(struct rte_mempool *mp, void *obj)
-{
-   struct rte_mempool_cache *cache;
-   cache = rte_mempool_default_cache(mp, rte_lcore_id());
-   rte_mempool_generic_put(mp, &obj, 1, cache, 0);
-}
-
-/**
- * @deprecated
- * Put one object back in the mempool (NOT multi-producers safe).
- *
- * @param mp
- *   A pointer to the mempool structure.
- * @param obj
- *   A pointer to the object to be added.
- */
-__rte_deprecated
-static inline void __attribute__((always_inline))
-rte_mempool_sp_put(struct rte_mempool *mp, void *obj)
-{
-   rte_mempool_generic_put(mp, &obj, 1, NULL, MEMPOOL_F_SP_PUT);
-}
-
-/**
  * Put one object back in the mempool.
  *
  * This function calls the multi-producer or the single-producer
@@ -1332,62 +1258,6 @@ rte_mempool_generic_get(struct rte_mempool *mp, void 
**obj_table, unsigned n,
 }
 
 /**
- * @deprecated
- * Get several objects from the mempool (multi-consumers safe).
- *
- * If cache is enabled, objects will be retrieved first from cache,
- * subsequently from the common pool. Note that it can return -ENOENT when
- * the local cache and common pool are empty, even if cache from other
- * lcores are full.
- *
- * @param mp
- *   A pointer to the mempool structure.
- * @param obj_table
- *   A pointer to a table of void * pointers (objects) that will be filled.
- * @param n
- *   The number of objects to get from mempool to obj_table.
- * @return
- *   - 0: Success; objects taken.
- *   - -ENOENT: Not enough entries in the mempool; no object is retrieved.
- */
-__rte_deprecated
-static inline int __attribute__((always_inline))
-rte_mempool_mc_get_bulk(struct rte_mempool *mp, void **obj_table, unsigned n)
-{
-   struct rte_mempool_cache *cache;
-   cache = rte_mempool_default_cache(mp, rte_lcore_id());
-   return rte_mempool_generic_get(mp, obj_table, n, cache, 0);
-}
-
-/**
- * @deprecated
- * Get

Re: [dpdk-dev] [PATCH] igb_uio: map dummy dma forcing iommu domain attachment

On 1/18/2017 12:27 PM, Alejandro Lucero wrote:
> For using a DPDK app when iommu is enabled, it requires to
> add iommu=pt to the kernel command line. But using igb_uio driver
> makes DMAR errors because the device has not an IOMMU domain.
> 
> Since kernel 3.15, iommu=pt requires to use the internal kernel
> DMA API for attaching the device to the IOMMU 1:1 mapping, aka
> si_domain. Previous versions did attach the device to that
> domain when intel iommu notifier was called.
> 
> This is not a problem if the driver does later some call to the
> DMA API because the mapping can be done then. But DPDK apps do
> not use that DMA API at all.
> 
> Doing this dma map and unmap is harmless even when iommu is not
> enabled at all.
> 
> Signed-off-by: Alejandro Lucero 

Acked-by: Ferruh Yigit 

(I suggest getting this early in 17.05 release, so it can be tested more)

Re: [dpdk-dev] [PATCHv7 00/47] NXP DPAA2 PMD

2017-02-17 Thread Hemant Agrawal

On 2/16/2017 6:57 PM, Bruce Richardson wrote:

On Thu, Feb 16, 2017 at 08:22:49AM -0500, Neil Horman wrote:

On Thu, Feb 16, 2017 at 06:08:59AM +0530, Hemant Agrawal wrote:

The patch series adds NXP’s QorIQ-Layerscape DPAA2 Architecture based
fsl-mc bus driver and network SoC PMD. This version of the driver
supports NXP LS208xA, LS204xA and LS108x families Network SoCs.

DPAA2, or Data Path Acceleration Architecture, is a hardware architecture
designed for high-speed network packet processing. It uses a bus name
‘fsl-mc’, part of Linux Kernel Staging tree [1], for resource management.

A brief description of architecture is given below; detailed description
is part of the documentation in the patches itself.

DPAA2 contains hardware component called the Management Complex (or MC).
It manages the DPAA2 hardware resources. The MC provides an object-based
abstraction for software drivers to use the DPAA2 hardware.

Some of the key objects are:
- DPNI, which refers to the network interface object.
- DPBP, which refers to HW based memory pool object
- DPIO, refers to processing context for accessing QBMAN

Besides the MC, DPAA2 also includes a Hardware based Queue and Buffer Manager
called QBMAN. Prime responsibility of QBMAN is to allow lockless access to
software/user-space to the queues and buffers implemented in the hardware.

The patch series could be logically structured into following sub-areas:
1. Make file changes for crc in armv8 core machine type and driver dependency
2. Common dpaa2 hw accelerator drivers for QBMAN.
3. Indroducing fsl-mc bus as rte_bus, it's componenets.
4. Introducing dpaa2 pmd driver
5. Introducing dpaa2 mempool
6. Support for DPAA2 Ethernet Device (ethdev)
7. Additional functionality in DPAA2 ethdev.

The following design decisions are made during development:

1. DPAA2 implements a new bus called "fsl-mc" and some common accelerator
drivers.
These drivers will be shared with dpaa2 based crypto drivers.

2. DPAA2 implements the HW mempool offload with DPBP object.
- The new pool is being configured using compile time option and pool name
as "dpaa2".

3. It maintains per lcore DPIO objects and affine the DPIO instance to the
processing threads accessing the QBMAN HW.

Prerequisites:
- For running the PMD, NXP's SoC (board) and SDK (software/BSP) is required.
Information about obtaining relevant software is available in the docs
as part of the patch.

NAK. The SDK requires registration to obtain, and appears to be non-open
source. This driver is unmaintainable given that.

Hi Hemant,

can you perhaps clarify things here. What is the requirement to:
* build the driver/DPDK for the platform
* run applications using DPDK on the platform

Also what is the license/availability for those requirements.

/Bruce

Hi Neil, Bruce,
I thought SDK is a simpler choice to get the required components in one
place. However there is no such restriction to get the components only
from the NXP SDK.

We will update the documentation with the same.

Following is a list of open source components required:

1. ARM 64 tool chain.
e.g. *aarch64* Linaro Toolchain:
https://releases.linaro.org/components/toolchain/binaries/4.9-2017.01/aarch64-linux-gnu/

2. Linux Kernel

http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git/log/?h=sdk-v2.0.x
or,
https://github.com/qoriq-open-source/linux
Please note that the particular linux kernel, I have used for my testing
is 4.1.8 (part of our SDK 2.0-17.01), I will publish the tree at github
shortly.

3. Rootfile system : any aarch64 supported e.g.
Ubuntu 15.10 (Wily) or 16.04 LTS (Xenial) userland
http://cdimage.ubuntu.com/ubuntu-base/releases/16.04/release/ubuntu-base-16.04.1-base-arm64.tar.gz

Initial kernel is best built in a Yocto build environment, then deployed
to target with a disk based Ubuntu userland.
However, both kernel and DPDK release can be natively built on the
target platform, using Ubuntu devtools.

Regards,
Hemant

Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization

2017-02-17 Thread Nélio Laranjeiro

Hi Olivier, Jan,

On Fri, Feb 17, 2017 at 11:51:53AM +0100, Olivier Matz wrote:
> Hi Jan,
> 
> On Thu, 16 Feb 2017 18:26:39 +0100, Jan Blunck 
> wrote:
> > On Thu, Feb 16, 2017 at 2:48 PM, Olivier Matz
> >  wrote:
> > > On Mon, 6 Feb 2017 18:41:27 +, "Ananyev, Konstantin"
> > >  wrote:  
> > >> >
> > >> > The main changes are:
> > >> > - reorder structure to increase vector performance on some non-ia
> > >> >   platforms.
> > >> > - add a 64bits timestamp field in the 1st cache line  
> > >>
> > >> Wonder why it deserves to be in first cache line?
> > >> How it differs from seqn below (pure SW stuff right now).  
> > >
> > > In case the timestamp is set from a NIC value, it is set in the Rx
> > > path. So that's why I think it deserve to be located in the 1st
> > > cache line.
> > >
> > > As you said, the seqn is a pure sw stuff right: it is set in a lib,
> > > not in a PMD rx path.
> > >  
> > 
> > If we talk about setting the timestamp value in the RX path this
> > implicitly means software timestamps. Hardware timestamping usually
> > works by letting the hardware inject sync events for coarse time
> > tracking and additionally injecting fine granular per-packet ticks at
> > a specific offset in the packet. Out of performance reasons I don't
> > think it makes sense to extract this during the burst and write it
> > into the mbuf again.
> 
> From what I've understand, at least it does not work like this for
> mellanox NICs: timestamp is a metadata attached to a rx packet. But
> maybe they (and other NIC vendors interrested in the feature) can
> confirm or not.

Olivier is right, this timestamp information is returned by the hardware
as the other fields describing the Rx packet (length, RSS hash, checksum
...).  The PMD only copy it into the Mbuf.

> > The problem with timestamps is to get the abstraction right wrt the
> > correction factors and the size of the tick vs. the timestamp in the
> > events injected. From my perspective it would be better to extract the
> > handling of timestamp data into a library with PMD specific
> > implementation of the conversions. That way the normalized timestamp
> > values can get extracted if they are present. The mbuf itself would
> > only indicate the presence of timestamp metadata in that case.
> 
> I agree however that we need to properly define the meaning of this
> field. My idea is:
> 
> - the timestamp is in nanosecond
> - the reference is always the same for a given path: if the timestamp is
>   set in a PMD, all the packets for this PMD will have the same
>   reference, but for 2 different PMDs (or a sw lib), the reference
>   would not be the same.
> 
> I think it's enough for many use cases.
> We can later add helpers to compare timestamps with different
> references.
> 
> Regards,
> Olivier

Regards,

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization

2017-02-17 Thread Jan Blunck

On Fri, Feb 17, 2017 at 11:51 AM, Olivier Matz  wrote:
> Hi Jan,
>
> On Thu, 16 Feb 2017 18:26:39 +0100, Jan Blunck 
> wrote:
>> On Thu, Feb 16, 2017 at 2:48 PM, Olivier Matz
>>  wrote:
>> > On Mon, 6 Feb 2017 18:41:27 +, "Ananyev, Konstantin"
>> >  wrote:
>> >> >
>> >> > The main changes are:
>> >> > - reorder structure to increase vector performance on some non-ia
>> >> >   platforms.
>> >> > - add a 64bits timestamp field in the 1st cache line
>> >>
>> >> Wonder why it deserves to be in first cache line?
>> >> How it differs from seqn below (pure SW stuff right now).
>> >
>> > In case the timestamp is set from a NIC value, it is set in the Rx
>> > path. So that's why I think it deserve to be located in the 1st
>> > cache line.
>> >
>> > As you said, the seqn is a pure sw stuff right: it is set in a lib,
>> > not in a PMD rx path.
>> >
>>
>> If we talk about setting the timestamp value in the RX path this
>> implicitly means software timestamps. Hardware timestamping usually
>> works by letting the hardware inject sync events for coarse time
>> tracking and additionally injecting fine granular per-packet ticks at
>> a specific offset in the packet. Out of performance reasons I don't
>> think it makes sense to extract this during the burst and write it
>> into the mbuf again.
>
> From what I've understand, at least it does not work like this for
> mellanox NICs: timestamp is a metadata attached to a rx packet. But
> maybe they (and other NIC vendors interrested in the feature) can
> confirm or not.
>

Mellanox NICs use a 48bit cycle counter split into a high and low
part. To convert the cycle values into a timestamp you need to
initialize and maintainer a timecounter that shifts the cycle count
e.g. nanosecs. IIRC Mellanox doesn't generate explicit clock events
but the cycle counter is large enough so that the user can easily
maintain the timecounter by manually updating it.

>>
>> The problem with timestamps is to get the abstraction right wrt the
>> correction factors and the size of the tick vs. the timestamp in the
>> events injected. From my perspective it would be better to extract the
>> handling of timestamp data into a library with PMD specific
>> implementation of the conversions. That way the normalized timestamp
>> values can get extracted if they are present. The mbuf itself would
>> only indicate the presence of timestamp metadata in that case.
>
> I agree however that we need to properly define the meaning of this
> field. My idea is:
>
> - the timestamp is in nanosecond
> - the reference is always the same for a given path: if the timestamp is
>   set in a PMD, all the packets for this PMD will have the same
>   reference, but for 2 different PMDs (or a sw lib), the reference
>   would not be the same.
>
> I think it's enough for many use cases.
> We can later add helpers to compare timestamps with different
> references.

My point is that I still doubt that it belongs into the first
cacheline. It requires accessing other structures for converting into
nanoseconds anyway. Optimally I would like to see this happening on
access instead but if that isn't achievable at least in a second step.

Re: [dpdk-dev] [PATCHv7 00/47] NXP DPAA2 PMD

2017-02-17 12:13, Bruce Richardson:
> On Fri, Feb 17, 2017 at 11:34:43AM +, Ferruh Yigit wrote:
> > On 2/16/2017 1:27 PM, Bruce Richardson wrote:
> > > On Thu, Feb 16, 2017 at 08:22:49AM -0500, Neil Horman wrote:
> > >> On Thu, Feb 16, 2017 at 06:08:59AM +0530, Hemant Agrawal wrote:
> > >>> Prerequisites:
> > >>>  - For running the PMD, NXP's SoC (board) and SDK (software/BSP) is 
> > >>> required.
> > >>>Information about obtaining relevant software is available in the 
> > >>> docs
> > >>>as part of the patch.
> > >>
> > >> NAK.  The SDK requires registration to obtain, and appears to be non-open
> > >> source.  This driver is unmaintainable given that.
> > >>
> > > Hi Hemant,
> > > 
> > > can you perhaps clarify things here. What is the requirement to:
> > > * build the driver/DPDK for the platform
> > > * run applications using DPDK on the platform
> > > 
> > > Also what is the license/availability for those requirements.
> > 
> > Hi Bruce, Hemant, Neil, Thomas,
> > 
> > I did able to compile the driver without the SDK. It looks like that SDK
> > is a runtime dependency.
> > 
> > What is the DPDK requirement here?
> > If it is not breaking the build, this PMD provides it.
> > 
> If it builds without an SDK dependency I'd be happy enough to see this
> merged into DPDK. Since I can't run it without the correct hardware, I
> don't see needing the correct runtime software being a difficulty too.
> So long as we can compile this, we can check for breakages in it due to
> refactoring in other parts of DPDK, like we do for other drivers. As
> with those other drivers, it's up to the maintainers/vendors to do the
> functional checking for additional issues. Nobody is likely to have the
> hardware to functionality test all drivers in DPDK anyway.

+1, I agree with Bruce

[dpdk-dev] [PATCH v9] net/kni: add KNI PMD

Add KNI PMD which wraps librte_kni for ease of use.

KNI PMD can be used as any regular PMD to send / receive packets to the
Linux networking stack.

Signed-off-by: Ferruh Yigit 
Reviewed-by: Yong Wang 
---

v9:
* update for 17.05

v8:
* Don't try to link against librte_pmd_kni if librte_kni is disabled

v7:
* Add dependency to CONFIG_RTE_LIBRTE_KNI config

v6:
* documentation typos fixed

v5:
* add kvargs "no_request_thread" to disable a specific pthread creation
to handle control requests.
* add documentation

v4:
* allow only single queue
* use driver.name as name

v3:
* rebase on top of latest master

v2:
* updated driver name eth_kni -> net_kni
---
 MAINTAINERS |   5 +
 config/common_base  |   1 +
 config/common_linuxapp  |   1 +
 doc/guides/nics/features/kni.ini|   7 +
 doc/guides/nics/index.rst   |   1 +
 doc/guides/nics/kni.rst | 197 
 drivers/net/Makefile|   4 +
 drivers/net/kni/Makefile|  64 
 drivers/net/kni/rte_eth_kni.c   | 515 
 drivers/net/kni/rte_pmd_kni_version.map |   4 +
 mk/rte.app.mk   |  12 +-
 11 files changed, 806 insertions(+), 5 deletions(-)
 create mode 100644 doc/guides/nics/features/kni.ini
 create mode 100644 doc/guides/nics/kni.rst
 create mode 100644 drivers/net/kni/Makefile
 create mode 100644 drivers/net/kni/rte_eth_kni.c
 create mode 100644 drivers/net/kni/rte_pmd_kni_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 8305237..b4617fc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -412,6 +412,11 @@ M: Keith Wiles 
 F: drivers/net/tap/
 F: doc/guides/nics/tap.rst
 
+KNI PMD
+M: Ferruh Yigit 
+F: drivers/net/kni/
+F: doc/guides/nics/kni.rst
+
 Ring PMD
 M: Bruce Richardson 
 F: drivers/net/ring/
diff --git a/config/common_base b/config/common_base
index 71a4fcb..63756c4 100644
--- a/config/common_base
+++ b/config/common_base
@@ -581,6 +581,7 @@ CONFIG_RTE_PIPELINE_STATS_COLLECT=n
 # Compile librte_kni
 #
 CONFIG_RTE_LIBRTE_KNI=n
+CONFIG_RTE_LIBRTE_PMD_KNI=n
 CONFIG_RTE_KNI_KMOD=n
 CONFIG_RTE_KNI_KMOD_ETHTOOL=n
 CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 00ebaac..d03a60a 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -39,6 +39,7 @@ CONFIG_RTE_EAL_IGB_UIO=y
 CONFIG_RTE_EAL_VFIO=y
 CONFIG_RTE_KNI_KMOD=y
 CONFIG_RTE_LIBRTE_KNI=y
+CONFIG_RTE_LIBRTE_PMD_KNI=y
 CONFIG_RTE_LIBRTE_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
diff --git a/doc/guides/nics/features/kni.ini b/doc/guides/nics/features/kni.ini
new file mode 100644
index 000..6deb66a
--- /dev/null
+++ b/doc/guides/nics/features/kni.ini
@@ -0,0 +1,7 @@
+;
+; Supported features of the 'kni' network poll mode driver.
+;
+; Refer to default.ini for the full list of available PMD features.
+;
+[Features]
+Usage doc= Y
diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 87f9334..5248625 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -46,6 +46,7 @@ Network Interface Controller Drivers
 i40e
 ixgbe
 intel_vf
+kni
 mlx4
 mlx5
 nfp
diff --git a/doc/guides/nics/kni.rst b/doc/guides/nics/kni.rst
new file mode 100644
index 000..77542b5
--- /dev/null
+++ b/doc/guides/nics/kni.rst
@@ -0,0 +1,197 @@
+..  BSD LICENSE
+Copyright(c) 2017 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

Re: [dpdk-dev] [PATCH v9] net/kni: add KNI PMD

2017-02-17 13:42, Ferruh Yigit:
> Add KNI PMD which wraps librte_kni for ease of use.
> 
> KNI PMD can be used as any regular PMD to send / receive packets to the
> Linux networking stack.
> 
> Signed-off-by: Ferruh Yigit 
> Reviewed-by: Yong Wang 
> ---
> 
> v9:
> * update for 17.05

You keep updating this patch in the hope that someone would be interested :)

Please let's make clear that I am OK to merge it
but you asked me to wait for someone supporting its inclusion.

Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization

2017-02-17 Thread Jan Blunck

On Fri, Feb 17, 2017 at 1:49 PM, Nélio Laranjeiro
 wrote:
> Hi Olivier, Jan,
>
> On Fri, Feb 17, 2017 at 11:51:53AM +0100, Olivier Matz wrote:
>> Hi Jan,
>>
>> On Thu, 16 Feb 2017 18:26:39 +0100, Jan Blunck 
>> wrote:
>> >
>> > If we talk about setting the timestamp value in the RX path this
>> > implicitly means software timestamps. Hardware timestamping usually
>> > works by letting the hardware inject sync events for coarse time
>> > tracking and additionally injecting fine granular per-packet ticks at
>> > a specific offset in the packet. Out of performance reasons I don't
>> > think it makes sense to extract this during the burst and write it
>> > into the mbuf again.
>>
>> From what I've understand, at least it does not work like this for
>> mellanox NICs: timestamp is a metadata attached to a rx packet. But
>> maybe they (and other NIC vendors interrested in the feature) can
>> confirm or not.
>
> Olivier is right, this timestamp information is returned by the hardware
> as the other fields describing the Rx packet (length, RSS hash, checksum
> ...).  The PMD only copy it into the Mbuf.
>

Indeed, for Mellanox the timestamp is stored in the CQ entry.
Solarflares write it relative to the packet header.

Re: [dpdk-dev] [PATCH v9] net/kni: add KNI PMD

2017-02-17 Thread Eelco Chaudron


On 17/02/17 14:47, Thomas Monjalon wrote:

2017-02-17 13:42, Ferruh Yigit:

Add KNI PMD which wraps librte_kni for ease of use.

KNI PMD can be used as any regular PMD to send / receive packets to the
Linux networking stack.

Signed-off-by: Ferruh Yigit 
Reviewed-by: Yong Wang 
---

v9:
* update for 17.05

You keep updating this patch in the hope that someone would be interested :)


We needed this a while back in DPDK for warp17, however I ended up 
implementing this myself, 
https://github.com/Juniper/warp17/blob/master/src/kni_if/tpg_kni_pmd.c


I think its useful,  so you do not have to use different APIs when 
sending/receiving over multiple types of interfaces.



Please let's make clear that I am OK to merge it
but you asked me to wait for someone supporting its inclusion.

Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization

Hi Jan,

On Fri, 17 Feb 2017 14:38:32 +0100, Jan Blunck 
wrote:
> On Fri, Feb 17, 2017 at 11:51 AM, Olivier Matz
>  wrote:
> > Hi Jan,
> >
> > On Thu, 16 Feb 2017 18:26:39 +0100, Jan Blunck
> >  wrote:  
> >> On Thu, Feb 16, 2017 at 2:48 PM, Olivier Matz
> >>  wrote:  
> >> > On Mon, 6 Feb 2017 18:41:27 +, "Ananyev, Konstantin"
> >> >  wrote:  
> >> >> >
> >> >> > The main changes are:
> >> >> > - reorder structure to increase vector performance on some
> >> >> > non-ia platforms.
> >> >> > - add a 64bits timestamp field in the 1st cache line  
> >> >>
> >> >> Wonder why it deserves to be in first cache line?
> >> >> How it differs from seqn below (pure SW stuff right now).  
> >> >
> >> > In case the timestamp is set from a NIC value, it is set in the
> >> > Rx path. So that's why I think it deserve to be located in the
> >> > 1st cache line.
> >> >
> >> > As you said, the seqn is a pure sw stuff right: it is set in a
> >> > lib, not in a PMD rx path.
> >> >  
> >>
> >> If we talk about setting the timestamp value in the RX path this
> >> implicitly means software timestamps. Hardware timestamping usually
> >> works by letting the hardware inject sync events for coarse time
> >> tracking and additionally injecting fine granular per-packet ticks
> >> at a specific offset in the packet. Out of performance reasons I
> >> don't think it makes sense to extract this during the burst and
> >> write it into the mbuf again.  
> >
> > From what I've understand, at least it does not work like this for
> > mellanox NICs: timestamp is a metadata attached to a rx packet. But
> > maybe they (and other NIC vendors interrested in the feature) can
> > confirm or not.
> >  
> 
> Mellanox NICs use a 48bit cycle counter split into a high and low
> part. To convert the cycle values into a timestamp you need to
> initialize and maintainer a timecounter that shifts the cycle count
> e.g. nanosecs. IIRC Mellanox doesn't generate explicit clock events
> but the cycle counter is large enough so that the user can easily
> maintain the timecounter by manually updating it.
> 
> >>
> >> The problem with timestamps is to get the abstraction right wrt the
> >> correction factors and the size of the tick vs. the timestamp in
> >> the events injected. From my perspective it would be better to
> >> extract the handling of timestamp data into a library with PMD
> >> specific implementation of the conversions. That way the
> >> normalized timestamp values can get extracted if they are present.
> >> The mbuf itself would only indicate the presence of timestamp
> >> metadata in that case.  
> >
> > I agree however that we need to properly define the meaning of this
> > field. My idea is:
> >
> > - the timestamp is in nanosecond
> > - the reference is always the same for a given path: if the
> > timestamp is set in a PMD, all the packets for this PMD will have
> > the same reference, but for 2 different PMDs (or a sw lib), the
> > reference would not be the same.
> >
> > I think it's enough for many use cases.
> > We can later add helpers to compare timestamps with different
> > references.  
> 
> My point is that I still doubt that it belongs into the first
> cacheline. It requires accessing other structures for converting into
> nanoseconds anyway. Optimally I would like to see this happening on
> access instead but if that isn't achievable at least in a second step.

Sorry, I don't really get your point. My comprehension of the timestamp
usage in a PMD is as following:

rx_burst(struct rxq *rxq, ...)
{
unsigned long factor = rxq->timestamp_factor;
unsigned port = rxq->port;

for each hw_desc {
m = rte_pktmbuf_alloc(rxq->pool);
m->len = hw_desc->len;
m->port = port;
m->ol_flags = 
...
m->timestamp = hw_desc->timestamp * factor;
}
...
}

In that case, I think it deserves to be in the 1st cache line.


Olivier

Re: [dpdk-dev] [PATCH v9] net/kni: add KNI PMD