[dpdk-dev] [dpdk-moving] Draft Project Charter

[O'Driscoll, Tim]

Agreed. I think we should use next week's meeting to walk through the document, 
discuss the comments, and agree on the changes.

As I said before, the two-level structure that's in there at the moment is a 
placeholder, but it does allow for one level of contribution to the shared lab 
and a lower level contribution for marketing purposes.


Tim

From: Matt Spencer [mailto:matt.spen...@arm.com]
Sent: Tuesday, November 8, 2016 6:18 PM
To: O'Driscoll, Tim ; Vincent JARDIN 
; moving at dpdk.org
Cc: dev at dpdk.org
Subject: Re: [dpdk-moving] [dpdk-dev] Draft Project Charter


I think we need a discussion about the levels of membership - possibly at next 
weeks meeting?



My feeling is that we need more than one level

  - One to enable contribution of hardware to the lab, as the lab will add cost 
to the overall project budget

  - A second to enable contribution to the marketing aspects of the project and 
to allow association for marketing purposes



Calling these Gold and Silver is fine with me, but as I say, lets discuss this 
at next weeks meeting.



Matt


From: moving mailto:moving-bounces at dpdk.org>> on 
behalf of O'Driscoll, Tim mailto:tim.odrisc...@intel.com>>
Sent: 08 November 2016 03:57:36
To: Vincent JARDIN; moving at dpdk.org
Cc: dev at dpdk.org
Subject: Re: [dpdk-moving] [dpdk-dev] Draft Project Charter


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Tuesday, November 8, 2016 11:41 AM
> To: moving at dpdk.org
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-moving] Draft Project Charter
>
> Tim,
>
> Thanks for your draft, but it is not a good proposal. It is not written
> in the spirit that we have discussed in Dublin:
>- you create the status of "Gold" members that we do not want from
> Linux Foundation,

As I said in the email, I put in two levels of membership as a placeholder. The 
first thing we need to decide is if we want to have a budget and membership, or 
if we want the OVS model with 0 budget and no membership. We can discuss that 
at today's meeting.

If we do want a membership model then we'll need to decide if everybody 
contributes at the same rate or if we support multiple levels. So, for now, the 
text on having two levels is just an example to show what a membership model 
might look like.

>- you start with "DPDK's first $1,000,000", it is far from the $O
> that we agreed based on OVS model.

That's just standard text that I see in all the LF charters. It's even in the 
OVS charter (http://openvswitch.org/charter/charter.pdf) even though they have 
0 budget. I assumed it's standard text for the LF. I'm sure Mike Dolan can 
clarify.

>
> Please, explain why you did change it?
>
> Thank you,
>Vincent
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

[dpdk-dev] [dpdk-moving] Draft Project Charter

[Matt Spencer]

I think we need a discussion about the levels of membership - possibly at next 
weeks meeting?


My feeling is that we need more than one level

  - One to enable contribution of hardware to the lab, as the lab will add cost 
to the overall project budget

  - A second to enable contribution to the marketing aspects of the project and 
to allow association for marketing purposes


Calling these Gold and Silver is fine with me, but as I say, lets discuss this 
at next weeks meeting.


Matt


From: moving  on behalf of O'Driscoll, Tim 

Sent: 08 November 2016 03:57:36
To: Vincent JARDIN; moving at dpdk.org
Cc: dev at dpdk.org
Subject: Re: [dpdk-moving] [dpdk-dev] Draft Project Charter


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Tuesday, November 8, 2016 11:41 AM
> To: moving at dpdk.org
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-moving] Draft Project Charter
>
> Tim,
>
> Thanks for your draft, but it is not a good proposal. It is not written
> in the spirit that we have discussed in Dublin:
>- you create the status of "Gold" members that we do not want from
> Linux Foundation,

As I said in the email, I put in two levels of membership as a placeholder. The 
first thing we need to decide is if we want to have a budget and membership, or 
if we want the OVS model with 0 budget and no membership. We can discuss that 
at today's meeting.

If we do want a membership model then we'll need to decide if everybody 
contributes at the same rate or if we support multiple levels. So, for now, the 
text on having two levels is just an example to show what a membership model 
might look like.

>- you start with "DPDK's first $1,000,000", it is far from the $O
> that we agreed based on OVS model.

That's just standard text that I see in all the LF charters. It's even in the 
OVS charter (http://openvswitch.org/charter/charter.pdf) even though they have 
0 budget. I assumed it's standard text for the LF. I'm sure Mike Dolan can 
clarify.

>
> Please, explain why you did change it?
>
> Thank you,
>Vincent
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

[dpdk-dev] [PATCH v3 02/12] net/virtio: setup and start cq in configure callback

[Olivier Matz]

Hi Lei,

On 11/02/2016 02:38 AM, Yao, Lei A wrote:
> Hi, Olivier
> 
> During the validation work with v16.11-rc2, I find that this patch will cause 
> VM crash if enable virtio bonding in VM. Could you have a check at your side? 
> The following is steps at my side. Thanks a lot
> 
> 1. bind PF port to igb_uio.
> modprobe uio
> insmod ./x86_64-native-linuxapp-gcc/kmod/igb_uio.ko
> ./tools/dpdk-devbind.py --bind=igb_uio 84:00.1
> 
> 2. start vhost switch.
> ./examples/vhost/build/vhost-switch -c 0x1c -n 4 --socket-mem 4096,4096 - 
> -p 0x1 --mergeable 0 --vm2vm 0 --socket-file ./vhost-net
> 
> 3. bootup one vm with four virtio net device
> qemu-system-x86_64 \
> -name vm0 -enable-kvm -chardev 
> socket,path=/tmp/vm0_qga0.sock,server,nowait,id=vm0_qga0 \
> -device virtio-serial -device 
> virtserialport,chardev=vm0_qga0,name=org.qemu.guest_agent.0 \
> -daemonize -monitor unix:/tmp/vm0_monitor.sock,server,nowait \
> -net nic,vlan=0,macaddr=00:00:00:c7:56:64,addr=1f \
> net user,vlan=0,hostfwd=tcp:10.239.129.127:6107:22 \
> -chardev socket,id=char0,path=./vhost-net \
> -netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce \
> -device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01 \
> -chardev socket,id=char1,path=./vhost-net \
> -netdev type=vhost-user,id=netdev1,chardev=char1,vhostforce \
> -device virtio-net-pci,netdev=netdev1,mac=52:54:00:00:00:02 \
> -chardev socket,id=char2,path=./vhost-net \
> -netdev type=vhost-user,id=netdev2,chardev=char2,vhostforce \
> -device virtio-net-pci,netdev=netdev2,mac=52:54:00:00:00:03 \
> -chardev socket,id=char3,path=./vhost-net \
> -netdev type=vhost-user,id=netdev3,chardev=char3,vhostforce \
> -device virtio-net-pci,netdev=netdev3,mac=52:54:00:00:00:04 \
> -cpu host -smp 8 -m 4096 \
> -object memory-backend-file,id=mem,size=4096M,mem-path=/mnt/huge,share=on \
> -numa node,memdev=mem -mem-prealloc -drive file=/home/osimg/ubuntu16.img -vnc 
> :10
> 
> 4. on vm:
> bind virtio net device to igb_uio
> modprobe uio
> insmod ./x86_64-native-linuxapp-gcc/kmod/igb_uio.ko
> tools/dpdk-devbind.py --bind=igb_uio 00:04.0 00:05.0 00:06.0 00:07.0
> 5. startup test_pmd app
> ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1f -n 4 - -i --txqflags=0xf00 
> --disable-hw-vlan-filter
> 6. create one bonding device (port 4)
> create bonded device 0 0 (the first 0: mode, the second: the socket number)
> show bonding config 4
> 7. bind port 0, 1, 2 to port 4
> add bonding slave 0 4
> add bonding slave 1 4
> add bonding slave 2 4
> port start 4
> Result: just after port start 4(port 4 is bonded port), the vm shutdown 
> immediately.

Sorry for the late answer. I reproduced the issue on rc2, and I confirm
that Yuanhan's patchset fixes it in rc3.

Regards,
Olivier

[dpdk-dev] [PATCH v2 1/1] mempool: Add sanity check when secondary link in less mempools than primary

[Olivier Matz]

Hello Jean,

On 10/28/2016 08:37 PM, Jean Tourrilhes wrote:
> If the mempool ops the caller wants to use is not registered, the
> library will segfault in an obscure way when trying to use that
> mempool. It's better to catch it early and warn the user.
> 
> If the primary and secondary process were build using different build
> systems, the list of constructors included by the linker in each
> binary might be different. Mempools are registered via constructors, so
> the linker magic will directly impact which tailqs are registered with
> the primary and the secondary.
> DPDK currently assumes that the secondary has a superset of the
> mempools registered at the primary, and they are in the same order
> (same index in primary and secondary). In some build scenario, the
> secondary might not initialise any mempools at all.
> 
> This would also catch cases where there is a bug in the mempool
> registration, or some memory corruptions, but this has not been
> observed.

I still don't get how you can have different constructors in your
primary and secondary. As I said in my previous answer, my
understanding of how secondary process works in dpdk is that the
binaries have to be synchronized.

Your are just talking about linker magic but you don't explain how
to reproduce your issue easily. Please, can you provide a simple
example (let's say one .c and one Makefile) plus a simple screenshot
that highlights the issue?

We'll then check if this issue should be fixed in mempool or if
we should provide helpers in the build system to avoid this situation.

> 
> Signed-off-by: Jean Tourrilhes 
> ---
>  lib/librte_mempool/rte_mempool.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/lib/librte_mempool/rte_mempool.c 
> b/lib/librte_mempool/rte_mempool.c
> index 2e28e2e..82260cc 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -1275,6 +1275,25 @@ rte_mempool_lookup(const char *name)
>   return NULL;
>   }
>  
> + /* Sanity check : secondary may have initialised less mempools
> +  * than primary due to linker and constructor magic. Or maybe
> +  * there is a mempool corruption or bug. In any case, we can't
> +  * go on, we will segfault in an obscure way.
> +  * This does not detect the case where the constructor order
> +  * is different between primary and secondary and where the
> +  * index points to the wrong ops. This would require more
> +  * extensive changes, and is much less likely.
> +  * Jean II */
> + if(mp->ops_index >= (int32_t) rte_mempool_ops_table.num_ops) {
> + unsigned i;
> + /* Dump list of mempool ops for further investigation. */
> + for (i = 0; i < rte_mempool_ops_table.num_ops; i++) {
> + RTE_LOG(ERR, EAL, "Registered mempool[%d] is %s\n", i, 
> rte_mempool_ops_table.ops[i].name);
> + }
> + /* Do not dump mempool list itself, it will segfault. */
> + rte_panic("Cannot find ops for mempool, ops_index %d, num_ops 
> %d - maybe due to build process or linker configuration\n", mp->ops_index, 
> rte_mempool_ops_table.num_ops);
> + }
> +

Also, please use checkpatch to ensure it matches the style.
See
http://dpdk.org/doc/guides/contributing/patches.html#checking-the-patches

I don't feel signing your comments is absolutely required. In addition
it does not give a lot of information about who wrote it, given the
large number of Jean II: https://fr.wikipedia.org/wiki/Jean_II

Regards,
Olivier

[dpdk-dev] Running 2 process on the same machine

[Keren Hochman]

Also, I can't understand how to define socket-mem. I did not see anything
related to hugepages in /etc/sysctl.conf. Can i mount hugepages to 2
different dirs instead and use --huge-dir ?
Thank you.





















On Tue, Nov 8, 2016 at 11:44 AM, Keren Hochman  wrote:

> Thank you for your response, I still can not run the 2 process together.
> if I add --no-pci to one process it can replace white and black lists
> right?
>
> Thanks, keren
>
> On Tue, Nov 8, 2016 at 12:36 AM, Wiles, Keith 
> wrote:
>
>>
>> > On Nov 7, 2016, at 7:28 AM, Keren Hochman 
>> wrote:
>> >
>> > Hi,
>> > I need to run 2 process that uses dpdk on the same machine. One uses
>> dpdk
>> > drivers, and the other just read from a pcap file.  If I disable
>> hugepages
>> > in the second process rte_mempool_create fails. What is the correct way
>> to
>> > handle this?
>>
>> If you look at the two scripts in Pktgen pktgen-master.sh and
>> pktgen-slave.sh these two scripts setup two instances of pktgen on the same
>> machine. Plus you can read the README.md file.
>>
>> http://dpdk.org/browse/apps/pktgen-dpdk/refs/
>>
>> You have to make sure you have enough memory (huge pages) allocated for
>> both instances to run.
>>
>> Then use ?file-prefix XX to give each instance a different prefix for the
>> huge page files in /dev/hugepages if that is the location of the files on
>> your system. I would remove any files in that directory to free up the
>> memory.
>>
>> Use the ?socket-mem to allocate the correct amount of memory for each
>> instances this way DPDK does not consume all the pages for a given instance.
>>
>> Make sure you blacklist the ports you do not want on the first instance
>> using -b option and then blacklist the ports from the first instance while
>> allowing the other ports to be used on the second one.
>>
>> That should do it for most cases.
>>
>> >
>> > Thanks, Keren
>>
>> Regards,
>> Keith
>>
>>
>

[dpdk-dev] [PATCH v3] doc: arm64: document DPDK application profiling methods

[Jianbo Liu]

On 8 November 2016 at 11:32, Jerin Jacob  
wrote:
> Signed-off-by: Jerin Jacob 
> Signed-off-by: John McNamara 
> ---
> v3:
> Fixed formatting issues:
> - Remove the introduction heading and put intro text under the main 
> heading(Thomas)
> - Fixed RST formatting issues such as enclosing technical terms in 
> backquotes(John)
> Thanks, John for providing the updated version
> v2:
> -Addressed ARM64 specific review comments(Suggested by Thomas)
> http://dpdk.org/dev/patchwork/patch/16362/
> ---
>  doc/guides/prog_guide/profile_app.rst | 64 
> ++-
>  1 file changed, 63 insertions(+), 1 deletion(-)
>

Acked-by: Jianbo Liu 

[dpdk-dev] [PATCH] ethdev: fix statistics description

[Tahhan, Maryam]

> 
> Hi, John & Greg
> 
> Would you please give any opinion for this patch ?
> 
> I have looked through all PMDs and found not all statistics items can be
> supported by some NIC.
> For example,  rx_nombuf,  q_ipackets,  q_opackets,  q_ibytes and q_obytes
> are not supported by i40e.

Queue stats should be supported by i40e as we have access to struct 
i40e_queue_stats  this is a gap. Same for e1000.
For me (from a stats perspective), we should be able to report everything that 
ethtool can report for the different kernel network drivers (as we have the 
same base driver code in DPDK). In other words, the DPDK stats API should 
provide the same set of stats as a standard networking interface would to an 
external monitoring tool in case we want to perform some sort of analytics on 
it afterwards.
At a very minimum the top level stats should include: ipackets, opackets, 
ibytes,  obytes,  imissed,  ierrors,  oerrors. The queue stats in theory could 
be migrated to the xstats, it would require a lot of clean up in existing 
drivers which is why we didn't remove them when we did the original cleanup of 
the struct for the xstats API.


> But when the function rte_eth_stats_get(uint8_t port_id, struct
> rte_eth_stats *stats) is called for i40e PMD, Above un-supported statistics
> item in output stats are zero, this is not real value.

Agreed - should not output 0 for these. But should ensure where stats are 
possible to obtain, we support them in DPDK.

> So far, there is no way to know whether an item in struct rte_eth_stats is
> supported or not only from this structure definition.
> Maybe some structure member can be added to indicate each of statistics
> item valid or not.
> But this means ABI change.

Migrating the queue/nonstandard stats to the xstats API would fix this, the 
only issue is with the existing drivers that are unsupported fields with 0.

> 
> In following list, I list statistics support details of all PMDs.
> Hope it can be displayed in your screen.
> 
Thanks for this, it's very helpful. I'm currently collating a list of the 
missing stats for e1000, ixgbe and i40e from DPDK. So this is very helpful.

> Thanks
> /Wei
> 
> NIC   ipackets   opackets  ibytes  obytes  imissed  ierrors  oerrors
> rx_nombuf  q_ipackets   q_opacktes q_ibytesq_obytes  q_errors
> af_packet  y  y y   y   nny   
>  n  yyy y
> y
> bnx2x y  y y   y   yyy
> y  nnn n
> n
> bnxt  y  y y   y   yyy
> n  yyy y
> y
> bonding   y  y y   y   yyy
> y  yyy y
> y
> cxgbe y  y y   y   yyy
> n  yyy y
> y
> e1000(igb) y  y y   y   yyy   
>  n  nnn n
> n
> e1000(igbvf)   y  y y   y   nnn   
>  n  nnn
> n n
> ena   y  y y   y   yyy
> y  nnn n
> n
> enic  y  y y   y   yyy
> y  nnn n
> n
> fm10k y  y y   y   nnn
> n  yyy y
> n
> i40e  y  y y   y   yyy
> n  nnn n
> n
> i40evfy  y y   y   nyy
> n  nnn n
> n
> ixgbe y  y y   y   yyy
> n  yyy y
> y
> ixgbevf   y  y y   y   nnn
> n  nnn n
> n
> mlx4  y  y y   y   nyy
> y  yyy y
> y
> mlx5  y  y y   y   nyy
> y  yyy y
> y
> mpipe y  y y   y   nyy
> y  yyy y
> y
> nfp   y  y y   y   yyy
> y  yyy y
> n
> null  y  y n   n   nny
> n  yyn n
> y
> pcap  y  y y   y   nny
> n   

[dpdk-dev] [dpdk-moving] Draft Project Charter

[Vincent JARDIN]

Tim,

Thanks for your draft, but it is not a good proposal. It is not written 
in the spirit that we have discussed in Dublin:
   - you create the status of "Gold" members that we do not want from 
Linux Foundation,
   - you start with "DPDK?s first $1,000,000", it is far from the $O 
that we agreed based on OVS model.

Please, explain why you did change it?

Thank you,
   Vincent

[dpdk-dev] [PATCH v4] latencystats: added new library for latency stats

[Pattan, Reshma]

CCing  maintainers of Mbuf , testpmd and dpdk-procinfo.

> -Original Message-
> From: Pattan, Reshma
> Sent: Monday, November 7, 2016 1:15 PM
> To: dev at dpdk.org
> Cc: Pattan, Reshma 
> Subject: [PATCH v4] latencystats: added new library for latency stats
> 
> Library is designed to calculate latency stats and report them to the
> application when queried. Library measures minimum, average, maximum
> latencies and jitter in nano seconds.
> Current implementation supports global latency stats, i.e. per application
> stats.
> 
> Added new field to mbuf struct to mark the packet arrival time on Rx and
> use the timestamp to measure the latency on Tx.
> 
> Modified testpmd code to initialize/uninitialize latency stats calulation.
> Modified dpdk-procinfo process to display the newly added metrics info.
> 
> This pacth is dependent on http://dpdk.org/dev/patchwork/patch/16927/ .
> 
> APIs:
> 
> Added APIs to initialize and un initialize latency stats calculation.
> Added API to retrieve latency stats names and values.
> 
> Functionality:
> 
> *Library will register ethdev Rx/Tx callbacks for each active port, queue
> combinations.
> *Library will register latency stats names with new metrics library.
> http://dpdk.org/dev/patchwork/patch/16927/
> *Rx packets will be marked with time stamp on each sampling interval.
> *On Tx side, packets with time stamp will be considered for calculating the
> minimum, maximum, average latencies and jitter.
> *Average latency is calculated using exponential weighted moving average
> method.
> *Minimum and maximum latencies will be low and high latency values
> observed so far.
> *Jitter calculation is done based on inter packet delay variation.
> *Measured stats are reported to the metrics library in a separate pthread.
> *Measured stats can be retrieved via get API of the libray (or) by calling
> generic get API of the new metrics library.
> 
> documents yet to be updated.
> 
> Signed-off-by: Reshma Pattan 
> ---
>  MAINTAINERS|   4 +
>  app/proc_info/main.c   |  70 
>  app/test-pmd/testpmd.c |  10 +
>  config/common_base |   5 +
>  lib/Makefile   |   1 +
>  lib/librte_latencystats/Makefile   |  57 
>  lib/librte_latencystats/rte_latencystats.c | 380
> +
>  lib/librte_latencystats/rte_latencystats.h | 141 
>  .../rte_latencystats_version.map   |  10 +
>  lib/librte_mbuf/rte_mbuf.h |   3 +
>  mk/rte.app.mk  |   2 +
>  11 files changed, 683 insertions(+)
>  create mode 100644 lib/librte_latencystats/Makefile  create mode 100644
> lib/librte_latencystats/rte_latencystats.c
>  create mode 100644 lib/librte_latencystats/rte_latencystats.h
>  create mode 100644 lib/librte_latencystats/rte_latencystats_version.map
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba12d1b..2567448 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -702,3 +702,7 @@ F: examples/tep_termination/
>  F: examples/vmdq/
>  F: examples/vmdq_dcb/
>  F: doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst
> +
> +Latency Stats
> +M: Reshma Pattan 
> +F: lib/librte_latencystats/
> diff --git a/app/proc_info/main.c b/app/proc_info/main.c index
> 2c56d10..37d5ae4 100644
> --- a/app/proc_info/main.c
> +++ b/app/proc_info/main.c
> @@ -57,6 +57,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  /* Maximum long option length for option parsing. */  #define
> MAX_LONG_OPT_SZ 64 @@ -68,6 +69,8 @@ static uint32_t
> enabled_port_mask;  static uint32_t enable_stats;  /**< Enable xstats. */
> static uint32_t enable_xstats;
> +/**< Enable metrics. */
> +static uint32_t enable_metrics;
>  /**< Enable stats reset. */
>  static uint32_t reset_stats;
>  /**< Enable xstats reset. */
> @@ -85,6 +88,8 @@ proc_info_usage(const char *prgname)
>   "  --stats: to display port statistics, enabled by default\n"
>   "  --xstats: to display extended port statistics, disabled by "
>   "default\n"
> + "  --metrics: to display derived metrics of the ports, disabled
> by "
> + "default\n"
>   "  --stats-reset: to reset port statistics\n"
>   "  --xstats-reset: to reset port extended statistics\n",
>   prgname);
> @@ -127,6 +132,7 @@ proc_info_parse_args(int argc, char **argv)
>   {"stats", 0, NULL, 0},
>   {"stats-reset", 0, NULL, 0},
>   {"xstats", 0, NULL, 0},
> + {"metrics", 0, NULL, 0},
>   {"xstats-reset", 0, NULL, 0},
>   {NULL, 0, 0, 0}
>   };
> @@ -159,6 +165,10 @@ proc_info_parse_args(int argc, char **argv)
>   else if (!strncmp(long_option[option_index].name,
> "xstats",
>

[dpdk-dev] [PATCH 2/2] net/thunderx: add cn83xx support

[Jerin Jacob]

83xx NIC subsystem differs in new PCI subsystem_device_id and
NICVF_CAP_DISABLE_APAD capability.

Signed-off-by: Jerin Jacob 
---
 doc/guides/nics/thunderx.rst | 1 +
 drivers/net/thunderx/base/nicvf_hw.c | 4 
 drivers/net/thunderx/base/nicvf_hw.h | 1 +
 drivers/net/thunderx/nicvf_ethdev.c  | 7 +++
 4 files changed, 13 insertions(+)

diff --git a/doc/guides/nics/thunderx.rst b/doc/guides/nics/thunderx.rst
index 9763bb6..187c9a4 100644
--- a/doc/guides/nics/thunderx.rst
+++ b/doc/guides/nics/thunderx.rst
@@ -62,6 +62,7 @@ Supported ThunderX SoCs
 ---
 - CN88xx
 - CN81xx
+- CN83xx

 Prerequisites
 -
diff --git a/drivers/net/thunderx/base/nicvf_hw.c 
b/drivers/net/thunderx/base/nicvf_hw.c
index a69cd02..04b3b69 100644
--- a/drivers/net/thunderx/base/nicvf_hw.c
+++ b/drivers/net/thunderx/base/nicvf_hw.c
@@ -146,6 +146,10 @@ nicvf_base_init(struct nicvf *nic)
if (nicvf_hw_version(nic) == PCI_SUB_DEVICE_ID_CN81XX_NICVF)
nic->hwcap |= NICVF_CAP_TUNNEL_PARSING | NICVF_CAP_CQE_RX2;

+   if (nicvf_hw_version(nic) == PCI_SUB_DEVICE_ID_CN83XX_NICVF)
+   nic->hwcap |= NICVF_CAP_TUNNEL_PARSING | NICVF_CAP_CQE_RX2 |
+   NICVF_CAP_DISABLE_APAD;
+
return NICVF_OK;
 }

diff --git a/drivers/net/thunderx/base/nicvf_hw.h 
b/drivers/net/thunderx/base/nicvf_hw.h
index cf68be9..14fb2fe 100644
--- a/drivers/net/thunderx/base/nicvf_hw.h
+++ b/drivers/net/thunderx/base/nicvf_hw.h
@@ -43,6 +43,7 @@
 #definePCI_SUB_DEVICE_ID_CN88XX_PASS1_NICVF0xA11E
 #definePCI_SUB_DEVICE_ID_CN88XX_PASS2_NICVF0xA134
 #definePCI_SUB_DEVICE_ID_CN81XX_NICVF  0xA234
+#definePCI_SUB_DEVICE_ID_CN83XX_NICVF  0xA334

 #define NICVF_ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))

diff --git a/drivers/net/thunderx/nicvf_ethdev.c 
b/drivers/net/thunderx/nicvf_ethdev.c
index 501c8c2..466e49c 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -2097,6 +2097,13 @@ static const struct rte_pci_id pci_id_nicvf_map[] = {
.subsystem_device_id = PCI_SUB_DEVICE_ID_CN81XX_NICVF,
},
{
+   .class_id = RTE_CLASS_ANY_ID,
+   .vendor_id = PCI_VENDOR_ID_CAVIUM,
+   .device_id = PCI_DEVICE_ID_THUNDERX_NICVF,
+   .subsystem_vendor_id = PCI_VENDOR_ID_CAVIUM,
+   .subsystem_device_id = PCI_SUB_DEVICE_ID_CN83XX_NICVF,
+   },
+   {
.vendor_id = 0,
},
 };
-- 
2.5.5

[dpdk-dev] [PATCH 1/2] net/thunderx: disable l3 alignment pad feature

[Jerin Jacob]

Based on the packet type(IPv4 or IPv6), the nicvf HW aligns
L3 data to the 64bit memory address.
The alignment creates a hole in mbuf(between the
end of headroom and packet data start).
The new revision of the HW provides an option to disable
the L3 alignment feature and make mbuf layout looks
more like other NICs. For better application compatibility,
disabling l3 alignment feature on the hardware revisions it supports.

Signed-off-by: Jerin Jacob 
---
 drivers/net/thunderx/base/nicvf_hw.c  | 18 ++
 drivers/net/thunderx/base/nicvf_hw.h  |  4 
 drivers/net/thunderx/base/nicvf_hw_defs.h |  2 ++
 drivers/net/thunderx/nicvf_ethdev.c   | 10 ++
 4 files changed, 34 insertions(+)

diff --git a/drivers/net/thunderx/base/nicvf_hw.c 
b/drivers/net/thunderx/base/nicvf_hw.c
index 1f08ef2..a69cd02 100644
--- a/drivers/net/thunderx/base/nicvf_hw.c
+++ b/drivers/net/thunderx/base/nicvf_hw.c
@@ -725,6 +725,24 @@ nicvf_vlan_hw_strip(struct nicvf *nic, bool enable)
 }

 void
+nicvf_apad_config(struct nicvf *nic, bool enable)
+{
+   uint64_t val;
+
+   /* APAD always enabled in this device */
+   if (!(nic->hwcap & NICVF_CAP_DISABLE_APAD))
+   return;
+
+   val = nicvf_reg_read(nic, NIC_VNIC_RQ_GEN_CFG);
+   if (enable)
+   val &= ~(1ULL << NICVF_QS_RQ_DIS_APAD_SHIFT);
+   else
+   val |= (1ULL << NICVF_QS_RQ_DIS_APAD_SHIFT);
+
+   nicvf_reg_write(nic, NIC_VNIC_RQ_GEN_CFG, val);
+}
+
+void
 nicvf_rss_set_key(struct nicvf *nic, uint8_t *key)
 {
int idx;
diff --git a/drivers/net/thunderx/base/nicvf_hw.h 
b/drivers/net/thunderx/base/nicvf_hw.h
index 2b8738b..cf68be9 100644
--- a/drivers/net/thunderx/base/nicvf_hw.h
+++ b/drivers/net/thunderx/base/nicvf_hw.h
@@ -54,6 +54,8 @@
 #define NICVF_CAP_TUNNEL_PARSING   (1ULL << 0)
 /* Additional word in Rx descriptor to hold optional tunneling extension info 
*/
 #define NICVF_CAP_CQE_RX2  (1ULL << 1)
+/* The device capable of setting NIC_CQE_RX_S[APAD] == 0 */
+#define NICVF_CAP_DISABLE_APAD (1ULL << 2)

 enum nicvf_tns_mode {
NIC_TNS_BYPASS_MODE,
@@ -217,6 +219,8 @@ uint32_t nicvf_qsize_sq_roundup(uint32_t val);

 void nicvf_vlan_hw_strip(struct nicvf *nic, bool enable);

+void nicvf_apad_config(struct nicvf *nic, bool enable);
+
 int nicvf_rss_config(struct nicvf *nic, uint32_t  qcnt, uint64_t cfg);
 int nicvf_rss_term(struct nicvf *nic);

diff --git a/drivers/net/thunderx/base/nicvf_hw_defs.h 
b/drivers/net/thunderx/base/nicvf_hw_defs.h
index e144d44..00dd2fe 100644
--- a/drivers/net/thunderx/base/nicvf_hw_defs.h
+++ b/drivers/net/thunderx/base/nicvf_hw_defs.h
@@ -105,6 +105,8 @@
 #define NICVF_INTR_MBOX_SHIFT   22
 #define NICVF_INTR_QS_ERR_SHIFT 23

+#define NICVF_QS_RQ_DIS_APAD_SHIFT  22
+
 #define NICVF_INTR_CQ_MASK  (0xFF << NICVF_INTR_CQ_SHIFT)
 #define NICVF_INTR_SQ_MASK  (0xFF << NICVF_INTR_SQ_SHIFT)
 #define NICVF_INTR_RBDR_MASK(0x03 << NICVF_INTR_RBDR_SHIFT)
diff --git a/drivers/net/thunderx/nicvf_ethdev.c 
b/drivers/net/thunderx/nicvf_ethdev.c
index 094c5d5..501c8c2 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -1527,6 +1527,16 @@ nicvf_vf_start(struct rte_eth_dev *dev, struct nicvf 
*nic, uint32_t rbdrsz)
/* Configure VLAN Strip */
nicvf_vlan_hw_strip(nic, dev->data->dev_conf.rxmode.hw_vlan_strip);

+   /* Based on the packet type(IPv4 or IPv6), the nicvf HW aligns L3 data
+* to the 64bit memory address.
+* The alignment creates a hole in mbuf(between the end of headroom and
+* packet data start). The new revision of the HW provides an option to
+* disable the L3 alignment feature and make mbuf layout looks
+* more like other NICs. For better application compatibility, disabling
+* l3 alignment feature on the hardware revisions it supports
+*/
+   nicvf_apad_config(nic, false);
+
/* Get queue ranges for this VF */
nicvf_tx_range(dev, nic, &tx_start, &tx_end);

-- 
2.5.5

[dpdk-dev] [PATCH 0/2] net/thunderx: add 83xx SoC support

[Jerin Jacob]

CN83xx is 24 core version of ThunderX ARMv8 SoC with integrated
octeon style packet and crypto accelerators.

The standard NIC block used in 88xx/81xx also included in 83xx.
This patchset adds support for existing standard NIC block on 83xx by
adding new HW capability flag to select the difference in runtime.

Jerin Jacob (2):
  net/thunderx: disable l3 alignment pad feature
  net/thunderx: add cn83xx support

 doc/guides/nics/thunderx.rst  |  1 +
 drivers/net/thunderx/base/nicvf_hw.c  | 22 ++
 drivers/net/thunderx/base/nicvf_hw.h  |  5 +
 drivers/net/thunderx/base/nicvf_hw_defs.h |  2 ++
 drivers/net/thunderx/nicvf_ethdev.c   | 17 +
 5 files changed, 47 insertions(+)

-- 
2.5.5

[dpdk-dev] [dpdk-moving] Draft Project Charter

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Tuesday, November 8, 2016 11:41 AM
> To: moving at dpdk.org
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-moving] Draft Project Charter
> 
> Tim,
> 
> Thanks for your draft, but it is not a good proposal. It is not written
> in the spirit that we have discussed in Dublin:
>- you create the status of "Gold" members that we do not want from
> Linux Foundation,

As I said in the email, I put in two levels of membership as a placeholder. The 
first thing we need to decide is if we want to have a budget and membership, or 
if we want the OVS model with 0 budget and no membership. We can discuss that 
at today's meeting.

If we do want a membership model then we'll need to decide if everybody 
contributes at the same rate or if we support multiple levels. So, for now, the 
text on having two levels is just an example to show what a membership model 
might look like.

>- you start with "DPDK's first $1,000,000", it is far from the $O
> that we agreed based on OVS model.

That's just standard text that I see in all the LF charters. It's even in the 
OVS charter (http://openvswitch.org/charter/charter.pdf) even though they have 
0 budget. I assumed it's standard text for the LF. I'm sure Mike Dolan can 
clarify.

> 
> Please, explain why you did change it?
> 
> Thank you,
>Vincent

[dpdk-dev] Running 2 process on the same machine

[Keren Hochman]

Thank you for your response, I still can not run the 2 process together.
if I add --no-pci to one process it can replace white and black lists
right?

Thanks, keren

On Tue, Nov 8, 2016 at 12:36 AM, Wiles, Keith  wrote:

>
> > On Nov 7, 2016, at 7:28 AM, Keren Hochman 
> wrote:
> >
> > Hi,
> > I need to run 2 process that uses dpdk on the same machine. One uses dpdk
> > drivers, and the other just read from a pcap file.  If I disable
> hugepages
> > in the second process rte_mempool_create fails. What is the correct way
> to
> > handle this?
>
> If you look at the two scripts in Pktgen pktgen-master.sh and
> pktgen-slave.sh these two scripts setup two instances of pktgen on the same
> machine. Plus you can read the README.md file.
>
> http://dpdk.org/browse/apps/pktgen-dpdk/refs/
>
> You have to make sure you have enough memory (huge pages) allocated for
> both instances to run.
>
> Then use ?file-prefix XX to give each instance a different prefix for the
> huge page files in /dev/hugepages if that is the location of the files on
> your system. I would remove any files in that directory to free up the
> memory.
>
> Use the ?socket-mem to allocate the correct amount of memory for each
> instances this way DPDK does not consume all the pages for a given instance.
>
> Make sure you blacklist the ports you do not want on the first instance
> using -b option and then blacklist the ports from the first instance while
> allowing the other ports to be used on the second one.
>
> That should do it for most cases.
>
> >
> > Thanks, Keren
>
> Regards,
> Keith
>
>

[dpdk-dev] [PATCH v3 1/3] lib: add information metrics library

[Remy Horton]

On 07/11/2016 23:25, Pattan, Reshma wrote:
[..]
>>> + * Initialises statistic module. This only has to be explicitly
>>> +called
>>
>> Typo < Initialises>
>
> To avoid confusion, here I mean to say "Initializes" should be used (i.e. US 
> English) .

Sorta guessed that.. :)


> Also another non-related comment, you may need to add a comment about EMWA
> near the mean bit rate calculation code.

Quite a few comments needed updating. Going to hold off the v5 until 
16.11 is out as I'll also need to change all the references to 17.02..

..Remy

[dpdk-dev] [PATCH] doc: move testpmd guide with other tools

[Thomas Monjalon]

The guide testpmd_app_ug/ is moved inside the new tools/ guide
as a section.

Signed-off-by: Thomas Monjalon 
---
 MAINTAINERS| 2 +-
 doc/guides/conf.py | 2 +-
 doc/guides/contributing/documentation.rst  | 1 -
 doc/guides/index.rst   | 1 -
 doc/guides/tools/index.rst | 2 +-
 doc/guides/{testpmd_app_ug => tools/testpmd}/build_app.rst | 0
 doc/guides/{testpmd_app_ug => tools/testpmd}/index.rst | 4 ++--
 doc/guides/{testpmd_app_ug => tools/testpmd}/intro.rst | 0
 doc/guides/{testpmd_app_ug => tools/testpmd}/run_app.rst   | 0
 doc/guides/{testpmd_app_ug => tools/testpmd}/testpmd_funcs.rst | 0
 10 files changed, 5 insertions(+), 7 deletions(-)
 rename doc/guides/{testpmd_app_ug => tools/testpmd}/build_app.rst (100%)
 rename doc/guides/{testpmd_app_ug => tools/testpmd}/index.rst (96%)
 rename doc/guides/{testpmd_app_ug => tools/testpmd}/intro.rst (100%)
 rename doc/guides/{testpmd_app_ug => tools/testpmd}/run_app.rst (100%)
 rename doc/guides/{testpmd_app_ug => tools/testpmd}/testpmd_funcs.rst (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index ba12d1b..19cd05b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -614,7 +614,7 @@ F: app/test/virtual_pmd.h
 Driver testing tool
 M: Pablo de Lara 
 F: app/test-pmd/
-F: doc/guides/testpmd_app_ug/
+F: doc/guides/tools/testpmd/

 Dump tool
 M: Maryam Tahhan 
diff --git a/doc/guides/conf.py b/doc/guides/conf.py
index 149bcdb..8619d04 100644
--- a/doc/guides/conf.py
+++ b/doc/guides/conf.py
@@ -106,7 +106,7 @@ class CustomLatexFormatter(LatexFormatter):
 PygmentsBridge.latex_formatter = CustomLatexFormatter

 # Configuration for man pages
-man_pages = [("testpmd_app_ug/run_app", "testpmd",
+man_pages = [("tools/testpmd/run_app", "testpmd",
   "tests for dpdk pmds", "", 1),
  ("tools/pdump", "dpdk-pdump",
   "enable packet capture on dpdk ports", "", 1),
diff --git a/doc/guides/contributing/documentation.rst 
b/doc/guides/contributing/documentation.rst
index 2cfb1a2..03dc59f 100644
--- a/doc/guides/contributing/documentation.rst
+++ b/doc/guides/contributing/documentation.rst
@@ -31,7 +31,6 @@ The main directories that contain files related to 
documentation are shown below
|-- prog_guide
|-- sample_app_ug
|-- guidelines
-   |-- testpmd_app_ug
|-- rel_notes
|-- nics
|-- xen
diff --git a/doc/guides/index.rst b/doc/guides/index.rst
index 57570f6..25f576a 100644
--- a/doc/guides/index.rst
+++ b/doc/guides/index.rst
@@ -42,7 +42,6 @@ DPDK documentation
cryptodevs/index
sample_app_ug/index
tools/index
-   testpmd_app_ug/index
faq/index
howto/index
rel_notes/index
diff --git a/doc/guides/tools/index.rst b/doc/guides/tools/index.rst
index cbe98b2..f9aa37d 100644
--- a/doc/guides/tools/index.rst
+++ b/doc/guides/tools/index.rst
@@ -39,4 +39,4 @@ Tool User Guides
 pdump
 pmdinfo
 devbind
-
+testpmd/index
diff --git a/doc/guides/testpmd_app_ug/build_app.rst 
b/doc/guides/tools/testpmd/build_app.rst
similarity index 100%
rename from doc/guides/testpmd_app_ug/build_app.rst
rename to doc/guides/tools/testpmd/build_app.rst
diff --git a/doc/guides/testpmd_app_ug/index.rst 
b/doc/guides/tools/testpmd/index.rst
similarity index 96%
rename from doc/guides/testpmd_app_ug/index.rst
rename to doc/guides/tools/testpmd/index.rst
index 1c39a17..10d2ec0 100644
--- a/doc/guides/testpmd_app_ug/index.rst
+++ b/doc/guides/tools/testpmd/index.rst
@@ -28,8 +28,8 @@
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-Testpmd Application User Guide
-==
+testpmd Application
+===

 .. toctree::
 :maxdepth: 3
diff --git a/doc/guides/testpmd_app_ug/intro.rst 
b/doc/guides/tools/testpmd/intro.rst
similarity index 100%
rename from doc/guides/testpmd_app_ug/intro.rst
rename to doc/guides/tools/testpmd/intro.rst
diff --git a/doc/guides/testpmd_app_ug/run_app.rst 
b/doc/guides/tools/testpmd/run_app.rst
similarity index 100%
rename from doc/guides/testpmd_app_ug/run_app.rst
rename to doc/guides/tools/testpmd/run_app.rst
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/tools/testpmd/testpmd_funcs.rst
similarity index 100%
rename from doc/guides/testpmd_app_ug/testpmd_funcs.rst
rename to doc/guides/tools/testpmd/testpmd_funcs.rst
-- 
2.7.0

[dpdk-dev] [PATCH v1] maintainers: update documentation maintainers

[Butler, Siobhan A]

> -Original Message-
> From: Mcnamara, John
> Sent: Tuesday, November 8, 2016 9:32 AM
> To: dev at dpdk.org
> Cc: Mcnamara, John 
> Subject: [PATCH v1] maintainers: update documentation maintainers
> 
> Signed-off-by: John McNamara 
> ---
>  MAINTAINERS | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS index ba12d1b..11de99c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -43,7 +43,6 @@ M: maintainers at dpdk.org
> 
>  Documentation (with overlaps)
>  -
> -M: Siobhan Butler 
>  M: John McNamara 
>  F: README
>  F: doc/
> --
> 2.7.4

Aked-by: Siobhan Butler 

[dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support to the TX path

[Wang, Zhihong]

> > > The setup where it goes wrong:
> > >  1. Xeon E5-2699, HT on, turbo off, 1GB hugepage for both host and guest
> > On the Haswell machine (on which I don't have BIOS access), HT is on,
> > but I unplug siblings at runtime.
> > I also have 1G pages on both sides, and I isolate the cores used by both
> > testpmd and vCPUS.
> >
> > >  2. Fortville 40G
> > >  3. Fedora 4.7.5-200.fc24.x86_64
> > >  4. gcc version 6.2.1
> > >  5. 16.11 RC2 for both host and guest
> > >  6. PVP, testpmd macswap for both host and guest
> > >
> > > BTW, I do see indirect_desc gives slightly better performance for
> loopback
> > > in tests on other platforms, but don't know how PVP performs yet.
> > Interesting, other platforms are also Haswell/Broadwell?
> 
> Yes, but with different OS.
> 
> If you don't have the setup I can do more detailed profiling for the
> root cause next week, since my platform is the only one right now that
> reporting the drop.
> 
> 

Hi Maxime,

I just did some profiling and see much higher L2 miss in vhost
dequeue with indirect_desc in my platform, indicates increase
of memory access contention.

I can keep digging further but might not be able to fix it in time
due to limited bandwidth.

Hope this helps.


Thanks
Zhihong

[dpdk-dev] [PATCH] virtio: tx with can_push when VERSION_1 is set

[Maxime Coquelin]

Hi Pierre,

On 11/08/2016 10:31 AM, Pierre Pfister (ppfister) wrote:
> Current virtio driver advertises VERSION_1 support,
> but does not handle device's VERSION_1 support when
> sending packets (it looks for ANY_LAYOUT feature,
> which is absent).
>
> This patch enables 'can_push' in tx path when VERSION_1
> is advertised by the device.
>
> This significantly improves small packets forwarding rate
> towards devices advertising VERSION_1 feature.
I think it depends whether offloading is enabled or not.
If no offloading enabled, I measured significant drop.
Indeed, when no offloading is enabled, the Tx path in Virtio
does not access the virtio header before your patch, as the header is 
memset to zero at device init time.
With your patch, it gets memset to zero at every transmit in the hot
path.

With offloading enabled, it does makes sense though, as the header will
be accessed.

This patch is for v17.02 anyway, and we may provide a way to enable and
disable features at Virtio PMD init time by this release.

Thanks,
Maxime

>
> Signed-off-by: Pierre Pfister 
> ---
>  drivers/net/virtio/virtio_rxtx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio/virtio_rxtx.c 
> b/drivers/net/virtio/virtio_rxtx.c
> index 724517e..2fe0338 100644
> --- a/drivers/net/virtio/virtio_rxtx.c
> +++ b/drivers/net/virtio/virtio_rxtx.c
> @@ -925,7 +925,8 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf 
> **tx_pkts, uint16_t nb_pkts)
> }
>
> /* optimize ring usage */
> -   if (vtpci_with_feature(hw, VIRTIO_F_ANY_LAYOUT) &&
> +   if ((vtpci_with_feature(hw, VIRTIO_F_ANY_LAYOUT) ||
> + vtpci_with_feature(hw, VIRTIO_F_VERSION_1)) &&
> rte_mbuf_refcnt_read(txm) == 1 &&
> RTE_MBUF_DIRECT(txm) &&
> txm->nb_segs == 1 &&
> --
> 2.7.4 (Apple Git-66)
>

[dpdk-dev] [PATCH v2] net/virtio: cache Rx/Tx offload ability check

[Olivier Matz]

Hi Yuanhan,

On 11/04/2016 03:29 PM, Yuanhan Liu wrote:
> It's not a good idea to do the check of whether Rx/Tx offload is
> enabled at the data path. Instead, we could do the check at init
> stage and store the result, so that we could avoid the check again
> and again at the critical datapath.
> 
> Cc: Olivier Matz 
> Signed-off-by: Yuanhan Liu 
> ---
> v2: - rebase on top of the bug fix patches
> - define rx/tx_offload as uint8_t instead of int
> 
>  drivers/net/virtio/virtio_ethdev.c | 19 +++
>  drivers/net/virtio/virtio_pci.h|  2 ++
>  drivers/net/virtio/virtio_rxtx.c   | 31 +--
>  3 files changed, 26 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c 
> b/drivers/net/virtio/virtio_ethdev.c
> index 1505f67..2adae58 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1188,6 +1188,22 @@ rx_func_get(struct rte_eth_dev *eth_dev)
>   eth_dev->rx_pkt_burst = &virtio_recv_pkts;
>  }
>  
> +static inline int
> +rx_offload_enabled(struct virtio_hw *hw)
> +{
> + return vtpci_with_feature(hw, VIRTIO_NET_F_GUEST_CSUM) ||
> + vtpci_with_feature(hw, VIRTIO_NET_F_GUEST_TSO4) ||
> + vtpci_with_feature(hw, VIRTIO_NET_F_GUEST_TSO6);
> +}
> +
> +static inline int
> +tx_offload_enabled(struct virtio_hw *hw)
> +{
> + return vtpci_with_feature(hw, VIRTIO_NET_F_CSUM) ||
> + vtpci_with_feature(hw, VIRTIO_NET_F_HOST_TSO4) ||
> + vtpci_with_feature(hw, VIRTIO_NET_F_HOST_TSO6);
> +}

Do we need these functions to be inlined?

It looks better to do like this, but out of curiosity, do you see a
performance improvement?

Regards,
Olivier

[dpdk-dev] [PATCH v1] maintainers: update documentation maintainers

[John McNamara]

Signed-off-by: John McNamara 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index ba12d1b..11de99c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -43,7 +43,6 @@ M: maintainers at dpdk.org

 Documentation (with overlaps)
 -
-M: Siobhan Butler 
 M: John McNamara 
 F: README
 F: doc/
-- 
2.7.4

[dpdk-dev] [PATCH] virtio: tx with can_push when VERSION_1 is set

[Pierre Pfister (ppfister)]

Current virtio driver advertises VERSION_1 support,
but does not handle device's VERSION_1 support when
sending packets (it looks for ANY_LAYOUT feature,
which is absent).

This patch enables 'can_push' in tx path when VERSION_1
is advertised by the device.

This significantly improves small packets forwarding rate
towards devices advertising VERSION_1 feature.

Signed-off-by: Pierre Pfister 
---
 drivers/net/virtio/virtio_rxtx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 724517e..2fe0338 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -925,7 +925,8 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, 
uint16_t nb_pkts)
}

/* optimize ring usage */
-   if (vtpci_with_feature(hw, VIRTIO_F_ANY_LAYOUT) &&
+   if ((vtpci_with_feature(hw, VIRTIO_F_ANY_LAYOUT) ||
+ vtpci_with_feature(hw, VIRTIO_F_VERSION_1)) &&
rte_mbuf_refcnt_read(txm) == 1 &&
RTE_MBUF_DIRECT(txm) &&
txm->nb_segs == 1 &&
--
2.7.4 (Apple Git-66)

[dpdk-dev] [PATCH v3] doc: arm64: document DPDK application profiling methods

[Jerin Jacob]

Signed-off-by: Jerin Jacob 
Signed-off-by: John McNamara 
---
v3:
Fixed formatting issues:
- Remove the introduction heading and put intro text under the main 
heading(Thomas)
- Fixed RST formatting issues such as enclosing technical terms in 
backquotes(John)
Thanks, John for providing the updated version
v2:
-Addressed ARM64 specific review comments(Suggested by Thomas)
http://dpdk.org/dev/patchwork/patch/16362/
---
 doc/guides/prog_guide/profile_app.rst | 64 ++-
 1 file changed, 63 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/profile_app.rst 
b/doc/guides/prog_guide/profile_app.rst
index 3226187..54b546a 100644
--- a/doc/guides/prog_guide/profile_app.rst
+++ b/doc/guides/prog_guide/profile_app.rst
@@ -31,8 +31,15 @@
 Profile Your Application
 

+The following sections describe methods of profiling DPDK applications on
+different architectures.
+
+
+Profiling on x86
+
+
 Intel processors provide performance counters to monitor events.
-Some tools provided by Intel can be used to profile and benchmark an 
application.
+Some tools provided by Intel, such as VTune, can be used to profile and 
benchmark an application.
 See the *VTune Performance Analyzer Essentials* publication from Intel Press 
for more information.

 For a DPDK application, this can be done in a Linux* application environment 
only.
@@ -50,3 +57,58 @@ The main situations that should be monitored through event 
counters are:
 Refer to the
 `Intel Performance Analysis Guide 
`_
 for details about application profiling.
+
+
+Profiling on ARM64
+--
+
+Using Linux perf
+
+
+The ARM64 architecture provide performance counters to monitor events.  The
+Linux ``perf`` tool can be used to profile and benchmark an application.  In
+addition to the standard events, ``perf`` can be used to profile arm64
+specific PMU (Performance Monitor Unit) events through raw events (``-e``
+``-rXX``).
+
+For more derails refer to the
+`ARM64 specific PMU events enumeration 
`_.
+
+
+High-resolution cycle counter
+~
+
+The default ``cntvct_el0`` based ``rte_rdtsc()`` provides a portable means to
+get a wall clock counter in user space. Typically it runs at <= 100MHz.
+
+The alternative method to enable ``rte_rdtsc()`` for a high resolution wall
+clock counter is through the armv8 PMU subsystem. The PMU cycle counter runs
+at CPU frequency. However, access to the PMU cycle counter from user space is
+not enabled by default in the arm64 linux kernel. It is possible to enable
+cycle counter for user space access by configuring the PMU from the privileged
+mode (kernel space).
+
+By default the ``rte_rdtsc()`` implementation uses a portable ``cntvct_el0``
+scheme.  Application can choose the PMU based implementation with
+``CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU``.
+
+The example below shows the steps to configure the PMU based cycle counter on
+an armv8 machine.
+
+.. code-block:: console
+
+git clone https://github.com/jerinjacobk/armv8_pmu_cycle_counter_el0
+cd armv8_pmu_cycle_counter_el0
+make
+sudo insmod pmu_el0_cycle_counter.ko
+cd $DPDK_DIR
+make config T=arm64-armv8a-linuxapp-gcc
+echo "CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU=y" >> build/.config
+make
+
+.. warning::
+
+   The PMU based scheme is useful for high accuracy performance profiling with
+   ``rte_rdtsc()``. However, this method can not be used in conjunction with
+   Linux userspace profiling tools like ``perf`` as this scheme alters the PMU
+   registers state.
-- 
2.5.5

[dpdk-dev] [RFC v2] Generic flow director/filtering/classification API

[Zhang, Helin]

Hi Adrien

Any update on the v1 APIs? We are struggling on that, as we need that for our 
development.
May I bring another idea to remove the blocking?
Can we send out the APIs with PMD changes based on our understaning of the RFC 
we discussed recenlty on community? Then you can just update any modification 
on top of it, or ask the submittors to change with your review comments?
Any comments on this idea? If not, then we may go this way. I guess this might 
be the most efficient way. Thank you very much!

Regards,
Helin

> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Wednesday, November 2, 2016 7:13 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org; Thomas Monjalon; Lu, Wenzhuo
> Subject: Re: [dpdk-dev] [RFC v2] Generic flow 
> director/filtering/classification
> API
> 
> Hi Helin,
> 
> On Mon, Oct 31, 2016 at 07:19:18AM +, Zhang, Helin wrote:
> > Hi Adrien
> >
> > Just a double check, do you have any update on the v1 patch set, as now it
> is the end of October?
> > We are extremly eager to see the v1 patch set for development.
> > I don't think we need full validation on the v1 patch set for API. It 
> > should be
> together with PMD and example application.
> > If we can see the v1 API patch set earlier, we can help to validate it with
> our code changes. That's should be more efficient and helpful.
> > Any comments on my personal understanding?
> >
> > Thank you very much for the hard work and kind helps!
> 
> I intend to send it shortly, likely this week. For the record, a large part 
> of this
> task was also dedicated to implement it on the client side (I've just read 
> Wei's
> RFC for a client-side application to which I will reply separately), in order 
> to
> validate it from a usability standpoint that led me to make a few necessary
> adjustments to the API.
> 
> My next submission will include both the updated API with several changes
> discussed on this ML and testpmd code (not a separate application) that uses
> it. Just hang on a bit longer!
> 
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Adrien
> > > Mazarguil
> > > Sent: Friday, September 30, 2016 1:11 AM
> > > To: dev at dpdk.org
> > > Cc: Thomas Monjalon
> > > Subject: Re: [dpdk-dev] [RFC v2] Generic flow
> > > director/filtering/classification API
> > >
> > > On Fri, Aug 19, 2016 at 08:50:44PM +0200, Adrien Mazarguil wrote:
> > > > Hi All,
> > > >
> > > > Thanks to many for the positive and constructive feedback I've
> > > > received so far. Here is the updated specification (v0.7) at last.
> > > >
> > > > I've attempted to address as many comments as possible but could
> > > > not process them all just yet. A new section "Future evolutions"
> > > > has been added for the remaining topics.
> > > >
> > > > This series adds rte_flow.h to the DPDK tree. Next time I will
> > > > attempt to convert the specification as a documentation commit
> > > > part of the patchset and actually implement API functions.
> > > [...]
> > >
> > > A quick update, we initially targeted 16.11 as the DPDK release this
> > > API would be available for, turns out this goal was somewhat too
> > > optimistic as September is ending and we are about to overshoot the
> > > deadline for integration (basically everything took longer than expected,
> big surprise).
> > >
> > > So instead of rushing things now to include a botched API in 16.11
> > > with no PMD support, we simply modified the target, now set to
> > > 17.02. On the plus side this should leave developers more time to
> > > refine and test the API before applications and PMDs start to use it.
> > >
> > > I intend to send the patchset for the first non-draft version
> > > mid-October worst case (ASAP in fact). I still haven't replied to
> > > several comments but did take them into account, thanks for your
> feedback.
> > >
> > > --
> > > Adrien Mazarguil
> > > 6WIND
> 
> --
> Adrien Mazarguil
> 6WIND

[dpdk-dev] rte_ixgbevf_pmd not reporting dropped packets

[Lu, Wenzhuo]

Hi Francesco,


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Montorsi, Francesco
> Sent: Tuesday, November 8, 2016 1:17 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] rte_ixgbevf_pmd not reporting dropped packets
> 
> Hi all,
> 
> I'm using DPDK inside the OS of a VM that is SR-IOV-accelerated.
> I noticed however that the "rte_ixgbevf_pmd" PMD does not report drops... I
> am sending packets at TX side at 14Mpps; at the RX side I'm using "testpmd" 
> and
> it's reporting 'just' 12Mpps, but zero drops (also through xstats).
> 
> Is this a known bug?
> I found a message at
>   http://dpdk.org/ml/archives/dev/2016-March/035374.html
> reporting a similar issue back in March this year...
It's a known limitation. The stats are got from HW. But there're very limited 
counters for VF. There's no similar counter as imiss for VF :(

> 
> 
> Thanks,
> 
> Francesco Montorsi

[dpdk-dev] [PATCH] lib/ip_frag: fix IP reassembly not working issue

[Lu, Wenzhuo]

Hi Thomas,


> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, November 8, 2016 4:28 AM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org; adrien.mazarguil at 6wind.com; Ananyev, Konstantin
> Subject: Re: [dpdk-dev] [PATCH] lib/ip_frag: fix IP reassembly not working 
> issue
> 
> 2016-11-06 12:16, Wenzhuo Lu:
> > After changing pkt[0] to pkt[], the example IP reassembly is not
> > working.
> > It's weird because this change is fine. There should be no difference
> > between them.
> > As a workaround, revert this change.
> >
> > Fixes: 347a1e037fd3 (lib: use C99 syntax for zero-size arrays)
> >
> > Reported-by: Huilong Xu 
> > Signed-off-by: Wenzhuo Lu 
> 
> Applied, thanks
> 
> Please keep us informed if you understand the issue.
Just FYI,
It's so weird, I have to work around it first.
1, I don't think there's any wrong with the code.
2, I cannot reproduce this issue on my machine, but Huilong can reproduce it on 
different machines. As Adrien said, it may be a compile issue. I guess it's a 
compiler issue. Maybe gcc 4.8.5 has its own problem. (I'm using gcc 4.8.3 which 
is fine.)