[dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3

[Tetsuya Mukawa]

On 2015/04/01 20:13, Mcnamara, John wrote:
>> -Original Message-
>> From: Masaru Oki [mailto:m-oki at stratosphere.co.jp]
>> Sent: Wednesday, April 1, 2015 11:14 AM
>> To: Mcnamara, John
>> Cc: Tetsuya Mukawa; De Lara Guarch, Pablo; dev at dpdk.org
>> Subject: Re: [dpdk-dev] Cannot build doc using DPDK-2.0.0-rc3
>>
>>
>> guide-% rule is selected instead of guide-pdf-% in mk/rte.sdkdoc.mk, I
>> guess.
> Hi,
>
> Changing the order of the guide-pdf-% and guide-% rules fixes the issue with 
> make 3.81. I'll submit a patch.
>
> John

Hi John and Oki-san,

Thanks, I made sure I could build doc.

Tetsuya

[dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on link_get

[Liang, Cunming]

Hi Thomas,

> What is the relation between link status timeout and qos_sched?
[LCM] Validation team found qos_sched test failure on i40e. The sample depends 
on link speed to calc the percentage.
The root cause comes from that i40e link_get hasn't support wait_to_complete 
well. 
I agree with you it should add more description in test report why 'Used QoS 
example to verified'.

> > +---+--+
> > |  Subport output rate  | Subport output rate  |
> > | (% line rate) | (Mpps)   |
> > +---+---+--+---+
> > |  Expected | Actual| Expected | Actual|
> > +---+---+--+---+
> 
> This table is empty.
[LCM] It's useless, should be omitted I think.

Cunming
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, April 02, 2015 3:52 AM
> To: Zhang, XiaonanX; Cao, Waterman
> Cc: dev at dpdk.org; Zhang, Helin; Liang, Cunming
> Subject: Re: [dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on 
> link_get
> 
> Hi,
> 
> 2015-04-01 06:10, Zhang, XiaonanX:
> >
> > Tested-by: Xiaonan zhang
> >
> > - OS: Fedora21 3.19.1-201.fc21.x86_64
> > - GCC: gcc version 4.9.1 20140930 (Red Hat 4.9.1-11) (GCC)
> > - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
> > - NIC: Ethernet controller [0200]: Intel Corporation Ethernet Controller 
> > X710 for
> 10GbE SFP+ [8086:1572] (rev 01)
> > - Default x86_64-native-linuxapp-gcc configuration
> > - Total 1 cases, 1 passed, 0 failed
> >
> > - Test case: Used Qos example to verified
> > -
> 
> What is the relation between link status timeout and qos_sched?
> 
> > Traffic shaping for subport. Check that the subport rate is enforced.
> >
> > Set the subport output rate to x% of line rate (x = 10 .. 100). Set the 
> > subport TC
> limits high (100% line rate each), so they do not constitute limitations. 
> Input traffic
> is 100% line rate.
> >
> > Different tb period and tb credits, therefore different output rate, are 
> > tried:
> 25%, 50%, 75%, 90% and 100% the lineal rate. (The output for subport is Tb 
> credits
> per period / Tb period.)
> > The traffic is injected change subport value random.
> >
> > Other parameters are same before tests and they don't change here.
> >
> > Cmdline:   ./examples/qos_sched/build/qos_sched  -c 0xe -n 4 -- --pfc
> "0,1,2,3,3" --cfg "/root/profile_sched_pipe_1.cfg"
> >
> > The result is this table:
> >
> >
> > +---+--+
> > |  Subport output rate  | Subport output rate  |
> > | (% line rate) | (Mpps)   |
> > +---+---+--+---+
> > |  Expected | Actual| Expected | Actual|
> > +---+---+--+---+
> 
> This table is empty.
> 
> >
> > Signed-off-by: Xiaonan Zhang 
> 
> It seems that this test report is not relevant.
> It will be ignored in the commit message. Sorry

[dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on link_get

[Zhang, XiaonanX]

Hi Thomas,
  First and foremost, We found this problem with using Qos example on Fedora21 
platform, there are our reproduce test steps as follows.
  We used this example found FVL 4*10G NIC link status caused to our Qos 
example could not boot normally in our dpdk2.0 Release Cycle;
  In addition, it is performance case about our FVL 4 * 10G NIC, as you know, 
our performance result currently should not be public;
  And also that's why our expectation performance data are empty.
  In a nutshell, We have verified this patch and confirmed the Qos example 
could run and get performance data after we applied this patch to our code.
  Thanks.


Best Regards,
Xiaonan

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Thursday, April 02, 2015 3:52 AM
To: Zhang, XiaonanX; Cao, Waterman
Cc: dev at dpdk.org; Zhang, Helin; Liang, Cunming
Subject: Re: [dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on link_get

Hi,

2015-04-01 06:10, Zhang, XiaonanX:
> 
> Tested-by: Xiaonan zhang
> 
> - OS: Fedora21 3.19.1-201.fc21.x86_64
> - GCC: gcc version 4.9.1 20140930 (Red Hat 4.9.1-11) (GCC)
> - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
> - NIC: Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 
> for 10GbE SFP+ [8086:1572] (rev 01)
> - Default x86_64-native-linuxapp-gcc configuration
> - Total 1 cases, 1 passed, 0 failed
> 
> - Test case: Used Qos example to verified 
> -

What is the relation between link status timeout and qos_sched?

> Traffic shaping for subport. Check that the subport rate is enforced.
>  
> Set the subport output rate to x% of line rate (x = 10 .. 100). Set the 
> subport TC limits high (100% line rate each), so they do not constitute 
> limitations. Input traffic is 100% line rate.
>  
> Different tb period and tb credits, therefore different output rate, are 
> tried: 25%, 50%, 75%, 90% and 100% the lineal rate. (The output for subport 
> is Tb credits per period / Tb period.)
> The traffic is injected change subport value random.
>  
> Other parameters are same before tests and they don't change here.
> 
> Cmdline:   ./examples/qos_sched/build/qos_sched  -c 0xe -n 4 -- --pfc 
> "0,1,2,3,3" --cfg "/root/profile_sched_pipe_1.cfg"
>  
> The result is this table:
>  
>  
> +---+--+
> |  Subport output rate  | Subport output rate  |
> | (% line rate) | (Mpps)   |
> +---+---+--+---+
> |  Expected | Actual| Expected | Actual|
> +---+---+--+---+

This table is empty.

> 
> Signed-off-by: Xiaonan Zhang 

It seems that this test report is not relevant.
It will be ignored in the commit message. Sorry

[dpdk-dev] Running DPDK with Docker

[Karmarkar Suyash]

<< igb_uio and rte_kni are unlikely to be accepted upstream since they have 
intrinsic security problems.

Can you use VFIO?>>

Hi Stephen,

Thanks for the reply. Can you please elaborate on the security issue?Thanks.

Regards
Suyash

-Original Message-
From: Stephen Hemminger [mailto:step...@networkplumber.org] 
Sent: Thursday, April 02, 2015 12:12 AM
To: Karmarkar Suyash
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Running DPDK with Docker

On Wed, 1 Apr 2015 17:56:56 +
Karmarkar Suyash  wrote:

> Hi,
> 
> Given the popularity of Docker it would be nice if we can run DPDK inside a 
> Docker container but the challenge is the igb_uio.ko and rte_kni.ko kernel 
> modules which need to be compiled with the exact kernel source running on the 
> host.  Are there ways to seamlessly run DPDK with Docker? I came across an 
> articles about running DPDK with Linux container but still the requirement is 
> to insert igb_uio. Any plans to make the igb_uio and rte_kni modules as 
> default modules of Linux source code or any other better 
> approaches/suggestions ? Thanks.
> 
> http://dpdk.org/ml/archives/dev/2014-October/006373.html
> http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/6479

igb_uio and rte_kni are unlikely to be accepted upstream since they have 
intrinsic security problems.

Can you use VFIO?

[dpdk-dev] Running DPDK with Docker

[Andre Richter]

The uio drivers are not secured by an iommu.
Therefore, you could misuse the NIC to DMA read/write into any part of
memory, e.g. reading or writing to memory of the host or other containers.

This is a security breach if you enable a container to do this by giving it
access via uio, because you have them to isolate processes against each
other in the first place.

VFIO uses iommus to protect against that, but you need capable hardware,
e.g. Intel VT-d support on x86.

http://en.m.wikipedia.org/wiki/IOMMU

Cheers,
Andre

Karmarkar Suyash  schrieb am Do., 2. Apr. 2015 um
05:28:

> << igb_uio and rte_kni are unlikely to be accepted upstream since they
> have intrinsic security problems.
>
> Can you use VFIO?>>
>
> Hi Stephen,
>
> Thanks for the reply. Can you please elaborate on the security
> issue?Thanks.
>
> Regards
> Suyash
>
> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Thursday, April 02, 2015 12:12 AM
> To: Karmarkar Suyash
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Running DPDK with Docker
>
> On Wed, 1 Apr 2015 17:56:56 +
> Karmarkar Suyash  wrote:
>
> > Hi,
> >
> > Given the popularity of Docker it would be nice if we can run DPDK
> inside a Docker container but the challenge is the igb_uio.ko and
> rte_kni.ko kernel modules which need to be compiled with the exact kernel
> source running on the host.  Are there ways to seamlessly run DPDK with
> Docker? I came across an articles about running DPDK with Linux container
> but still the requirement is to insert igb_uio. Any plans to make the
> igb_uio and rte_kni modules as default modules of Linux source code or any
> other better approaches/suggestions ? Thanks.
> >
> > http://dpdk.org/ml/archives/dev/2014-October/006373.html
> > http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/6479
>
> igb_uio and rte_kni are unlikely to be accepted upstream since they have
> intrinsic security problems.
>
> Can you use VFIO?
>

[dpdk-dev] Running DPDK with Docker

[Zhou, Danny]

Container itself is not considered as a secured solution that could provide 
strict resource isolation which
VT could provide. Basically, we have 4 different configuration as below, you 
could pick most appropriate one
depending on usage scenarios.

1) VT + VFIO: supposed to be the most secured solution, but unfortunately VFIO 
cannot run in a VM unless 
either software IOMMU(at performance degradation cost) or nested 
Vt-d(unavailable on any architecture) hardware 
feature is enable.
2) VT + UIO: secured solution in both host(uio to drive VF on host) and VM(uio 
to driver a pass-through VF in a VM), but VT 
has overhead comparing to container which is basically native performance.
3) Container + VFIO: Container itself does not provide strict resource 
isolation even VFIO could avoid changed PMD to DMA
packets to arbitrary memory regions.
4) Container + UIO: least secured solution, but might fit NFV use cases in 
which it runs trusted L4-L7 virtualized service functions
rather than customer applications in containers.

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Andre Richter
> Sent: Thursday, April 02, 2015 2:36 PM
> To: Karmarkar Suyash; Stephen Hemminger
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Running DPDK with Docker
> 
> The uio drivers are not secured by an iommu.
> Therefore, you could misuse the NIC to DMA read/write into any part of
> memory, e.g. reading or writing to memory of the host or other containers.
> 
> This is a security breach if you enable a container to do this by giving it
> access via uio, because you have them to isolate processes against each
> other in the first place.
> 
> VFIO uses iommus to protect against that, but you need capable hardware,
> e.g. Intel VT-d support on x86.
> 
> http://en.m.wikipedia.org/wiki/IOMMU
> 
> Cheers,
> Andre
> 
> Karmarkar Suyash  schrieb am Do., 2. Apr. 2015 um
> 05:28:
> 
> > << igb_uio and rte_kni are unlikely to be accepted upstream since they
> > have intrinsic security problems.
> >
> > Can you use VFIO?>>
> >
> > Hi Stephen,
> >
> > Thanks for the reply. Can you please elaborate on the security
> > issue?Thanks.
> >
> > Regards
> > Suyash
> >
> > -Original Message-
> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > Sent: Thursday, April 02, 2015 12:12 AM
> > To: Karmarkar Suyash
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] Running DPDK with Docker
> >
> > On Wed, 1 Apr 2015 17:56:56 +
> > Karmarkar Suyash  wrote:
> >
> > > Hi,
> > >
> > > Given the popularity of Docker it would be nice if we can run DPDK
> > inside a Docker container but the challenge is the igb_uio.ko and
> > rte_kni.ko kernel modules which need to be compiled with the exact kernel
> > source running on the host.  Are there ways to seamlessly run DPDK with
> > Docker? I came across an articles about running DPDK with Linux container
> > but still the requirement is to insert igb_uio. Any plans to make the
> > igb_uio and rte_kni modules as default modules of Linux source code or any
> > other better approaches/suggestions ? Thanks.
> > >
> > > http://dpdk.org/ml/archives/dev/2014-October/006373.html
> > > http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/6479
> >
> > igb_uio and rte_kni are unlikely to be accepted upstream since they have
> > intrinsic security problems.
> >
> > Can you use VFIO?
> >

[dpdk-dev] [PATCH v2 0/3] split programmers guide a bit

[Mcnamara, John]

> -Original Message-
> From: Iremonger, Bernard
> Sent: Wednesday, April 1, 2015 6:20 PM
> To: Mcnamara, John; Thomas Monjalon
> Cc: Butler, Siobhan A; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 0/3] split programmers guide a bit


> > The main positive is that it would give us automatic* figure/table
> > numbering in Html and PDF and the captioning looks quite good. (*This
> requires Sphinx 1.3).
> >
> > John
> >
> Hi John,
> 
> I am not sure why the captions have to be under the images.
> At present the captions are just a bold line of text before the image in
> the rst files for example, **Figure 17. Components of a DPDK KNI
> Application**

Hi Bernard,

The issue with the current solution is that the caption isn't tied to the image 
in any way and the pdf formatter frequently puts it on a separate page. 
Unfortunately, the solution to that issue, to use figure:: instead of image::, 
doesn't support captions above the image. If it did I would be happy to leave 
the placement as it is.

> This will probably affect the cross reference links as well or does the
> automatic numbering work with the links as well.

The automatic numbering can be added to the cross references as well. I'll 
submit an RFC patch and you can try it out and see if it is worth changing.

John

[dpdk-dev] [PATCH] doc: update mlx4 usage and dependencies

[Adrien Mazarguil]

- libmlx4 and libibverbs dependencies distributed with Mellanox OFED are now
  also available on DPDK.org to make installation easier.
- Document Mellanox OFED and firmware versions to use.
- Add links to Mellanox and its community websites.
- Add kernel modules parameters section.

Signed-off-by: Adrien Mazarguil 
---
 doc/guides/nics/mlx4.rst | 85 
 1 file changed, 78 insertions(+), 7 deletions(-)

diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index b26c219..93a7f57 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -31,8 +31,15 @@ MLX4 poll mode driver library
 =

 The MLX4 poll mode driver library (**librte_pmd_mlx4**) implements support
-for **Mellanox ConnectX-3** 10/40 Gbps adapters (EN 40, EN 10, Pro EN 40) as
-well as their virtual functions (VF) in SR-IOV context.
+for **Mellanox ConnectX-3 EN** 10/40 Gbps adapters as well as their virtual
+functions (VF) in SR-IOV context.
+
+Information and documentation about this family of adapters can be found on
+the `Mellanox website `_. Help is also provided by
+the `Mellanox community `_.
+
+There is also a `section dedicated to this poll mode driver
+`_.

 .. note::

@@ -78,7 +85,7 @@ Features and limitations
 - Multiple MAC addresses (unicast, multicast) can be configured.
 - Scattered packets are supported for TX and RX.

-..
+.. break

 - RSS hash key cannot be modified.
 - Hardware counters are not implemented (they are software counters).
@@ -90,6 +97,8 @@ Configuration
 Compilation options
 ~~~

+These options can be modified in the ``.config`` file.
+
 - ``CONFIG_RTE_LIBRTE_MLX4_PMD`` (default **n**)

   Toggle compilation of librte_pmd_mlx4 itself.
@@ -146,6 +155,30 @@ Run-time configuration

 - **ethtool** operations on related kernel interfaces also affect the PMD.

+Kernel module parameters
+
+
+The **mlx4_core** kernel module has several parameters that affect the
+behavior and/or the performance of librte_pmd_mlx4. Some of them are described
+below.
+
+- **num_vfs** (integer or triplet, optionally prefixed by device address
+  strings)
+
+  Create the given number of VFs on the specified devices.
+
+- **log_num_mgm_entry_size** (integer)
+
+  Device-managed flow steering (DMFS) is required by DPDK applications. It is
+  enabled by using a negative value, the last four bits of which have a
+  special meaning.
+
+  - **-1**: force device-managed flow steering (DMFS).
+  - **-7**: configure optimized steering mode to improve performance with the
+following limitation: Ethernet frames with the port MAC address as the
+destination cannot be received, even in promiscuous mode. Additional MAC
+addresses can still be set by ``rte_eth_dev_mac_addr_addr()``.
+
 Prerequisites
 -

@@ -185,6 +218,26 @@ DPDK and must be installed separately:
   - mlx4_ib: InifiniBand device driver.
   - ib_uverbs: user space driver for verbs (entry point for libibverbs).

+- **Firmware update**
+
+  Mellanox OFED releases include firmware updates for ConnectX-3 adapters.
+
+  Because each release provides new features, these updates must be applied to
+  match the kernel modules and libraries they come with.
+
+.. note::
+
+   Both libraries are BSD and GPL licensed. Linux kernel modules are GPL
+   licensed.
+
+Currently supported by DPDK:
+
+- Mellanox OFED **2.4-1**.
+- Firmware version **2.33.5000** and higher.
+
+Getting Mellanox OFED
+~
+
 While these libraries and kernel modules are available on OpenFabrics
 Aliance's `website `_ and provided by package
 managers on most distributions, this PMD requires Ethernet extensions that
@@ -193,13 +246,31 @@ may not be supported at the moment (this is a work in 
progress).
 `Mellanox OFED
 
`_
 includes the necessary support and should be used in the meantime. For DPDK,
-only libibverbs, libmlx4 and mlnx-ofed-kernel packages are required from
-that distribution.
+only libibverbs, libmlx4, mlnx-ofed-kernel packages and firmware updates are
+required from that distribution.

 .. note::

-   Both libraries are BSD and GPL licensed. Linux kernel modules are GPL
-   licensed.
+   Several versions of Mellanox OFED are available. Installing the version
+   this DPDK release was developped and tested against is strongly
+   recommended. Please check the `prerequisites`_.
+
+Getting libibverbs and libmlx4 from DPDK.org
+
+
+Based on Mellanox OFED, optimized libibverbs and libmlx4 versions can be
+optionally downloaded from DPDK.org:
+
+``_
+
+Some enhancements are done for better performance with DPDK appl

[dpdk-dev] calling rte_eth_rx_queue_setup from secondary processes

[Nissim Nisimov]

Hi all,

I wonder if there is a possibility to call rte_eth_rx_queue_setup() from 
different processes (for different RSS queues off course)

For example, the code will look something like:


>From Process 1:

retval = rte_eth_rx_queue_setup(port_num, 0, rx_ring_size,

rte_eth_dev_socket_id(port_num), &rx_conf_default, dpdk_mp_handle);


from process 2:

retval = rte_eth_rx_queue_setup(port_num, 1, rx_ring_size,

rte_eth_dev_socket_id(port_num), &rx_conf_default, dpdk_mp_handle);




I know that rte_eth_rx_queue_setup() is not meant to work on secondary 
processes but my question is if there is a real reason for it. and if it can be 
changed so it will indeed work in such case

Thanks!
Nissim

[dpdk-dev] [RFC] doc: refactored figure numbers into references

[John McNamara]

The is an RFC patch demonstrating automatic figure references
in the documentation. The figure numbers in the generated
Html and PDF docs with by automatically numbered based on
section. Requires Sphinx >= 1.3.

The patch makes the following changes.

* Changes image:: tag to figure:: and moves image caption
  to the figure.

* Adds captions to figures that didn't previously have any.

* Un-templates the |image-name| substitution definitions
  into explicit figure:: tags. They weren't used more
  than once anyway and Sphinx doesn't support them
  for figure.

* Adds a target to each image that didn't previously
  have one so that they can be cross-referenced.

* Renamed existing image target to match the image
  name for consistency.

* Replaces the Figures lists with automatic :numref:
  :ref: entries to generate automatic numbering
  and captions.

* Replaces "Figure" references with automatic :numref:
  references.

Note: a V2 patch would be required to do the same for
  tables.

Signed-off-by: John McNamara 
---
 doc/guides/conf.py |   2 +
 doc/guides/nics/index.rst  |  18 ++-
 doc/guides/nics/intel_vf.rst   |  37 ++---
 doc/guides/nics/virtio.rst |  18 ++-
 doc/guides/nics/vmxnet3.rst|  18 ++-
 doc/guides/prog_guide/env_abstraction_layer.rst|   8 +-
 doc/guides/prog_guide/index.rst|  92 +++-
 doc/guides/prog_guide/ivshmem_lib.rst  |   8 +-
 doc/guides/prog_guide/kernel_nic_interface.rst |  40 ++---
 .../prog_guide/link_bonding_poll_mode_drv_lib.rst  |  43 --
 doc/guides/prog_guide/lpm6_lib.rst |   8 +-
 doc/guides/prog_guide/lpm_lib.rst  |   8 +-
 doc/guides/prog_guide/malloc_lib.rst   |   9 +-
 doc/guides/prog_guide/mbuf_lib.rst |  20 +--
 doc/guides/prog_guide/mempool_lib.rst  |  32 ++--
 doc/guides/prog_guide/multi_proc_support.rst   |   9 +-
 doc/guides/prog_guide/overview.rst |   9 +-
 doc/guides/prog_guide/packet_distrib_lib.rst   |  15 +-
 doc/guides/prog_guide/packet_framework.rst |  81 +-
 doc/guides/prog_guide/qos_framework.rst| 163 +++--
 doc/guides/prog_guide/ring_lib.rst | 159 +++-
 doc/guides/sample_app_ug/dist_app.rst  |  20 ++-
 doc/guides/sample_app_ug/exception_path.rst|   8 +-
 doc/guides/sample_app_ug/index.rst |  58 
 doc/guides/sample_app_ug/intel_quickassist.rst |  11 +-
 doc/guides/sample_app_ug/kernel_nic_interface.rst  |   9 +-
 doc/guides/sample_app_ug/l2_forward_job_stats.rst  |  23 +--
 .../sample_app_ug/l2_forward_real_virtual.rst  |  22 +--
 .../sample_app_ug/l3_forward_access_ctrl.rst   |  21 ++-
 doc/guides/sample_app_ug/load_balancer.rst |   9 +-
 doc/guides/sample_app_ug/multi_process.rst |  36 ++---
 doc/guides/sample_app_ug/qos_scheduler.rst |   9 +-
 doc/guides/sample_app_ug/quota_watermark.rst   |  36 ++---
 doc/guides/sample_app_ug/test_pipeline.rst |   9 +-
 doc/guides/sample_app_ug/vhost.rst |  45 ++
 doc/guides/sample_app_ug/vm_power_management.rst   |  18 +--
 doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst   |  11 +-
 doc/guides/xen/pkt_switch.rst  |  30 ++--
 38 files changed, 539 insertions(+), 633 deletions(-)

diff --git a/doc/guides/conf.py b/doc/guides/conf.py
index b1ef323..1bc031f 100644
--- a/doc/guides/conf.py
+++ b/doc/guides/conf.py
@@ -41,6 +41,8 @@ release = version

 master_doc = 'index'

+numfig = True
+
 latex_documents = [
 ('index',
  'doc.tex',
diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index aadbae3..1ee67fa 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -50,14 +50,20 @@ Network Interface Controller Drivers

 **Figures**

-:ref:`Figure 1. Virtualization for a Single Port NIC in SR-IOV Mode 
`
+:numref:`figure_single_port_nic` :ref:`figure_single_port_nic`

-:ref:`Figure 2. SR-IOV Performance Benchmark Setup `
+:numref:`figure_perf_benchmark` :ref:`figure_perf_benchmark`

-:ref:`Figure 3. Fast Host-based Packet Processing `
+:numref:`figure_fast_pkt_proc` :ref:`figure_fast_pkt_proc`

-:ref:`Figure 4. SR-IOV Inter-VM Communication `
+:numref:`figure_inter_vm_comms` :ref:`figure_inter_vm_comms`

-:ref:`Figure 5. Virtio Host2VM Communication Example Using KNI vhost Back End 
`
+:numref:`figure_host_vm_comms` :ref:`figure_host_vm_comms`

-:ref:`Figure 6. Virtio Host2VM Communication Example Using Qemu vhost Back End 
`
+:numref:`figure_host_vm_comms_qemu` :ref:`figure_host_vm_comms_qemu`
+
+:numref:`figure_vmxnet3_int` :ref:`figure_vmxnet3_int`
+
+:numref:`figure_vswitch_vm` :ref:`figure_vswitch_vm`
+
+:numref:`figure_vm_vm_comms` :ref:`figure_vm_vm_comms`
diff --git a/doc/guides/nics/intel_vf.rst b/doc/guid

[dpdk-dev] library choices for AES CBC/GCM on dpdk app datapath

[Neil Horman]

On Wed, Apr 01, 2015 at 03:54:27PM -0700, Deep Debroy wrote:
> Hi, I was wondering if anyone has pointers for a crypto library
> implementing AES CBC and GCM that I can use for encrypting network packets
> in a DPDK app's datapath.
> 
> The app is supposed to run in a VM in the cloud. So access to crypto
> acceleration hardware (besides Intel AES NI/pmuludq) may not be present.
> 
> Does it make sense to look into OpenSSL and invoking it's APIs from a DPDK
> app?
> 
> Thanks!
> 

The openssl libcrypto library provides most of the above I think.  You can also
just use the AF_ALG protocol to leverage the kernels crypto resources.

Neil

[dpdk-dev] [PATCH] eal: decrease the memory init time with many hugepages setup

[jerry.lili...@huawei.com]

From: Lilijun 

In the function map_all_hugepages(), hugepage memory is truly allocated by
memset(virtaddr, 0, hugepage_sz). Then it costs about 40s to finish the
dpdk memory initialization when 4 2M hugepages are setup in host os.
In fact we can only write one byte to finish  the allocation.

Signed-off-by: Lilijun 
---
 lib/librte_eal/linuxapp/eal/eal_memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c 
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 5f9f92e..8bbee9c 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -378,7 +378,7 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl,

if (orig) {
hugepg_tbl[i].orig_va = virtaddr;
-   memset(virtaddr, 0, hugepage_sz);
+   memset(virtaddr, 0, 1);
}
else {
hugepg_tbl[i].final_va = virtaddr;
-- 
1.9.4.msysgit.1

[dpdk-dev] Testpmd with Mellanox ConnectX-3

[Adrien Mazarguil]

Hi,

On Wed, Apr 01, 2015 at 08:18:30PM +, Raghav Sethi wrote:
> Hi folks,
> 
> Hopefully this is the right place to ask questions. I'm  trying to run
> testpmd (and then develop my own applications) with DPDK 1.8 and the
> Mellanox ConnectX-3. The setup script/quickstart/Getting Started guide
> don't have too much information about what to do if you have a
> Mellanox. I've installed libibverbs and libmlx4 system-wide. This is the
> closest I found to a guide for the Mellanox:
> https://dpdk.readthedocs.org/en/stable/prog_guide/mlx4_poll_mode_drv.html .
> When I run testpmd as described by this article, I get "Cause: No probed
> ethernet device".

First, the ConnectX-3 (mlx4) driver is not included in DPDK 1.8, the
documentation you refer to is from a DPDK 2.0 release candidate.
DPDK 2.0 will support it.

> Here are my questions:
> 1. Is this how I should set the PMD flag for DPDK? "make install T=
> CONFIG_RTE_LIBRTE_MLX4_PMD=y"

No, see below.

> 2. If not, how should I do it?

You should either create a specific configuration file in configs/ with that
option and use make config T=, or update your .config file after
you've run make config T=.

> 3. Does using the Mellanox mean that I shouldn't use igb_uio at all?

Indeed. Loading it is harmless though.

> 4. Do I need to bind the Mellanox to mlx4_core before using testpmd?

The kernel module (mlx4_core) must remain bound to its devices, the PMD
relies on it.

> I would be happy to contribute to the help page with end-to-end
> instructions for using the Mellanox with testpmd.

I've just submitted a patch to provide more details about the installation
process, you should have a look.

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH] eal: decrease the memory init time with many hugepages setup

[Thomas Monjalon]

2015-04-02 19:30, jerry.lilijun at huawei.com:
> From: Lilijun 
> 
> In the function map_all_hugepages(), hugepage memory is truly allocated by
> memset(virtaddr, 0, hugepage_sz). Then it costs about 40s to finish the
> dpdk memory initialization when 4 2M hugepages are setup in host os.

Yes it's something we should try to reduce.

> In fact we can only write one byte to finish  the allocation.

Isn't it a security hole?

This article speaks about "prezeroing optimizations" in Linux kernel:
http://landley.net/writing/memory-faq.txt

[dpdk-dev] [PATCH] eal: decrease the memory init time with many hugepages setup

[Jay Rolette]

On Thu, Apr 2, 2015 at 7:55 AM, Thomas Monjalon 
wrote:

> 2015-04-02 19:30, jerry.lilijun at huawei.com:
> > From: Lilijun 
> >
> > In the function map_all_hugepages(), hugepage memory is truly allocated
> by
> > memset(virtaddr, 0, hugepage_sz). Then it costs about 40s to finish the
> > dpdk memory initialization when 4 2M hugepages are setup in host os.
>
> Yes it's something we should try to reduce.
>

I have a patch in my tree that does the same opto, but it is commented out
right now. In our case, 2/3's of the startup time for our entire app was
due to that particular call - memset(virtaddr, 0, hugepage_sz). Just
zeroing 1 byte per huge page reduces that by 30% in my tests.

The only reason I have it commented out is that I didn't have time to make
sure there weren't side-effects for DPDK or my app. For normal shared
memory on Linux, pages are initialized to zero automatically once they are
touched, so the memset isn't required but I wasn't sure whether that
applied to huge pages. Also wasn't sure how hugetlbfs factored into the
equation.

Hopefully someone can chime in on that. Would love to uncomment the opto :)

> In fact we can only write one byte to finish  the allocation.
>
> Isn't it a security hole?
>

Not necessarily. If the kernel pre-zeros the huge pages via CoW like normal
pages, then definitely not.

Even if the kernel doesn't pre-zero the pages, if DPDK takes care of
properly initializing memory structures on startup as they are carved out
of the huge pages, then it isn't a security hole. However, that approach is
susceptible to bit rot... You can audit the code and make sure everything
is kosher at first, but you have to worry about new code making assumptions
about how memory is initialized.


> This article speaks about "prezeroing optimizations" in Linux kernel:
> http://landley.net/writing/memory-faq.txt


I read through that when I was trying to figure out what whether huge pages
were pre-zeroed or not. It doesn't talk about huge pages much beyond why
they are useful for reducing TLB swaps.

Jay

[dpdk-dev] [RFC] Adding multiple device types to DPDK.

[Wiles, Keith]

Hi All, just to make a comment on my own email :-)

On 4/1/15, 7:44 AM, "Wiles, Keith"  wrote:

>Hi all, (hoping format of the text is maintained)
>
>Bruce and myself are submitting this RFC in hopes of providing discussion
>points for the idea. Please do not get carried away with the code
>included, it was to help everyone understand the proposal/RFC.
>
>The RFC is to describe a proposed change we are looking to make to DPDK to
>add more device types. We would like to add in to DPDK the idea of a
>generic packet-device or ?pktdev?, which can be thought of as a thin layer
>for all device classes. For other device types such as potentially a
>?cryptodev? or ?dpidev?. One of the main goals is to not effect
>performance and not require any current application to be modified. The
>pktdev layer is providing a light framework for developers to add a device
>to DPDK.
>
>Reason for Change
>-
>
>The reason why we are looking to introduce these concepts to DPDK are:
>
>* Expand the scope of DPDK so that it can provide APIs for more than just
>packet acquisition and transmission, but also provide APIs that can be
>used to work with other hardware and software offloads, such as
>cryptographic accelerators, or accelerated libraries for cryptographic
>functions. [The reason why both software and hardware are mentioned is so
>that the same APIs can be used whether or not a hardware accelerator is
>actually available].
>* Provide a minimal common basis for device abstraction in DPDK, that can
>be used to unify the different types of packet I/O devices already
>existing in DPDK. To this end, the ethdev APIs are a good starting point,
>but the ethdev library contains too many functions which are NIC-specific
>to be a general-purpose set of APIs across all devices.
> Note: The idea was previously touched on here:
>http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/13545
>
>Description of Proposed Change
>--
>
>The basic idea behind "pktdev" is to abstract out a few common routines
>and structures/members of structures by starting with ethdev structures as
>a starting point, cut it down to little more than a few members in each
>structure then possible add just rx_burst and tx_burst. Then use the
>structures as a starting point for writing a device type. Currently we
>have the rx_burst/tx_burst routines moved to the pktdev and it see like
>move a couple more common functions maybe resaonable. It could be the
>Rx/Tx routines in pktdev should be left as is, but in the code below is a
>possible reason to abstract a few routines into a common set of files.
>
>From there, we have the ethdev type which adds in the existing functions
>specific to Ethernet devices, and also, for example, a cryptodev which may
>add in functions specific for cryptographic offload. As now, with the
>ethdev, the specific drivers provide concrete implementations of the
>functionality exposed by the interface. This hierarchy is shown in the
>diagram below, using the existing ethdev and ixgbe drivers as a reference,
>alongside a hypothetical cryptodev class and driver implementation
>(catchingly called) "X":
>
>,-.
>| struct rte_pktdev   |
>+-+
>| rte_pkt_rx_burst()  |
>.---| rte_pkt_tx_burst()  |---.
>|   `-'   |
>| |
>| |
>  ,---.,--.
>  |struct rte_ethdev  ||  struct rte_cryptodev|
>  +---++--+
>  | rte_eth_dev_configure()   || rte_crypto_init_sym_session()|
>  | rte_eth_allmulticast_enable() || rte_crypto_del_sym_session() |
>  | rte_eth_filter_ctrl() ||  |
>  `---'`---.--'
>|  |
>|  |
>  ,-'-.,---'--.
>  |struct rte_pmd_ixgbe   ||  struct rte_pmd_X|
>  +---++--+
>  | .configure -> ixgbe_configure || .init_session -> X_init_ses()|
>  | .tx_burst  -> ixgbe_xmit_pkts || .tx_burst -> X_handle_pkts() |
>  `---'`--'
>
>We are not attempting to create a real class model here only looking at
>creating a very basic common set of APIs and structures for other device
>types.
>
>In terms of code changes for this, we obviously need to add in new
>interface libraries for pktdev and cryptodev. The pktdev library can
>define a skeleton structure for the first few elements 

[dpdk-dev] [PATCH v3 1/5] mbuf: fix clone support when application uses private mbuf data

[Zoltan Kiss]

On 31/03/15 20:23, Olivier Matz wrote:
> From: Olivier Matz 
>
> Add a new private_size field in mbuf structure that should
> be initialized at mbuf pool creation. This field contains the
> size of the application private data in mbufs.
>
> Introduce new static inline functions rte_mbuf_from_indirect()
> and rte_mbuf_to_baddr() to replace the existing macros, which
> take the private size in account when attaching and detaching
> mbufs.
>
> Signed-off-by: Olivier Matz 
Reviewed-by: Zoltan Kiss 

I assume the rest of the series haven't changed apart from occasional 
rebasing, I've reviewed them earlier.

> ---
>   app/test-pmd/testpmd.c |  1 +
>   examples/vhost/main.c  |  4 +--
>   lib/librte_mbuf/rte_mbuf.c |  1 +
>   lib/librte_mbuf/rte_mbuf.h | 77 
> +++---
>   4 files changed, 63 insertions(+), 20 deletions(-)
>
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 3057791..c5a195a 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -425,6 +425,7 @@ testpmd_mbuf_ctor(struct rte_mempool *mp,
>   mb->tx_offload   = 0;
>   mb->vlan_tci = 0;
>   mb->hash.rss = 0;
> + mb->priv_size= 0;
>   }
>
>   static void
> diff --git a/examples/vhost/main.c b/examples/vhost/main.c
> index c3fcb80..e44e82f 100644
> --- a/examples/vhost/main.c
> +++ b/examples/vhost/main.c
> @@ -139,7 +139,7 @@
>   /* Number of descriptors per cacheline. */
>   #define DESC_PER_CACHELINE (RTE_CACHE_LINE_SIZE / sizeof(struct vring_desc))
>
> -#define MBUF_EXT_MEM(mb)   (RTE_MBUF_FROM_BADDR((mb)->buf_addr) != (mb))
> +#define MBUF_EXT_MEM(mb)   (rte_mbuf_from_indirect(mb) != (mb))
>
>   /* mask of enabled ports */
>   static uint32_t enabled_port_mask = 0;
> @@ -1550,7 +1550,7 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
>   static inline void pktmbuf_detach_zcp(struct rte_mbuf *m)
>   {
>   const struct rte_mempool *mp = m->pool;
> - void *buf = RTE_MBUF_TO_BADDR(m);
> + void *buf = rte_mbuf_to_baddr(m);
>   uint32_t buf_ofs;
>   uint32_t buf_len = mp->elt_size - sizeof(*m);
>   m->buf_physaddr = rte_mempool_virt2phy(mp, m) + sizeof(*m);
> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> index 526b18d..e095999 100644
> --- a/lib/librte_mbuf/rte_mbuf.c
> +++ b/lib/librte_mbuf/rte_mbuf.c
> @@ -125,6 +125,7 @@ rte_pktmbuf_init(struct rte_mempool *mp,
>   m->pool = mp;
>   m->nb_segs = 1;
>   m->port = 0xff;
> + m->priv_size = 0;
>   }
>
>   /* do some sanity checks on a mbuf: panic if it fails */
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 17ba791..932fe58 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -317,18 +317,51 @@ struct rte_mbuf {
>   /* uint64_t unused:8; */
>   };
>   };
> +
> + /** Size of the application private data. In case of an indirect
> +  * mbuf, it stores the direct mbuf private data size. */
> + uint16_t priv_size;
>   } __rte_cache_aligned;
>
>   /**
> - * Given the buf_addr returns the pointer to corresponding mbuf.
> + * Return the mbuf owning the data buffer address of an indirect mbuf.
> + *
> + * @param mi
> + *   The pointer to the indirect mbuf.
> + * @return
> + *   The address of the direct mbuf corresponding to buffer_addr.
>*/
> -#define RTE_MBUF_FROM_BADDR(ba) (((struct rte_mbuf *)(ba)) - 1)
> +static inline struct rte_mbuf *
> +rte_mbuf_from_indirect(struct rte_mbuf *mi)
> +{
> +   struct rte_mbuf *md;
> +
> +   /* mi->buf_addr and mi->priv_size correspond to buffer and
> + * private size of the direct mbuf */
> +   md = (struct rte_mbuf *)((char *)mi->buf_addr - sizeof(*mi) -
> +mi->priv_size);
> +   return md;
> +}
>
>   /**
> - * Given the pointer to mbuf returns an address where it's  buf_addr
> - * should point to.
> + * Return the buffer address embedded in the given mbuf.
> + *
> + * The user must ensure that m->priv_size corresponds to the
> + * private size of this mbuf, which is not the case for indirect
> + * mbufs.
> + *
> + * @param md
> + *   The pointer to the mbuf.
> + * @return
> + *   The address of the data buffer owned by the mbuf.
>*/
> -#define RTE_MBUF_TO_BADDR(mb)   (((struct rte_mbuf *)(mb)) + 1)
> +static inline char *
> +rte_mbuf_to_baddr(struct rte_mbuf *md)
> +{
> +   char *buffer_addr;
> +   buffer_addr = (char *)md + sizeof(*md) + md->priv_size;
> +   return buffer_addr;
> +}
>
>   /**
>* Returns TRUE if given mbuf is indirect, or FALSE otherwise.
> @@ -688,6 +721,7 @@ static inline struct rte_mbuf *rte_pktmbuf_alloc(struct 
> rte_mempool *mp)
>
>   /**
>* Attach packet mbuf to another packet mbuf.
> + *
>* After attachment we refer the mbuf we attached as 'indirect',
>* while mbuf we attached to as 'direct'.
>* Right now, not supported:
> @@ -701,7 +735,6 @@ static inline struct rte_mbuf *rte_pktmbuf_alloc

[dpdk-dev] [PATCH] mbuf: clean old refcnt option

[Butler, Siobhan A]

Huawei/Changchun can you please ack this patch or if you are not happy with it 
ask for it to be deffered but it is blocking.
Thank you 
S

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, April 1, 2015 8:58 PM
> To: Xie, Huawei; Ouyang, Changchun
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] mbuf: clean old refcnt option
> 
> 2015-03-31 21:26, Olivier MATZ:
> > Hi Thomas,
> >
> > On 03/31/2015 07:58 PM, Thomas Monjalon wrote:
> > > CONFIG_RTE_MBUF_SCATTER_GATHER was renamed into
> > > CONFIG_RTE_MBUF_REFCNT by commit 62814bc2e923 and removed by
> commit 4769bc5a27cc.
> > > Some traces remain because of delayed patches.
> > >
> > > It can also be removed from doxygen config.
> > > It is now poisoned in rte_mbuf.h to warn any misuse.
> > >
> > > Fixes: d0dff9ba445e ("doc: sample application user guide")
> > > Fixes: fc1f2750a3ec ("doc: programmers guide")
> > > Fixes: 4769bc5a27cc ("mbuf: remove build option to disable refcnt")
> > >
> > > Signed-off-by: Thomas Monjalon 
> [...]
> > > --- a/doc/guides/sample_app_ug/vhost.rst
> > > +++ b/doc/guides/sample_app_ug/vhost.rst
> > > @@ -338,28 +338,6 @@ Compiling the Sample Code
> > >
> > >  .. code-block:: console
> > >
> > > -make
> > > -
> > > -.. note::
> > > -
> > > -Note For zero copy, need firstly disable
> CONFIG_RTE_MBUF_SCATTER_GATHER,
> > > -CONFIG_RTE_LIBRTE_IP_FRAG and
> CONFIG_RTE_LIBRTE_DISTRIBUTOR
> > > -in the config file and then re-configure and compile the core 
> > > lib, and
> then build the application:
> > > -
> > > -.. code-block:: console
> > > -
> > > -vi ${RTE_SDK}/config/common_linuxapp
> > > -
> > > -change it as follows:
> > > -
> > > -::
> > > -
> > > -CONFIG_RTE_MBUF_SCATTER_GATHER=n
> > > -CONFIG_RTE_LIBRTE_IP_FRAG=n
> > > -CONFIG_RTE_LIBRTE_DISTRIBUTOR=n
> > > -
> > > -.. code-block:: console
> > > -
> > >  cd ${RTE_SDK}
> > >  make config ${RTE_TARGET}
> > >  make install ${RTE_TARGET}
> 
> Note that make config is useless and T= is missing.
> 
> > I have one doubt about the vhost part, as the previous doc was telling
> > to disable refcnt option and now the behavior is equivalent to having
> > the option always enabled. Also you are removing parts of doc that
> > talk about CONFIG_RTE_LIBRTE_DISTRIBUTOR and
> CONFIG_RTE_LIBRTE_IP_FRAG.
> >
> > It would be safer to also have an acknowledgment from a vhost expert.
> 
> Huawei, Changchun, any opinion please?

[dpdk-dev] [PATCH v4 0/5] Refactor module `eventfd_link'

[Pavel Boldin]

This patchset contains refactoring steps for the `eventfd_link' module
of the DPDK's `librte_vhost' part.

Pavel Boldin (5):
  vhost: eventfd_link: moving ioctl to a function
  vhost: eventfd_link: add function fget_from_files
  vhost: eventfd_link: fix ioctl return values
  vhost: eventfd_link: replace copy-pasted sys_close
  vhost: eventfd_link: removing extra #includes

 lib/librte_vhost/eventfd_link/eventfd_link.c | 181 +--
 1 file changed, 87 insertions(+), 94 deletions(-)

-- 
1.9.1

[dpdk-dev] [PATCH v4 1/5] vhost: eventfd_link: moving ioctl to a function

[Pavel Boldin]

Move ioctl `EVENTFD_COPY' handler code to an inline function.
---
 lib/librte_vhost/eventfd_link/eventfd_link.c | 171 ++-
 1 file changed, 89 insertions(+), 82 deletions(-)

diff --git a/lib/librte_vhost/eventfd_link/eventfd_link.c 
b/lib/librte_vhost/eventfd_link/eventfd_link.c
index 62c45c8..d7cb81f 100644
--- a/lib/librte_vhost/eventfd_link/eventfd_link.c
+++ b/lib/librte_vhost/eventfd_link/eventfd_link.c
@@ -65,9 +65,8 @@ put_files_struct(struct files_struct *files)
BUG();
 }

-
-static long
-eventfd_link_ioctl(struct file *f, unsigned int ioctl, unsigned long arg)
+static inline long
+eventfd_link_ioctl_copy(unsigned long arg)
 {
void __user *argp = (void __user *) arg;
struct task_struct *task_target = NULL;
@@ -76,90 +75,98 @@ eventfd_link_ioctl(struct file *f, unsigned int ioctl, 
unsigned long arg)
struct fdtable *fdt;
struct eventfd_copy eventfd_copy;

-   switch (ioctl) {
-   case EVENTFD_COPY:
-   if (copy_from_user(&eventfd_copy, argp,
-   sizeof(struct eventfd_copy)))
-   return -EFAULT;
-
-   /*
-* Find the task struct for the target pid
-*/
-   task_target =
-   pid_task(find_vpid(eventfd_copy.target_pid), 
PIDTYPE_PID);
-   if (task_target == NULL) {
-   pr_debug("Failed to get mem ctx for target pid\n");
-   return -EFAULT;
-   }
-
-   files = get_files_struct(current);
-   if (files == NULL) {
-   pr_debug("Failed to get files struct\n");
-   return -EFAULT;
-   }
-
-   rcu_read_lock();
-   file = fcheck_files(files, eventfd_copy.source_fd);
-   if (file) {
-   if (file->f_mode & FMODE_PATH ||
-   !atomic_long_inc_not_zero(&file->f_count))
+   if (copy_from_user(&eventfd_copy, argp,
+   sizeof(struct eventfd_copy)))
+   return -EFAULT;
+
+   /*
+* Find the task struct for the target pid
+*/
+   task_target =
+   pid_task(find_vpid(eventfd_copy.target_pid), PIDTYPE_PID);
+   if (task_target == NULL) {
+   pr_debug("Failed to get mem ctx for target pid\n");
+   return -EFAULT;
+   }
+
+   files = get_files_struct(current);
+   if (files == NULL) {
+   pr_debug("Failed to get files struct\n");
+   return -EFAULT;
+   }
+
+   rcu_read_lock();
+   file = fcheck_files(files, eventfd_copy.source_fd);
+   if (file) {
+   if (file->f_mode & FMODE_PATH ||
+   !atomic_long_inc_not_zero(&file->f_count))
+   file = NULL;
+   }
+   rcu_read_unlock();
+   put_files_struct(files);
+
+   if (file == NULL) {
+   pr_debug("Failed to get file from source pid\n");
+   return 0;
+   }
+
+   /*
+* Release the existing eventfd in the source process
+*/
+   spin_lock(&files->file_lock);
+   fput(file);
+   filp_close(file, files);
+   fdt = files_fdtable(files);
+   fdt->fd[eventfd_copy.source_fd] = NULL;
+   spin_unlock(&files->file_lock);
+
+   /*
+* Find the file struct associated with the target fd.
+*/
+
+   files = get_files_struct(task_target);
+   if (files == NULL) {
+   pr_debug("Failed to get files struct\n");
+   return -EFAULT;
+   }
+
+   rcu_read_lock();
+   file = fcheck_files(files, eventfd_copy.target_fd);
+   if (file) {
+   if (file->f_mode & FMODE_PATH ||
+   !atomic_long_inc_not_zero(&file->f_count))
file = NULL;
-   }
-   rcu_read_unlock();
-   put_files_struct(files);
-
-   if (file == NULL) {
-   pr_debug("Failed to get file from source pid\n");
-   return 0;
-   }
-
-   /*
-* Release the existing eventfd in the source process
-*/
-   spin_lock(&files->file_lock);
-   fput(file);
-   filp_close(file, files);
-   fdt = files_fdtable(files);
-   fdt->fd[eventfd_copy.source_fd] = NULL;
-   spin_unlock(&files->file_lock);
-
-   /*
-* Find the file struct associated with the target fd.
-*/
-
-   files = get_files_struct(task_target);
-   if (files == NULL) {
-   pr_debug("Failed to get files struct\n");
-   return -EFAULT;
-   }
-
-   rcu_read_lock();
-   file = fcheck_files(files, eventfd_copy.target_fd);
-

[dpdk-dev] [PATCH v4 3/5] vhost: eventfd_link: fix ioctl return values

[Pavel Boldin]

Fix ioctl return values:
 * `-EFAULT' when unable to fetch user supplied arguments,
 * `-ESRCH' when no target process is found,
 * `-ESTALE' when unable to get `struct files',
 * `-EBADF' when unable to get `struct file' for fd.
---
 lib/librte_vhost/eventfd_link/eventfd_link.c | 46 ++--
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/lib/librte_vhost/eventfd_link/eventfd_link.c 
b/lib/librte_vhost/eventfd_link/eventfd_link.c
index 2a2..0a06594 100644
--- a/lib/librte_vhost/eventfd_link/eventfd_link.c
+++ b/lib/librte_vhost/eventfd_link/eventfd_link.c
@@ -92,33 +92,38 @@ eventfd_link_ioctl_copy(unsigned long arg)
struct files_struct *files;
struct fdtable *fdt;
struct eventfd_copy eventfd_copy;
+   long ret = -EFAULT;

-   if (copy_from_user(&eventfd_copy, argp,
-   sizeof(struct eventfd_copy)))
-   return -EFAULT;
+   if (copy_from_user(&eventfd_copy, argp, sizeof(struct eventfd_copy)))
+   goto out;

/*
 * Find the task struct for the target pid
 */
+   ret = -ESRCH;
+
task_target =
-   pid_task(find_vpid(eventfd_copy.target_pid), PIDTYPE_PID);
+   get_pid_task(find_vpid(eventfd_copy.target_pid), PIDTYPE_PID);
if (task_target == NULL) {
-   pr_debug("Failed to get mem ctx for target pid\n");
-   return -EFAULT;
+   pr_info("Unable to find pid %d\n", eventfd_copy.target_pid);
+   goto out;
}

+   ret = -ESTALE;
files = get_files_struct(current);
if (files == NULL) {
-   pr_debug("Failed to get files struct\n");
-   return -EFAULT;
+   pr_info("Failed to get current files struct\n");
+   goto out_task;
}

+   ret = -EBADF;
file = fget_from_files(files, eventfd_copy.source_fd);
-   put_files_struct(files);

if (file == NULL) {
-   pr_debug("Failed to get file from source pid\n");
-   return 0;
+   pr_info("Failed to get fd %d from source\n",
+   eventfd_copy.source_fd);
+   put_files_struct(files);
+   goto out_task;
}

/*
@@ -131,22 +136,27 @@ eventfd_link_ioctl_copy(unsigned long arg)
fdt->fd[eventfd_copy.source_fd] = NULL;
spin_unlock(&files->file_lock);

+   put_files_struct(files);
+
/*
 * Find the file struct associated with the target fd.
 */

+   ret = -ESTALE;
files = get_files_struct(task_target);
if (files == NULL) {
-   pr_debug("Failed to get files struct\n");
-   return -EFAULT;
+   pr_info("Failed to get target files struct\n");
+   goto out_task;
}

+   ret = -EBADF;
file = fget_from_files(files, eventfd_copy.target_fd);
put_files_struct(files);

if (file == NULL) {
-   pr_debug("Failed to get file from target pid\n");
-   return 0;
+   pr_info("Failed to get fd %d from target\n",
+   eventfd_copy.target_fd);
+   goto out_task;
}

/*
@@ -155,8 +165,12 @@ eventfd_link_ioctl_copy(unsigned long arg)
 */

fd_install(eventfd_copy.source_fd, file);
+   ret = 0;

-   return 0;
+out_task:
+   put_task_struct(task_target);
+out:
+   return ret;
 }

 static long
-- 
1.9.1

[dpdk-dev] [PATCH v4 2/5] vhost: eventfd_link: add function fget_from_files

[Pavel Boldin]

Move copy-pasted code of `fget' for different `struct files' to
the added `fget_from_files' function.
---
 lib/librte_vhost/eventfd_link/eventfd_link.c | 36 +++-
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/lib/librte_vhost/eventfd_link/eventfd_link.c 
b/lib/librte_vhost/eventfd_link/eventfd_link.c
index d7cb81f..2a2 100644
--- a/lib/librte_vhost/eventfd_link/eventfd_link.c
+++ b/lib/librte_vhost/eventfd_link/eventfd_link.c
@@ -65,6 +65,24 @@ put_files_struct(struct files_struct *files)
BUG();
 }

+static struct file *
+fget_from_files(struct files_struct *files, unsigned fd)
+{
+   struct file *file;
+
+   rcu_read_lock();
+   file = fcheck_files(files, fd);
+   if (file)
+   {
+   if (file->f_mode & FMODE_PATH
+   || !atomic_long_inc_not_zero(&file->f_count))
+   file = NULL;
+   }
+   rcu_read_unlock();
+
+   return file;
+}
+
 static inline long
 eventfd_link_ioctl_copy(unsigned long arg)
 {
@@ -95,14 +113,7 @@ eventfd_link_ioctl_copy(unsigned long arg)
return -EFAULT;
}

-   rcu_read_lock();
-   file = fcheck_files(files, eventfd_copy.source_fd);
-   if (file) {
-   if (file->f_mode & FMODE_PATH ||
-   !atomic_long_inc_not_zero(&file->f_count))
-   file = NULL;
-   }
-   rcu_read_unlock();
+   file = fget_from_files(files, eventfd_copy.source_fd);
put_files_struct(files);

if (file == NULL) {
@@ -130,14 +141,7 @@ eventfd_link_ioctl_copy(unsigned long arg)
return -EFAULT;
}

-   rcu_read_lock();
-   file = fcheck_files(files, eventfd_copy.target_fd);
-   if (file) {
-   if (file->f_mode & FMODE_PATH ||
-   !atomic_long_inc_not_zero(&file->f_count))
-   file = NULL;
-   }
-   rcu_read_unlock();
+   file = fget_from_files(files, eventfd_copy.target_fd);
put_files_struct(files);

if (file == NULL) {
-- 
1.9.1

[dpdk-dev] [PATCH v4 4/5] vhost: eventfd_link: replace copy-pasted sys_close

[Pavel Boldin]

Replace copy-pasted `fget_from_files' -> `filp_close' with
a `sys_close' call.
---
 lib/librte_vhost/eventfd_link/eventfd_link.c | 49 +++-
 1 file changed, 12 insertions(+), 37 deletions(-)

diff --git a/lib/librte_vhost/eventfd_link/eventfd_link.c 
b/lib/librte_vhost/eventfd_link/eventfd_link.c
index 0a06594..9bc52a3 100644
--- a/lib/librte_vhost/eventfd_link/eventfd_link.c
+++ b/lib/librte_vhost/eventfd_link/eventfd_link.c
@@ -88,9 +88,8 @@ eventfd_link_ioctl_copy(unsigned long arg)
 {
void __user *argp = (void __user *) arg;
struct task_struct *task_target = NULL;
-   struct file *file;
-   struct files_struct *files;
-   struct fdtable *fdt;
+   struct file *target_file;
+   struct files_struct *target_files;
struct eventfd_copy eventfd_copy;
long ret = -EFAULT;

@@ -109,51 +108,27 @@ eventfd_link_ioctl_copy(unsigned long arg)
goto out;
}

-   ret = -ESTALE;
-   files = get_files_struct(current);
-   if (files == NULL) {
-   pr_info("Failed to get current files struct\n");
-   goto out_task;
-   }
-
-   ret = -EBADF;
-   file = fget_from_files(files, eventfd_copy.source_fd);
-
-   if (file == NULL) {
-   pr_info("Failed to get fd %d from source\n",
-   eventfd_copy.source_fd);
-   put_files_struct(files);
+   /* Closing the source_fd */
+   ret = sys_close(eventfd_copy.source_fd);
+   if (ret)
goto out_task;
-   }
-
-   /*
-* Release the existing eventfd in the source process
-*/
-   spin_lock(&files->file_lock);
-   fput(file);
-   filp_close(file, files);
-   fdt = files_fdtable(files);
-   fdt->fd[eventfd_copy.source_fd] = NULL;
-   spin_unlock(&files->file_lock);
-
-   put_files_struct(files);
+   ret = -ESTALE;

/*
 * Find the file struct associated with the target fd.
 */

-   ret = -ESTALE;
-   files = get_files_struct(task_target);
-   if (files == NULL) {
+   target_files = get_files_struct(task_target);
+   if (target_files == NULL) {
pr_info("Failed to get target files struct\n");
goto out_task;
}

ret = -EBADF;
-   file = fget_from_files(files, eventfd_copy.target_fd);
-   put_files_struct(files);
+   target_file = fget_from_files(target_files, eventfd_copy.target_fd);
+   put_files_struct(target_files);

-   if (file == NULL) {
+   if (target_file == NULL) {
pr_info("Failed to get fd %d from target\n",
eventfd_copy.target_fd);
goto out_task;
@@ -164,7 +139,7 @@ eventfd_link_ioctl_copy(unsigned long arg)
 * file desciptor of the source process,
 */

-   fd_install(eventfd_copy.source_fd, file);
+   fd_install(eventfd_copy.source_fd, target_file);
ret = 0;

 out_task:
-- 
1.9.1

[dpdk-dev] [PATCH v4 5/5] vhost: eventfd_link: removing extra #includes

[Pavel Boldin]

---
 lib/librte_vhost/eventfd_link/eventfd_link.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/lib/librte_vhost/eventfd_link/eventfd_link.c 
b/lib/librte_vhost/eventfd_link/eventfd_link.c
index 9bc52a3..0ee7357 100644
--- a/lib/librte_vhost/eventfd_link/eventfd_link.c
+++ b/lib/librte_vhost/eventfd_link/eventfd_link.c
@@ -22,18 +22,11 @@
  *   Intel Corporation
  */

-#include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
+#include 

 #include "eventfd_link.h"

-- 
1.9.1

[dpdk-dev] [PATCH v3 1/5] mbuf: fix clone support when application uses private mbuf data

[Ananyev, Konstantin]

Hi Olivier,

> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, March 31, 2015 8:23 PM
> To: dev at dpdk.org
> Cc: Ananyev, Konstantin; zoltan.kiss at linaro.org; Richardson, Bruce; 
> Olivier Matz
> Subject: [PATCH v3 1/5] mbuf: fix clone support when application uses private 
> mbuf data
> 
> From: Olivier Matz 
> 
> Add a new private_size field in mbuf structure that should
> be initialized at mbuf pool creation. This field contains the
> size of the application private data in mbufs.
> 
> Introduce new static inline functions rte_mbuf_from_indirect()
> and rte_mbuf_to_baddr() to replace the existing macros, which
> take the private size in account when attaching and detaching
> mbufs.
> 
> Signed-off-by: Olivier Matz 
> ---
>  app/test-pmd/testpmd.c |  1 +
>  examples/vhost/main.c  |  4 +--
>  lib/librte_mbuf/rte_mbuf.c |  1 +
>  lib/librte_mbuf/rte_mbuf.h | 77 
> +++---
>  4 files changed, 63 insertions(+), 20 deletions(-)
> 
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 3057791..c5a195a 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -425,6 +425,7 @@ testpmd_mbuf_ctor(struct rte_mempool *mp,
>   mb->tx_offload   = 0;
>   mb->vlan_tci = 0;
>   mb->hash.rss = 0;
> + mb->priv_size= 0;
>  }
> 
>  static void
> diff --git a/examples/vhost/main.c b/examples/vhost/main.c
> index c3fcb80..e44e82f 100644
> --- a/examples/vhost/main.c
> +++ b/examples/vhost/main.c
> @@ -139,7 +139,7 @@
>  /* Number of descriptors per cacheline. */
>  #define DESC_PER_CACHELINE (RTE_CACHE_LINE_SIZE / sizeof(struct vring_desc))
> 
> -#define MBUF_EXT_MEM(mb)   (RTE_MBUF_FROM_BADDR((mb)->buf_addr) != (mb))
> +#define MBUF_EXT_MEM(mb)   (rte_mbuf_from_indirect(mb) != (mb))
> 
>  /* mask of enabled ports */
>  static uint32_t enabled_port_mask = 0;
> @@ -1550,7 +1550,7 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
>  static inline void pktmbuf_detach_zcp(struct rte_mbuf *m)
>  {
>   const struct rte_mempool *mp = m->pool;
> - void *buf = RTE_MBUF_TO_BADDR(m);
> + void *buf = rte_mbuf_to_baddr(m);
>   uint32_t buf_ofs;
>   uint32_t buf_len = mp->elt_size - sizeof(*m);
>   m->buf_physaddr = rte_mempool_virt2phy(mp, m) + sizeof(*m);
> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> index 526b18d..e095999 100644
> --- a/lib/librte_mbuf/rte_mbuf.c
> +++ b/lib/librte_mbuf/rte_mbuf.c
> @@ -125,6 +125,7 @@ rte_pktmbuf_init(struct rte_mempool *mp,
>   m->pool = mp;
>   m->nb_segs = 1;
>   m->port = 0xff;
> + m->priv_size = 0;

Why it is 0?
Shouldn't it be the same calulations as in detach() below:
m->priv_size = /*get private size from mempool private*/;
m->buf_addr = (char *)m + sizeof(struct rte_mbuf) + m->priv_size;
m->buf_len = mp->elt_size - sizeof(struct rte_mbuf) - m->priv_size;
?

BTW, don't see changes in rte_pktmbuf_pool_init() to setup
mbp_priv->mbuf_data_room_size properly.
Without that changes, how can people start using that feature?
It seems that the only way now - setup priv_size and buf_len for each mbuf 
manually.

>  }
> 
>  /* do some sanity checks on a mbuf: panic if it fails */
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 17ba791..932fe58 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -317,18 +317,51 @@ struct rte_mbuf {
>   /* uint64_t unused:8; */
>   };
>   };
> +
> + /** Size of the application private data. In case of an indirect
> +  * mbuf, it stores the direct mbuf private data size. */
> + uint16_t priv_size;
>  } __rte_cache_aligned;
> 
>  /**
> - * Given the buf_addr returns the pointer to corresponding mbuf.
> + * Return the mbuf owning the data buffer address of an indirect mbuf.
> + *
> + * @param mi
> + *   The pointer to the indirect mbuf.
> + * @return
> + *   The address of the direct mbuf corresponding to buffer_addr.
>   */
> -#define RTE_MBUF_FROM_BADDR(ba) (((struct rte_mbuf *)(ba)) - 1)
> +static inline struct rte_mbuf *
> +rte_mbuf_from_indirect(struct rte_mbuf *mi)
> +{
> +   struct rte_mbuf *md;
> +
> +   /* mi->buf_addr and mi->priv_size correspond to buffer and
> + * private size of the direct mbuf */
> +   md = (struct rte_mbuf *)((char *)mi->buf_addr - sizeof(*mi) -
> +mi->priv_size);

(uintptr_t)mi->buf_addr?

> +   return md;
> +}
> 
>  /**
> - * Given the pointer to mbuf returns an address where it's  buf_addr
> - * should point to.
> + * Return the buffer address embedded in the given mbuf.
> + *
> + * The user must ensure that m->priv_size corresponds to the
> + * private size of this mbuf, which is not the case for indirect
> + * mbufs.
> + *
> + * @param md
> + *   The pointer to the mbuf.
> + * @return
> + *   The address of the data buffer owned by the mbuf.
>   */
> -#define RTE_MBUF_TO_BADDR(m

[dpdk-dev] [PATCH 0/5] packaging release 2.0.0

[Thomas Monjalon]

These are the last patches needed for packaging the release of dpdk-2.0.0.
It was tested to generate a RPM on Fedora 20 without fuse.
The package includes PDF doc and enable features for vhost, pcap and Xen.

If nobody see something wrong in these patches, they will be applied
tomorrow, April 3rd in order to close the release.

Thomas Monjalon (5):
  mk: remove fuse requirement for vhost-user
  mk: reduce PDF build commands
  pkg: remove -core file suffix
  pkg: update RPM
  version: 2.0.0

 doc/guides/rel_notes/index.rst  |  2 +-
 doc/guides/rel_notes/rel_description.rst|  2 +-
 lib/librte_eal/common/include/rte_version.h |  4 +-
 mk/rte.app.mk   |  2 +-
 mk/rte.sdkdoc.mk|  2 +-
 pkg/{dpdk-core.spec => dpdk.spec}   | 59 -
 6 files changed, 38 insertions(+), 33 deletions(-)
 rename pkg/{dpdk-core.spec => dpdk.spec} (66%)

-- 
2.2.2

[dpdk-dev] [PATCH 1/5] mk: remove fuse requirement for vhost-user

[Thomas Monjalon]

The fuse library is needed for vhost-cuse as required in commit 28a1ccca41bf.
The case vhost-user was forgotten for application linking.

Fixes: 28a1ccca41bf ("vhost: add build option for vhost-user")

Signed-off-by: Thomas Monjalon 
---
 mk/rte.app.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 63a41e2..56886dc 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -143,7 +143,7 @@ ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
 LDLIBS += -lpcap
 endif

-ifeq ($(CONFIG_RTE_LIBRTE_VHOST),y)
+ifeq ($(CONFIG_RTE_LIBRTE_VHOST)$(CONFIG_RTE_LIBRTE_VHOST_USER),yn)
 LDLIBS += -lfuse
 endif

-- 
2.2.2

[dpdk-dev] [PATCH 2/5] mk: reduce PDF build commands

[Thomas Monjalon]

In case of documents without image, an empty rm command can be seen if V=1.
Remove it to avoid disturbing debugging.

Signed-off-by: Thomas Monjalon 
---
 mk/rte.sdkdoc.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mk/rte.sdkdoc.mk b/mk/rte.sdkdoc.mk
index f91e079..9952f25 100644
--- a/mk/rte.sdkdoc.mk
+++ b/mk/rte.sdkdoc.mk
@@ -99,7 +99,7 @@ guides-pdf-%:
$(Q)$(RTE_SPHINX_BUILD) -b latex $(RTE_SPHINX_VERBOSE) \
-c $(RTE_SDK)/doc/guides $(RTE_SDK)/doc/guides/$* \
$(RTE_OUTPUT)/doc/pdf/guides/$*
-   $(Q)rm -f $^
+   $(if $^,$(Q)rm -f $^)
@echo 'pdflatex processing $@...'
$(Q)$(MAKE) all-pdf -sC $(RTE_OUTPUT)/doc/pdf/guides/$* \
LATEXOPTS=$(RTE_PDFLATEX_VERBOSE)
-- 
2.2.2

[dpdk-dev] [PATCH 3/5] pkg: remove -core file suffix

[Thomas Monjalon]

Since -core suffix was removed from the package names in commit
6f2760ecdf4e, the file name should also be updated.

The alignment of build commands is also changed to prepare next patch.

Signed-off-by: Thomas Monjalon 
---
 pkg/{dpdk-core.spec => dpdk.spec} | 48 +++
 1 file changed, 24 insertions(+), 24 deletions(-)
 rename pkg/{dpdk-core.spec => dpdk.spec} (71%)

diff --git a/pkg/dpdk-core.spec b/pkg/dpdk.spec
similarity index 71%
rename from pkg/dpdk-core.spec
rename to pkg/dpdk.spec
index 76ae701..9a92e95 100644
--- a/pkg/dpdk-core.spec
+++ b/pkg/dpdk.spec
@@ -88,30 +88,30 @@ make O=%{target} doc

 %install
 rm -rf %{buildroot}
-make   O=%{target} DESTDIR=%{destdir}
-mkdir -p   %{buildroot}%{moddir}
-mv%{destdir}/%{target}/kmod/*.ko   %{buildroot}%{moddir}
-rmdir %{destdir}/%{target}/kmod
-mkdir -p   %{buildroot}%{_sbindir}
-ln -s %{datadir}/tools/*nic_bind.py%{buildroot}%{_sbindir}/dpdk_nic_bind
-mkdir -p   %{buildroot}%{_bindir}
-mv%{destdir}/%{target}/app/testpmd %{buildroot}%{_bindir}
-rmdir %{destdir}/%{target}/app
-mv%{destdir}/%{target}/include %{buildroot}%{_includedir}
-mv%{destdir}/%{target}/lib %{buildroot}%{_libdir}
-mkdir -p   %{buildroot}%{docdir}
-mv%{destdir}/%{target}/doc/*   %{buildroot}%{docdir}
-rmdir %{destdir}/%{target}/doc
-mkdir -p   %{buildroot}%{datadir}
-mv%{destdir}/%{target}/.config %{buildroot}%{datadir}/config
-mv%{destdir}/%{target} %{buildroot}%{datadir}
-mv%{destdir}/scripts   %{buildroot}%{datadir}
-mv%{destdir}/mk%{buildroot}%{datadir}
-cp -aexamples  %{buildroot}%{datadir}
-cp -atools %{buildroot}%{datadir}
-ln -s%{datadir}/config %{buildroot}%{datadir}/%{target}/.config
-ln -s%{_includedir}%{buildroot}%{datadir}/%{target}/include
-ln -s%{_libdir}%{buildroot}%{datadir}/%{target}/lib
+makeO=%{target}  DESTDIR=%{destdir}
+mkdir -p %{buildroot}%{moddir}
+mv %{destdir}/%{target}/kmod/*.ko%{buildroot}%{moddir}
+rmdir  %{destdir}/%{target}/kmod
+mkdir -p %{buildroot}%{_sbindir}
+ln -s  %{datadir}/tools/*nic_bind.py %{buildroot}%{_sbindir}/dpdk_nic_bind
+mkdir -p %{buildroot}%{_bindir}
+mv %{destdir}/%{target}/app/testpmd  %{buildroot}%{_bindir}
+rmdir  %{destdir}/%{target}/app
+mv %{destdir}/%{target}/include  %{buildroot}%{_includedir}
+mv %{destdir}/%{target}/lib  %{buildroot}%{_libdir}
+mkdir -p %{buildroot}%{docdir}
+mv %{destdir}/%{target}/doc/*%{buildroot}%{docdir}
+rmdir  %{destdir}/%{target}/doc
+mkdir -p %{buildroot}%{datadir}
+mv %{destdir}/%{target}/.config  %{buildroot}%{datadir}/config
+mv %{destdir}/%{target}  %{buildroot}%{datadir}
+mv %{destdir}/scripts%{buildroot}%{datadir}
+mv %{destdir}/mk %{buildroot}%{datadir}
+cp -a examples   %{buildroot}%{datadir}
+cp -a tools  %{buildroot}%{datadir}
+ln -s %{datadir}/config  
%{buildroot}%{datadir}/%{target}/.config
+ln -s %{_includedir} 
%{buildroot}%{datadir}/%{target}/include
+ln -s %{_libdir} %{buildroot}%{datadir}/%{target}/lib

 %files
 %dir %{datadir}
-- 
2.2.2

[dpdk-dev] [PATCH 4/5] pkg: update RPM

[Thomas Monjalon]

Enable vhost-user and build PDF doc.
Inkscape and TeXLive are required to convert .svg and .rst to .pdf.
Temporary sphinx files .* (.doctrees/ and .buildinfo) are cleaned.

Tested on Fedora 20.

Signed-off-by: Thomas Monjalon 
---
 pkg/dpdk.spec | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/pkg/dpdk.spec b/pkg/dpdk.spec
index 9a92e95..56fccd0 100644
--- a/pkg/dpdk.spec
+++ b/pkg/dpdk.spec
@@ -44,7 +44,9 @@ ExclusiveArch: i686, x86_64
 %global target %{_arch}-native-linuxapp-gcc
 %global machine default

-BuildRequires: kernel-devel, kernel-headers, libpcap-devel, xen-devel, 
doxygen, python-sphinx
+BuildRequires: kernel-devel, kernel-headers, libpcap-devel, xen-devel
+BuildRequires: doxygen, python-sphinx, inkscape
+BuildRequires: texlive-collection-latexextra, texlive-collection-fontsextra

 %description
 DPDK core includes kernel modules, core libraries and tools.
@@ -65,7 +67,7 @@ Summary: Data Plane Development Kit API documentation
 BuildArch: noarch
 %description doc
 DPDK doc is divided in two parts: API details in doxygen HTML format
-and guides in sphinx HTML format.
+and guides in sphinx HTML/PDF formats.

 %global destdir %{buildroot}%{_prefix}
 %global moddir  /lib/modules/%(uname -r)/extra
@@ -80,6 +82,7 @@ make O=%{target} T=%{target} config
 sed -ri 's,(RTE_MACHINE=).*,\1%{machine},' %{target}/.config
 sed -ri 's,(RTE_APP_TEST=).*,\1n,' %{target}/.config
 sed -ri 's,(RTE_BUILD_SHARED_LIB=).*,\1y,' %{target}/.config
+sed -ri 's,(LIBRTE_VHOST=).*,\1y,' %{target}/.config
 sed -ri 's,(LIBRTE_PMD_PCAP=).*,\1y,'  %{target}/.config
 sed -ri 's,(LIBRTE_PMD_XENVIRT=).*,\1y,'   %{target}/.config
 sed -ri 's,(LIBRTE_XEN_DOM0=).*,\1y,'  %{target}/.config
@@ -100,8 +103,10 @@ rmdir  %{destdir}/%{target}/app
 mv %{destdir}/%{target}/include  %{buildroot}%{_includedir}
 mv %{destdir}/%{target}/lib  %{buildroot}%{_libdir}
 mkdir -p %{buildroot}%{docdir}
-mv %{destdir}/%{target}/doc/*%{buildroot}%{docdir}
-rmdir  %{destdir}/%{target}/doc
+rm -rf %{destdir}/%{target}/doc/*/*/.{build,doc}*
+mv %{destdir}/%{target}/doc/html/*   %{buildroot}%{docdir}
+mv %{destdir}/%{target}/doc/*/*/*pdf %{buildroot}%{docdir}/guides
+rm -rf %{destdir}/%{target}/doc
 mkdir -p %{buildroot}%{datadir}
 mv %{destdir}/%{target}/.config  %{buildroot}%{datadir}/config
 mv %{destdir}/%{target}  %{buildroot}%{datadir}
-- 
2.2.2

[dpdk-dev] [PATCH 5/5] version: 2.0.0

[Thomas Monjalon]

Signed-off-by: Thomas Monjalon 
---
 doc/guides/rel_notes/index.rst  | 2 +-
 doc/guides/rel_notes/rel_description.rst| 2 +-
 lib/librte_eal/common/include/rte_version.h | 4 ++--
 pkg/dpdk.spec   | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index cf712b2..d790783 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -31,7 +31,7 @@
 Release Notes
 =

-Package Version: 1.8
+Package Version: 2.0

 |today|

diff --git a/doc/guides/rel_notes/rel_description.rst 
b/doc/guides/rel_notes/rel_description.rst
index c8ff483..9b1fb7f 100644
--- a/doc/guides/rel_notes/rel_description.rst
+++ b/doc/guides/rel_notes/rel_description.rst
@@ -32,7 +32,7 @@ Description of Release
 ==

 These release notes cover the new features,
-fixed bugs and known issues for Data Plane Development Kit (DPDK) release 
version 1.7.0.
+fixed bugs and known issues for Data Plane Development Kit (DPDK) release 
version 2.0.0.

 For instructions on compiling and running the release, see the *DPDK Getting 
Started Guide*.

diff --git a/lib/librte_eal/common/include/rte_version.h 
b/lib/librte_eal/common/include/rte_version.h
index 5a50809..459b648 100644
--- a/lib/librte_eal/common/include/rte_version.h
+++ b/lib/librte_eal/common/include/rte_version.h
@@ -70,14 +70,14 @@ extern "C" {
 /**
  * Extra string to be appended to version number
  */
-#define RTE_VER_SUFFIX "-rc"
+#define RTE_VER_SUFFIX ""

 /**
  * Patch release number
  *   0-15 = release candidates
  *   16   = release
  */
-#define RTE_VER_PATCH_RELEASE 3
+#define RTE_VER_PATCH_RELEASE 16

 /**
  * Macro to compute a version number usable for comparisons
diff --git a/pkg/dpdk.spec b/pkg/dpdk.spec
index 56fccd0..5f6ec6a 100644
--- a/pkg/dpdk.spec
+++ b/pkg/dpdk.spec
@@ -30,7 +30,7 @@
 # OF THE POSSIBILITY OF SUCH DAMAGE.

 Name: dpdk
-Version: 1.8.0
+Version: 2.0.0
 Release: 1
 Packager: packaging at 6wind.com
 URL: http://dpdk.org
-- 
2.2.2

[dpdk-dev] [PATCH v3] ixgbe: fix data access on big endian cpu

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of
> xuelin.shi at freescale.com
> Sent: Tuesday, March 31, 2015 8:26 AM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org; Xuelin Shi
> Subject: [dpdk-dev] [PATCH v3] ixgbe: fix data access on big endian cpu
> 
> From: Xuelin Shi 
> 
> enforce rules of the cpu and ixgbe exchange data.
> 1. cpu use data owned by ixgbe must use rte_le_to_cpu_xx(...) 2. cpu fill
> data to ixgbe must use rte_cpu_to_le_xx(...) 3. checking pci status with
> converted constant.
> 
> Signed-off-by: Xuelin Shi 
> ---
> change for v3:
>check pci status with converted constant to avoid performance penalty.
>remove tmp variable.
> 
>  lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 89 ---
> 
>  1 file changed, 56 insertions(+), 33 deletions(-)
> 
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> index 9da2c7e..6e508ec 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> @@ -129,7 +129,7 @@ ixgbe_tx_free_bufs(struct ixgbe_tx_queue *txq)
> 
>   /* check DD bit on threshold descriptor */
>   status = txq->tx_ring[txq->tx_next_dd].wb.status;
> - if (! (status & IXGBE_ADVTXD_STAT_DD))
> + if (!(status & rte_cpu_to_le_32(IXGBE_ADVTXD_STAT_DD)))
>   return 0;
> 
>   /*
> @@ -174,11 +174,14 @@ tx4(volatile union ixgbe_adv_tx_desc *txdp, struct
> rte_mbuf **pkts)
>   pkt_len = (*pkts)->data_len;
> 
>   /* write data to descriptor */
> - txdp->read.buffer_addr = buf_dma_addr;
> + txdp->read.buffer_addr =
> rte_cpu_to_le_64(buf_dma_addr);
> +
>   txdp->read.cmd_type_len =
> - ((uint32_t)DCMD_DTYP_FLAGS | pkt_len);
> + rte_cpu_to_le_32((uint32_t)DCMD_DTYP_FLAGS |
> pkt_len);
> +
>   txdp->read.olinfo_status =
> - (pkt_len << IXGBE_ADVTXD_PAYLEN_SHIFT);
> + rte_cpu_to_le_32(pkt_len <<
> IXGBE_ADVTXD_PAYLEN_SHIFT);
> +
>   rte_prefetch0(&(*pkts)->pool);
>   }
>  }
> @@ -194,11 +197,14 @@ tx1(volatile union ixgbe_adv_tx_desc *txdp, struct
> rte_mbuf **pkts)
>   pkt_len = (*pkts)->data_len;
> 
>   /* write data to descriptor */
> - txdp->read.buffer_addr = buf_dma_addr;
> + txdp->read.buffer_addr = rte_cpu_to_le_64(buf_dma_addr);
> +
>   txdp->read.cmd_type_len =
> - ((uint32_t)DCMD_DTYP_FLAGS | pkt_len);
> + rte_cpu_to_le_32((uint32_t)DCMD_DTYP_FLAGS |
> pkt_len);
> +
>   txdp->read.olinfo_status =
> - (pkt_len << IXGBE_ADVTXD_PAYLEN_SHIFT);
> + rte_cpu_to_le_32(pkt_len <<
> IXGBE_ADVTXD_PAYLEN_SHIFT);
> +
>   rte_prefetch0(&(*pkts)->pool);
>  }
> 
> @@ -285,7 +291,7 @@ tx_xmit_pkts(void *tx_queue, struct rte_mbuf
> **tx_pkts,
>* a divisor of the ring size
>*/
>   tx_r[txq->tx_next_rs].read.cmd_type_len |=
> - rte_cpu_to_le_32(IXGBE_ADVTXD_DCMD_RS);
> +
>   rte_cpu_to_le_32(IXGBE_ADVTXD_DCMD_RS);
>   txq->tx_next_rs = (uint16_t)(txq->tx_rs_thresh - 1);
> 
>   txq->tx_tail = 0;
> @@ -304,7 +310,7 @@ tx_xmit_pkts(void *tx_queue, struct rte_mbuf
> **tx_pkts,
>*/
>   if (txq->tx_tail > txq->tx_next_rs) {
>   tx_r[txq->tx_next_rs].read.cmd_type_len |=
> - rte_cpu_to_le_32(IXGBE_ADVTXD_DCMD_RS);
> +
>   rte_cpu_to_le_32(IXGBE_ADVTXD_DCMD_RS);
>   txq->tx_next_rs = (uint16_t)(txq->tx_next_rs +
>   txq->tx_rs_thresh);
>   if (txq->tx_next_rs >= txq->nb_tx_desc) @@ -505,6 +511,7
> @@ ixgbe_xmit_cleanup(struct ixgbe_tx_queue *txq)
>   uint16_t nb_tx_desc = txq->nb_tx_desc;
>   uint16_t desc_to_clean_to;
>   uint16_t nb_tx_to_clean;
> + uint32_t stat;
> 
>   /* Determine the last descriptor needing to be cleaned */
>   desc_to_clean_to = (uint16_t)(last_desc_cleaned + txq-
> >tx_rs_thresh); @@ -513,7 +520,9 @@ ixgbe_xmit_cleanup(struct
> ixgbe_tx_queue *txq)
> 
>   /* Check to make sure the last descriptor to clean is done */
>   desc_to_clean_to = sw_ring[desc_to_clean_to].last_id;
> - if (! (txr[desc_to_clean_to].wb.status & IXGBE_TXD_STAT_DD))
> +
> + stat = txr[desc_to_clean_to].wb.status;
> + if (!(stat & rte_cpu_to_le_32(IXGBE_TXD_STAT_DD)))
>   {
>   PMD_TX_FREE_LOG(DEBUG,
>   "TX descriptor %4u is not done"
> @@ -801,12 +810,14 @@ ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf
> **tx_pkts,
>*/
>   slen = m_seg->data_len;
>   buf_dma_addr =
> RTE_MBUF_DATA_DMA_ADDR(m_seg);
> +
>   txd->read.buffer_addr =
> - rte_cpu_to_le_64(buf_dma_addr);
> 

[dpdk-dev] [PATCH] ixgbe: do not include CRC in Tx byte count

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen
> Hemminger
> Sent: Tuesday, March 24, 2015 3:55 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org; Stephen Hemminger
> Subject: Re: [dpdk-dev] [PATCH] ixgbe: do not include CRC in Tx byte count
> 
> On Mon, 23 Mar 2015 16:45:44 +
> "Ananyev, Konstantin"  wrote:
> 
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of
> > > stephen at networkplumber.org
> > > Sent: Friday, January 23, 2015 6:24 AM
> > > To: dev at dpdk.org
> > > Cc: Stephen Hemminger
> > > Subject: [dpdk-dev] [PATCH] ixgbe: do not include CRC in Tx byte
> > > count
> > >
> > > From: Stephen Hemminger 
> > >
> > > The ixgbe driver was including CRC in the transmit packet byte
> > > count, but not for packets received.
> > > This was notice when forwarding and
> > > the number of bytes received was greater than the number of bytes
> > > transmitted for the same number of packets. Make the driver behave
> > > like other virtual devices and not include CRC in byte count. Use
> > > the same queue counters already computed and used for Rx.
> >
> > About RX side stats - as I remember it depends to what value hw_stip_crc
> is set at configure().
> > If hw_stip_crc==1, then, yes CRC bytes are not included into  QBRC value.
> > I If hw_stip_crc==0, then CRC bytes are included into QBRC.
> 
> That is an additional bug!
>   * CRC should never be included in the byte count.
> This is not how Linux or other drivers report byte count.
> 
>   * the byte count must be symmetrical Rx == Tx
> 
> The Brocade router always set strip_crc to 1. So did not see the additional
> bug of CRC being included in byte count.
> 
> 
Great to see some discussion here all but can we hold on to the patch until 
after the 2.0 package is made so there is enough time to review and test it 
properly?
Thanks 
Siobhan

[dpdk-dev] [PATCH] doc: update version number in release notes description

[Siobhan Butler]

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/rel_description.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/rel_description.rst 
b/doc/guides/rel_notes/rel_description.rst
index c8ff483..2fb5379 100644
--- a/doc/guides/rel_notes/rel_description.rst
+++ b/doc/guides/rel_notes/rel_description.rst
@@ -32,7 +32,7 @@ Description of Release
 ==

 These release notes cover the new features,
-fixed bugs and known issues for Data Plane Development Kit (DPDK) release 
version 1.7.0.
+fixed bugs and known issues for Data Plane Development Kit (DPDK) release 
version 2.0.

 For instructions on compiling and running the release, see the *DPDK Getting 
Started Guide*.

-- 
1.8.3.1

[dpdk-dev] [PATCH] doc: update version number in release notes description

[Thomas Monjalon]

2015-04-02 21:41, Siobhan Butler:
> --- a/doc/guides/rel_notes/rel_description.rst
> +++ b/doc/guides/rel_notes/rel_description.rst
> -fixed bugs and known issues for Data Plane Development Kit (DPDK) release 
> version 1.7.0.
> +fixed bugs and known issues for Data Plane Development Kit (DPDK) release 
> version 2.0.

This change is already covered by this patch:
http://dpdk.org/dev/patchwork/patch/4229/

I think it's better to change every numbers at once.
Thanks

[dpdk-dev] [PATCH] doc: remove duplicate in release nots new features

[Siobhan Butler]

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/new_features.rst | 38 +--
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/doc/guides/rel_notes/new_features.rst 
b/doc/guides/rel_notes/new_features.rst
index e3edec4..cb58409 100644
--- a/doc/guides/rel_notes/new_features.rst
+++ b/doc/guides/rel_notes/new_features.rst
@@ -32,6 +32,24 @@ New Features
 
 *   Poll-mode driver support for an early release of the PCIE host interface 
of the Intel(R) Ethernet Switch FM1.

+*   Basic Rx/Tx functions for PF/VF
+
+*   Interrupt handling support for PF/VF
+
+*   Per queue start/stop functions for PF/VF
+
+*   Support Mailbox handling between PF/VF and PF/Switch Manager
+
+*   Receive Side Scaling (RSS) for PF/VF
+
+*   Scatter receive function for PF/VF
+
+*   Reta update/query for PF/VF
+
+*   VLAN filter set for PF
+
+*   Link status query for PF/VF
+
 .. note:: The software is intended to run on pre-release hardware and may 
contain unknown or unresolved defects or
   issues related to functionality and performance.
   The poll mode driver is also pre-release and will be updated to a 
released version post hardware and base driver release.
@@ -67,24 +85,4 @@ New Features

 *   Job Stats library and Sample Application.

-*   Poll Mode Driver - PCIE host-interface of Intel Ethernet Switch FM1 
Series (librte_pmd_fm10k)
-
-*   Basic Rx/Tx functions for PF/VF
-
-*   Interrupt handling support for PF/VF
-
-*   Per queue start/stop functions for PF/VF
-
-*   Support Mailbox handling between PF/VF and PF/Switch Manager
-
-*   Receive Side Scaling (RSS) for PF/VF
-
-*   Scatter receive function for PF/VF
-
-*   Reta update/query for PF/VF
-
-*   VLAN filter set for PF
-
-*   Link status query for PF/VF
-
 For further features supported in this release, see Chapter 3 Supported 
Features.
-- 
1.8.3.1

[dpdk-dev] [PATCH] doc: remove release version from known issues

[Siobhan Butler]

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/known_issues.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/known_issues.rst 
b/doc/guides/rel_notes/known_issues.rst
index 6c81fcf..4c43191 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -31,7 +31,7 @@
 Known Issues and Limitations
 

-This section describes known issues with the DPDK software, Release 1.8.0.
+This section describes known issues with the DPDK software.

 Pause Frame Forwarding does not work properly on igb
 
-- 
1.8.3.1

[dpdk-dev] [PATCH] doc: added known issue to release notes

[Siobhan Butler]

-Note: This patch relies on patch 'doc: remove release version from known 
issues'
-Added issue with failing unit test for link bonding to known issues

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/known_issues.rst | 28 
 1 file changed, 28 insertions(+)

diff --git a/doc/guides/rel_notes/known_issues.rst 
b/doc/guides/rel_notes/known_issues.rst
index 4c43191..a94b6aa 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -33,6 +33,34 @@ Known Issues and Limitations

 This section describes known issues with the DPDK software.

+Unit Test for Link Bonding may fail at test_tlb_tx_burst()
+--
+++--+
+| Title  | Unit Test for Link Bonding may fail at 
test_tlb_tx_burst()   |
+|| 
 |
+++==+
+| Reference #| IXA00390304 
 |
+|| 
 |
+++--+
+| Description| Unit tests will fail at test_tlb_tx_burst 
function with error for uneven distribution|
+|| of packets. 
 |
+|| 
 |
+++--+
+| Implication| Unit test link_bonding_autotest will fail   
 |
+|| 
 |
+|| 
 |
+++--+
+| Resolution/ Workaround | There is no workaround available.   
 |
+|| 
 |
+++--+
+| Affected Environment/ Platform | Fedora 20   
 |
+|| 
 |
+++--+
+| Driver/Module  | Link Bonding
 |
+|| 
 |
+++--+
+
+
 Pause Frame Forwarding does not work properly on igb
 

-- 
1.8.3.1

[dpdk-dev] [PATCH] doc: update version number in release notes description

[Butler, Siobhan A]

> -Original Message-
> From: Butler, Siobhan A
> Sent: Thursday, April 2, 2015 9:42 PM
> To: dev at dpdk.org
> Cc: Butler, Siobhan A
> Subject: [PATCH] doc: update version number in release notes description
> 
> Signed-off-by: Siobhan Butler 
> ---
>  doc/guides/rel_notes/rel_description.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/guides/rel_notes/rel_description.rst
> b/doc/guides/rel_notes/rel_description.rst
> index c8ff483..2fb5379 100644
> --- a/doc/guides/rel_notes/rel_description.rst
> +++ b/doc/guides/rel_notes/rel_description.rst
> @@ -32,7 +32,7 @@ Description of Release  ==
> 
>  These release notes cover the new features, -fixed bugs and known issues
> for Data Plane Development Kit (DPDK) release version 1.7.0.
> +fixed bugs and known issues for Data Plane Development Kit (DPDK)
> release version 2.0.
> 
>  For instructions on compiling and running the release, see the *DPDK
> Getting Started Guide*.
> 
> --
> 1.8.3.1
Ignore this patch - superseded by patch to change all the version numbers.
Thanks
S

[dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on link_get

[Stephen Hemminger]

The qos_scheduler has a 32 bit speed value and therefore I doubt it will
work work at 40G

On Wed, Apr 1, 2015 at 6:44 PM, Liang, Cunming 
wrote:

> Hi Thomas,
>
> > What is the relation between link status timeout and qos_sched?
> [LCM] Validation team found qos_sched test failure on i40e. The sample
> depends on link speed to calc the percentage.
> The root cause comes from that i40e link_get hasn't support
> wait_to_complete well.
> I agree with you it should add more description in test report why 'Used
> QoS example to verified'.
>
> > > +---+--+
> > > |  Subport output rate  | Subport output rate  |
> > > | (% line rate) | (Mpps)   |
> > > +---+---+--+---+
> > > |  Expected | Actual| Expected | Actual|
> > > +---+---+--+---+
> >
> > This table is empty.
> [LCM] It's useless, should be omitted I think.
>
> Cunming
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Thursday, April 02, 2015 3:52 AM
> > To: Zhang, XiaonanX; Cao, Waterman
> > Cc: dev at dpdk.org; Zhang, Helin; Liang, Cunming
> > Subject: Re: [dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on
> link_get
> >
> > Hi,
> >
> > 2015-04-01 06:10, Zhang, XiaonanX:
> > >
> > > Tested-by: Xiaonan zhang
> > >
> > > - OS: Fedora21 3.19.1-201.fc21.x86_64
> > > - GCC: gcc version 4.9.1 20140930 (Red Hat 4.9.1-11) (GCC)
> > > - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
> > > - NIC: Ethernet controller [0200]: Intel Corporation Ethernet
> Controller X710 for
> > 10GbE SFP+ [8086:1572] (rev 01)
> > > - Default x86_64-native-linuxapp-gcc configuration
> > > - Total 1 cases, 1 passed, 0 failed
> > >
> > > - Test case: Used Qos example to verified
> > > -
> >
> > What is the relation between link status timeout and qos_sched?
> >
> > > Traffic shaping for subport. Check that the subport rate is enforced.
> > >
> > > Set the subport output rate to x% of line rate (x = 10 .. 100). Set
> the subport TC
> > limits high (100% line rate each), so they do not constitute
> limitations. Input traffic
> > is 100% line rate.
> > >
> > > Different tb period and tb credits, therefore different output rate,
> are tried:
> > 25%, 50%, 75%, 90% and 100% the lineal rate. (The output for subport is
> Tb credits
> > per period / Tb period.)
> > > The traffic is injected change subport value random.
> > >
> > > Other parameters are same before tests and they don't change here.
> > >
> > > Cmdline:   ./examples/qos_sched/build/qos_sched  -c 0xe -n 4 -- --pfc
> > "0,1,2,3,3" --cfg "/root/profile_sched_pipe_1.cfg"
> > >
> > > The result is this table:
> > >
> > >
> > > +---+--+
> > > |  Subport output rate  | Subport output rate  |
> > > | (% line rate) | (Mpps)   |
> > > +---+---+--+---+
> > > |  Expected | Actual| Expected | Actual|
> > > +---+---+--+---+
> >
> > This table is empty.
> >
> > >
> > > Signed-off-by: Xiaonan Zhang 
> >
> > It seems that this test report is not relevant.
> > It will be ignored in the commit message. Sorry
>
>