[dpdk-dev] [PATCH] app/test: increase memory allocated for greedy autotests

[Thomas Monjalon]

The autotest lists, requirements and distribution needs a big rework
to reduce the amount of cores and memory required.
The root cause is not addressed yet.

This patch just increase some memory allocation for some greedy tests
which often fail because of memory fragmentation:
LPM6 and reentrancy tests in groups 3 and 6 respectively.

Signed-off-by: Thomas Monjalon 
---
 app/test/autotest_data.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test/autotest_data.py b/app/test/autotest_data.py
index c69705e..defd46e 100644
--- a/app/test/autotest_data.py
+++ b/app/test/autotest_data.py
@@ -158,7 +158,7 @@ parallel_test_group_list = [
 },
 {
"Prefix":   "group_3",
-   "Memory" :  per_sockets(390),
+   "Memory" :  per_sockets(512),
"Tests" :
[
{
@@ -287,7 +287,7 @@ parallel_test_group_list = [
 },
 {
"Prefix":   "group_6",
-   "Memory" :  per_sockets(128),
+   "Memory" :  per_sockets(512),
"Tests" :
[
{
-- 
2.7.0

[dpdk-dev] [PATCH] app/test: disable filtering with stripped binary

[Thomas Monjalon]

The unavailable tests are filtered out by autotest by looking for
the symbols in the binary:

PCI autotest:  Skipped [Not Available]   [00m 00s]
Malloc autotest:   Success   [00m 00s]

It results to skip everything if the binary has no symbol (stripped):

PCI autotest:  Skipped [Not Available]   [00m 00s]
Malloc autotest:   Skipped [Not Available]   [00m 00s]

This case is handled by getting back to the old behaviour if the binary
has no symbol information:

PCI autotest:  Fail [Not found]  [00m 00s]
Malloc autotest:   Success   [00m 00s]

Fixes: d553c8f2b1a2 ("app/test: filter out unavailable tests")

Signed-off-by: Thomas Monjalon 
---
 app/test/autotest_runner.py | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/app/test/autotest_runner.py b/app/test/autotest_runner.py
index bd99e19..21d3be2 100644
--- a/app/test/autotest_runner.py
+++ b/app/test/autotest_runner.py
@@ -107,8 +107,10 @@ def run_test_group(cmdline, test_group):

# parse the binary for available test commands
binary = cmdline.split()[0]
-   symbols = subprocess.check_output(['nm', binary]).decode('utf-8')
-   avail_cmds = re.findall('test_register_(\w+)', symbols)
+   stripped = 'not stripped' not in subprocess.check_output(['file', 
binary])
+   if not stripped:
+   symbols = subprocess.check_output(['nm', 
binary]).decode('utf-8')
+   avail_cmds = re.findall('test_register_(\w+)', symbols)

# run all tests in test group
for test in test_group["Tests"]:
@@ -129,7 +131,7 @@ def run_test_group(cmdline, test_group):
print >>logfile, "\n%s %s\n" % ("-"*20, test["Name"])

# run test function associated with the test
-   if test["Command"] in avail_cmds:
+   if stripped or test["Command"] in avail_cmds:
result = test["Func"](child, test["Command"])
else:
result = (0, "Skipped [Not Available]")
-- 
2.7.0

[dpdk-dev] [PATCH] mempool: adjust name string size in related data types

[Olivier Matz]

Hi Zoltan,

On 07/19/2016 05:59 PM, Zoltan Kiss wrote:
> 
> 
> On 19/07/16 16:37, Olivier Matz wrote:
>> Hi Zoltan,
>>
>> On 07/19/2016 04:37 PM, Zoltan Kiss wrote:
>>> A recent fix brought up an issue about the size of the 'name' fields:
>>>
>>> 85cf0079 mem: avoid memzone/mempool/ring name truncation
>>>
>>> These relations should be observed:
>>>
>>> RTE_RING_NAMESIZE <= RTE_MEMZONE_NAMESIZE - strlen(RTE_RING_MZ_PREFIX)
>>> RTE_MEMPOOL_NAMESIZE <= RTE_RING_NAMESIZE -
>>> strlen(RTE_MEMPOOL_MZ_PREFIX)
>>>
>>> Setting all of them to 32 hides this restriction from the application.
>>> This patch increases the memzone string size to accomodate for these
>>> prefixes, and the same happens with the ring name string. The ABI
>>> needs to
>>> be broken to fix this API issue, this way doesn't break applications
>>> previously not failing due to the truncating bug now fixed.
>>>
>>> Signed-off-by: Zoltan Kiss 
>>
>> I agree it is a problem for an application because it cannot know what
>> is the maximum name length. On the other hand, breaking the ABI for this
>> looks a bit overkill. Maybe we could reduce RTE_MEMPOOL_NAMESIZE and
>> RTE_RING_NAMESIZE instead of increasing RTE_MEMZONE_NAMESIZE? That way,
>> we could keep the ABI as is.
> 
> But that would break the ABI too, wouldn't it? Unless you keep the array
> the same size (32 bytes) by using RTE_MEMZONE_NAMESIZE.

Yes, that was the idea.

> And even then, the API breaks anyway. There are applications - I have at
> least some - which use all 32 bytes to store the name. Decrease that
> would cause headache to change the naming scheme, because it's a 30
> character long id, and chopping the last few chars would cause name
> collisions and annoying bugs.

Before my patch (85cf0079), long names were silently truncated when
mempool created its ring and/or memzones. Now, it returns an error.

I'm not getting why changing the struct to something like below would
break the API, since it would already return an error today.

  #define RTE_MEMPOOL_NAMESIZE \
  (RTE_MEMZONE_NAMESIZE - sizeof(pool_prefix) - sizeof(ring prefix))
  struct rte_mempool {
  union {
char name[RTE_MEMPOOL_NAMESIZE];
char pad[32];
  };
  ...
  }

Anyway, it may not be the proper solution since it supposes that a
mempool includes a ring based on a memzone, which is not always true now
with mempool handlers.

>> It would even be better to get rid of this static char[] for the
>> structure names and replace it by an allocated const char *. I didn't
>> check it's feasible for memzones. What do you think?
> 
> It would work too, but I don't think it would help a lot. We would still
> need max sizes for the names. Storing them somewhere else won't help us
> in this problem.

Why should we have a maximum length for the names?


Thanks,
Olivier

[dpdk-dev] using virtio driver in dpdk release 2.0

[Shirley Avishour]

Hi,
We are using KVM for loading our VM using e1000 driver for the VM interface.
we noticed that the maximum rate (rx/tx) I get is 10Mbps.
I am currently attempting to move to virtio driver using dpdk release 2.0.
>From the documentation it seems that I have to load my dpdk application
with librte_pmd_virtio.so.
1) The Makefile under lib/librte_pmd_virtio creates a static library. do I
have to write another Makefile for shared object?
2) there is a known bug regarding application taking control of the kernel
managed virtio device, and it seems that there is a patch for this bug only
for release 16.04  - is that correct? is there a patch for release 2.0 as
well?
http://dpdk.org/dev/patchwork/patch/12462/
3) I tried to run my application with the librte_pmd_virtio.so which I
compiled but the application fails to load the interfaces. is it a known
issue in release 2.0?

thanks.

[dpdk-dev] [PATCH] ixgbe: support checksum flags in sse vector Rx function

[Olivier Matz]

Hi Sugesh,

On 07/14/2016 11:24 AM, Chandran, Sugesh wrote:
> Hi Olivier,
> Thank you for working on this.
> We tried to enable checksum offload in OVS-DPDK and couldn't proceed due to 
> the performance impact.
> I assume this patch will fix that issue by enabling checksum offloading with 
> vectorization ON at Rx side.
> 
> Few questions,
> 1) Is there any plan to extend this to other NIC drivers, other than ixgbe? 
> What are the implications of it?

On my side no plan for other drivers, but this is more a question for
pmd maintainers.


> 2) Is it possible to enable it on the Tx side as well?

Yes, vector tx is enabled or not depending on the feature you request at
init (offload, multisegments, ...). See ixgbe_set_tx_function() for
details. My patch does not change this behavior.

> 
> I haven't looked into patch very detail and very little context on it. So 
> please forgive me if any of these queries make no sense.
> 
> Regards
> _Sugesh

Regards,
Olivier

[dpdk-dev] [PATCH] mempool: adjust name string size in related data types

[Olivier Matz]

Hi Zoltan,

On 07/19/2016 04:37 PM, Zoltan Kiss wrote:
> A recent fix brought up an issue about the size of the 'name' fields:
> 
> 85cf0079 mem: avoid memzone/mempool/ring name truncation
> 
> These relations should be observed:
> 
> RTE_RING_NAMESIZE <= RTE_MEMZONE_NAMESIZE - strlen(RTE_RING_MZ_PREFIX)
> RTE_MEMPOOL_NAMESIZE <= RTE_RING_NAMESIZE - strlen(RTE_MEMPOOL_MZ_PREFIX)
> 
> Setting all of them to 32 hides this restriction from the application.
> This patch increases the memzone string size to accomodate for these
> prefixes, and the same happens with the ring name string. The ABI needs to
> be broken to fix this API issue, this way doesn't break applications
> previously not failing due to the truncating bug now fixed.
> 
> Signed-off-by: Zoltan Kiss 

I agree it is a problem for an application because it cannot know what
is the maximum name length. On the other hand, breaking the ABI for this
looks a bit overkill. Maybe we could reduce RTE_MEMPOOL_NAMESIZE and
RTE_RING_NAMESIZE instead of increasing RTE_MEMZONE_NAMESIZE? That way,
we could keep the ABI as is.

It would even be better to get rid of this static char[] for the
structure names and replace it by an allocated const char *. I didn't
check it's feasible for memzones. What do you think?

In any case, I think it's a bit late for 16.07 for this kind of fix.

Regards,
Olivier

[dpdk-dev] [PATCH] doc: announce ABI change for mbuf structure

[Olivier Matz]

On 07/19/2016 05:07 PM, Richardson, Bruce wrote:
> 
> 
>> -Original Message-
>> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
>> Sent: Tuesday, July 19, 2016 4:04 PM
>> To: Richardson, Bruce 
>> Cc: dev at dpdk.org; jerin.jacob at caviumnetworks.com;
>> thomas.monjalon at 6wind.com
>> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for mbuf
>> structure
>>
>> Hi Bruce,
>>
>> On 07/19/2016 04:40 PM, Bruce Richardson wrote:
>>> On Tue, Jul 19, 2016 at 04:01:15PM +0200, Olivier Matz wrote:
 For 16.11, the mbuf structure will be modified implying ABI breakage.
 Some discussions already took place here:
 http://www.dpdk.org/dev/patchwork/patch/12878/

 Signed-off-by: Olivier Matz 
 ---
  doc/guides/rel_notes/deprecation.rst | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/doc/guides/rel_notes/deprecation.rst
 b/doc/guides/rel_notes/deprecation.rst
 index f502f86..2245bc2 100644
 --- a/doc/guides/rel_notes/deprecation.rst
 +++ b/doc/guides/rel_notes/deprecation.rst
 @@ -41,3 +41,9 @@ Deprecation Notices
  * The mempool functions for single/multi producer/consumer are
>> deprecated and
will be removed in 16.11.
It is replaced by rte_mempool_generic_get/put functions.
 +
 +* ABI changes are planned for 16.11 in the ``rte_mbuf`` structure:
 +some
 +  fields will be reordered to facilitate the writing of
 +``data_off``,
 +  ``refcnt``, and ``nb_segs`` in one operation. Indeed, some
 +platforms
 +  have an overhead if the store address is not naturally aligned.
 +The
 +  useless ``port`` field will also be removed at the same occasion.
 --
>>>
>>> Have we fully bottomed out on the mbuf changes. I'm not sure that once
>>> patches start getting considered for merge, new opinions may come
>>> forward. For instance, is the "port" field really "useless"?
>>>
>>> Would it not be better to put in a less specific deprecation notice?
>>> What happens if this notice goes in and the final changes are
>>> different from those called out here?
>>
>> Yes, you are right. What about the following text?
>>
>> ABI changes are planned for 16.11 in the ``rte_mbuf`` structure: some
>> fields may be reordered to facilitate the writing of ``data_off``,
>> ``refcnt``, and ``nb_segs`` in one operation. Indeed, some platforms have
>> an overhead if the store address is not naturally aligned. The ``port``
>> field may also be removed at the same occasion.
>>
> Better. Two suggestions:
> 1. change "Indeed" to "because" and join the sentences.
> 2. change the last sentence to be even more general: "Other mbuf fields, such 
> as the port field, may be moved or removed as part of this mbuf work".

It's much better indeed ;)
Thanks Bruce, I'll submit a v2.

[dpdk-dev] [PATCH] mempool: fix lack of free() registration

[Olivier Matz]

Hi Zoltan,

I ran ./scripts/check-git-log.sh on your patch, showing some minor
styling issues:

On 07/19/2016 04:37 PM, Zoltan Kiss wrote:
> [PATCH] mempool: fix lack of free() registration

"()" should be removed

> The new mempool handler interface forgets to register the free() function
> of the ops. Introduced in this patch:
> 
> 449c49b9 mempool: support handler operations

The format should be:
Fixes: 449c49b93a6b ("mempool: support handler operations")


> 
> Signed-off-by: Zoltan Kiss 
> ---
>  lib/librte_mempool/rte_mempool_ops.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/librte_mempool/rte_mempool_ops.c 
> b/lib/librte_mempool/rte_mempool_ops.c
> index fd0b64c..5f24de2 100644
> --- a/lib/librte_mempool/rte_mempool_ops.c
> +++ b/lib/librte_mempool/rte_mempool_ops.c
> @@ -81,6 +81,7 @@ rte_mempool_register_ops(const struct rte_mempool_ops *h)
>   ops = &rte_mempool_ops_table.ops[ops_index];
>   snprintf(ops->name, sizeof(ops->name), "%s", h->name);
>   ops->alloc = h->alloc;
> + ops->free = h->free;
>   ops->enqueue = h->enqueue;
>   ops->dequeue = h->dequeue;
>   ops->get_count = h->get_count;
> 

Apart from that:
Acked-by: Olivier Matz 

+CC Thomas, I think it should be included in 16.07.

Thanks!

[dpdk-dev] [PATCH] mempool: fix lack of free() registration

[Zoltan Kiss]

On 19/07/16 16:26, Olivier Matz wrote:
> Hi Zoltan,
>
> I ran ./scripts/check-git-log.sh on your patch, showing some minor
> styling issues:

Thanks, do you want me to resend it, or could Thomas fix them upon 
commiting?

>
> On 07/19/2016 04:37 PM, Zoltan Kiss wrote:
>> [PATCH] mempool: fix lack of free() registration
>
> "()" should be removed
>
>> The new mempool handler interface forgets to register the free() function
>> of the ops. Introduced in this patch:
>>
>> 449c49b9 mempool: support handler operations
>
> The format should be:
> Fixes: 449c49b93a6b ("mempool: support handler operations")
>
>
>>
>> Signed-off-by: Zoltan Kiss 
>> ---
>>   lib/librte_mempool/rte_mempool_ops.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/librte_mempool/rte_mempool_ops.c 
>> b/lib/librte_mempool/rte_mempool_ops.c
>> index fd0b64c..5f24de2 100644
>> --- a/lib/librte_mempool/rte_mempool_ops.c
>> +++ b/lib/librte_mempool/rte_mempool_ops.c
>> @@ -81,6 +81,7 @@ rte_mempool_register_ops(const struct rte_mempool_ops *h)
>>  ops = &rte_mempool_ops_table.ops[ops_index];
>>  snprintf(ops->name, sizeof(ops->name), "%s", h->name);
>>  ops->alloc = h->alloc;
>> +ops->free = h->free;
>>  ops->enqueue = h->enqueue;
>>  ops->dequeue = h->dequeue;
>>  ops->get_count = h->get_count;
>>
>
> Apart from that:
> Acked-by: Olivier Matz 
>
> +CC Thomas, I think it should be included in 16.07.
>
> Thanks!
>

[dpdk-dev] capture packets on VM

[Raja Jayapal]

Hi Reshma, 

Thanks for your information.
I have been trying to run the testpmd app and would like to get some idea on 
the packet flow in testpmd.

br0 -vnet0- (port0)VM NIC

br1--vnet1--(port1)VM NIC

br2--vnet2--(port2)VM NIC

br0 IP and MAC:
fe:54:00:0d:af:af - 192.168.100.10
br1 IP and MAC:
fe:54:00:4e:5b:df - 192.168.100.20
br2 IP and MAC:
fe:54:00:93:78:6d - 192.168.100.30

Ran testpmd application on VM and sending packets from Host using packeth.

Using PackETH generator, sent traffic from br0 destined to br1(modified the 
source / destination MAC and IP in packeth tool), but i could see that the 
packets are received on port0 and transmitted on port2.

Sending packets from br0 to br1:

./testpmd -c 3 -n 4 -- -i --total-num-mbufs=3000
testpmd> show port stats all
?  NIC statistics for port 0? 
? RX-packets: 4? RX-missed: 0? RX-bytes:? 0
? RX-errors: 0
? RX-nombuf:? 0 
? TX-packets: 0? TX-errors: 0? TX-bytes:? 0
? 
?  NIC statistics for port 1? 
? RX-packets: 0? RX-missed: 0? RX-bytes:? 0
? RX-errors: 0
? RX-nombuf:? 0 
? TX-packets: 0? TX-errors: 0? TX-bytes:? 0
? 
?  NIC statistics for port 2? 
? RX-packets: 0? RX-missed: 0? RX-bytes:? 0
? RX-errors: 0
? RX-nombuf:? 0 
? TX-packets: 4? TX-errors: 0? TX-bytes:? 0
? 
testpmd> 

Second time, sent traffic from br1 to br2, but the packets are received on 
port2 and transmitted on port0.

Sending packets from br1 to br2:

testpmd> show port stats all
?  NIC statistics for port 0? 
? RX-packets: 0? RX-missed: 0? RX-bytes:? 0
? RX-errors: 0
? RX-nombuf:? 0 
? TX-packets: 6? TX-errors: 0? TX-bytes:? 0
? 
?  NIC statistics for port 1? 
? RX-packets: 6? RX-missed: 0? RX-bytes:? 0
? RX-errors: 0
? RX-nombuf:? 0 
? TX-packets: 0? TX-errors: 0? TX-bytes:? 0
? 
?  NIC statistics for port 2? 
? RX-packets: 0? RX-missed: 0? RX-bytes:? 0
? RX-errors: 0
? RX-nombuf:? 0 
? TX-packets: 0? TX-errors: 0? TX-bytes:? 0
? 
testpmd> 

Could you please suggest whether this is expected behaviour?
Also suggest if any configuarion needs to be done to make the flow to work 
correctly. 


Thanks,
Raja

-"Pattan, Reshma"  wrote: -
To: Raja Jayapal 
From: "Pattan, Reshma" 
Date: 07/15/2016 07:33PM
Cc: "dev at dpdk.org" 
Subject: RE: [dpdk-dev] capture packets on VM


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Raja Jayapal
> Sent: Friday, July 15, 2016 6:55 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] capture packets on VM
> 
> Hi All,
> 
> I have installed dpdk on VM and would like to know how to capture the packets
> on dpdk ports.
> I am sending traffic from host? and want to know how to confirm whether the
> packets are flowing via dpdk ports.
> I tried with tcpdump and wireshark but could not capture the packets inside 
> VM.
> setup : bridge1(Host)--- VM(Guest with DPDK) - bridge2(Host)
> 

Hi,

On DPDK you can capture packets with app/pdump/ tool. This tool is available 
for use from 16.07RC1. 
What you can do is run testpmd and see if packets are seen in testpmd, that 
confirms if packets are landing on dpdk ports or not.
If you also want to capture packet for analysis, you need to run app/pdump/ 
tool along with testpmd. 
The pdump tool captures the packet to pcap file, so you can use tcpdump -ni 
 to view the packets. 
More about the tool usage can be found under doc/guides/sample_app_ug/pdump.rst

Let me know if you need further help on this.

Thanks,
Reshma


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

[dpdk-dev] [PATCH] doc: announce ABI change for mbuf structure

[Olivier Matz]

Hi Bruce,

On 07/19/2016 04:40 PM, Bruce Richardson wrote:
> On Tue, Jul 19, 2016 at 04:01:15PM +0200, Olivier Matz wrote:
>> For 16.11, the mbuf structure will be modified implying ABI breakage.
>> Some discussions already took place here:
>> http://www.dpdk.org/dev/patchwork/patch/12878/
>>
>> Signed-off-by: Olivier Matz 
>> ---
>>  doc/guides/rel_notes/deprecation.rst | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/doc/guides/rel_notes/deprecation.rst 
>> b/doc/guides/rel_notes/deprecation.rst
>> index f502f86..2245bc2 100644
>> --- a/doc/guides/rel_notes/deprecation.rst
>> +++ b/doc/guides/rel_notes/deprecation.rst
>> @@ -41,3 +41,9 @@ Deprecation Notices
>>  * The mempool functions for single/multi producer/consumer are deprecated 
>> and
>>will be removed in 16.11.
>>It is replaced by rte_mempool_generic_get/put functions.
>> +
>> +* ABI changes are planned for 16.11 in the ``rte_mbuf`` structure: some
>> +  fields will be reordered to facilitate the writing of ``data_off``,
>> +  ``refcnt``, and ``nb_segs`` in one operation. Indeed, some platforms
>> +  have an overhead if the store address is not naturally aligned. The
>> +  useless ``port`` field will also be removed at the same occasion.
>> -- 
> 
> Have we fully bottomed out on the mbuf changes. I'm not sure that once patches
> start getting considered for merge, new opinions may come forward. For 
> instance,
> is the "port" field really "useless"?
> 
> Would it not be better to put in a less specific deprecation notice? What 
> happens
> if this notice goes in and the final changes are different from those called 
> out
> here?

Yes, you are right. What about the following text?

ABI changes are planned for 16.11 in the ``rte_mbuf`` structure: some
fields may be reordered to facilitate the writing of ``data_off``,
``refcnt``, and ``nb_segs`` in one operation. Indeed, some platforms
have an overhead if the store address is not naturally aligned. The
``port`` field may also be removed at the same occasion.


Thanks,
Olivier

[dpdk-dev] [PATCH] mempool: adjust name string size in related data types

[Zoltan Kiss]

On 19/07/16 16:37, Olivier Matz wrote:
> Hi Zoltan,
>
> On 07/19/2016 04:37 PM, Zoltan Kiss wrote:
>> A recent fix brought up an issue about the size of the 'name' fields:
>>
>> 85cf0079 mem: avoid memzone/mempool/ring name truncation
>>
>> These relations should be observed:
>>
>> RTE_RING_NAMESIZE <= RTE_MEMZONE_NAMESIZE - strlen(RTE_RING_MZ_PREFIX)
>> RTE_MEMPOOL_NAMESIZE <= RTE_RING_NAMESIZE - strlen(RTE_MEMPOOL_MZ_PREFIX)
>>
>> Setting all of them to 32 hides this restriction from the application.
>> This patch increases the memzone string size to accomodate for these
>> prefixes, and the same happens with the ring name string. The ABI needs to
>> be broken to fix this API issue, this way doesn't break applications
>> previously not failing due to the truncating bug now fixed.
>>
>> Signed-off-by: Zoltan Kiss 
>
> I agree it is a problem for an application because it cannot know what
> is the maximum name length. On the other hand, breaking the ABI for this
> looks a bit overkill. Maybe we could reduce RTE_MEMPOOL_NAMESIZE and
> RTE_RING_NAMESIZE instead of increasing RTE_MEMZONE_NAMESIZE? That way,
> we could keep the ABI as is.

But that would break the ABI too, wouldn't it? Unless you keep the array 
the same size (32 bytes) by using RTE_MEMZONE_NAMESIZE.
And even then, the API breaks anyway. There are applications - I have at 
least some - which use all 32 bytes to store the name. Decrease that 
would cause headache to change the naming scheme, because it's a 30 
character long id, and chopping the last few chars would cause name 
collisions and annoying bugs.

>
> It would even be better to get rid of this static char[] for the
> structure names and replace it by an allocated const char *. I didn't
> check it's feasible for memzones. What do you think?

It would work too, but I don't think it would help a lot. We would still 
need max sizes for the names. Storing them somewhere else won't help us 
in this problem.

>
> In any case, I think it's a bit late for 16.07 for this kind of fix.
>
> Regards,
> Olivier
>

[dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs for some RX mbuf sizes

[Take Ceara]

Hi Beilei,

On Tue, Jul 19, 2016 at 11:31 AM, Xing, Beilei  wrote:
> Hi Ceara,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Take Ceara
>> Sent: Tuesday, July 19, 2016 12:14 AM
>> To: Zhang, Helin 
>> Cc: Wu, Jingjing ; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710
>> NICs for some RX mbuf sizes
>>
>> Hi Helin,
>>
>> On Mon, Jul 18, 2016 at 5:15 PM, Zhang, Helin 
>> wrote:
>> > Hi Ceara
>> >
>> > Could you help to let me know your firmware version?
>>
>> # ethtool -i p7p1 | grep firmware
>> firmware-version: f4.40.35115 a1.4 n4.53 e2021
>>
>> > And could you help to try with the standard DPDK example application,
>> such as testpmd, to see if there is the same issue?
>> > Basically we always set the same size for both rx and tx buffer, like the
>> default one of 2048 for a lot of applications.
>>
>> I'm a bit lost in the testpmd CLI. I enabled RSS, configured 2 RX queues per
>> port and started sending traffic with single segmnet packets of size 2K but I
>> didn't figure out how to actually verify that the RSS hash is correctly set..
>> Please let me know if I should do it in a different way.
>>
>> testpmd -c 0x331 -w :82:00.0 -w :83:00.0 -- --mbuf-size 2048 -i [...]
>>
>> testpmd> port stop all
>> Stopping ports...
>> Checking link statuses...
>> Port 0 Link Up - speed 4 Mbps - full-duplex Port 1 Link Up - speed 4
>> Mbps - full-duplex Done
>>
>> testpmd> port config all txq 2
>>
>> testpmd> port config all rss all
>>
>> testpmd> port config all max-pkt-len 2048 port start all
>> Configuring Port 0 (socket 0)
>> PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq.
>> PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq.
>> PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are
>> satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=0.
>> PMD: i40e_set_tx_function(): Vector tx finally be used.
>> PMD: i40e_set_rx_function(): Using Vector Scattered Rx callback (port=0).
>> Port 0: 3C:FD:FE:9D:BE:F0
>> Configuring Port 1 (socket 0)
>> PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq.
>> PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq.
>> PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are
>> satisfied. Rx Burst Bulk Alloc function will be used on port=1, queue=0.
>> PMD: i40e_set_tx_function(): Vector tx finally be used.
>> PMD: i40e_set_rx_function(): Using Vector Scattered Rx callback (port=1).
>> Port 1: 3C:FD:FE:9D:BF:30
>> Checking link statuses...
>> Port 0 Link Up - speed 4 Mbps - full-duplex Port 1 Link Up - speed 4
>> Mbps - full-duplex Done
>>
>> testpmd> set txpkts 2048
>> testpmd> show config txpkts
>> Number of segments: 1
>> Segment sizes: 2048
>> Split packet: off
>>
>>
>> testpmd> start tx_first
>>   io packet forwarding - CRC stripping disabled - packets/burst=32
>>   nb forwarding cores=1 - nb forwarding ports=2
>>   RX queues=1 - RX desc=128 - RX free threshold=32
>
> In testpmd, when RX queues=1, RSS will be disabled, so could you re-configure 
> rx queue(>1) and try again with testpmd?

I changed the way I run testmpd to:

testpmd -c 0x331 -w :82:00.0 -w :83:00.0 -- --mbuf-size 1152
--rss-ip --rxq=2 --txpkts 1024 -i

As far as I understand this will allocate mbufs with the same size I
was using in my test (--mbuf-size seems to include the mbuf headroom
therefore 1152 = 1024 + 128 headroom).

testpmd> start tx_first
  io packet forwarding - CRC stripping disabled - packets/burst=32
  nb forwarding cores=1 - nb forwarding ports=2
  RX queues=2 - RX desc=128 - RX free threshold=32
  RX threshold registers: pthresh=8 hthresh=8 wthresh=0
  TX queues=1 - TX desc=512 - TX free threshold=32
  TX threshold registers: pthresh=32 hthresh=0 wthresh=0
  TX RS bit threshold=32 - TXQ flags=0xf01
testpmd> show port stats all

   NIC statistics for port 0  
  RX-packets: 18817613   RX-missed: 5  RX-bytes:  19269115888
  RX-errors: 0
  RX-nombuf:  0
  TX-packets: 18818064   TX-errors: 0  TX-bytes:  19269567464
  

   NIC statistics for port 1  
  RX-packets: 18818392   RX-missed: 5  RX-bytes:  19269903360
  RX-errors: 0
  RX-nombuf:  0
  TX-packets: 18817979   TX-errors: 0  TX-bytes:  19269479424
  

Ttraffic is sent/received. However, I couldn't find any way to verify
that the incoming mbufs actually have the mbuf->hash.rss field set
except for starting test-pmd with gdb and setting a breakpoint in the
io fwd engine. After doing that I noticed that none of the incoming
packets has the PKT_RX_RSS_HASH flag set in ol_flags... I guess for
some reason test-pmd doesn't actually config

[dpdk-dev] [PATCH v4] doc: flow bifurcation guide on Linux

[Mcnamara, John]

> -Original Message-
> From: Wu, Jingjing
> Sent: Tuesday, July 19, 2016 4:31 AM
> To: Mcnamara, John 
> Cc: dev at dpdk.org; Wu, Jingjing ; Liu, Yong
> ; Zhang, Helin 
> Subject: [PATCH v4] doc: flow bifurcation guide on Linux
> 
> Flow Bifurcation is a mechanism which uses features of advanced Ethernet
> devices to split traffic between queues. It provides the capability to let
> the kernel driver and DPDK driver co-exist and take advantage of both.
> 
> It is achieved by using SR-IOV and the NIC's advanced filtering. This
> patch describes Flow Bifurcation and adds the user guide for ixgbe and
> i40e NICs.
> 
> Signed-off-by: Jingjing Wu 




This patch is dependent on:
[PATCH v5 1/2] doc: live migration of VM with Virtio and VF

The following patch is also dependent on it:

[PATCH v3 1/2] doc: live migration of VM with vhost_user on host

There is now a merge conflict between your patch and the second patch
because index.rst has been changed.

Maybe the 2 patches above could be combined and you can rebase your
patch against it.

But as for the patch itself:


Acked-by: John McNamara 

[dpdk-dev] [PATCH] doc: fix vhost setup in tep-termination app guide

[Mark Kavanagh]

- Fix vhost setup flags
- Add minor edits to improve readability and consistency

Signed-off-by: Mark Kavanagh 
---
 doc/guides/sample_app_ug/tep_termination.rst | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 mode change 100644 => 100755 doc/guides/sample_app_ug/tep_termination.rst

diff --git a/doc/guides/sample_app_ug/tep_termination.rst 
b/doc/guides/sample_app_ug/tep_termination.rst
old mode 100644
new mode 100755
index 2d86a03..c3d1e97
--- a/doc/guides/sample_app_ug/tep_termination.rst
+++ b/doc/guides/sample_app_ug/tep_termination.rst
@@ -59,8 +59,8 @@ This allows network isolation, QOS, etc to be provided on a 
per client basis.
 In a typical setup, the network overlay tunnel is terminated at the 
Virtual/Tunnel End Point (VEP/TEP).
 The TEP is normally located at the physical host level ideally in the software 
switch.
 Due to processing constraints and the inevitable bottleneck that the switch
-becomes the ability to offload overlay support features becomes an important 
requirement.
-Intel? XL710 10/40 G Ethernet network card provides hardware filtering
+becomes, the ability to offload overlay support features becomes an important 
requirement.
+Intel? XL710 10/40 Gigabit Ethernet network card provides hardware filtering
 and offload capabilities to support overlay networks implementations such as 
MAC in UDP and MAC in GRE.

 Sample Code Overview
@@ -131,14 +131,14 @@ Compiling the Sample Code

 .. code-block:: console

-CONFIG_RTE_LIBRTE_VHOST=n
+CONFIG_RTE_LIBRTE_VHOST=y

 vhost user is turned on by default in the configure file 
config/common_linuxapp.
 To enable vhost cuse, disable vhost user.

 .. code-block:: console

-CONFIG_RTE_LIBRTE_VHOST_USER=y
+CONFIG_RTE_LIBRTE_VHOST_USER=n

  After vhost is enabled and the implementation is selected, build the 
vhost library.

-- 
1.9.3

[dpdk-dev] [PATCH v3] mk: fix FreeBSD build

[Christian Ehrhardt]

Hi,
the order changed, but IMHO actually it improved.
Things are now at the place they were before, but with the overwriting
config value that came later - that is the best of both worlds.

Tested a few config runs pre/post patch and compared them sorted (equal)
and unsorted - now configs slotted in where they belong.
Thanks for updating Sergio

Acked-by: Christian Ehrhardt 

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Tue, Jul 19, 2016 at 3:40 PM, Sergio Gonzalez Monroy <
sergio.gonzalez.monroy at intel.com> wrote:

> The sed syntax of '0,/regexp/' is GNU specific and fails with
> non GNU sed in FreeBSD.
>
> To solve the issue we can use awk instead to remove duplicates.
>
> The awk script basically keeps the last config value, while
> maintaining order and comments from original config file.
>
> Fixes: b2063f104db7 ("mk: filter duplicate configuration entries")
>
> Signed-off-by: Sergio Gonzalez Monroy 
> ---
>  mk/rte.sdkconfig.mk | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
> index e93237f..5c94edf 100644
> --- a/mk/rte.sdkconfig.mk
> +++ b/mk/rte.sdkconfig.mk
> @@ -88,11 +88,13 @@ $(RTE_OUTPUT)/.config: $(RTE_CONFIG_TEMPLATE) FORCE |
> $(RTE_OUTPUT)
> $(CPP) -undef -P -x assembler-with-cpp \
> -ffreestanding \
> -o $(RTE_OUTPUT)/.config_tmp $(RTE_CONFIG_TEMPLATE) ; \
> -   for config in $$(grep -v "^#" $(RTE_OUTPUT)/.config_tmp |
> cut -d"=" -f1 | sort | uniq -d); do \
> -   while [ $$(grep "^$${config}="
> $(RTE_OUTPUT)/.config_tmp -c ) -gt 1 ]; do \
> -   sed -i "0,/^$${config}=/{//d}"
> $(RTE_OUTPUT)/.config_tmp; \
> -   done; \
> -   done; \
> +   config=$$(cat $(RTE_OUTPUT)/.config_tmp) ; \
> +   echo "$$config" | awk -F '=' 'BEGIN {i=1} \
> +   /^#/ {pos[i++]=$$0} \
> +   !/^#/ {if (!s[$$1]) {pos[i]=$$0; s[$$1]=i++} \
> +   else {pos[s[$$1]]=$$0}} END \
> +   {for (j=1; j +   > $(RTE_OUTPUT)/.config_tmp ; \
> if ! cmp -s $(RTE_OUTPUT)/.config_tmp
> $(RTE_OUTPUT)/.config; then \
> cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config
> ; \
> cp $(RTE_OUTPUT)/.config_tmp
> $(RTE_OUTPUT)/.config.orig ; \
> --
> 2.4.11
>
>

[dpdk-dev] [PATCH] doc: fix vhost setup in tep-termination app guide

[Mark Kavanagh]

- Fix vhost setup flags
- Add minor edits to improve readability and consistency

Signed-off-by: Mark Kavanagh 
---
 doc/guides/sample_app_ug/tep_termination.rst | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 mode change 100644 => 100755 doc/guides/sample_app_ug/tep_termination.rst

diff --git a/doc/guides/sample_app_ug/tep_termination.rst 
b/doc/guides/sample_app_ug/tep_termination.rst
old mode 100644
new mode 100755
index 2d86a03..c3d1e97
--- a/doc/guides/sample_app_ug/tep_termination.rst
+++ b/doc/guides/sample_app_ug/tep_termination.rst
@@ -59,8 +59,8 @@ This allows network isolation, QOS, etc to be provided on a 
per client basis.
 In a typical setup, the network overlay tunnel is terminated at the 
Virtual/Tunnel End Point (VEP/TEP).
 The TEP is normally located at the physical host level ideally in the software 
switch.
 Due to processing constraints and the inevitable bottleneck that the switch
-becomes the ability to offload overlay support features becomes an important 
requirement.
-Intel? XL710 10/40 G Ethernet network card provides hardware filtering
+becomes, the ability to offload overlay support features becomes an important 
requirement.
+Intel? XL710 10/40 Gigabit Ethernet network card provides hardware filtering
 and offload capabilities to support overlay networks implementations such as 
MAC in UDP and MAC in GRE.

 Sample Code Overview
@@ -131,14 +131,14 @@ Compiling the Sample Code

 .. code-block:: console

-CONFIG_RTE_LIBRTE_VHOST=n
+CONFIG_RTE_LIBRTE_VHOST=y

 vhost user is turned on by default in the configure file 
config/common_linuxapp.
 To enable vhost cuse, disable vhost user.

 .. code-block:: console

-CONFIG_RTE_LIBRTE_VHOST_USER=y
+CONFIG_RTE_LIBRTE_VHOST_USER=n

  After vhost is enabled and the implementation is selected, build the 
vhost library.

-- 
1.9.3

[dpdk-dev] [PATCH v3 2/2] doc: add vhost_user live migration image

[Mcnamara, John]

> -Original Message-
> From: Iremonger, Bernard
> Sent: Monday, July 18, 2016 3:30 PM
> To: Mcnamara, John ; dev at dpdk.org
> Cc: Liu, Yong ; Xu, Qian Q ;
> yuanhan.liu at linux.intel.com; Iremonger, Bernard
> 
> Subject: [PATCH v3 2/2] doc: add vhost_user live migration image
> 
> This patch adds an image of the Live Migration of a VM using vhost_user on
> the host, test configuration.
> 
> Signed-off-by: Bernard Iremonger 

Acked-by: John McNamara 

[dpdk-dev] [PATCH v3 1/2] doc: live migration of VM with vhost_user on host

[Mcnamara, John]

> -Original Message-
> From: Iremonger, Bernard
> Sent: Monday, July 18, 2016 3:30 PM
> To: Mcnamara, John ; dev at dpdk.org
> Cc: Liu, Yong ; Xu, Qian Q ;
> yuanhan.liu at linux.intel.com; Iremonger, Bernard
> 
> Subject: [PATCH v3 1/2] doc: live migration of VM with vhost_user on host
> 
> This patch describes the procedure to be be followed to perform Live
> Migration of a VM with Virtio PMD running on a host which is running the
> vhost_user sample application (vhost-switch).
> 
> It includes sample host and VM scripts used in the procedure.
> 
> Signed-off-by: Bernard Iremonger 


Note: this patch is dependent on:
[PATCH v5 1/2] doc: live migration of VM with Virtio and VF

Acked-by: John McNamara 

[dpdk-dev] [PATCH v5 2/2] doc: add live migration virtio sriov image

[Mcnamara, John]

> -Original Message-
> From: Iremonger, Bernard
> Sent: Tuesday, July 19, 2016 4:09 PM
> To: Mcnamara, John ; dev at dpdk.org
> Cc: Liu, Yong ; Xu, Qian Q ;
> yuanhan.liu at linux.intel.com; Iremonger, Bernard
> 
> Subject: [PATCH v5 2/2] doc: add live migration virtio sriov image
> 
> This patch adds an image of the Live Migration for virtio and sriov test
> configuration.
> 
> Signed-off-by: Bernard Iremonger 

Acked-by: John McNamara 

[dpdk-dev] [PATCH v5 1/2] doc: live migration of VM with Virtio and VF

[Mcnamara, John]

> -Original Message-
> From: Iremonger, Bernard
> Sent: Tuesday, July 19, 2016 4:09 PM
> To: Mcnamara, John ; dev at dpdk.org
> Cc: Liu, Yong ; Xu, Qian Q ;
> yuanhan.liu at linux.intel.com; Iremonger, Bernard
> 
> Subject: [PATCH v5 1/2] doc: live migration of VM with Virtio and VF
> 
> This patch describes the procedure to be be followed to perform Live
> Migration of a VM with Virtio and VF PMD's using the bonding PMD.
> 
> It includes sample host and VM scripts used in the procedure, and a sample
> switch configuration.
> 
> Signed-off-by: Bernard Iremonger 

Acked-by: John McNamara 

[dpdk-dev] [PATCH v5 2/2] doc: add live migration virtio sriov image

[Bernard Iremonger]

This patch adds an image of the Live Migration for
virtio and sriov test configuration.

Signed-off-by: Bernard Iremonger 
---
 doc/guides/howto/img/lm_bond_virtio_sriov.svg | 666 ++
 doc/guides/howto/lm_bond_virtio_sriov.rst |   4 +
 2 files changed, 670 insertions(+)
 create mode 100644 doc/guides/howto/img/lm_bond_virtio_sriov.svg

diff --git a/doc/guides/howto/img/lm_bond_virtio_sriov.svg 
b/doc/guides/howto/img/lm_bond_virtio_sriov.svg
new file mode 100644
index 000..d913ae0
--- /dev/null
+++ b/doc/guides/howto/img/lm_bond_virtio_sriov.svg
@@ -0,0 +1,666 @@
+
+
+
+http://purl.org/dc/elements/1.1/";
+   xmlns:cc="http://creativecommons.org/ns#";
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
+   xmlns:svg="http://www.w3.org/2000/svg";
+   xmlns="http://www.w3.org/2000/svg";
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd";
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape";
+   width="1052.8693"
+   height="762.99158"
+   id="svg2"
+   version="1.1"
+   inkscape:version="0.48.4 r9939"
+   sodipodi:docname="lm_overview.svg">
+  
+
+  
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+
+  
+image/svg+xml
+http://purl.org/dc/dcmitype/StillImage"; />
+
+  
+
+  
+  
+
+
+
+
+
+
+
+
+VM 1 
+Switch with 10Gb ports
+Server 1
+Server 2
+  10 Gb Traffic Generator
+VM 2 
+Linux, KVM, QEMU 
+Linux, KVM, QEMU 
+10 Gb NIC
+10 Gb NIC
+
+
+10 Gb NIC
+10 Gb NIC
+
+DPDK Testpmd App.
+bonded device withvirtio and VF slaves
+
+DPDK Testpmd App.
+bonded device withvirtio and VF slaves
+Kernel PF driver
+Kernel PF driver
+SW bridge with Tapand PF connected 
+NFS ServerVM disk image
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+SW bridge with Tapand PF connected 
+10 Gb Migration Link
+  
+
diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst 
b/doc/guides/howto/lm_bond_virtio_sriov.rst
index 6cf797d..49666f1 100644
--- a/doc/guides/howto/lm_bond_virtio_sriov.rst
+++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
@@ -67,6 +67,10 @@ The ip address of host_server_1 is 10.237.212.46

 The ip address of host_server_2 is 10.237.212.131

+.. _figure_lm_bond_virtio_sriov:
+
+.. figure:: img/lm_bond_virtio_sriov.*
+
 Live Migration steps
 

-- 
2.9.0

[dpdk-dev] [PATCH v5 1/2] doc: live migration of VM with Virtio and VF

[Bernard Iremonger]

This patch describes the procedure to be be followed
to perform Live Migration of a VM with Virtio and VF PMD's
using the bonding PMD.

It includes sample host and VM scripts used in the procedure,
and a sample switch configuration.

Signed-off-by: Bernard Iremonger 
---
 doc/guides/howto/index.rst|  38 ++
 doc/guides/howto/lm_bond_virtio_sriov.rst | 709 ++
 doc/guides/index.rst  |   1 +
 3 files changed, 748 insertions(+)
 create mode 100644 doc/guides/howto/index.rst
 create mode 100644 doc/guides/howto/lm_bond_virtio_sriov.rst

diff --git a/doc/guides/howto/index.rst b/doc/guides/howto/index.rst
new file mode 100644
index 000..5ff7526
--- /dev/null
+++ b/doc/guides/howto/index.rst
@@ -0,0 +1,38 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+How To User Guides
+==
+
+.. toctree::
+:maxdepth: 2
+:numbered:
+
+lm_bond_virtio_sriov
diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst 
b/doc/guides/howto/lm_bond_virtio_sriov.rst
new file mode 100644
index 000..6cf797d
--- /dev/null
+++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
@@ -0,0 +1,709 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Live Migration of VM with SR-IOV VF
+===
+
+Overview
+
+
+It is not possible to migrate a Virtual Machine which has an SR-IOV Virtual 
Function (VF).
+
+To get around this problem the bonding PMD is used.
+
+The following sections show an example of how to do this.
+
+Test Setup
+--
+
+A bonded device is created in the VM.
+The virtio and VF PMD's are added as slaves to the bonded device.
+The VF is set as the primary slave of the bonded device.
+
+A bridge must be set up on the Host connecting the tap device, which is the
+backend 

[dpdk-dev] [PATCH v5 0/2] doc: live migration procedure

[Bernard Iremonger]

This patch set describes the procedure to Live migrate
a VM with Virtio and VF PMD's using the bonding PMD.

Changes in v5:
restore missing image file
change Guide to Guides in heading

Changes in v4:
rename image file and patch
added links to rst file
updated rst file in line with comments

Changes in v3:
rename directory from how_to to howto
move to after FAQ in the index

Changes in v2:
change primary port before removing slave port
remove unused variables from QEMU scripts
identify NIC's in bridge setup scripts

Bernard Iremonger (2):
  doc: live migration of VM with Virtio and VF
  doc: add live migration virtio sriov image

 doc/guides/howto/img/lm_bond_virtio_sriov.svg | 666 
 doc/guides/howto/index.rst|  38 ++
 doc/guides/howto/lm_bond_virtio_sriov.rst | 713 ++
 doc/guides/index.rst  |   1 +
 4 files changed, 1418 insertions(+)
 create mode 100644 doc/guides/howto/img/lm_bond_virtio_sriov.svg
 create mode 100644 doc/guides/howto/index.rst
 create mode 100644 doc/guides/howto/lm_bond_virtio_sriov.rst

-- 
2.9.0

[dpdk-dev] [PATCH] doc: fix vhost setup in tep-termination app guide

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mark Kavanagh
> Sent: Tuesday, July 19, 2016 4:32 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: fix vhost setup in tep-termination app
> guide
> 
> - Fix vhost setup flags
> - Add minor edits to improve readability and consistency
> 
> Signed-off-by: Mark Kavanagh 

Good catch. Thanks.

Acked-by: John McNamara 

[dpdk-dev] [PATCH v3] mk: fix FreeBSD build

[Ferruh Yigit]

On 7/19/2016 3:30 PM, Christian Ehrhardt wrote:
> Hi,
> the order changed, but IMHO actually it improved.
> Things are now at the place they were before, but with the overwriting
> config value that came later - that is the best of both worlds.

Agreed, this is a good solution. Also fixes multiple copy of file
comment issue ...

> 
> Tested a few config runs pre/post patch and compared them sorted (equal)
> and unsorted - now configs slotted in where they belong.
> Thanks for updating Sergio
> 
> Acked-by: Christian Ehrhardt  >
> 
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
> 

[dpdk-dev] [PATCH] doc: announce ABI change for mbuf structure

[Olivier Matz]

For 16.11, the mbuf structure will be modified implying ABI breakage.
Some discussions already took place here:
http://www.dpdk.org/dev/patchwork/patch/12878/

Signed-off-by: Olivier Matz 
---
 doc/guides/rel_notes/deprecation.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index f502f86..2245bc2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -41,3 +41,9 @@ Deprecation Notices
 * The mempool functions for single/multi producer/consumer are deprecated and
   will be removed in 16.11.
   It is replaced by rte_mempool_generic_get/put functions.
+
+* ABI changes are planned for 16.11 in the ``rte_mbuf`` structure: some
+  fields will be reordered to facilitate the writing of ``data_off``,
+  ``refcnt``, and ``nb_segs`` in one operation. Indeed, some platforms
+  have an overhead if the store address is not naturally aligned. The
+  useless ``port`` field will also be removed at the same occasion.
-- 
2.8.1

[dpdk-dev] [PATCH] virtio: fix packet corruption

[Olivier Matz]

Hi,

On 07/19/2016 03:57 PM, Tan, Jianfeng wrote:
> 
> 
>> -Original Message-
>> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
>> Sent: Tuesday, July 19, 2016 9:11 PM
>> To: Tan, Jianfeng; dev at dpdk.org; Xie, Huawei; yuanhan.liu at 
>> linux.intel.com
>> Subject: Re: [PATCH] virtio: fix packet corruption
>>
>> Hi Jianfeng,
>>
>> On 07/19/2016 03:03 PM, Tan, Jianfeng wrote:
>>> Hi Oliver,
>>>
 -Original Message-
 From: Olivier Matz [mailto:olivier.matz at 6wind.com]
 Sent: Tuesday, July 19, 2016 8:32 PM
 To: dev at dpdk.org; Tan, Jianfeng; Xie, Huawei;
>> yuanhan.liu at linux.intel.com
 Subject: [PATCH] virtio: fix packet corruption

 The support of virtio-user changed the way the mbuf dma address is
 retrieved, using a physical address in case of virtio-pci and a virtual
 address in case of virtio-user.

 This change introduced some possible memory corruption in packets,
 replacing:
   m->buf_physaddr + RTE_PKTMBUF_HEADROOM
 by:
   m->buf_physaddr + m->data_off (through a macro)

 This patch fixes this issue, restoring the original behavior.
>>>
>>> Could you be more specific on why we cannot use m->data_off here?
>>
>> There is no guarantee that m->data_off == RTE_PKTMBUF_HEADROOM here
>> as
>> virtqueue_enqueue_recv_refill() is called on a mbuf that is just
>> allocated with rte_mbuf_raw_alloc(). An alternative would be to set
>> data_off to RTE_PKTMBUF_HEADROOM, but as it's a fix and we are close to
>> the release, I prefered to restore the initial behavior.
> 
> Oh yes, gotcha.
> 
> But if we do not set data_off properly, it's still buggy when others consume 
> these mbufs, right?
> 

This is done later in virtio_recv_pkts*() functions, one the host has
written the data in the mbuf.

[dpdk-dev] [PATCH v2] Memory leak when adding/removing vhost_user ports

[Christian Ehrhardt]

Hi,
thanks for evaluating.
I'll need a few days until I'm ready for OVS again and until OVS is ready
for DPDK 16.07.
Then I can run an adapted version of my old testcase to be sure.

In the worst cases it will be in 16.11 and I'll backport to 16.07 as
distributed.
I'll let you know then.


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Tue, Jul 12, 2016 at 2:08 PM, Yuanhan Liu 
wrote:

> On Wed, Jul 06, 2016 at 09:08:12PM +0800, Yuanhan Liu wrote:
> > On Wed, Jul 06, 2016 at 02:24:57PM +0200, Christian Ehrhardt wrote:
> > > Hi,
> > > while checking for dpdk 16.07 what backports are accepted in the
> meantime so I
> > > can drop them I found this particular discussion has been silently
> forgotten by
> > > all of us.
> >
> > Not really. As later I found that my patch was actually wrong (besides
> > the issue you already found). I will revisit this issue thoroughly when
> > get time, hopefully, next week.
>
> Here it is: vhost_destroy() will be invoked when:
>
> - QEMU quits gracefully
> - QEMU terminates unexpectedly
>
> Meaning, there should be no memory leak. I think we are fine here (I
> maybe wrong though, feeling a bit dizzy now :(
>
> --yliu
>

[dpdk-dev] [PATCH] net/enic: heed VLAN strip flag in device configure function

[John Daley]

The configure function enicpmd_dev_configure() was not paying attention
to the rxmode VLAN strip bit. Set the VLAN strip mode according to the bit.

Fixes: fefed3d1e62c ("enic: new driver")

Signed-off-by: John Daley 
---

Although not critical, it is low risk and would be nice to have in 16_07.

 drivers/net/enic/enic_ethdev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 59082d2..47b07c9 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -356,6 +356,7 @@ static int enicpmd_dev_configure(struct rte_eth_dev 
*eth_dev)
eth_dev->data->dev_conf.rxmode.split_hdr_size);
}

+   enicpmd_vlan_offload_set(eth_dev, ETH_VLAN_STRIP_MASK);
enic->hw_ip_checksum = eth_dev->data->dev_conf.rxmode.hw_ip_checksum;
return 0;
 }
-- 
2.7.0

[dpdk-dev] [PATCH] net/enic: fix possible Rx corruption

[John Daley]

Initialize the mbuf data offset to RTE_PKTMBUF_HEADROOM as the
enic takes ownership of them. If allocated mbufs had some offset
other than RTE_PKTMBUF_HEADROOM, the application would read mbuf
data starting at the wrong place and misinterpret the packet.

Fixes: 856d7ba7ed22 ("net/enic: support scattered Rx")

Reviewed-by: Nelson Escobar 
Signed-off-by: John Daley 
---

Please include this patch in 16.07 since the bug found in late testing
can cause data corruption.

 drivers/net/enic/enic_main.c | 1 +
 drivers/net/enic/enic_rxtx.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 542f095..b4ca371 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -317,6 +317,7 @@ enic_alloc_rx_queue_mbufs(struct enic *enic, struct vnic_rq 
*rq)
return -ENOMEM;
}

+   mb->data_off = RTE_PKTMBUF_HEADROOM;
dma_addr = (dma_addr_t)(mb->buf_physaddr
   + RTE_PKTMBUF_HEADROOM);
rq_enet_desc_enc(rqd, dma_addr,
diff --git a/drivers/net/enic/enic_rxtx.c b/drivers/net/enic/enic_rxtx.c
index 845a8e6..50f0b28 100644
--- a/drivers/net/enic/enic_rxtx.c
+++ b/drivers/net/enic/enic_rxtx.c
@@ -300,6 +300,7 @@ enic_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
(struct cq_enet_rq_desc *)&cqd);

/* Push descriptor for newly allocated mbuf */
+   nmb->data_off = RTE_PKTMBUF_HEADROOM;
dma_addr = (dma_addr_t)(nmb->buf_physaddr +
RTE_PKTMBUF_HEADROOM);
rq_enet_desc_enc(rqd_ptr, dma_addr,
-- 
2.7.0

[dpdk-dev] [PATCH] doc: announce ABI change for mbuf structure

[Bruce Richardson]

On Tue, Jul 19, 2016 at 04:01:15PM +0200, Olivier Matz wrote:
> For 16.11, the mbuf structure will be modified implying ABI breakage.
> Some discussions already took place here:
> http://www.dpdk.org/dev/patchwork/patch/12878/
> 
> Signed-off-by: Olivier Matz 
> ---
>  doc/guides/rel_notes/deprecation.rst | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index f502f86..2245bc2 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -41,3 +41,9 @@ Deprecation Notices
>  * The mempool functions for single/multi producer/consumer are deprecated and
>will be removed in 16.11.
>It is replaced by rte_mempool_generic_get/put functions.
> +
> +* ABI changes are planned for 16.11 in the ``rte_mbuf`` structure: some
> +  fields will be reordered to facilitate the writing of ``data_off``,
> +  ``refcnt``, and ``nb_segs`` in one operation. Indeed, some platforms
> +  have an overhead if the store address is not naturally aligned. The
> +  useless ``port`` field will also be removed at the same occasion.
> -- 

Have we fully bottomed out on the mbuf changes. I'm not sure that once patches
start getting considered for merge, new opinions may come forward. For instance,
is the "port" field really "useless"?

Would it not be better to put in a less specific deprecation notice? What 
happens
if this notice goes in and the final changes are different from those called out
here?

/Bruce

[dpdk-dev] [PATCH] mempool: adjust name string size in related data types

[Zoltan Kiss]

A recent fix brought up an issue about the size of the 'name' fields:

85cf0079 mem: avoid memzone/mempool/ring name truncation

These relations should be observed:

RTE_RING_NAMESIZE <= RTE_MEMZONE_NAMESIZE - strlen(RTE_RING_MZ_PREFIX)
RTE_MEMPOOL_NAMESIZE <= RTE_RING_NAMESIZE - strlen(RTE_MEMPOOL_MZ_PREFIX)

Setting all of them to 32 hides this restriction from the application.
This patch increases the memzone string size to accomodate for these
prefixes, and the same happens with the ring name string. The ABI needs to
be broken to fix this API issue, this way doesn't break applications
previously not failing due to the truncating bug now fixed.

Signed-off-by: Zoltan Kiss 
---
 lib/librte_eal/common/include/rte_memzone.h | 2 +-
 lib/librte_mempool/rte_mempool.h| 4 +++-
 lib/librte_ring/rte_ring.h  | 5 -
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_memzone.h 
b/lib/librte_eal/common/include/rte_memzone.h
index f69b5a8..ba3a1f0 100644
--- a/lib/librte_eal/common/include/rte_memzone.h
+++ b/lib/librte_eal/common/include/rte_memzone.h
@@ -74,7 +74,7 @@ extern "C" {
  */
 struct rte_memzone {

-#define RTE_MEMZONE_NAMESIZE 32   /**< Maximum length of memory zone 
name.*/
+#define RTE_MEMZONE_NAMESIZE (32 + 6) /**< Maximum length of memory zone 
name.*/
char name[RTE_MEMZONE_NAMESIZE];  /**< Name of the memory zone. */

phys_addr_t phys_addr;/**< Start physical address. */
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 4a8fbb1..61e8d19 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -123,7 +123,9 @@ struct rte_mempool_objsz {
/**< Total size of an object (header + elt + trailer). */
 };

-#define RTE_MEMPOOL_NAMESIZE 32 /**< Maximum length of a memory pool. */
+/**< Maximum length of a memory pool's name. */
+#define RTE_MEMPOOL_NAMESIZE (RTE_RING_NAMESIZE - \
+ sizeof(RTE_MEMPOOL_MZ_PREFIX) + 1)
 #define RTE_MEMPOOL_MZ_PREFIX "MP_"

 /* "MP_" */
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index eb45e41..d6185de 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -100,6 +100,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 

 #define RTE_TAILQ_RING_NAME "RTE_RING"

@@ -126,8 +127,10 @@ struct rte_ring_debug_stats {
 } __rte_cache_aligned;
 #endif

-#define RTE_RING_NAMESIZE 32 /**< The maximum length of a ring name. */
 #define RTE_RING_MZ_PREFIX "RG_"
+/**< The maximum length of a ring name. */
+#define RTE_RING_NAMESIZE (RTE_MEMZONE_NAMESIZE - \
+  sizeof(RTE_RING_MZ_PREFIX) + 1)

 #ifndef RTE_RING_PAUSE_REP_COUNT
 #define RTE_RING_PAUSE_REP_COUNT 0 /**< Yield after pause num of times, no 
yield
-- 
1.9.1

[dpdk-dev] [PATCH] mempool: fix lack of free() registration

[Zoltan Kiss]

The new mempool handler interface forgets to register the free() function
of the ops. Introduced in this patch:

449c49b9 mempool: support handler operations

Signed-off-by: Zoltan Kiss 
---
 lib/librte_mempool/rte_mempool_ops.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_mempool/rte_mempool_ops.c 
b/lib/librte_mempool/rte_mempool_ops.c
index fd0b64c..5f24de2 100644
--- a/lib/librte_mempool/rte_mempool_ops.c
+++ b/lib/librte_mempool/rte_mempool_ops.c
@@ -81,6 +81,7 @@ rte_mempool_register_ops(const struct rte_mempool_ops *h)
ops = &rte_mempool_ops_table.ops[ops_index];
snprintf(ops->name, sizeof(ops->name), "%s", h->name);
ops->alloc = h->alloc;
+   ops->free = h->free;
ops->enqueue = h->enqueue;
ops->dequeue = h->dequeue;
ops->get_count = h->get_count;
-- 
1.9.1

[dpdk-dev] [RFC PATCH] i40: remove weak version of i40e_rx_vec_dev_conf_condition_check()

[Zoltan Kiss]

Using weak symbols have a few issues with static linking:

- normally the linker searches the .o files already linked, if your weak
  one is there, it won't check if there is a strong version
- unless the symbol is directly referred, but it's not the right thing to
  rely on
- or --whole-archive specified in the command line, which pulls in a lot
  of unwanted stuff
- whole-archive also makes libtool dropping the library from the command
  line, which is what should happen with dynamic linking, but not with
  static (observed on Ubuntu 14.04). This is an important bug if you
  build a static library depending on DPDK

This patch merges the two version and make the behaviour rely on the
config.

If we can agree in the concept, I can send a series to fix this for the
other weak functions.

Signed-off-by: Zoltan Kiss 
---
 drivers/net/i40e/i40e_rxtx.c | 36 +++-
 drivers/net/i40e/i40e_rxtx_vec.c | 36 
 2 files changed, 35 insertions(+), 37 deletions(-)

diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index d3cfb98..ad34d3a 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -3278,10 +3278,44 @@ i40e_set_tx_function(struct rte_eth_dev *dev)
 }

 /* Stubs needed for linkage when CONFIG_RTE_I40E_INC_VECTOR is set to 'n' */
-int __attribute__((weak))
+int __attribute__((cold))
 i40e_rx_vec_dev_conf_condition_check(struct rte_eth_dev __rte_unused *dev)
 {
+#ifndef RTE_LIBRTE_I40E_INC_VECTOR
return -1;
+#else
+#ifndef RTE_LIBRTE_IEEE1588
+   struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
+   struct rte_fdir_conf *fconf = &dev->data->dev_conf.fdir_conf;
+
+   /* need SSE4.1 support */
+   if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_SSE4_1))
+   return -1;
+
+#ifndef RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE
+   /* whithout rx ol_flags, no VP flag report */
+   if (rxmode->hw_vlan_strip != 0 ||
+   rxmode->hw_vlan_extend != 0)
+   return -1;
+#endif /* RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE */
+
+   /* no fdir support */
+   if (fconf->mode != RTE_FDIR_MODE_NONE)
+   return -1;
+
+/* - no csum error report support
+* - no header split support
+*/
+   if (rxmode->hw_ip_checksum == 1 ||
+   rxmode->header_split == 1)
+   return -1;
+
+   return 0;
+#else
+   RTE_SET_USED(dev);
+   return -1;
+#endif /* RTE_LIBRTE_IEEE1588 */
+#endif /* RTE_LIBRTE_I40E_INC_VECTOR */
 }

 uint16_t __attribute__((weak))
diff --git a/drivers/net/i40e/i40e_rxtx_vec.c b/drivers/net/i40e/i40e_rxtx_vec.c
index 05cb415..983b2c0 100644
--- a/drivers/net/i40e/i40e_rxtx_vec.c
+++ b/drivers/net/i40e/i40e_rxtx_vec.c
@@ -723,39 +723,3 @@ i40e_txq_vec_setup(struct i40e_tx_queue __rte_unused *txq)
 {
return 0;
 }
-
-int __attribute__((cold))
-i40e_rx_vec_dev_conf_condition_check(struct rte_eth_dev *dev)
-{
-#ifndef RTE_LIBRTE_IEEE1588
-   struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
-   struct rte_fdir_conf *fconf = &dev->data->dev_conf.fdir_conf;
-
-   /* need SSE4.1 support */
-   if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_SSE4_1))
-   return -1;
-
-#ifndef RTE_LIBRTE_I40E_RX_OLFLAGS_ENABLE
-   /* whithout rx ol_flags, no VP flag report */
-   if (rxmode->hw_vlan_strip != 0 ||
-   rxmode->hw_vlan_extend != 0)
-   return -1;
-#endif
-
-   /* no fdir support */
-   if (fconf->mode != RTE_FDIR_MODE_NONE)
-   return -1;
-
-/* - no csum error report support
-* - no header split support
-*/
-   if (rxmode->hw_ip_checksum == 1 ||
-   rxmode->header_split == 1)
-   return -1;
-
-   return 0;
-#else
-   RTE_SET_USED(dev);
-   return -1;
-#endif
-}
-- 
1.9.1

[dpdk-dev] [PATCH] doc: fix vhost setup in tep-termination app guide

[Kavanagh, Mark B]

Please disregard this patch - I'll push it again, this time with the correct 
subject line format.

Apologies - Mark.

>
>- Fix vhost setup flags
>- Add minor edits to improve readability and consistency
>
>Signed-off-by: Mark Kavanagh 
>---
> doc/guides/sample_app_ug/tep_termination.rst | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
> mode change 100644 => 100755 doc/guides/sample_app_ug/tep_termination.rst
>
>diff --git a/doc/guides/sample_app_ug/tep_termination.rst
>b/doc/guides/sample_app_ug/tep_termination.rst
>old mode 100644
>new mode 100755
>index 2d86a03..c3d1e97
>--- a/doc/guides/sample_app_ug/tep_termination.rst
>+++ b/doc/guides/sample_app_ug/tep_termination.rst
>@@ -59,8 +59,8 @@ This allows network isolation, QOS, etc to be provided on a 
>per client
>basis.
> In a typical setup, the network overlay tunnel is terminated at the 
> Virtual/Tunnel End Point
>(VEP/TEP).
> The TEP is normally located at the physical host level ideally in the 
> software switch.
> Due to processing constraints and the inevitable bottleneck that the switch
>-becomes the ability to offload overlay support features becomes an important 
>requirement.
>-Intel? XL710 10/40 G Ethernet network card provides hardware filtering
>+becomes, the ability to offload overlay support features becomes an important 
>requirement.
>+Intel? XL710 10/40 Gigabit Ethernet network card provides hardware filtering
> and offload capabilities to support overlay networks implementations such as 
> MAC in UDP and
>MAC in GRE.
>
> Sample Code Overview
>@@ -131,14 +131,14 @@ Compiling the Sample Code
>
> .. code-block:: console
>
>-CONFIG_RTE_LIBRTE_VHOST=n
>+CONFIG_RTE_LIBRTE_VHOST=y
>
> vhost user is turned on by default in the configure file 
> config/common_linuxapp.
> To enable vhost cuse, disable vhost user.
>
> .. code-block:: console
>
>-CONFIG_RTE_LIBRTE_VHOST_USER=y
>+CONFIG_RTE_LIBRTE_VHOST_USER=n
>
>  After vhost is enabled and the implementation is selected, build the 
> vhost library.
>
>--
>1.9.3

[dpdk-dev] [PATCH] rte_delay_us can be replaced with user function

[Thomas Monjalon]

Hi,

2016-07-19 14:42, jozmarti at cisco.com:
> when running single-core, some drivers tend to call rte_delay_us for a
> long time, and that is causing packet drops.
> Attached patch introduces 2 new functions:
> 
> void rte_delay_us_callback_register(void(*userfunc)(unsigned));
> void rte_delay_us_callback_unregister(void);
> 
> First one replaces rte_delay_us with userfunc and second one restores
> original rte_delay_us.

I think we could avoid the function unregister by exporting the
default implementation (let's say rte_delay_us_block).


> +REGISTER_TEST_COMMAND(user_delay_us, test_user_delay_us);

Thanks for providing an unit test.


> --- a/lib/librte_eal/common/eal_common_timer.c
> +++ b/lib/librte_eal/common/eal_common_timer.c
>  void
>  rte_delay_us(unsigned us)
>  {
> + if (unlikely(rte_delay_us_override != NULL))
> + {
> + rte_delay_us_override(us);
> + return;
> + }

Why not always call the registered callback and initialize it
to the default implementation (maybe using a constructor)?

[dpdk-dev] SRIOV hot unplug

[Declan Doherty]

On 07/19/2016 12:18 PM, Eli Britstein wrote:
>
>
>> -Original Message-
>> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
>> Sent: Tuesday, 19 July, 2016 5:49 AM
>> To: Eli Britstein; dev at dpdk.org
>> Cc: Iremonger, Bernard
>> Subject: Re: [dpdk-dev] SRIOV hot unplug
>>
>> Hi Eli,
>>
>> On 2016/07/18 17:47, Eli Britstein wrote:
>>> Hi Bernard,
>>>
>>> Thank you for your answer.
>>> However, to do this, I have to have some communication protocol to the
>> VM's application in order for it to do this sequence and acknowledge that it 
>> is
>> now safe to proceed with detaching the device.
>>> This implies some kind of integration from the host side, which I would like
>> to avoid.
>>
>> I guess you should have some kind of communication channel to notice the
>> hotpluging events from host to VM.
> [Eli Britstein]
> In order just to notice the hotplugging events inside the VM, I can use add 
> some udev action in the VM, in /etc/udev/rules.d/XXX
> However, those are asynchronous events. The host proceeds with unplugging 
> without waiting for the VM to acknowledge it.
>
>>
>>> Do you think might there be any other way for the application to handle
>> such event in a smooth way?
>>
>> So far, I guess having one more virtio-net device will be easiest way.
> [Eli Britstein]
> Could you please elaborate your meaning? How do you mean to use this extra 
> virtio-net device?
>
> To clarify: I would like to have my bond device automatically set the vNIC as 
> its primary, and close/remove the VF before it is unplugged.
>
> Thanks,
> Eli

The only that I can think of which would allow bonding to support this 
is if you could force a link down notification to the VF. The bonding 
driver should automatically then fail over to the vNIC, but again this 
is asynchronous event so I'm not sure how you could confirm this action 
from the host other than by monitoring traffic?

Also I don't know if the DPDK environment has been tested to support the 
removal of dynamic hot-plugging you are suggesting via the udev action. 
There are no hooks that I'm aware of which would detect that the PCI 
device is no longer available and then clean the resources away in DPDK.

>

>

Also could you please drop the footer/disclaimer on replies to the 
mailing list (see http://dpdk.org/ml)

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

[Adrien Mazarguil]

On Tue, Jul 19, 2016 at 08:11:48AM +, Lu, Wenzhuo wrote:
> Hi Adrien,
> Thanks for your clarification.  Most of my questions are clear, but still 
> something may need to be discussed, comment below.

Hi Wenzhuo,

Please see below.

[...]
> > > > Requirements for a new API:
> > > >
> > > > - Flexible and extensible without causing API/ABI problems for existing
> > > >   applications.
> > > > - Should be unambiguous and easy to use.
> > > > - Support existing filtering features and actions listed in `Filter 
> > > > types`_.
> > > > - Support packet alteration.
> > > > - In case of overlapping filters, their priority should be well 
> > > > documented.
> > > Does that mean we don't guarantee the consistent of priority? The 
> > > priority can
> > be different on different NICs. So the behavior of the actions  can be 
> > different.
> > Right?
> > 
> > No, the intent is precisely to define what happens in order to get a 
> > consistent
> > result across different devices, and document cases with undefined behavior.
> > There must be no room left for interpretation.
> > 
> > For example, the API must describe what happens when two overlapping filters
> > (e.g. one matching an Ethernet header, another one matching an IP header)
> > match a given packet at a given priority level.
> > 
> > It is documented in section 4.1.1 (priorities) as "undefined behavior".
> > Applications remain free to do it and deal with consequences, at least they 
> > know
> > they cannot expect a consistent outcome, unless they use different priority
> > levels for both rules, see also 4.4.5 (flow rules priority).
> > 
> > > Seems the users still need to aware the some details of the HW? Do we need
> > to add the negotiation for the priority?
> > 
> > Priorities as defined in this document may not be directly mappable to HW
> > capabilities (e.g. HW does not support enough priorities, or that some 
> > corner
> > case make them not work as described), in which case the PMD may choose to
> > simulate priorities (again 4.4.5), as long as the end result follows the
> > specification.
> > 
> > So users must not be aware of some HW details, the PMD does and must
> > perform the needed workarounds to suit their expectations. Users may only be
> > impacted by errors while attempting to create rules that are either 
> > unsupported
> > or would cause them (or existing rules) to diverge from the spec.
> The problem is sometime the priority of the filters is fixed according to
> > HW's implementation. For example, on ixgbe, n-tuple has a higher
> > priority than flow director.

As a side note I did not know that N-tuple had a higher priority than flow
director on ixgbe, priorities among filter types do not seem to be
documented at all in DPDK. This is one of the reasons I think we need a
generic API to handle flow configuration.

So, today an application cannot combine N-tuple and FDIR flow rules and get
a reliable outcome, unless it is designed for specific devices with a known
behavior.

> What's the right behavior of PMD if APP want to create a flow director rule 
> which has a higher or even equal priority than an existing n-tuple rule? 
> Should PMD return fail? 

First remember applications only deal with the generic API, PMDs are
responsible for choosing the most appropriate HW implementation to use
according to the requested flow rules (FDIR, N-tuple or anything else).

For the specific case of FDIR vs N-tuple, if the underlying HW supports both
I do not see why the PMD would create a N-tuple rule. Doesn't FDIR support
everything N-tuple can do and much more?

Assuming such a thing happened anyway, that the PMD had to create a rule
using a high priority filter type and that the application requests the
creation of a rule that can only be done using a lower priority filter type,
but also requested a higher priority for that rule, then yes, it should
obviously fail.

That is, unless the PMD can perform some kind of workaround to have both.

> If so, do we need more fail reasons? According to this RFC, I think we need 
> return " EEXIST: collision with an existing rule. ", but it's not very clear, 
> APP doesn't know the problem is priority, maybe more detailed reason is 
> helpful.

Possibly, I've defined a basic set of errors, there are quite a number of
errno values to choose from. However I think we should not define too many
values. In my opinion the basic set covers every possible failure:

- EINVAL: invalid format, rule is broken or cannot be understood by the PMD
  anyhow.

- ENOTSUP: pattern/actions look fine but something in the requested rule is
  not supported and thus cannot be applied.

- EEXIST: pattern/actions are fine and could have been applied if only some
  other rule did not prevent the PMD to do it (I see it as the closest thing
  to "ETOOBAD" which unfortunately does not exist).

- ENOMEM: like EEXIST, except it is due to the lack of resources not because
  of another rule. I wasn't sure which of ENOMEM or ENOSPC 

[dpdk-dev] [PATCH] virtio: fix packet corruption

[Olivier Matz]

Hi Jianfeng,

On 07/19/2016 03:03 PM, Tan, Jianfeng wrote:
> Hi Oliver,
> 
>> -Original Message-
>> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
>> Sent: Tuesday, July 19, 2016 8:32 PM
>> To: dev at dpdk.org; Tan, Jianfeng; Xie, Huawei; yuanhan.liu at 
>> linux.intel.com
>> Subject: [PATCH] virtio: fix packet corruption
>>
>> The support of virtio-user changed the way the mbuf dma address is
>> retrieved, using a physical address in case of virtio-pci and a virtual
>> address in case of virtio-user.
>>
>> This change introduced some possible memory corruption in packets,
>> replacing:
>>   m->buf_physaddr + RTE_PKTMBUF_HEADROOM
>> by:
>>   m->buf_physaddr + m->data_off (through a macro)
>>
>> This patch fixes this issue, restoring the original behavior.
> 
> Could you be more specific on why we cannot use m->data_off here?

There is no guarantee that m->data_off == RTE_PKTMBUF_HEADROOM here as
virtqueue_enqueue_recv_refill() is called on a mbuf that is just
allocated with rte_mbuf_raw_alloc(). An alternative would be to set
data_off to RTE_PKTMBUF_HEADROOM, but as it's a fix and we are close to
the release, I prefered to restore the initial behavior.

I did not include the test plan because it relies on patch that are not
submitted yet (offload patches, they will be upstreamed very soon). It
is a quite simple test case with testpmd.

Regards,
Olivier

[dpdk-dev] [PATCH] doc: announce ABI change for mbuf structure

[Richardson, Bruce]

> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, July 19, 2016 4:04 PM
> To: Richardson, Bruce 
> Cc: dev at dpdk.org; jerin.jacob at caviumnetworks.com;
> thomas.monjalon at 6wind.com
> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for mbuf
> structure
> 
> Hi Bruce,
> 
> On 07/19/2016 04:40 PM, Bruce Richardson wrote:
> > On Tue, Jul 19, 2016 at 04:01:15PM +0200, Olivier Matz wrote:
> >> For 16.11, the mbuf structure will be modified implying ABI breakage.
> >> Some discussions already took place here:
> >> http://www.dpdk.org/dev/patchwork/patch/12878/
> >>
> >> Signed-off-by: Olivier Matz 
> >> ---
> >>  doc/guides/rel_notes/deprecation.rst | 6 ++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/doc/guides/rel_notes/deprecation.rst
> >> b/doc/guides/rel_notes/deprecation.rst
> >> index f502f86..2245bc2 100644
> >> --- a/doc/guides/rel_notes/deprecation.rst
> >> +++ b/doc/guides/rel_notes/deprecation.rst
> >> @@ -41,3 +41,9 @@ Deprecation Notices
> >>  * The mempool functions for single/multi producer/consumer are
> deprecated and
> >>will be removed in 16.11.
> >>It is replaced by rte_mempool_generic_get/put functions.
> >> +
> >> +* ABI changes are planned for 16.11 in the ``rte_mbuf`` structure:
> >> +some
> >> +  fields will be reordered to facilitate the writing of
> >> +``data_off``,
> >> +  ``refcnt``, and ``nb_segs`` in one operation. Indeed, some
> >> +platforms
> >> +  have an overhead if the store address is not naturally aligned.
> >> +The
> >> +  useless ``port`` field will also be removed at the same occasion.
> >> --
> >
> > Have we fully bottomed out on the mbuf changes. I'm not sure that once
> > patches start getting considered for merge, new opinions may come
> > forward. For instance, is the "port" field really "useless"?
> >
> > Would it not be better to put in a less specific deprecation notice?
> > What happens if this notice goes in and the final changes are
> > different from those called out here?
> 
> Yes, you are right. What about the following text?
> 
> ABI changes are planned for 16.11 in the ``rte_mbuf`` structure: some
> fields may be reordered to facilitate the writing of ``data_off``,
> ``refcnt``, and ``nb_segs`` in one operation. Indeed, some platforms have
> an overhead if the store address is not naturally aligned. The ``port``
> field may also be removed at the same occasion.
> 
Better. Two suggestions:
1. change "Indeed" to "because" and join the sentences.
2. change the last sentence to be even more general: "Other mbuf fields, such 
as the port field, may be moved or removed as part of this mbuf work".

/Bruce

[dpdk-dev] [PATCH] eal: fix rte_intr_dp_is_en() check

[Yong Wang]

> On Jul 18, 2016, at 2:21 AM, Thomas Monjalon  
> wrote:
> 
> Hi Yong,
> 
> I think the interrupt management should be simpler.
> If you want to invest some time to rework this API, you
> are very welcome.
> 
> 
> 2016-07-18 14:19, Liang, Cunming:
>> Hi Yong,
>> 
>> rte_intr_dp_is_en() returns true when rte_intr_efd_enable() (the way to 
>> enable data-path interrupt) sets a number of event fds.
>> In this case, "intr_conf.rxq=1" configuration causes "nb_efd=1". The 
>> value comes from RTE_MIN($nb_efd, 1) from data-path, but not from link 
>> event.
>> Per link event, you shouldn't use rte_intr_dp_is_en() as the indication.
>> As igb_uio only has a single vector, when the conflict(both intr_rxq and 
>> intr_lsc turn on) happens, the intr_rxq has high priority than intr_lsc 
>> as default PMD behavior.
>> Reference as PG 3.1.9 note in 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_doc_guides_prog-5Fguide_env-5Fabstraction-5Flayer.html&d=CwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=44mSO5N5yEs4CeCdtQE0xt0F7J0p67_mApYVAzyYms0&m=xFO005GdZMA9a6IC2kvhKYaXW7Rhl3dlcom5HfOSy2g&s=yERFYJTe6TBWFCltmR3xikmxkLKutbot5BfFxK30tZ0&e=
>>  
>> 
>> Regards,
>> Cunning

Thanks Cunming and Thomas for the feedback.  I agree with Thomas that the rx 
queue interrupt APIs could be simplified and it?s not clear to me if the API 
user needs to be concerned about rte_intr_cap_multiple(), 
rte_intr_allow_others(), rte_intr_dp_is_en(), etc. if all he needs is to enable 
intr with certain # of vectors and map the vectors to either efds or callbacks. 
 I feel it?s simpler just returning the number of vectors the system can 
support if it cannot satisfy nb_efd vectors and let the application decide how 
should this be handled. The link event and rxq interrupt init/uninit path also 
looks quite different and some unification will be helpful.

The API documentation can also use some more clarification.  For example, 
without reading the program guide, it?s easy to miss the fact that when the 
device is bound to UIO, the implementation will try to enable rxq instead of 
lsc when both intr_conf.lsc and intr_conf.rxq is set to 1. I can imagine there 
are cases where an application would prefer to enable link event instead of rxq 
interrupt in such cases and currently there is no easy way to achieve that.  Or 
is there any particular reason such a preference is chosen?

>> 
>> On 7/15/2016 8:36 AM, Yong Wang wrote:
>>> When binding a device to igb_uio with intr_conf.rxq set to 1, nb_efd
>>> is 1 (for link event) but rte_intr_dp_is_en() will still return true.
>>> rte_intr_dp_is_en() should also consider intr_handle type in addition
>>> to nb_efd.
>>> 
>>> Signed-off-by: Yong Wang 
> 

[dpdk-dev] [PATCH] rte_delay_us can be replaced with user function

[jozma...@cisco.com]

From: Jozef Martiniak 

when running single-core, some drivers tend to call rte_delay_us for a
long time, and that is causing packet drops.
Attached patch introduces 2 new functions:

void rte_delay_us_callback_register(void(*userfunc)(unsigned));
void rte_delay_us_callback_unregister(void);

First one replaces rte_delay_us with userfunc and second one restores
original rte_delay_us.
Test user_delay_us is included.

Signed-off-by: Jozef Martiniak 
---
 app/test/test_cycles.c | 39 ++
 lib/librte_eal/common/eal_common_timer.c   | 19 +++
 lib/librte_eal/common/include/generic/rte_cycles.h | 13 
 3 files changed, 71 insertions(+)

diff --git a/app/test/test_cycles.c b/app/test/test_cycles.c
index f6c043a..2b44a53 100644
--- a/app/test/test_cycles.c
+++ b/app/test/test_cycles.c
@@ -90,3 +90,42 @@ test_cycles(void)
 }

 REGISTER_TEST_COMMAND(cycles_autotest, test_cycles);
+
+/*
+ * rte_delay_us_callback test
+ *
+ * - check if callback is correctly registered/unregistered
+ *
+ */
+
+static int pattern;
+static void my_rte_delay_us(unsigned us)
+{
+pattern += us;
+}
+
+static int
+test_user_delay_us(void)
+{
+pattern = 0;
+
+rte_delay_us_callback_register(my_rte_delay_us);
+
+rte_delay_us(2);
+if (pattern != 2)
+return -1;
+
+rte_delay_us(3);
+if (pattern != 5)
+return -1;
+
+rte_delay_us_callback_unregister();
+
+rte_delay_us(3);
+if (pattern != 5)
+return -1;
+
+return 0;
+}
+
+REGISTER_TEST_COMMAND(user_delay_us, test_user_delay_us);
diff --git a/lib/librte_eal/common/eal_common_timer.c 
b/lib/librte_eal/common/eal_common_timer.c
index c4227cd..a982562 100644
--- a/lib/librte_eal/common/eal_common_timer.c
+++ b/lib/librte_eal/common/eal_common_timer.c
@@ -47,9 +47,18 @@
 /* The frequency of the RDTSC timer resolution */
 static uint64_t eal_tsc_resolution_hz;

+/* User function which replaces rte_delay_us function */
+static void (*rte_delay_us_override)(unsigned) = NULL;
+
 void
 rte_delay_us(unsigned us)
 {
+   if (unlikely(rte_delay_us_override != NULL))
+   {
+   rte_delay_us_override(us);
+   return;
+   }
+
const uint64_t start = rte_get_timer_cycles();
const uint64_t ticks = (uint64_t)us * rte_get_timer_hz() / 1E6;
while ((rte_get_timer_cycles() - start) < ticks)
@@ -84,3 +93,13 @@ set_tsc_freq(void)
RTE_LOG(DEBUG, EAL, "TSC frequency is ~%" PRIu64 " KHz\n", freq / 1000);
eal_tsc_resolution_hz = freq;
 }
+
+void rte_delay_us_callback_register(void (*userfunc)(unsigned))
+{
+rte_delay_us_override = userfunc;
+}
+
+void rte_delay_us_callback_unregister(void)
+{
+rte_delay_us_override = NULL;
+}
diff --git a/lib/librte_eal/common/include/generic/rte_cycles.h 
b/lib/librte_eal/common/include/generic/rte_cycles.h
index 8cc21f2..274f798 100644
--- a/lib/librte_eal/common/include/generic/rte_cycles.h
+++ b/lib/librte_eal/common/include/generic/rte_cycles.h
@@ -202,4 +202,17 @@ rte_delay_ms(unsigned ms)
rte_delay_us(ms * 1000);
 }

+/**
+ * Replace rte_delay_us with user defined function.
+ *
+ * @param userfunc
+ *   User function which replaces rte_delay_us.
+ */
+void rte_delay_us_callback_register(void(*userfunc)(unsigned));
+
+/**
+ * Unregister user callback function. Restores original rte_delay_us.
+ */
+void rte_delay_us_callback_unregister(void);
+
 #endif /* _RTE_CYCLES_H_ */
-- 
2.1.4

[dpdk-dev] [PATCH v3] mk: fix FreeBSD build

[Sergio Gonzalez Monroy]

The sed syntax of '0,/regexp/' is GNU specific and fails with
non GNU sed in FreeBSD.

To solve the issue we can use awk instead to remove duplicates.

The awk script basically keeps the last config value, while
maintaining order and comments from original config file.

Fixes: b2063f104db7 ("mk: filter duplicate configuration entries")

Signed-off-by: Sergio Gonzalez Monroy 
---
 mk/rte.sdkconfig.mk | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
index e93237f..5c94edf 100644
--- a/mk/rte.sdkconfig.mk
+++ b/mk/rte.sdkconfig.mk
@@ -88,11 +88,13 @@ $(RTE_OUTPUT)/.config: $(RTE_CONFIG_TEMPLATE) FORCE | 
$(RTE_OUTPUT)
$(CPP) -undef -P -x assembler-with-cpp \
-ffreestanding \
-o $(RTE_OUTPUT)/.config_tmp $(RTE_CONFIG_TEMPLATE) ; \
-   for config in $$(grep -v "^#" $(RTE_OUTPUT)/.config_tmp | cut 
-d"=" -f1 | sort | uniq -d); do \
-   while [ $$(grep "^$${config}=" 
$(RTE_OUTPUT)/.config_tmp -c ) -gt 1 ]; do \
-   sed -i "0,/^$${config}=/{//d}" 
$(RTE_OUTPUT)/.config_tmp; \
-   done; \
-   done; \
+   config=$$(cat $(RTE_OUTPUT)/.config_tmp) ; \
+   echo "$$config" | awk -F '=' 'BEGIN {i=1} \
+   /^#/ {pos[i++]=$$0} \
+   !/^#/ {if (!s[$$1]) {pos[i]=$$0; s[$$1]=i++} \
+   else {pos[s[$$1]]=$$0}} END \
+   {for (j=1; j $(RTE_OUTPUT)/.config_tmp ; \
if ! cmp -s $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config; 
then \
cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config ; \
cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config.orig 
; \
-- 
2.4.11

[dpdk-dev] SRIOV hot unplug

[Eli Britstein]

> -Original Message-
> From: Declan Doherty [mailto:declan.doherty at intel.com]
> Sent: Tuesday, 19 July, 2016 5:15 PM
> To: Eli Britstein; Tetsuya Mukawa; dev at dpdk.org
> Cc: Iremonger, Bernard
> Subject: Re: [dpdk-dev] SRIOV hot unplug
>
> On 07/19/2016 12:18 PM, Eli Britstein wrote:
> >
> >
> >> -Original Message-
> >> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> >> Sent: Tuesday, 19 July, 2016 5:49 AM
> >> To: Eli Britstein; dev at dpdk.org
> >> Cc: Iremonger, Bernard
> >> Subject: Re: [dpdk-dev] SRIOV hot unplug
> >>
> >> Hi Eli,
> >>
> >> On 2016/07/18 17:47, Eli Britstein wrote:
> >>> Hi Bernard,
> >>>
> >>> Thank you for your answer.
> >>> However, to do this, I have to have some communication protocol to
> >>> the
> >> VM's application in order for it to do this sequence and acknowledge
> >> that it is now safe to proceed with detaching the device.
> >>> This implies some kind of integration from the host side, which I
> >>> would like
> >> to avoid.
> >>
> >> I guess you should have some kind of communication channel to notice
> >> the hotpluging events from host to VM.
> > [Eli Britstein]
> > In order just to notice the hotplugging events inside the VM, I can
> > use add some udev action in the VM, in /etc/udev/rules.d/XXX However,
> those are asynchronous events. The host proceeds with unplugging without
> waiting for the VM to acknowledge it.
> >
> >>
> >>> Do you think might there be any other way for the application to
> >>> handle
> >> such event in a smooth way?
> >>
> >> So far, I guess having one more virtio-net device will be easiest way.
> > [Eli Britstein]
> > Could you please elaborate your meaning? How do you mean to use this
> extra virtio-net device?
> >
> > To clarify: I would like to have my bond device automatically set the vNIC 
> > as
> its primary, and close/remove the VF before it is unplugged.
> >
> > Thanks,
> > Eli
>
> The only that I can think of which would allow bonding to support this is if 
> you
> could force a link down notification to the VF. The bonding driver should
> automatically then fail over to the vNIC, but again this is asynchronous event
> so I'm not sure how you could confirm this action from the host other than by
> monitoring traffic?
[Eli Britstein]
How can I force link down notification to the VF?

>
> Also I don't know if the DPDK environment has been tested to support the
> removal of dynamic hot-plugging you are suggesting via the udev action.
> There are no hooks that I'm aware of which would detect that the PCI device
> is no longer available and then clean the resources away in DPDK.
>
> >
> 
> >
>
> Also could you please drop the footer/disclaimer on replies to the
> mailing list (see http://dpdk.org/ml)

-
This email and any files transmitted and/or attachments with it are 
confidential and proprietary information of
Toga Networks Ltd., and intended solely for the use of the individual or entity 
to whom they are addressed.
If you have received this email in error please notify the system manager. This 
message contains confidential
information of Toga Networks Ltd., and is intended only for the individual 
named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail. Please 
notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on
the contents of this information is strictly prohibited.

[dpdk-dev] [PATCH] virtio: fix packet corruption

[Olivier Matz]

The support of virtio-user changed the way the mbuf dma address is
retrieved, using a physical address in case of virtio-pci and a virtual
address in case of virtio-user.

This change introduced some possible memory corruption in packets,
replacing:
  m->buf_physaddr + RTE_PKTMBUF_HEADROOM
by:
  m->buf_physaddr + m->data_off (through a macro)

This patch fixes this issue, restoring the original behavior.

By the way, it also rework the macros, adding a "VIRTIO_" prefix and
API comments.

Fixes: f24f8f9fee8a ("net/virtio: allow virtual address to fill vring 
descriptors")

Signed-off-by: Olivier Matz 
---
 drivers/net/virtio/virtio_ethdev.c  |  2 +-
 drivers/net/virtio/virtio_rxtx.c|  5 +++--
 drivers/net/virtio/virtio_rxtx_simple.c | 13 +++--
 drivers/net/virtio/virtqueue.h  | 25 +
 4 files changed, 28 insertions(+), 17 deletions(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 850e3ba..fcc996e 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -454,7 +454,7 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,

/* For virtio-user case (that is when dev->pci_dev is NULL), we use
 * virtual address. And we need properly set _offset_, please see
-* MBUF_DATA_DMA_ADDR in virtqueue.h for more information.
+* VIRTIO_MBUF_DATA_DMA_ADDR in virtqueue.h for more information.
 */
if (dev->pci_dev)
vq->offset = offsetof(struct rte_mbuf, buf_physaddr);
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index a27208e..9aba044 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -193,7 +193,8 @@ virtqueue_enqueue_recv_refill(struct virtqueue *vq, struct 
rte_mbuf *cookie)

start_dp = vq->vq_ring.desc;
start_dp[idx].addr =
-   MBUF_DATA_DMA_ADDR(cookie, vq->offset) - hw->vtnet_hdr_size;
+   VIRTIO_MBUF_ADDR(cookie, vq) +
+   RTE_PKTMBUF_HEADROOM - hw->vtnet_hdr_size;
start_dp[idx].len =
cookie->buf_len - RTE_PKTMBUF_HEADROOM + hw->vtnet_hdr_size;
start_dp[idx].flags =  VRING_DESC_F_WRITE;
@@ -265,7 +266,7 @@ virtqueue_enqueue_xmit(struct virtnet_tx *txvq, struct 
rte_mbuf *cookie,
}

do {
-   start_dp[idx].addr  = MBUF_DATA_DMA_ADDR(cookie, vq->offset);
+   start_dp[idx].addr  = VIRTIO_MBUF_DATA_DMA_ADDR(cookie, vq);
start_dp[idx].len   = cookie->data_len;
start_dp[idx].flags = cookie->next ? VRING_DESC_F_NEXT : 0;
idx = start_dp[idx].next;
diff --git a/drivers/net/virtio/virtio_rxtx_simple.c 
b/drivers/net/virtio/virtio_rxtx_simple.c
index d8fcc15..6517aa8 100644
--- a/drivers/net/virtio/virtio_rxtx_simple.c
+++ b/drivers/net/virtio/virtio_rxtx_simple.c
@@ -80,8 +80,9 @@ virtqueue_enqueue_recv_refill_simple(struct virtqueue *vq,
vq->sw_ring[desc_idx] = cookie;

start_dp = vq->vq_ring.desc;
-   start_dp[desc_idx].addr = MBUF_DATA_DMA_ADDR(cookie, vq->offset) -
- vq->hw->vtnet_hdr_size;
+   start_dp[desc_idx].addr =
+   VIRTIO_MBUF_ADDR(cookie, vq) +
+   RTE_PKTMBUF_HEADROOM - vq->hw->vtnet_hdr_size;
start_dp[desc_idx].len = cookie->buf_len -
RTE_PKTMBUF_HEADROOM + vq->hw->vtnet_hdr_size;

@@ -120,8 +121,8 @@ virtio_rxq_rearm_vec(struct virtnet_rx *rxvq)
*(uint64_t *)p = rxvq->mbuf_initializer;

start_dp[i].addr =
-   MBUF_DATA_DMA_ADDR(sw_ring[i], vq->offset) -
-   vq->hw->vtnet_hdr_size;
+   VIRTIO_MBUF_ADDR(sw_ring[i], vq) +
+   RTE_PKTMBUF_HEADROOM - vq->hw->vtnet_hdr_size;
start_dp[i].len = sw_ring[i]->buf_len -
RTE_PKTMBUF_HEADROOM + vq->hw->vtnet_hdr_size;
}
@@ -371,7 +372,7 @@ virtio_xmit_pkts_simple(void *tx_queue, struct rte_mbuf 
**tx_pkts,
vq->vq_descx[desc_idx + i].cookie = tx_pkts[i];
for (i = 0; i < nb_tail; i++) {
start_dp[desc_idx].addr =
-   MBUF_DATA_DMA_ADDR(*tx_pkts, vq->offset);
+   VIRTIO_MBUF_DATA_DMA_ADDR(*tx_pkts, vq);
start_dp[desc_idx].len = (*tx_pkts)->pkt_len;
tx_pkts++;
desc_idx++;
@@ -383,7 +384,7 @@ virtio_xmit_pkts_simple(void *tx_queue, struct rte_mbuf 
**tx_pkts,
vq->vq_descx[desc_idx + i].cookie = tx_pkts[i];
for (i = 0; i < nb_commit; i++) {
start_dp[desc_idx].addr =
-   MBUF_DATA_DMA_ADDR(*tx_pkts, vq->offset);
+   VIRTIO_MBUF_DATA_DMA_ADDR(*tx_pkts, vq);
start_dp[desc_idx].len = (*tx_pkts)->pkt_len;

[dpdk-dev] [PATCH v4 2/2] doc: add live migration virtio sriov image

[Iremonger, Bernard]

Hi John,

> -Original Message-
> From: Mcnamara, John
> Sent: Tuesday, July 19, 2016 3:09 PM
> To: Iremonger, Bernard ; dev at dpdk.org
> Cc: Liu, Yong ; Xu, Qian Q ;
> yuanhan.liu at linux.intel.com
> Subject: RE: [PATCH v4 2/2] doc: add live migration virtio sriov image
> 
> 
> 
> > -Original Message-
> > From: Iremonger, Bernard
> > Sent: Monday, July 18, 2016 11:17 AM
> > To: Mcnamara, John ; dev at dpdk.org
> > Cc: Liu, Yong ; Xu, Qian Q ;
> > yuanhan.liu at linux.intel.com; Iremonger, Bernard
> > 
> > Subject: [PATCH v4 2/2] doc: add live migration virtio sriov image
> >
> > This patch adds an image of the Live Migration for virtio and sriov
> > test configuration.
> >
> > Signed-off-by: Bernard Iremonger 
> > ---
> >  doc/guides/howto/lm_bond_virtio_sriov.rst | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst
> > b/doc/guides/howto/lm_bond_virtio_sriov.rst
> > index 6cf797d..49666f1 100644
> > --- a/doc/guides/howto/lm_bond_virtio_sriov.rst
> > +++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
> > @@ -67,6 +67,10 @@ The ip address of host_server_1 is 10.237.212.46
> >
> >  The ip address of host_server_2 is 10.237.212.131
> >
> > +.. _figure_lm_bond_virtio_sriov:
> > +
> > +.. figure:: img/lm_bond_virtio_sriov.*
> > +
> >  Live Migration steps
> >  
> 
> Hi,
> 
> The image is missing in this patch.
> 
> John

It will be in the v5.

Regards,

Bernard.

[dpdk-dev] [PATCH v4 1/2] doc: live migration of VM with Virtio and VF

[Iremonger, Bernard]

Hi John,

> -Original Message-
> From: Mcnamara, John
> Sent: Tuesday, July 19, 2016 3:09 PM
> To: Iremonger, Bernard ; dev at dpdk.org
> Cc: Liu, Yong ; Xu, Qian Q ;
> yuanhan.liu at linux.intel.com
> Subject: RE: [PATCH v4 1/2] doc: live migration of VM with Virtio and VF
> 
> > -Original Message-
> > From: Iremonger, Bernard
> > Sent: Monday, July 18, 2016 11:17 AM
> > To: Mcnamara, John ; dev at dpdk.org
> > Cc: Liu, Yong ; Xu, Qian Q ;
> > yuanhan.liu at linux.intel.com; Iremonger, Bernard
> > 
> > Subject: [PATCH v4 1/2] doc: live migration of VM with Virtio and VF
> >
> > +
> > +How To User Guide
> > +=
> 
> Sorry, I missed this last time but could you change this to "How to Guides"
> since there will be more than one.
> 
> Thanks,
> 
> John

I will send a v5

Regards,

Bernard.

[dpdk-dev] [PATCH] virtio: fix packet corruption

[Tan, Jianfeng]

Hi Oliver,

> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, July 19, 2016 10:00 PM
> To: Tan, Jianfeng; dev at dpdk.org; Xie, Huawei; yuanhan.liu at 
> linux.intel.com
> Subject: Re: [PATCH] virtio: fix packet corruption
> 
> Hi,
> 
> On 07/19/2016 03:57 PM, Tan, Jianfeng wrote:
> >
> >
> >> -Original Message-
> >> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> >> Sent: Tuesday, July 19, 2016 9:11 PM
> >> To: Tan, Jianfeng; dev at dpdk.org; Xie, Huawei;
> yuanhan.liu at linux.intel.com
> >> Subject: Re: [PATCH] virtio: fix packet corruption
> >>
> >> Hi Jianfeng,
> >>
> >> On 07/19/2016 03:03 PM, Tan, Jianfeng wrote:
> >>> Hi Oliver,
> >>>
>  -Original Message-
>  From: Olivier Matz [mailto:olivier.matz at 6wind.com]
>  Sent: Tuesday, July 19, 2016 8:32 PM
>  To: dev at dpdk.org; Tan, Jianfeng; Xie, Huawei;
> >> yuanhan.liu at linux.intel.com
>  Subject: [PATCH] virtio: fix packet corruption
> 
>  The support of virtio-user changed the way the mbuf dma address is
>  retrieved, using a physical address in case of virtio-pci and a virtual
>  address in case of virtio-user.
> 
>  This change introduced some possible memory corruption in packets,
>  replacing:
>    m->buf_physaddr + RTE_PKTMBUF_HEADROOM
>  by:
>    m->buf_physaddr + m->data_off (through a macro)
> 
>  This patch fixes this issue, restoring the original behavior.
> >>>
> >>> Could you be more specific on why we cannot use m->data_off here?
> >>
> >> There is no guarantee that m->data_off == RTE_PKTMBUF_HEADROOM
> here
> >> as
> >> virtqueue_enqueue_recv_refill() is called on a mbuf that is just
> >> allocated with rte_mbuf_raw_alloc(). An alternative would be to set
> >> data_off to RTE_PKTMBUF_HEADROOM, but as it's a fix and we are close
> to
> >> the release, I prefered to restore the initial behavior.
> >
> > Oh yes, gotcha.
> >
> > But if we do not set data_off properly, it's still buggy when others consume
> these mbufs, right?
> >
> 
> This is done later in virtio_recv_pkts*() functions, one the host has
> written the data in the mbuf.

Thanks for clarification. Looks good to me.

Acked-by: Jianfeng Tan 

[dpdk-dev] [PATCH v1] doc: fix release notes for 16.07

[John McNamara]

Fix grammar, spelling and formatting of DPDK 16.07 release notes.

Signed-off-by: John McNamara 
---
 doc/guides/rel_notes/release_16_07.rst | 134 +
 1 file changed, 71 insertions(+), 63 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_07.rst 
b/doc/guides/rel_notes/release_16_07.rst
index d3a144f..38887a5 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -40,16 +40,16 @@ New Features

 * **Added mempool external cache for non-EAL thread.**

-   Added new functions to create, free or flush a user-owned mempool
-   cache for non-EAL threads. Previously, cache was always disabled
-   on these threads.
+  Added new functions to create, free or flush a user-owned mempool
+  cache for non-EAL threads. Previously the cache was always disabled
+  on these threads.

 * **Changed the memory allocation in mempool library.**

   * Added ability to allocate a large mempool in virtually fragmented memory.
   * Added new APIs to populate a mempool with memory.
   * Added an API to free a mempool.
-  * Modified the API of rte_mempool_obj_iter() function.
+  * Modified the API of the ``rte_mempool_obj_iter()`` function.
   * Dropped specific Xen Dom0 code.
   * Dropped specific anonymous mempool code in testpmd.

@@ -63,10 +63,10 @@ New Features

 * **Added mailbox interrupt support for ixgbe and igb VFs.**

-  When the physical NIC link comes down or up, the PF driver will send a
+  When the physical NIC link comes up or down, the PF driver will send a
   mailbox message to notify each VF. To handle this link up/down event,
-  add mailbox interrupts support to receive the message and allow the app to
-  register a callback for it.
+  support have been added for a mailbox interrupt to receive the message and
+  allow the application to register a callback for it.

 * **Updated the ixgbe base driver.**

@@ -74,51 +74,49 @@ New Features
   following:

   * Added sgmii link for X550.
-  * Added mac link setup for X550a SFP and SFP+.
+  * Added MAC link setup for X550a SFP and SFP+.
   * Added KR support for X550em_a.
-  * Added new phy definitions for M88E1500.
+  * Added new PHY definitions for M88E1500.
   * Added support for the VLVF to be bypassed when adding/removing a VFTA 
entry.
   * Added X550a flow control auto negotiation support.

 * **Updated the i40e base driver.**

-  Updated the i40e base driver, which includes support for new devices IDs.
+  Updated the i40e base driver including support for new devices IDs.

-* **Supported virtio on IBM POWER8.**
+* **Added support for virtio on IBM POWER8.**

   The ioports are mapped in memory when using Linux UIO.

-* **Virtio support for containers.**
+* **Added support for Virtio in containers.**

   Add a new virtual device, named virtio-user, to support virtio for 
containers.

   Known limitations:

   * Control queue and multi-queue are not supported yet.
-  * Cannot work with --huge-unlink.
-  * Cannot work with --no-huge.
-  * Cannot work when there are more than VHOST_MEMORY_MAX_NREGIONS(8) 
hugepages.
-  * Root privilege is a must for sorting hugepages by physical address.
-  * Can only be used with vhost user backend.
+  * Doesn't work with ``--huge-unlink``.
+  * Doesn't work with ``--no-huge``.
+  * Doesn't work when there are more than ``VHOST_MEMORY_MAX_NREGIONS(8)`` 
hugepages.
+  * Root privilege is required for sorting hugepages by physical address.
+  * Can only be used with the vhost user backend.

 * **Added vhost-user client mode.**

-  DPDK vhost-user could be the server as well as the client. It supports
-  server mode only before, now it also supports client mode. Client mode
-  is enabled when ``RTE_VHOST_USER_CLIENT`` flag is set while calling
+  DPDK vhost-user now supports client mode as well as server mode. Client mode
+  is enabled when the ``RTE_VHOST_USER_CLIENT`` flag is set while calling
   ``rte_vhost_driver_register``.

-  When DPDK vhost-user restarts from normal or abnormal quit (say crash),
-  the client mode would allow DPDK to establish the connect again.  Note
-  that a brand new QEMU version (v2.7 or above) is needed, otherwise, the
-  reconnect won't work.
+  When DPDK vhost-user restarts from an normal or abnormal exit (such as a
+  crash), the client mode allows DPDK to establish the connection again. Note
+  that QEMU version v2.7 or above is required for this feature.

-  DPDK vhost-user will also try to reconnect by default when
+  DPDK vhost-user will also try to reconnect by default when:

-  * the first connect fails (when QEMU is not started yet)
-  * the connection is broken (when QEMU restarts)
+  * The first connect fails (when QEMU is not started yet).
+  * The connection is broken (when QEMU restarts).

-  It can be turned off if flag ``RTE_VHOST_USER_NO_RECONNECT`` is set.
+  It can be turned off by setting the ``RTE_VHOST_USER_NO_RECONNECT`` flag.

 * **Added NSH packet recognition in i40e.**

@@ -127,7 +125,7 @@ New Fea

[dpdk-dev] [PATCH v4 2/2] doc: add live migration virtio sriov image

[Mcnamara, John]

> -Original Message-
> From: Iremonger, Bernard
> Sent: Monday, July 18, 2016 11:17 AM
> To: Mcnamara, John ; dev at dpdk.org
> Cc: Liu, Yong ; Xu, Qian Q ;
> yuanhan.liu at linux.intel.com; Iremonger, Bernard
> 
> Subject: [PATCH v4 2/2] doc: add live migration virtio sriov image
> 
> This patch adds an image of the Live Migration for virtio and sriov test
> configuration.
> 
> Signed-off-by: Bernard Iremonger 
> ---
>  doc/guides/howto/lm_bond_virtio_sriov.rst | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst
> b/doc/guides/howto/lm_bond_virtio_sriov.rst
> index 6cf797d..49666f1 100644
> --- a/doc/guides/howto/lm_bond_virtio_sriov.rst
> +++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
> @@ -67,6 +67,10 @@ The ip address of host_server_1 is 10.237.212.46
> 
>  The ip address of host_server_2 is 10.237.212.131
> 
> +.. _figure_lm_bond_virtio_sriov:
> +
> +.. figure:: img/lm_bond_virtio_sriov.*
> +
>  Live Migration steps
>  

Hi,

The image is missing in this patch.

John

[dpdk-dev] [PATCH v4 1/2] doc: live migration of VM with Virtio and VF

[Mcnamara, John]

> -Original Message-
> From: Iremonger, Bernard
> Sent: Monday, July 18, 2016 11:17 AM
> To: Mcnamara, John ; dev at dpdk.org
> Cc: Liu, Yong ; Xu, Qian Q ;
> yuanhan.liu at linux.intel.com; Iremonger, Bernard
> 
> Subject: [PATCH v4 1/2] doc: live migration of VM with Virtio and VF
> 
> +
> +How To User Guide
> +=

Sorry, I missed this last time but could you change this to "How to Guides" 
since there will be more than one.

Thanks,

John

[dpdk-dev] [PATCH v2] doc: autogenerate nic overview table from ini files

[Ferruh Yigit]

On 7/17/2016 1:59 PM, John McNamara wrote:
> Convert the NIC feature table in the overview doc into a set of ini
> files and add functions into the Sphinx conf.py file to auto-generate
> them back into an RST table.
> 
> The reason for doing this is to make it easier for PMD maintainers to
> update the feature matrix that makes up the table and to avoid
> frequent and hard to resolve conflicts in doc/guides/nics/overview.rst.
> 
> A NIC/PMD feature matrix is now an ini file like the following:
> 
> $ head doc/guides/nics/nic_features/i40e.ini
> ;
> ; Features of the i40e network driver.
> ;
> [Features]
> Link status  = Y
> Link status event= Y
> Rx interrupt = Y
> Queue start/stop = Y
> ...
> 
> The output RST table matches the existing table with the column
> headers sorted.
> 
> Signed-off-by: John McNamara 

Tested-by: Ferruh Yigit 

[dpdk-dev] [PATCH] doc: add section on tested platforms and nics and OS

[Yulong Pei]

Add new section on tested platforms and nics and OS to the release notes.

Signed-off-by: Yulong Pei 
---
 doc/guides/rel_notes/release_16_07.rst | 117 +
 1 file changed, 106 insertions(+), 11 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_07.rst 
b/doc/guides/rel_notes/release_16_07.rst
index d3a144f..3b3c23e 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -350,25 +350,120 @@ The libraries prepended with a plus sign were 
incremented in this version.
 Tested Platforms
 

-.. This section should contain a list of platforms that were tested with this
-   release.
+#. SuperMicro 1U

-   The format is:
+   - BIOS: 1.0c
+   - Processor: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz

-   #. Platform name.
+#. SuperMicro 1U

-  - Platform details.
-  - Platform details.
+   - BIOS: 1.0a
+   - Processor: Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz
+   - Onboard NIC: Intel(R) X552/X557-AT (2x10G)
+
+ - Firmware-version: 0x81cf
+ - Device ID (PF/VF): 8086:15ad /8086:15a8
+
+   - kernel driver version: 4.2.5 (ixgbe)
+
+#. SuperMicro 2U
+
+   - BIOS: 1.0a
+   - Processor: Intel(R) Xeon(R) CPU E5-4667 v3 @ 2.00GHz
+
+#. Intel(R) Server board S2600GZ
+
+   - BIOS: SE5C600.86B.02.02.0002.122320131210
+   - Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
+
+#. Intel(R) Server board W2600CR
+
+   - BIOS: SE5C600.86B.02.01.0002.082220131453
+   - Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
+
+#. Intel(R) Server board S2600CWT
+
+   - BIOS: SE5C610.86B.01.01.0009.060120151350
+   - Processor: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
+
+#. Intel(R) Server board S2600WTT
+
+   - BIOS: SE5C610.86B.01.01.0005.101720141054
+   - Processor: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
+
+#. Intel(R) Server board S2600WTT
+
+   - BIOS: SE5C610.86B.11.01.0044.090120151156
+   - Processor: Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10GHz


 Tested NICs
 ---

-.. This section should contain a list of NICs that were tested with this 
release.
+#. Intel(R) Ethernet Controller X540-AT2
+
+   - Firmware version: 0x8389
+   - Device id (pf): 8086:1528
+   - Driver version: 3.23.2 (ixgbe)
+
+#. Intel(R) 82599ES 10 Gigabit Ethernet Controller
+
+   - Firmware version: 0x61bf0001
+   - Device id (pf/vf): 8086:10fb / 8086:10ed
+   - Driver version: 4.0.1-k (ixgbe)
+
+#. Intel(R) Corporation Ethernet Connection X552/X557-AT 10GBASE-T
+
+   - Firmware version: 0x81cf
+   - Device id (pf/vf): 8086:15ad / 8086:15a8
+   - Driver version: 4.2.5 (ixgbe)
+
+#. Intel(R) Ethernet Converged Network Adapter X710-DA4 (4x10G)
+
+   - Firmware version: 5.04
+   - Device id (pf/vf): 8086:1572 / 8086:154c
+   - Driver version: 1.4.26 (i40e)
+
+#. Intel(R) Ethernet Converged Network Adapter X710-DA2 (2x10G)
+
+   - Firmware version: 5.04
+   - Device id (pf/vf): 8086:1572 / 8086:154c
+   - Driver version: 1.4.25 (i40e)
+
+#. Intel(R) Ethernet Converged Network Adapter XL710-QDA1 (1x40G)
+
+   - Firmware version: 5.04
+   - Device id (pf/vf): 8086:1584 / 8086:154c
+   - Driver version: 1.4.25 (i40e)
+
+#. Intel(R) Ethernet Converged Network Adapter XL710-QDA2 (2X40G)
+
+   - Firmware version: 5.04
+   - Device id (pf/vf): 8086:1583 / 8086:154c
+   - Driver version: 1.4.25 (i40e)
+
+#. Intel(R) Corporation I350 Gigabit Network Connection
+
+   - Firmware version: 1.48, 0x86e7
+   - Device id (pf/vf): 8086:1521 / 8086:1520
+   - Driver version: 5.2.13-k (igb)
+
+#. Intel(R) Ethernet Multi-host Controller FM1
+
+   - Firmware version: N/A
+   - Device id (pf/vf): 8086:15d0
+   - Driver version: 0.17.0.9 (fm10k)

-   The format is:

-   #. NIC name.
+Tested OS
+-

-  - NIC details.
-  - NIC details.
+   - Red Hat Enterprise Linux 7.2
+   - CentOS 7.0
+   - Ubuntu 16.04 LTS
+   - Fedora 24
+   - SUSE Enterprise Linux 12
+   - Wind River Linux 8
+   - FreeBSD 10.3
+   - Ubuntu 15.10
+   - Fedora 23
-- 
2.1.0

[dpdk-dev] [PATCH] virtio: fix packet corruption

[Tan, Jianfeng]

> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, July 19, 2016 9:11 PM
> To: Tan, Jianfeng; dev at dpdk.org; Xie, Huawei; yuanhan.liu at 
> linux.intel.com
> Subject: Re: [PATCH] virtio: fix packet corruption
> 
> Hi Jianfeng,
> 
> On 07/19/2016 03:03 PM, Tan, Jianfeng wrote:
> > Hi Oliver,
> >
> >> -Original Message-
> >> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> >> Sent: Tuesday, July 19, 2016 8:32 PM
> >> To: dev at dpdk.org; Tan, Jianfeng; Xie, Huawei;
> yuanhan.liu at linux.intel.com
> >> Subject: [PATCH] virtio: fix packet corruption
> >>
> >> The support of virtio-user changed the way the mbuf dma address is
> >> retrieved, using a physical address in case of virtio-pci and a virtual
> >> address in case of virtio-user.
> >>
> >> This change introduced some possible memory corruption in packets,
> >> replacing:
> >>   m->buf_physaddr + RTE_PKTMBUF_HEADROOM
> >> by:
> >>   m->buf_physaddr + m->data_off (through a macro)
> >>
> >> This patch fixes this issue, restoring the original behavior.
> >
> > Could you be more specific on why we cannot use m->data_off here?
> 
> There is no guarantee that m->data_off == RTE_PKTMBUF_HEADROOM here
> as
> virtqueue_enqueue_recv_refill() is called on a mbuf that is just
> allocated with rte_mbuf_raw_alloc(). An alternative would be to set
> data_off to RTE_PKTMBUF_HEADROOM, but as it's a fix and we are close to
> the release, I prefered to restore the initial behavior.

Oh yes, gotcha.

But if we do not set data_off properly, it's still buggy when others consume 
these mbufs, right?

Thanks,
Jianfeng

> 
> I did not include the test plan because it relies on patch that are not
> submitted yet (offload patches, they will be upstreamed very soon). It
> is a quite simple test case with testpmd.
> 
> Regards,
> Olivier

[dpdk-dev] [PATCH] doc: note a pitfall on reconnect feature

[Mcnamara, John]

> -  Note: the "reconnect" feature requires **QEMU v2.7** (or above).
> +  .. Note::
> + * The "reconnect" feature requires **QEMU v2.7** (or above).
> +
> + * The vhost supported features must be exactly the same before and
> +   after the restart. For example, if TSO is disabled and then
> enabled,
> +   nothing will work and issues undefined might happen.

s/ issues undefined / undefined issues /

Apart from that:

Acked-by: John McNamara 

[dpdk-dev] [PATCH] examples/vhost: fix perf regression

[Jianfeng Tan]

We find significant perfermance drop introduced by below commit,
when vhost example is started with --mergeable 0 and inside vm,
kernel virtio-net driver is used to do ip based forwarding.

The root cause is that below commit adds support for
VIRTIO_NET_F_GUEST_TSO4 and VIRTIO_NET_F_GUEST_TSO6, and when
mergeable is disabled, it triggers big_packets path of virtio-net
driver. In this path, virtio driver uses 19 desc with 18 4K-sized
pages to receive each packet, so that it can receive a big packet
with size of 64K. But QEMU only creates 256 desc entries for each
vq, which results in that only 13 packets can be received. VM
kernel can quickly handle those packets and go to sleep (HLT).

As QEMU has no option to set the desc entries of a vq, so here,
we disable VIRTIO_NET_F_GUEST_TSO4 and VIRTIO_NET_F_GUEST_TSO6
with VIRTIO_NET_F_HOST_TSO4 and VIRTIO_NET_F_HOST_TSO6 when we
disable tso of vhost example, to avoid VM kernel virtio driver
go into big_packets path.

Fixes: 859b480d5afd ("vhost: add guest offload setting")

Reported-by: Qian Xu 
Signed-off-by: Jianfeng Tan 
---
 examples/vhost/main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 3b98f42..92a9823 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -327,6 +327,8 @@ port_init(uint8_t port)
if (enable_tso == 0) {
rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_HOST_TSO4);
rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_HOST_TSO6);
+   rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_GUEST_TSO4);
+   rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_GUEST_TSO6);
}

rx_rings = (uint16_t)dev_info.max_rx_queues;
-- 
2.7.4

[dpdk-dev] [PATCH] rte_delay_us can be replaced with user function

[Jozef Martiniak -X (jozmarti - PANTHEON TECHNOLOGIES@Cisco)]

Hi,

On Tue, 2016-07-19 at 15:21 +0200, Thomas Monjalon wrote:
Hi,
> 
> 2016-07-19 14:42, jozmarti at cisco.com:
> > when running single-core, some drivers tend to call rte_delay_us for a
> > long time, and that is causing packet drops.
> > Attached patch introduces 2 new functions:
> > 
> > void rte_delay_us_callback_register(void(*userfunc)(unsigned));
> > void rte_delay_us_callback_unregister(void);
> > 
> > First one replaces rte_delay_us with userfunc and second one restores
> > original rte_delay_us.
> 
> I think we could avoid the function unregister by exporting the
> default implementation (let's say rte_delay_us_block).
> 

I think register/unregister is the standard way how to handle callbacks. 
Unregister func is now "empty" but can be extended in the future.

> > +REGISTER_TEST_COMMAND(user_delay_us, test_user_delay_us);
> 
> Thanks for providing an unit test.
> 
> 
> > --- a/lib/librte_eal/common/eal_common_timer.c
> > +++ b/lib/librte_eal/common/eal_common_timer.c
> >  void
> >  rte_delay_us(unsigned us)
> >  {
> > +   if (unlikely(rte_delay_us_override != NULL))
> > +   {
> > +   rte_delay_us_override(us);
> > +   return;
> > +   }
> 
> Why not always call the registered callback and initialize it
> to the default implementation (maybe using a constructor)?
> 
I wanted to touch as few things as possible with this patch.

[dpdk-dev] DPDK Coverity issue 127559

[Rahul Lakkireddy]

Hi all,

On Monday, July 07/04/16, 2016 at 08:29:49 -0700, john.mcnamara at intel.com 
wrote:
> Hi Rahul,
> 
> This is an automated email in relation to a new Coverity static code analysis
> issue in DPDK. Details of the issue are below.
> 
[...]

> Git commit data and Coverity defect information below.
> 
> Commit data
> ===
> 
> Commit: net/cxgbe: support EEPROM access
> Id: fe0bd9ee5da3fd52766458a5d0fa9a8728182be1
> Author: Rahul Lakkireddy
> Email:  rahul.lakkireddy at chelsio.com
> Date:   Fri May  6 08:43:18 2016 +0530
> 
> Defect information
> ==
> 
> /drivers/net/cxgbe/cxgbe_ethdev.c: 919 in cxgbe_set_eeprom()
> *** CID 127559:(TAINTED_SCALAR)
> 913   }
> 914
> 915   if (!err)
> 916   err = t4_seeprom_wp(adapter, true);
> 917 out:
> 918   if (buf != eeprom->data)
> >>> CID 127559:(TAINTED_SCALAR)
> >>> Passing tainted variable "buf" to a tainted sink.
> 919   rte_free(buf);
> 920   return err;
> 921 }
> 922
> 923 static int cxgbe_get_regs_len(struct rte_eth_dev *eth_dev)
> 924 {
> /drivers/net/cxgbe/cxgbe_ethdev.c: 910 in cxgbe_set_eeprom()
> 904   }
> 905
> 906   err = t4_seeprom_wp(adapter, false);
> 907   if (err)
> 908   goto out;
> 909
> >>> CID 127559:(TAINTED_SCALAR)
> >>> Assigning: "p" = "(u32 *)buf". Both are now tainted.
> 910   for (p = (u32 *)buf; !err && aligned_len; aligned_len -= 4, 
> p++) {
> 911   err = eeprom_wr_phys(adapter, aligned_offset, *p);
> 912   aligned_offset += 4;
> 913   }
> 914
> 915   if (!err)
> 

I'm not an expert in Coverity and am having trouble understanding what
the defect is and need some clarification.  Is it telling me that "buf"
is being used without doing lower and upper bounds check?

Thanks,
Rahul

[dpdk-dev] [PATCH] doc: add section on tested platforms and nics and OS

[Mcnamara, John]

> -Original Message-
> From: Pei, Yulong
> Sent: Tuesday, July 19, 2016 7:04 AM
> To: dev at dpdk.org; Mcnamara, John 
> Cc: thomas.monjalon at 6wind.com; Pei, Yulong 
> Subject: [PATCH] doc: add section on tested platforms and nics and OS
> 
> Add new section on tested platforms and nics and OS to the release notes.

Hi,

Thanks for that. One comment below.


> +Tested OS
> +-
> 
> -  - NIC details.
> -  - NIC details.
> +   - Red Hat Enterprise Linux 7.2
> +   - CentOS 7.0
> +   - Ubuntu 16.04 LTS
> +   - Fedora 24
> +   - SUSE Enterprise Linux 12
> +   - Wind River Linux 8
> +   - FreeBSD 10.3
> +   - Ubuntu 15.10
> +   - Fedora 23

This should be "Tested OSes". Also in the commit message.

Also it would be better to sort these in alphabetical order. There are 
2 Ubuntu and 2 Fedora versions here but it isn't clear since they aren't 
together.

John

[dpdk-dev] [PATCH] net: virtio: clear reserved vring properly at setup time

[Yuanhan Liu]

On Tue, Jul 19, 2016 at 07:31:35AM +0200, Maxime Coquelin wrote:
> >And to Thomas, I don't find a good reason to have this in 16.07. Let's
> >delay the apply to v16.11.
> Yes, that's why I mentioned it didn't fixed any problem on my side.
> 
> So I propose we skip this patch, I'll resend one removing the memset for
> v16.11.

Good to me.

--yliu

[dpdk-dev] [PATCH] net/ena: fix icc compile error

[Jan Mędala]

Ferruh,

Actually we can stay with this patch. It's ok.

Acked-by: Jan Medala 

  Jan

2016-07-19 12:48 GMT+02:00 Ferruh Yigit :

> On 7/19/2016 10:33 AM, Ferruh Yigit wrote:
> > compile error:
> >   CC ena_com.o
> > .../drivers/net/ena/base/ena_com.c(346):
> > error #3656: variable "dev_node" may be used before its value is set
> > ENA_MEM_ALLOC_COHERENT_NODE(ena_dev->dmadev,
> > ^
> >
> > .../drivers/net/ena/base/ena_com.c(399):
> > error #3656: variable "prev_node" may be used before its value is set
> > ENA_MEM_ALLOC_COHERENT_NODE(ena_dev->dmadev,
> > ^
> >
> > Fixes: 3d3edc265fc8 ("net/ena: make coherent memory allocation
> NUMA-aware")
> >
> > Reported-by: Eoin Breen 
> > Signed-off-by: Ferruh Yigit 
>
> Self-Nack
> I wasn't aware Jan is already working on this and has a patch. We can
> drop this one.
>
> Thanks,
> ferruh
>
>

[dpdk-dev] [PATCH] rte_delay_us can be replaced with user function

[Wiles, Keith]

Hi Jozef,

I have two quick comments inline.
> On Jul 19, 2016, at 7:42 AM, jozmarti at cisco.com wrote:
> 
> From: Jozef Martiniak 
> 
> when running single-core, some drivers tend to call rte_delay_us for a
> long time, and that is causing packet drops.
> Attached patch introduces 2 new functions:
> 
> void rte_delay_us_callback_register(void(*userfunc)(unsigned));
> void rte_delay_us_callback_unregister(void);
> 
> First one replaces rte_delay_us with userfunc and second one restores
> original rte_delay_us.
> Test user_delay_us is included.
> 
> Signed-off-by: Jozef Martiniak 
> ---
> app/test/test_cycles.c | 39 ++
> lib/librte_eal/common/eal_common_timer.c   | 19 +++
> lib/librte_eal/common/include/generic/rte_cycles.h | 13 
> 3 files changed, 71 insertions(+)
> 
> diff --git a/app/test/test_cycles.c b/app/test/test_cycles.c
> index f6c043a..2b44a53 100644
> --- a/app/test/test_cycles.c
> +++ b/app/test/test_cycles.c
> @@ -90,3 +90,42 @@ test_cycles(void)
> }
> 
> REGISTER_TEST_COMMAND(cycles_autotest, test_cycles);
> +
> +/*
> + * rte_delay_us_callback test
> + *
> + * - check if callback is correctly registered/unregistered
> + *
> + */
> +
> +static int pattern;
> +static void my_rte_delay_us(unsigned us)
> +{
> +pattern += us;
> +}
> +
> +static int
> +test_user_delay_us(void)
> +{
> +pattern = 0;
> +
> +rte_delay_us_callback_register(my_rte_delay_us);
> +
> +rte_delay_us(2);
> +if (pattern != 2)
> +return -1;
> +
> +rte_delay_us(3);
> +if (pattern != 5)
> +return -1;
> +
> +rte_delay_us_callback_unregister();
> +
> +rte_delay_us(3);
> +if (pattern != 5)
> +return -1;
> +
> +return 0;
> +}
> +
> +REGISTER_TEST_COMMAND(user_delay_us, test_user_delay_us);
> diff --git a/lib/librte_eal/common/eal_common_timer.c 
> b/lib/librte_eal/common/eal_common_timer.c
> index c4227cd..a982562 100644
> --- a/lib/librte_eal/common/eal_common_timer.c
> +++ b/lib/librte_eal/common/eal_common_timer.c
> @@ -47,9 +47,18 @@
> /* The frequency of the RDTSC timer resolution */
> static uint64_t eal_tsc_resolution_hz;
> 
> +/* User function which replaces rte_delay_us function */
> +static void (*rte_delay_us_override)(unsigned) = NULL;
> +
> void
> rte_delay_us(unsigned us)
> {
> + if (unlikely(rte_delay_us_override != NULL))
> + {
> + rte_delay_us_override(us);
> + return;
> + }
> +
>   const uint64_t start = rte_get_timer_cycles();
>   const uint64_t ticks = (uint64_t)us * rte_get_timer_hz() / 1E6;
>   while ((rte_get_timer_cycles() - start) < ticks)
> @@ -84,3 +93,13 @@ set_tsc_freq(void)
>   RTE_LOG(DEBUG, EAL, "TSC frequency is ~%" PRIu64 " KHz\n", freq / 1000);
>   eal_tsc_resolution_hz = freq;
> }
> +
> +void rte_delay_us_callback_register(void (*userfunc)(unsigned))
> +{
> +rte_delay_us_override = userfunc;
> +}
> +
> +void rte_delay_us_callback_unregister(void)
> +{
> +rte_delay_us_override = NULL;
> +}

I guess I would have used the rte_delay_us_callback_register(NULL) to 
unregister, but this is fine.

> diff --git a/lib/librte_eal/common/include/generic/rte_cycles.h 
> b/lib/librte_eal/common/include/generic/rte_cycles.h
> index 8cc21f2..274f798 100644
> --- a/lib/librte_eal/common/include/generic/rte_cycles.h
> +++ b/lib/librte_eal/common/include/generic/rte_cycles.h
> @@ -202,4 +202,17 @@ rte_delay_ms(unsigned ms)
>   rte_delay_us(ms * 1000);
> }
> 
> +/**
> + * Replace rte_delay_us with user defined function.
> + *
> + * @param userfunc
> + *   User function which replaces rte_delay_us.
> + */
> +void rte_delay_us_callback_register(void(*userfunc)(unsigned));
> +
> +/**
> + * Unregister user callback function. Restores original rte_delay_us.
> + */
> +void rte_delay_us_callback_unregister(void);

Just a note we need to add these two new APIs to the map file for ABI checking.

Other then these two comments I would give this one a +1 unless someone else 
has some comments.

> +
> #endif /* _RTE_CYCLES_H_ */
> -- 
> 2.1.4
> 

[dpdk-dev] [PATCH] virtio: fix packet corruption

[Tan, Jianfeng]

Hi Oliver,

> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, July 19, 2016 8:32 PM
> To: dev at dpdk.org; Tan, Jianfeng; Xie, Huawei; yuanhan.liu at 
> linux.intel.com
> Subject: [PATCH] virtio: fix packet corruption
> 
> The support of virtio-user changed the way the mbuf dma address is
> retrieved, using a physical address in case of virtio-pci and a virtual
> address in case of virtio-user.
> 
> This change introduced some possible memory corruption in packets,
> replacing:
>   m->buf_physaddr + RTE_PKTMBUF_HEADROOM
> by:
>   m->buf_physaddr + m->data_off (through a macro)
> 
> This patch fixes this issue, restoring the original behavior.

Could you be more specific on why we cannot use m->data_off here?

Thanks,
Jianfeng

> 
> By the way, it also rework the macros, adding a "VIRTIO_" prefix and
> API comments.
> 
> Fixes: f24f8f9fee8a ("net/virtio: allow virtual address to fill vring 
> descriptors")
> 
> Signed-off-by: Olivier Matz 
> ---
>  drivers/net/virtio/virtio_ethdev.c  |  2 +-
>  drivers/net/virtio/virtio_rxtx.c|  5 +++--
>  drivers/net/virtio/virtio_rxtx_simple.c | 13 +++--
>  drivers/net/virtio/virtqueue.h  | 25 +
>  4 files changed, 28 insertions(+), 17 deletions(-)
> 

[dpdk-dev] [PATCH v2] mk: fix FreeBSD build

[Christian Ehrhardt]

Hi,
I haven't tested the new suggested way, just went into explaining what
formerly were the reasons.
But I'd strongly vote against reordering and dropping comments.

Sergio - v3 had still awk for some parts.
It doesn't have the "0,..." you mentioned.
Could you check if that is already using GNU-sed only syntax -
http://dpdk.org/dev/patchwork/patch/14592/ ?

If this would be ok - AND - if it creates the same .config as the current
code I'd think that is the way to go.


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Tue, Jul 19, 2016 at 12:32 PM, Ferruh Yigit 
wrote:

> On 7/18/2016 5:06 PM, Sergio Gonzalez Monroy wrote:
> > The sed syntax of '0,/regexp/' is GNU specific and fails with
> > non GNU sed in FreeBSD.
> >
> > To solve the issue we can use awk instead to remove duplicates.
> >
> > Fixes: b2063f104db7 ("mk: filter duplicate configuration entries")
> >
> > Signed-off-by: Sergio Gonzalez Monroy 
> > ---
> >
> > v2:
> > - Use temp var instead of temp file
> >
> >  mk/rte.sdkconfig.mk | 7 ++-
> >  1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
> > index e93237f..c2b6e13 100644
> > --- a/mk/rte.sdkconfig.mk
> > +++ b/mk/rte.sdkconfig.mk
> > @@ -88,11 +88,8 @@ $(RTE_OUTPUT)/.config: $(RTE_CONFIG_TEMPLATE) FORCE |
> $(RTE_OUTPUT)
> >   $(CPP) -undef -P -x assembler-with-cpp \
> >   -ffreestanding \
> >   -o $(RTE_OUTPUT)/.config_tmp $(RTE_CONFIG_TEMPLATE) ; \
> > - for config in $$(grep -v "^#" $(RTE_OUTPUT)/.config_tmp |
> cut -d"=" -f1 | sort | uniq -d); do \
> > - while [ $$(grep "^$${config}="
> $(RTE_OUTPUT)/.config_tmp -c ) -gt 1 ]; do \
> > - sed -i "0,/^$${config}=/{//d}"
> $(RTE_OUTPUT)/.config_tmp; \
> > - done; \
> > - done; \
> > + config=$$(grep -v "^#" $(RTE_OUTPUT)/.config_tmp) ; \
> > + echo "$$config" | awk -F'=' '{a[$$1]=$$0} END {for (i in
> a) print a[i]}' > $(RTE_OUTPUT)/.config_tmp ; \
> This is another nice awk command.
>
> A few comments about new command:
> - Removes all comments from final config
> - Spreads config option all over the file, logical grouping of options
> removed.
>
> When both happens at the same time, I have a concern that this may lead
> missing some config options when somebody wants to update local config
> file, but I am OK if everybody is OK.
>
>
> >   if ! cmp -s $(RTE_OUTPUT)/.config_tmp
> $(RTE_OUTPUT)/.config; then \
> >   cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config
> ; \
> >   cp $(RTE_OUTPUT)/.config_tmp
> $(RTE_OUTPUT)/.config.orig ; \
> >
>
>

[dpdk-dev] [PATCH v2] mk: fix FreeBSD build

[Sergio Gonzalez Monroy]

Sorry Christian, I did miss your previous patches.

On 19/07/2016 12:01, Christian Ehrhardt wrote:
> Hi,
> I haven't tested the new suggested way, just went into explaining what 
> formerly were the reasons.
> But I'd strongly vote against reordering and dropping comments.
>
Fair enough.
We would  still have some not-order options if they are duplicated as we 
would just keep the last one but nevertheless most of them would be 
properly grouped and ordered.

I'll rework something based on your v3 patch.

Sergio

> Sergio - v3 had still awk for some parts.
> It doesn't have the "0,..." you mentioned.
> Could you check if that is already using GNU-sed only syntax - 
> http://dpdk.org/dev/patchwork/patch/14592/ ?
>
> If this would be ok - AND - if it creates the same .config as the 
> current code I'd think that is the way to go.
>
>
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>
> On Tue, Jul 19, 2016 at 12:32 PM, Ferruh Yigit  > wrote:
>
> On 7/18/2016 5:06 PM, Sergio Gonzalez Monroy wrote:
> > The sed syntax of '0,/regexp/' is GNU specific and fails with
> > non GNU sed in FreeBSD.
> >
> > To solve the issue we can use awk instead to remove duplicates.
> >
> > Fixes: b2063f104db7 ("mk: filter duplicate configuration entries")
> >
> > Signed-off-by: Sergio Gonzalez Monroy
>  >
> > ---
> >
> > v2:
> > - Use temp var instead of temp file
> >
> >  mk/rte.sdkconfig.mk  | 7 ++-
> >  1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/mk/rte.sdkconfig.mk 
> b/mk/rte.sdkconfig.mk 
> > index e93237f..c2b6e13 100644
> > --- a/mk/rte.sdkconfig.mk 
> > +++ b/mk/rte.sdkconfig.mk 
> > @@ -88,11 +88,8 @@ $(RTE_OUTPUT)/.config: $(RTE_CONFIG_TEMPLATE)
> FORCE | $(RTE_OUTPUT)
> >   $(CPP) -undef -P -x assembler-with-cpp \
> >   -ffreestanding \
> >   -o $(RTE_OUTPUT)/.config_tmp
> $(RTE_CONFIG_TEMPLATE) ; \
> > - for config in $$(grep -v "^#"
> $(RTE_OUTPUT)/.config_tmp | cut -d"=" -f1 | sort | uniq -d); do \
> > - while [ $$(grep "^$${config}="
> $(RTE_OUTPUT)/.config_tmp -c ) -gt 1 ]; do \
> > - sed -i "0,/^$${config}=/{//d}"
> $(RTE_OUTPUT)/.config_tmp; \
> > - done; \
> > - done; \
> > + config=$$(grep -v "^#" $(RTE_OUTPUT)/.config_tmp) ; \
> > + echo "$$config" | awk -F'=' '{a[$$1]=$$0} END {for
> (i in a) print a[i]}' > $(RTE_OUTPUT)/.config_tmp ; \
> This is another nice awk command.
>
> A few comments about new command:
> - Removes all comments from final config
> - Spreads config option all over the file, logical grouping of options
> removed.
>
> When both happens at the same time, I have a concern that this may
> lead
> missing some config options when somebody wants to update local config
> file, but I am OK if everybody is OK.
>
>
> >   if ! cmp -s $(RTE_OUTPUT)/.config_tmp
> $(RTE_OUTPUT)/.config; then \
> >   cp $(RTE_OUTPUT)/.config_tmp
> $(RTE_OUTPUT)/.config ; \
> >   cp $(RTE_OUTPUT)/.config_tmp
> $(RTE_OUTPUT)/.config.orig ; \
> >
>
>

[dpdk-dev] [PATCH RFC] maintainers: add git tree for virtio/vhost

[Yuanhan Liu]

Add a git tree line for the virtio/vhost section, to make an explicit
statement that the developers are suggested to make patches based on
that tree.

Signed-off-by: Yuanhan Liu 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9c76352..433ddd8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -356,6 +356,7 @@ F: doc/guides/nics/qede.rst
 RedHat virtio
 M: Huawei Xie 
 M: Yuanhan Liu 
+T: git://dpdk.org/next/dpdk-next-virtio
 F: drivers/net/virtio/
 F: doc/guides/nics/virtio.rst
 F: lib/librte_vhost/
@@ -371,6 +372,7 @@ F: doc/guides/nics/vmxnet3.rst
 Vhost PMD
 M: Tetsuya Mukawa 
 M: Yuanhan Liu 
+T: git://dpdk.org/next/dpdk-next-virtio
 F: drivers/net/vhost/

 PCAP PMD
-- 
1.9.0

[dpdk-dev] [PATCH] doc: note a pitfall on reconnect feature

[Yuanhan Liu]

The vhost feature negotiation only happens at virtio reset stage, say
when a virtio-net device is firstly initiated, or when DPDK virtio PMD
initiates. That means, if vhost APP restarts after the negotiation and
reconnects, the feature negotiation process will not be triggered again,
meaning the info is lost. To make reconnect work, QEMU simply saves
the negotiated features before the restart and restores it afterwards.

Therefore, the vhost supported features must be exactly the same before
and after the restart. For example, if TSO is disabled and then enabled,
nothing will work and issues undefined might happen.

Signed-off-by: Yuanhan Liu 
---

I just put the part "people should not do this" into the doc, and I'm
not quite sure I need put the "why" part there or not.
---
 doc/guides/prog_guide/vhost_lib.rst | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/vhost_lib.rst 
b/doc/guides/prog_guide/vhost_lib.rst
index 14d5e67..6b0c6b2 100644
--- a/doc/guides/prog_guide/vhost_lib.rst
+++ b/doc/guides/prog_guide/vhost_lib.rst
@@ -189,7 +189,12 @@ vhost-user implementation has two options:
   When the DPDK vhost-user application restarts, DPDK vhost-user will try to
   connect to the server again. This is how the "reconnect" feature works.

-  Note: the "reconnect" feature requires **QEMU v2.7** (or above).
+  .. Note::
+ * The "reconnect" feature requires **QEMU v2.7** (or above).
+
+ * The vhost supported features must be exactly the same before and
+   after the restart. For example, if TSO is disabled and then enabled,
+   nothing will work and issues undefined might happen.

 No matter which mode is used, once a connection is established, DPDK
 vhost-user will start receiving and processing vhost messages from QEMU.
-- 
1.9.0

[dpdk-dev] [PATCH] examples/ipsec-secgw: fix GCC 4.5.x build error

[Sergio Gonzalez Monroy]

GCC 4.5.x does not handle well initializing anonymous union and/or
structs.

To make the compiler happy we name those anonymous union/struct.

Fixes: 906257e965b7 ("examples/ipsec-secgw: support IPv6")

Signed-off-by: Sergio Gonzalez Monroy 
---
 examples/ipsec-secgw/ipip.h  |  4 +--
 examples/ipsec-secgw/ipsec.h |  4 +--
 examples/ipsec-secgw/sa.c| 60 ++--
 3 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/examples/ipsec-secgw/ipip.h b/examples/ipsec-secgw/ipip.h
index ce25a2e..ff1dccd 100644
--- a/examples/ipsec-secgw/ipip.h
+++ b/examples/ipsec-secgw/ipip.h
@@ -100,8 +100,8 @@ ipip_outbound(struct rte_mbuf *m, uint32_t offset, uint32_t 
is_ipv6,
outip4->ip_ttl = IPDEFTTL;
outip4->ip_p = IPPROTO_ESP;

-   outip4->ip_src.s_addr = src->ip4;
-   outip4->ip_dst.s_addr = dst->ip4;
+   outip4->ip_src.s_addr = src->ip.ip4;
+   outip4->ip_dst.s_addr = dst->ip.ip4;

return outip4;
 }
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index 0d2ee25..a442a74 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -86,8 +86,8 @@ struct ip_addr {
union {
uint64_t ip6[2];
uint8_t ip6_b[16];
-   };
-   };
+   } ip6;
+   } ip;
 };

 struct ipsec_sa {
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index ab18b81..4439e0f 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -53,8 +53,8 @@
 const struct ipsec_sa sa_out[] = {
{
.spi = 5,
-   .src.ip4 = IPv4(172, 16, 1, 5),
-   .dst.ip4 = IPv4(172, 16, 2, 5),
+   .src.ip.ip4 = IPv4(172, 16, 1, 5),
+   .dst.ip.ip4 = IPv4(172, 16, 2, 5),
.cipher_algo = RTE_CRYPTO_CIPHER_AES_CBC,
.auth_algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
.digest_len = 12,
@@ -64,8 +64,8 @@ const struct ipsec_sa sa_out[] = {
},
{
.spi = 6,
-   .src.ip4 = IPv4(172, 16, 1, 6),
-   .dst.ip4 = IPv4(172, 16, 2, 6),
+   .src.ip.ip4 = IPv4(172, 16, 1, 6),
+   .dst.ip.ip4 = IPv4(172, 16, 2, 6),
.cipher_algo = RTE_CRYPTO_CIPHER_AES_CBC,
.auth_algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
.digest_len = 12,
@@ -93,8 +93,8 @@ const struct ipsec_sa sa_out[] = {
},
{
.spi = 15,
-   .src.ip4 = IPv4(172, 16, 1, 5),
-   .dst.ip4 = IPv4(172, 16, 2, 5),
+   .src.ip.ip4 = IPv4(172, 16, 1, 5),
+   .dst.ip.ip4 = IPv4(172, 16, 2, 5),
.cipher_algo = RTE_CRYPTO_CIPHER_NULL,
.auth_algo = RTE_CRYPTO_AUTH_NULL,
.digest_len = 0,
@@ -104,8 +104,8 @@ const struct ipsec_sa sa_out[] = {
},
{
.spi = 16,
-   .src.ip4 = IPv4(172, 16, 1, 6),
-   .dst.ip4 = IPv4(172, 16, 2, 6),
+   .src.ip.ip4 = IPv4(172, 16, 1, 6),
+   .dst.ip.ip4 = IPv4(172, 16, 2, 6),
.cipher_algo = RTE_CRYPTO_CIPHER_NULL,
.auth_algo = RTE_CRYPTO_AUTH_NULL,
.digest_len = 0,
@@ -115,9 +115,9 @@ const struct ipsec_sa sa_out[] = {
},
{
.spi = 25,
-   .src.ip6_b = { 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11,
+   .src.ip.ip6.ip6_b = { 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11,
0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x55, 0x55 },
-   .dst.ip6_b = { 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22,
+   .dst.ip.ip6.ip6_b = { 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22,
0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x55, 0x55 },
.cipher_algo = RTE_CRYPTO_CIPHER_AES_CBC,
.auth_algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
@@ -128,9 +128,9 @@ const struct ipsec_sa sa_out[] = {
},
{
.spi = 26,
-   .src.ip6_b = { 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11,
+   .src.ip.ip6.ip6_b = { 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11,
0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x66, 0x66 },
-   .dst.ip6_b = { 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22,
+   .dst.ip.ip6.ip6_b = { 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22,
0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x66, 0x66 },
.cipher_algo = RTE_CRYPTO_CIPHER_AES_CBC,
.auth_algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
@@ -145,8 +145,8 @@ const struct ipsec_sa sa_out[] = {
 const struct ipsec_sa sa_in[] = {
{
.spi = 105,
-   .src.ip4 = IPv4(172, 16, 2, 5),
-   .dst.ip4 = IPv4(172, 16, 1, 5),
+   .src.ip.ip4 = IPv4(172, 16, 2, 5),
+   .dst.ip.ip4 = IPv4(172, 16, 1, 5),
.cipher_algo = RTE_CRYPTO_CIPHER_AES_CBC,
.auth_algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
.digest_len = 12,
@@ -156,8 +156,8 @@ const struct ipsec_sa sa_in[] = {
},
{
.spi = 106,
-   .src.ip4 = IPv4(172, 16, 2, 6),
-   .dst.ip4 = IPv4(172, 16, 1, 6),
+   .src.ip.ip4 = IPv4(172, 16, 2, 6),
+   .dst.ip.ip4 = IPv4(172, 16, 1, 6),
.cipher_algo 

[dpdk-dev] [PATCH v1] ether: fix overwriting driver-specific stats

[Remy Horton]

After doing a driver callout to fill in the driver specific
parts of struct rte_eth_stats, rte_eth_stats_get() overwrites
the rx_nombuf member regardless of whether the driver itself
has assigned a value. Any driver-assigned value should take
priority.

Fixes: af75078fece3 ("first public release")

Signed-off-by: Remy Horton 
---
 lib/librte_ether/rte_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 0a6e3f1..f62a9ec 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1490,8 +1490,8 @@ rte_eth_stats_get(uint8_t port_id, struct rte_eth_stats 
*stats)
memset(stats, 0, sizeof(*stats));

RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->stats_get, -ENOTSUP);
-   (*dev->dev_ops->stats_get)(dev, stats);
stats->rx_nombuf = dev->data->rx_mbuf_alloc_failed;
+   (*dev->dev_ops->stats_get)(dev, stats);
return 0;
 }

-- 
2.5.5

[dpdk-dev] SRIOV hot unplug

[Tetsuya Mukawa]

Hi Eli,

On 2016/07/18 17:47, Eli Britstein wrote:
> Hi Bernard,
> 
> Thank you for your answer.
> However, to do this, I have to have some communication protocol to the VM's 
> application in order for it to do this sequence and acknowledge that it is 
> now safe to proceed with detaching the device.
> This implies some kind of integration from the host side, which I would like 
> to avoid.

I guess you should have some kind of communication channel to notice the
hotpluging events from host to VM.

> Do you think might there be any other way for the application to handle such 
> event in a smooth way?

So far, I guess having one more virtio-net device will be easiest way.

Thanks,
Tetsuya

> 
> Thanks,
> Eli
> 
>> -Original Message-
>> From: Iremonger, Bernard [mailto:bernard.iremonger at intel.com]
>> Sent: Sunday, 17 July, 2016 11:53 PM
>> To: Eli Britstein; dev at dpdk.org
>> Cc: Iremonger, Bernard
>> Subject: RE: SRIOV hot unplug
>>
>> Hi Eli,
>>
>> The DPDK application in the VM should remove the slave device from the
>> bond device, stop, close and detach the device in the VM before doing "virsh
>> detach-device" from the host.
>>
>> Regards,
>>
>> Bernard.
>>
>>
>>> -Original Message-
>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Eli Britstein
>>> Sent: Sunday, July 17, 2016 9:58 AM
>>> To: dev at dpdk.org
>>> Subject: [dpdk-dev] SRIOV hot unplug
>>>
>>> Hello,
>>>
>>> A DPDK application with a DPDK bond device, with 2 slaves: one vnic,
>>> and another is a SRIOV VF connected as a pathrough.
>>> The bond device is configured as ACTIVE/BACKUP, and the primary is the
>>> VF slave.
>>> Now, I do "virsh detach-device" from the host, and the DPDK process in
>>> the VM gets segmentation fault, as it tries to poll an address that is
>>> not mmaped anymore.
>>> I wonder if this flow is supposed to be supported by DPDK, or not.
>>> Please advise.
>>>
>>> Thanks,
>>> Eli
>>> --
>>> 
>>> ---
>>> This email and any files transmitted and/or attachments with it are
>>> confidential and proprietary information of Toga Networks Ltd., and
>>> intended solely for the use of the individual or entity to whom they
>>> are addressed.
>>> If you have received this email in error please notify the system manager.
>>> This message contains confidential information of Toga Networks Ltd.,
>>> and is intended only for the individual named. If you are not the
>>> named addressee you should not disseminate, distribute or copy this
>>> e-mail. Please notify the sender immediately by e-mail if you have
>>> received this e-mail by mistake and delete this e-mail from your
>>> system. If you are not the intended recipient you are notified that
>>> disclosing, copying, distributing or taking any action in reliance on the
>> contents of this information is strictly prohibited.
>>> --
>>> 
>>> --
> 
> -
> This email and any files transmitted and/or attachments with it are 
> confidential and proprietary information of
> Toga Networks Ltd., and intended solely for the use of the individual or 
> entity to whom they are addressed.
> If you have received this email in error please notify the system manager. 
> This message contains confidential
> information of Toga Networks Ltd., and is intended only for the individual 
> named. If you are not the named
> addressee you should not disseminate, distribute or copy this e-mail. Please 
> notify the sender immediately
> by e-mail if you have received this e-mail by mistake and delete this e-mail 
> from your system. If you are not
> the intended recipient you are notified that disclosing, copying, 
> distributing or taking any action in reliance on
> the contents of this information is strictly prohibited.
> 
> 

[dpdk-dev] [PATCH] net/ena: fix icc compile error

[Ferruh Yigit]

On 7/19/2016 10:33 AM, Ferruh Yigit wrote:
> compile error:
>   CC ena_com.o
> .../drivers/net/ena/base/ena_com.c(346):
> error #3656: variable "dev_node" may be used before its value is set
> ENA_MEM_ALLOC_COHERENT_NODE(ena_dev->dmadev,
> ^
> 
> .../drivers/net/ena/base/ena_com.c(399):
> error #3656: variable "prev_node" may be used before its value is set
> ENA_MEM_ALLOC_COHERENT_NODE(ena_dev->dmadev,
> ^
> 
> Fixes: 3d3edc265fc8 ("net/ena: make coherent memory allocation NUMA-aware")
> 
> Reported-by: Eoin Breen 
> Signed-off-by: Ferruh Yigit 

Self-Nack
I wasn't aware Jan is already working on this and has a patch. We can
drop this one.

Thanks,
ferruh

[dpdk-dev] [PATCH v2] mk: fix FreeBSD build

[Ferruh Yigit]

On 7/18/2016 5:06 PM, Sergio Gonzalez Monroy wrote:
> The sed syntax of '0,/regexp/' is GNU specific and fails with
> non GNU sed in FreeBSD.
> 
> To solve the issue we can use awk instead to remove duplicates.
> 
> Fixes: b2063f104db7 ("mk: filter duplicate configuration entries")
> 
> Signed-off-by: Sergio Gonzalez Monroy 
> ---
> 
> v2:
> - Use temp var instead of temp file
> 
>  mk/rte.sdkconfig.mk | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
> index e93237f..c2b6e13 100644
> --- a/mk/rte.sdkconfig.mk
> +++ b/mk/rte.sdkconfig.mk
> @@ -88,11 +88,8 @@ $(RTE_OUTPUT)/.config: $(RTE_CONFIG_TEMPLATE) FORCE | 
> $(RTE_OUTPUT)
>   $(CPP) -undef -P -x assembler-with-cpp \
>   -ffreestanding \
>   -o $(RTE_OUTPUT)/.config_tmp $(RTE_CONFIG_TEMPLATE) ; \
> - for config in $$(grep -v "^#" $(RTE_OUTPUT)/.config_tmp | cut 
> -d"=" -f1 | sort | uniq -d); do \
> - while [ $$(grep "^$${config}=" 
> $(RTE_OUTPUT)/.config_tmp -c ) -gt 1 ]; do \
> - sed -i "0,/^$${config}=/{//d}" 
> $(RTE_OUTPUT)/.config_tmp; \
> - done; \
> - done; \
> + config=$$(grep -v "^#" $(RTE_OUTPUT)/.config_tmp) ; \
> + echo "$$config" | awk -F'=' '{a[$$1]=$$0} END {for (i in a) 
> print a[i]}' > $(RTE_OUTPUT)/.config_tmp ; \
This is another nice awk command.

A few comments about new command:
- Removes all comments from final config
- Spreads config option all over the file, logical grouping of options
removed.

When both happens at the same time, I have a concern that this may lead
missing some config options when somebody wants to update local config
file, but I am OK if everybody is OK.


>   if ! cmp -s $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config; 
> then \
>   cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config ; \
>   cp $(RTE_OUTPUT)/.config_tmp $(RTE_OUTPUT)/.config.orig 
> ; \
> 

[dpdk-dev] purifier

[Vladimir Medvedkin]

Hi all!

I decided to open my project's code. It is fast scalable transparent
statefull firewall which helps to mitigate transport layer DDoS attacks in
datacenter environment.

https://github.com/medvedv/purifier

It was written with dpdk1.7.1 and I hope to rewrite it with the current
stable version of DPDK soon.

-- 
Regards,
Vladimir

[dpdk-dev] [PATCH v4] doc: flow bifurcation guide on Linux

[Jingjing Wu]

Flow Bifurcation is a mechanism which uses features of advanced
Ethernet devices to split traffic between queues. It provides
the capability to let the kernel driver and DPDK driver co-exist
and take advantage of both.

It is achieved by using SR-IOV and the NIC's advanced filtering. This
patch describes Flow Bifurcation and adds the user guide for ixgbe
and i40e NICs.

Signed-off-by: Jingjing Wu 
---
v3 changes:
 - rename bifurcated driver to flow bifurcation.
 - move the doc from nics to howto.

v4 changes:
 - rework on John's comments about format.

 doc/guides/howto/flow_bifurcation.rst  | 299 +++
 doc/guides/howto/img/flow_bifurcation_overview.svg | 544 +
 doc/guides/howto/img/ixgbe_bifu_queue_idx.svg  | 101 
 doc/guides/howto/index.rst |   1 +
 4 files changed, 945 insertions(+)
 create mode 100644 doc/guides/howto/flow_bifurcation.rst
 create mode 100644 doc/guides/howto/img/flow_bifurcation_overview.svg
 create mode 100644 doc/guides/howto/img/ixgbe_bifu_queue_idx.svg

diff --git a/doc/guides/howto/flow_bifurcation.rst 
b/doc/guides/howto/flow_bifurcation.rst
new file mode 100644
index 000..a1c6262
--- /dev/null
+++ b/doc/guides/howto/flow_bifurcation.rst
@@ -0,0 +1,299 @@
+..  BSD LICENSE
+Copyright(c) 2016 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+Flow Bifurcation How-to Guide
+=
+
+Flow Bifurcation is a mechanism which uses hardware capable Ethernet devices
+to split traffic between Linux user space and kernel space. Since it is a
+hardware assisted feature this approach can provide line rate processing
+capability. Other than :ref:`KNI `, the software is just required to
+enable device configuration, there is no need to take care of the packet
+movement during the traffic split. This can yield better performance with
+less CPU overhead.
+
+The Flow Bifurcation splits the incoming data traffic to user space
+applications (such as DPDK applications) and/or kernel space programs (such as
+the Linux kernel stack). It can direct some traffic, for example data plane
+traffic, to DPDK, while directing some other traffic, for example control
+plane traffic, to the traditional Linux networking stack.
+
+There are a number of technical options to achieve this. A typical example is
+to combine the technology of SR-IOV and packet classification filtering.
+
+SR-IOV is a PCI standard that allows the same physical adapter to be split as
+multiple virtual functions. Each virtual function (VF) has separated queues
+with physical functions (PF). The network adapter will direct traffic to a
+virtual function with a matching destination MAC address. In a sense, SR-IOV
+has the capability for queue division.
+
+Packet classification filtering is a hardware capability available on most
+network adapters. Filters can be configured to direct specific flows to a
+given receive queue by hardware. Different NICs may have different filter
+types to direct flows to a Virtual Function or a queue that belong to it.
+
+In this way the Linux networking stack can receive specific traffic through
+the kernel driver while a DPDK application can receive specific traffic
+bypassing the Linux kernel by using drivers like VFIO or the DPDK ``igb_uio``
+module.
+
+.. _figure_flow_bifurcation_overview:
+
+.. figure:: img/flow_bifurcation_overview.*
+
+   Flow Bifurcation Overview
+
+
+Using Fl

[dpdk-dev] SRIOV hot unplug

[Eli Britstein]

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Tuesday, 19 July, 2016 5:49 AM
> To: Eli Britstein; dev at dpdk.org
> Cc: Iremonger, Bernard
> Subject: Re: [dpdk-dev] SRIOV hot unplug
>
> Hi Eli,
>
> On 2016/07/18 17:47, Eli Britstein wrote:
> > Hi Bernard,
> >
> > Thank you for your answer.
> > However, to do this, I have to have some communication protocol to the
> VM's application in order for it to do this sequence and acknowledge that it 
> is
> now safe to proceed with detaching the device.
> > This implies some kind of integration from the host side, which I would like
> to avoid.
>
> I guess you should have some kind of communication channel to notice the
> hotpluging events from host to VM.
[Eli Britstein]
In order just to notice the hotplugging events inside the VM, I can use add 
some udev action in the VM, in /etc/udev/rules.d/XXX
However, those are asynchronous events. The host proceeds with unplugging 
without waiting for the VM to acknowledge it.

>
> > Do you think might there be any other way for the application to handle
> such event in a smooth way?
>
> So far, I guess having one more virtio-net device will be easiest way.
[Eli Britstein]
Could you please elaborate your meaning? How do you mean to use this extra 
virtio-net device?

To clarify: I would like to have my bond device automatically set the vNIC as 
its primary, and close/remove the VF before it is unplugged.

Thanks,
Eli

>
> Thanks,
> Tetsuya
>
> >
> > Thanks,
> > Eli
> >
> >> -Original Message-
> >> From: Iremonger, Bernard [mailto:bernard.iremonger at intel.com]
> >> Sent: Sunday, 17 July, 2016 11:53 PM
> >> To: Eli Britstein; dev at dpdk.org
> >> Cc: Iremonger, Bernard
> >> Subject: RE: SRIOV hot unplug
> >>
> >> Hi Eli,
> >>
> >> The DPDK application in the VM should remove the slave device from
> >> the bond device, stop, close and detach the device in the VM before
> >> doing "virsh detach-device" from the host.
> >>
> >> Regards,
> >>
> >> Bernard.
> >>
> >>
> >>> -Original Message-
> >>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Eli Britstein
> >>> Sent: Sunday, July 17, 2016 9:58 AM
> >>> To: dev at dpdk.org
> >>> Subject: [dpdk-dev] SRIOV hot unplug
> >>>
> >>> Hello,
> >>>
> >>> A DPDK application with a DPDK bond device, with 2 slaves: one vnic,
> >>> and another is a SRIOV VF connected as a pathrough.
> >>> The bond device is configured as ACTIVE/BACKUP, and the primary is
> >>> the VF slave.
> >>> Now, I do "virsh detach-device" from the host, and the DPDK process
> >>> in the VM gets segmentation fault, as it tries to poll an address
> >>> that is not mmaped anymore.
> >>> I wonder if this flow is supposed to be supported by DPDK, or not.
> >>> Please advise.
> >>>
> >>> Thanks,
> >>> Eli
> >>> 
> >>> --
> >>> 
> >>> ---
> >>> This email and any files transmitted and/or attachments with it are
> >>> confidential and proprietary information of Toga Networks Ltd., and
> >>> intended solely for the use of the individual or entity to whom they
> >>> are addressed.
> >>> If you have received this email in error please notify the system
> manager.
> >>> This message contains confidential information of Toga Networks
> >>> Ltd., and is intended only for the individual named. If you are not
> >>> the named addressee you should not disseminate, distribute or copy
> >>> this e-mail. Please notify the sender immediately by e-mail if you
> >>> have received this e-mail by mistake and delete this e-mail from
> >>> your system. If you are not the intended recipient you are notified
> >>> that disclosing, copying, distributing or taking any action in
> >>> reliance on the
> >> contents of this information is strictly prohibited.
> >>> 
> >>> --
> >>> 
> >>> --
> >
> > --
> > --
> > - This email and any files transmitted and/or attachments with it
> > are confidential and proprietary information of Toga Networks Ltd.,
> > and intended solely for the use of the individual or entity to whom they are
> addressed.
> > If you have received this email in error please notify the system
> > manager. This message contains confidential information of Toga
> > Networks Ltd., and is intended only for the individual named. If you
> > are not the named addressee you should not disseminate, distribute or
> > copy this e-mail. Please notify the sender immediately by e-mail if
> > you have received this e-mail by mistake and delete this e-mail from your
> system. If you are not the intended recipient you are notified that 
> disclosing,
> copying, distributi

[dpdk-dev] [PATCH] net/virtio: fix crash on null dereference

[Yuanhan Liu]

The rxq/txq for the queue_release callback could be NULL, say when
rte_eth_dev_configure() fails that the queue is not setup at all.

Do a simple NULL check would fix the crash issue.

Fixes: 01ad44fd374f ("net/virtio: split Rx/Tx queue")

Reported-by: Olivier Matz 
Signed-off-by: Yuanhan Liu 
---
 drivers/net/virtio/virtio_rxtx.c | 30 ++
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index a27208e..2f967de 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -467,13 +467,19 @@ void
 virtio_dev_rx_queue_release(void *rxq)
 {
struct virtnet_rx *rxvq = rxq;
-   struct virtqueue *vq = rxvq->vq;
-   /* rxvq is freed when vq is freed, and as mz should be freed after the
+   struct virtqueue *vq;
+   const struct rte_memzone *mz;
+
+   if (rxvq == NULL)
+   return;
+
+   /*
+* rxvq is freed when vq is freed, and as mz should be freed after the
 * del_queue, so we reserve the mz pointer first.
 */
-   const struct rte_memzone *mz = rxvq->mz;
+   vq = rxvq->vq;
+   mz = rxvq->mz;

-   /* no need to free rxq as vq and rxq are allocated together */
virtio_dev_queue_release(vq);
rte_memzone_free(mz);
 }
@@ -553,12 +559,20 @@ void
 virtio_dev_tx_queue_release(void *txq)
 {
struct virtnet_tx *txvq = txq;
-   struct virtqueue *vq = txvq->vq;
-   /* txvq is freed when vq is freed, and as mz should be freed after the
+   struct virtqueue *vq;
+   const struct rte_memzone *mz;
+   const struct rte_memzone *hdr_mz;
+
+   if (txvq == NULL)
+   return;
+
+   /*
+* txvq is freed when vq is freed, and as mz should be freed after the
 * del_queue, so we reserve the mz pointer first.
 */
-   const struct rte_memzone *hdr_mz = txvq->virtio_net_hdr_mz;
-   const struct rte_memzone *mz = txvq->mz;
+   vq = txvq->vq;
+   mz = txvq->mz;
+   hdr_mz = txvq->virtio_net_hdr_mz;

virtio_dev_queue_release(vq);
rte_memzone_free(mz);
-- 
1.9.0

[dpdk-dev] crash in virtio pmd

[Yuanhan Liu]

On Mon, Jul 18, 2016 at 06:06:53PM +0200, Olivier Matz wrote:
> Hi,
> 
> On 16.07-rc3, when I start testpmd with a virtio driver in a VM,
> requesting options that are not implemented (rx checksum), it crashes:
> 
...

> Sorry, I have not a lot of time to investigate further, hope you can
> find the appropriate fix with the info above.

Nope, thanks for the report and detailed info. I think a simple NULL
check is enough here. Will send the fix soon.

--yliu

[dpdk-dev] [PATCH] net/ena: fix icc compile error

[Ferruh Yigit]

compile error:
  CC ena_com.o
.../drivers/net/ena/base/ena_com.c(346):
error #3656: variable "dev_node" may be used before its value is set
ENA_MEM_ALLOC_COHERENT_NODE(ena_dev->dmadev,
^

.../drivers/net/ena/base/ena_com.c(399):
error #3656: variable "prev_node" may be used before its value is set
ENA_MEM_ALLOC_COHERENT_NODE(ena_dev->dmadev,
^

Fixes: 3d3edc265fc8 ("net/ena: make coherent memory allocation NUMA-aware")

Reported-by: Eoin Breen 
Signed-off-by: Ferruh Yigit 
---
 drivers/net/ena/base/ena_com.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ena/base/ena_com.c b/drivers/net/ena/base/ena_com.c
index a3649d8..88053e3 100644
--- a/drivers/net/ena/base/ena_com.c
+++ b/drivers/net/ena/base/ena_com.c
@@ -329,7 +329,7 @@ static int ena_com_init_io_sq(struct ena_com_dev *ena_dev,
  struct ena_com_io_sq *io_sq)
 {
size_t size;
-   int dev_node;
+   int dev_node = 0;

ENA_TOUCH(ctx);

@@ -383,7 +383,7 @@ static int ena_com_init_io_cq(struct ena_com_dev *ena_dev,
  struct ena_com_io_cq *io_cq)
 {
size_t size;
-   int prev_node;
+   int prev_node = 0;

ENA_TOUCH(ctx);
memset(&io_cq->cdesc_addr, 0x0, sizeof(struct ena_com_io_desc_addr));
-- 
2.7.4

[dpdk-dev] [PATCH v3] i40: fix the VXLAN TSO issue

[Ananyev, Konstantin]

> 
> Problem:
> When using the TSO + VXLAN feature in i40e, the outer UDP length fields in 
> the multiple UDP segments which are TSOed by the i40e will
> have a wrong value.
> 
> Fix this problem by adding the tunnel type field in the i40e descriptor which 
> was missed before.
> 
> Fixes: 77b8301733c3 ("i40e: VXLAN Tx checksum offload")
> 
> Signed-off-by: Zhe Tao 
> ---
> v2: edited the comments
> v3: added external IP offload flag when TSO is enabled for tunnelling packets
> 
>  app/test-pmd/csumonly.c  | 29 +
>  drivers/net/i40e/i40e_rxtx.c | 12 +---
>  lib/librte_mbuf/rte_mbuf.h   | 16 +++-
>  3 files changed, 45 insertions(+), 12 deletions(-)
> 
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c index 
> ac4bd8f..aaa006f 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -204,7 +204,8 @@ parse_ethernet(struct ether_hdr *eth_hdr, struct 
> testpmd_offload_info *info)  static void  parse_vxlan(struct
> udp_hdr *udp_hdr,
>   struct testpmd_offload_info *info,
> - uint32_t pkt_type)
> + uint32_t pkt_type,
> + uint64_t *ol_flags)
>  {
>   struct ether_hdr *eth_hdr;
> 
> @@ -215,6 +216,7 @@ parse_vxlan(struct udp_hdr *udp_hdr,
>   RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0)
>   return;
> 
> + *ol_flags |= PKT_TX_TUNNEL_VXLAN;


Hmm, I don't actually see much difference between that version and the previous 
one.
 Regarding your comment on V2:
" this flag is for tunnelling type, and CTD is based on whether we need to do 
the
external ip offload and TSO.so this flag will not cause one extra CTD."
I think CTD selection should be based not only on is EIP cksum is enabled or 
not.
You can have tunneled packet with TSO on over IPv6, right?
I think for i40e we need CTD each time PKT_TX_TUNNEL_ is on.


>   info->is_tunnel = 1;
>   info->outer_ethertype = info->ethertype;
>   info->outer_l2_len = info->l2_len;
> @@ -231,7 +233,9 @@ parse_vxlan(struct udp_hdr *udp_hdr,
> 
>  /* Parse a gre header */
>  static void
> -parse_gre(struct simple_gre_hdr *gre_hdr, struct testpmd_offload_info *info)
> +parse_gre(struct simple_gre_hdr *gre_hdr,
> +   struct testpmd_offload_info *info,
> +   uint64_t *ol_flags)
>  {
>   struct ether_hdr *eth_hdr;
>   struct ipv4_hdr *ipv4_hdr;
> @@ -242,6 +246,8 @@ parse_gre(struct simple_gre_hdr *gre_hdr, struct 
> testpmd_offload_info *info)
>   if ((gre_hdr->flags & _htons(~GRE_SUPPORTED_FIELDS)) != 0)
>   return;
> 
> + *ol_flags |= PKT_TX_TUNNEL_GRE;
> +
>   gre_len += sizeof(struct simple_gre_hdr);
> 
>   if (gre_hdr->flags & _htons(GRE_KEY_PRESENT)) @@ -417,7 +423,7 @@ 
> process_inner_cksums(void *l3_hdr, const struct
> testpmd_offload_info *info,
>   * packet */
>  static uint64_t
>  process_outer_cksums(void *outer_l3_hdr, struct testpmd_offload_info *info,
> - uint16_t testpmd_ol_flags)
> + uint16_t testpmd_ol_flags, uint64_t orig_ol_flags)
>  {
>   struct ipv4_hdr *ipv4_hdr = outer_l3_hdr;
>   struct ipv6_hdr *ipv6_hdr = outer_l3_hdr; @@ -428,7 +434,8 @@ 
> process_outer_cksums(void *outer_l3_hdr, struct
> testpmd_offload_info *info,
>   ipv4_hdr->hdr_checksum = 0;
>   ol_flags |= PKT_TX_OUTER_IPV4;
> 
> - if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM)
> + if ((testpmd_ol_flags & TESTPMD_TX_OFFLOAD_OUTER_IP_CKSUM) ||
> + (info->tso_segsz != 0))
>   ol_flags |= PKT_TX_OUTER_IP_CKSUM;

Why do you need to always raise OUTER_IP_CKSUM when TSO is enabled?

>   else
>   ipv4_hdr->hdr_checksum = rte_ipv4_cksum(ipv4_hdr); @@ 
> -442,6 +449,9 @@ process_outer_cksums(void
> *outer_l3_hdr, struct testpmd_offload_info *info,
>* hardware supporting it today, and no API for it. */
> 
>   udp_hdr = (struct udp_hdr *)((char *)outer_l3_hdr + info->outer_l3_len);
> + if ((orig_ol_flags & PKT_TX_TCP_SEG) &&
> + ((orig_ol_flags & PKT_TX_TUNNEL_MASK) == PKT_TX_TUNNEL_VXLAN))
> + udp_hdr->dgram_cksum = 0;
>   /* do not recalculate udp cksum if it was 0 */
>   if (udp_hdr->dgram_cksum != 0) {
>   udp_hdr->dgram_cksum = 0;
> @@ -705,15 +715,18 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
>   if (info.l4_proto == IPPROTO_UDP) {
>   struct udp_hdr *udp_hdr;
>   udp_hdr = (struct udp_hdr *)((char *)l3_hdr +
> - info.l3_len);
> - parse_vxlan(udp_hdr, &info, m->packet_type);
> +info.l3_len);
> + parse_vxlan(udp_hdr, &info, m->packet_type,
> + &ol_flags);
>   } else if (info.l4_proto == IPPROTO_GRE) {
>   struc

[dpdk-dev] dpdk daily build error on dpdk16.07-rc2

[Liu, Yu Y]

Hi All,

Patches for below two issues are verified by Yongjie.
dpdk16.07-rc2 compile error on FC18 & UB1204
ena compile error on UB1404 & FC20

Best Regards,
Yu Liu

From: Gu, YongjieX
Sent: Thursday, July 14, 2016 5:23 PM
To: thomas.monjalon at 6wind.com; Richardson, Bruce ; Yigit, Ferruh ; Gonzalez Monroy, Sergio 
; Jan Medala ; dev at 
dpdk.org
Cc: Cao, Waterman ; Liu, Yu Y ; Chen, WeichunX ; Xu, HuilongX 
; Gu, YongjieX 
Subject: dpdk daily build error on dpdk16.07-rc2

Hi,All,
  There are 4 build errors reported by our dpdk daily report,and can you take a 
look on these issues.
  Jan is working on ena issues,and I will help to test it.

OS, Kernel , GCC , ICC

Affected Targets

Build errors

comments

FC18_64,3.6.10-4,4.7.2,14.0.0

x86_64-ivshmem-linuxapp-gcc

CC test_kvargs.o

UBT124_64,3.8.0-29,4.6.3,14.0.0

  LD test

SUSE11SP2_64,3.0.13-0,4.5.1,14.0.0

/jenkins/workspace/DPDK_AUTO_IDT_VM_FC18_64_BUILD2/DPDK/x86_64-ivshmem-linuxapp-gcc/lib/librte_eal.a(eal_alarm.o):
 In function `eal_alarm_callback':


eal_alarm.c:(.text+0xd7): undefined reference to `clock_gettime'


/jenkins/workspace/DPDK_AUTO_IDT_VM_FC18_64_BUILD2/DPDK/x86_64-ivshmem-linuxapp-gcc/lib/librte_eal.a(eal_alarm.o):
 In function `rte_eal_alarm_set':


eal_alarm.c:(.text+0x20f): undefined reference to `clock_gettime'


/jenkins/workspace/DPDK_AUTO_IDT_VM_FC18_64_BUILD2/DPDK/x86_64-ivshmem-linuxapp-gcc/lib/librte_eal.a(eal_timer.o):
 In function `get_tsc_freq':


eal_timer.c:(.text+0x108): undefined reference to `clock_gettime'


eal_timer.c:(.text+0x146): undefined reference to `clock_gettime'


collect2: error: ld returned 1 exit status


make[5]: *** [test] Error 1


make[4]: *** [test] Error 2


make[3]: *** [app] Error 2


make[2]: *** [all] Error 2


make[1]: *** [pre_install] Error 2


make: *** [install] Error 2



SUSE11SP2_64,3.0.13-0,4.5.1,14.0.0

x86_64-native-linuxapp-gcc-examples

== ipsec-secgw


  CC ipsec.o


  CC esp.o


  CC sp4.o


  CC sp6.o


  CC sa.o


/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/examples/ipsec-secgw/sa.c:56:2:
 error: unknown field 'ip4' specified in initializer


compilation terminated due to -Wfatal-errors.


make[4]: *** [sa.o] Error 1


make[3]: *** [all] Error 2


make[2]: *** [ipsec-secgw] Error 2


make[1]: *** [x86_64-native-linuxapp-gcc_examples] Error 2


make: *** [examples] Error 2



x86_64-native-linuxapp-icc-examples

== ipsec-secgw




x86_64-ivshmem-linuxapp-icc-examples

  CC ipsec.o




  CC esp.o




  CC sp4.o




  CC sp6.o




  CC sa.o




icc: command line warning #10158: ignoring option '-diag-disable'; argument 
must be separate




/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/examples/ipsec-secgw/sa.c(56):
 error: a designator for an anonymous union member can only appear within 
braces corresponding to that anonymous union




.src.ip4 = IPv4(172, 16, 1, 5),




 ^







compilation aborted for 
/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/examples/ipsec-secgw/sa.c
 (code 4)




make[4]: *** [sa.o] Error 4




make[3]: *** [all] Error 2




make[2]: *** [ipsec-secgw] Error 2




make[1]: *** [x86_64-native-linuxapp-icc_examples] Error 2




make: *** [examples] Error 2





UBT144_32,3.13.0-30,4.8.2,14.0.0

i686-native-linuxapp-icc

== Build drivers/net/ena






  CC ena_ethdev.o






  PMDINFO ena_ethdev.o.pmd.c






  CC ena_ethdev.o.pmd.o






  LD ena_ethdev.o






  CC ena_com.o






/jenkins/workspace/DPDK_AUTO_IDT_VM_UBT144_32_BUILD/DPDK/drivers/net/ena/base/ena_com.c(346):
 error #3656: variable "dev_node" may be used before its value is set






ENA_MEM_ALLOC_COHERENT_NODE(ena_dev->dmadev,






^









compilation aborted for 
/jenkins/workspace/DPDK_AUTO_IDT_VM_UBT144_32_BUILD/DPDK/drivers/net/ena/base/ena_com.c
 (code 4)






make[6]: *** [ena_com.o] Error 4






make[5]: *** [ena] Error 2






make[4]: *** [net] Error 2






make[3]: *** [drivers] Error 2






make[2]: *** [all] Error 2






make[1]: *** [pre_install] Error 2






make: *** [install] Error 2






freebsd10.3,10.3-RELEASE,4.8.5

x86_64-native-linuxapp-gcc

sed: 1: "/usr/home/xugang/dpdk-1 ...": extra characters at the end of h command


sed: 1: "/usr/home/xugang/dpdk-1 ...": extra characters at the end of h command


sed: 1: "/usr/home/xugang/dpdk-1 ...": extra characters at the end of h command


sed: 1: "/usr/home/xugang/dpdk-1 ...": extra characters at the end of h command


sed: 1: "/usr/home/xugang/dpdk-1 ...": extra characters at the end of h command


sed: 1: "/usr/home/xugang/dpdk-1 ...": extra characters at the end of h command


sed: 1: "/usr/home/xugang/dpdk-1 ...": extra characters at the end of h command


sed: 1: "/usr/home/xugang/dpdk-1 ...": extra characters at the end of h command


sed: 1: "/usr/home/xugang/dpdk-1 ...": extra characters at the end of h command


sed: 1: "/usr/home/xugang/dpdk-1 ...": extra characters at the end of h command


sed: 1: "/usr/home/xugang/dpdk-1 ...": extra characters at th

[dpdk-dev] [PATCH] net: virtio: clear reserved vring properly at setup time

[Yuanhan Liu]

On Mon, Jul 18, 2016 at 07:09:24PM +0200, Maxime Coquelin wrote:
> After vring reservation, only the first bytes of the vring were
> cleared.
> 
> This patch fixes this to clear the real size fo the vring.
> 
> Signed-off-by: Maxime Coquelin 
> ---
> 
> Note: I found this bug while doing some code review,

Nice catch!

> it is not a fix for
> a problem I encountered.

Yes, there should be no problem: vring memory is completely zero-ed
at port start stage by virtio_dev_vring_start().

> ---
>  drivers/net/virtio/virtio_ethdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c 
> b/drivers/net/virtio/virtio_ethdev.c
> index 850e3ba..336b3fc 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -387,7 +387,7 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
>   }
>   }
>  
> - memset(mz->addr, 0, sizeof(mz->len));
> + memset(mz->addr, 0, mz->len);

Actually, I think we could simply drop the memset here. It's redundant,
as stated.

And to Thomas, I don't find a good reason to have this in 16.07. Let's
delay the apply to v16.11.

--yliu

>   vq->vq_ring_mem = mz->phys_addr;
>   vq->vq_ring_virt_mem = mz->addr;
> -- 
> 2.7.4

[dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710 NICs for some RX mbuf sizes

[Xing, Beilei]

Hi Ceara,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Take Ceara
> Sent: Tuesday, July 19, 2016 12:14 AM
> To: Zhang, Helin 
> Cc: Wu, Jingjing ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-users] RSS Hash not working for XL710/X710
> NICs for some RX mbuf sizes
> 
> Hi Helin,
> 
> On Mon, Jul 18, 2016 at 5:15 PM, Zhang, Helin 
> wrote:
> > Hi Ceara
> >
> > Could you help to let me know your firmware version?
> 
> # ethtool -i p7p1 | grep firmware
> firmware-version: f4.40.35115 a1.4 n4.53 e2021
> 
> > And could you help to try with the standard DPDK example application,
> such as testpmd, to see if there is the same issue?
> > Basically we always set the same size for both rx and tx buffer, like the
> default one of 2048 for a lot of applications.
> 
> I'm a bit lost in the testpmd CLI. I enabled RSS, configured 2 RX queues per
> port and started sending traffic with single segmnet packets of size 2K but I
> didn't figure out how to actually verify that the RSS hash is correctly set..
> Please let me know if I should do it in a different way.
> 
> testpmd -c 0x331 -w :82:00.0 -w :83:00.0 -- --mbuf-size 2048 -i [...]
> 
> testpmd> port stop all
> Stopping ports...
> Checking link statuses...
> Port 0 Link Up - speed 4 Mbps - full-duplex Port 1 Link Up - speed 4
> Mbps - full-duplex Done
> 
> testpmd> port config all txq 2
> 
> testpmd> port config all rss all
> 
> testpmd> port config all max-pkt-len 2048 port start all
> Configuring Port 0 (socket 0)
> PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq.
> PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq.
> PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are
> satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=0.
> PMD: i40e_set_tx_function(): Vector tx finally be used.
> PMD: i40e_set_rx_function(): Using Vector Scattered Rx callback (port=0).
> Port 0: 3C:FD:FE:9D:BE:F0
> Configuring Port 1 (socket 0)
> PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq.
> PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq.
> PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are
> satisfied. Rx Burst Bulk Alloc function will be used on port=1, queue=0.
> PMD: i40e_set_tx_function(): Vector tx finally be used.
> PMD: i40e_set_rx_function(): Using Vector Scattered Rx callback (port=1).
> Port 1: 3C:FD:FE:9D:BF:30
> Checking link statuses...
> Port 0 Link Up - speed 4 Mbps - full-duplex Port 1 Link Up - speed 4
> Mbps - full-duplex Done
> 
> testpmd> set txpkts 2048
> testpmd> show config txpkts
> Number of segments: 1
> Segment sizes: 2048
> Split packet: off
> 
> 
> testpmd> start tx_first
>   io packet forwarding - CRC stripping disabled - packets/burst=32
>   nb forwarding cores=1 - nb forwarding ports=2
>   RX queues=1 - RX desc=128 - RX free threshold=32

In testpmd, when RX queues=1, RSS will be disabled, so could you re-configure 
rx queue(>1) and try again with testpmd?

Regards,
Beilei

>   RX threshold registers: pthresh=8 hthresh=8 wthresh=0
>   TX queues=2 - TX desc=512 - TX free threshold=32
>   TX threshold registers: pthresh=32 hthresh=0 wthresh=0
>   TX RS bit threshold=32 - TXQ flags=0xf01
> testpmd> stop
> Telling cores to stop...
> Waiting for lcores to finish...
> 
>   -- Forward statistics for port 0  --
>   RX-packets: 32 RX-dropped: 0 RX-total: 32
>   TX-packets: 32 TX-dropped: 0 TX-total: 32
>   
> 
>   -- Forward statistics for port 1  --
>   RX-packets: 32 RX-dropped: 0 RX-total: 32
>   TX-packets: 32 TX-dropped: 0 TX-total: 32
>   
> 
>   +++ Accumulated forward statistics for all
> ports+++
>   RX-packets: 64 RX-dropped: 0 RX-total: 64
>   TX-packets: 64 TX-dropped: 0 TX-total: 64
> 
> ++
> ++
> 
> Done.
> testpmd>
> 
> 
> >
> > Definitely we will try to reproduce that issue with testpmd, with using 2K
> mbufs. Hopefully we can find the root cause, or tell you that's not an issue.
> >
> 
> I forgot to mention that in my test code the TX/RX_MBUF_SIZE macros also
> include the mbuf headroom and the size of the mbuf structure.
> Therefore testing with 2K mbufs in my scenario actually creates mempools of
> objects of size 2K + sizeof(struct rte_mbuf) + RTE_PKTMBUF_HEADROOM.
> 
> > Thank you very much for your reporting!
> >
> > BTW, dev at dpdk.org should be the right one to replace users at dpdk.org,
> for sending questions/issues like this.
> 
> Thanks, I'll keep that in mind.
> 
>

[dpdk-dev] [PATCH v3 1/2] examples/ipsec-secgw: add configuration file support

[Sergio Gonzalez Monroy]

On 12/07/2016 10:44, Fan Zhang wrote:
> This patch adds the configuration file support to ipsec_secgw
> sample application. Instead of hard-coded rules, the users can
> specify their own SP, SA, and routing rules in the configuration
> file. An command line option "-f" is added to pass the
> configuration file location to the application.
>
> Configuration item formats:
>
> SP rule format:
> sp   esp \
>   
>
> SA rule format:
> sa   

I think we should be able to set the key also on config file for both 
cipher and auth.
Then we can check that the key size is the expected by the chosen 
cipher/auth algo.

I think we should also create and set the xforms dynamically instead of 
static as
they currently are (sa_add_rules function).

Sergio

> Routing rule format:
> rt
>
> Signed-off-by: Fan Zhang 
> ---

[dpdk-dev] DPDK Coverity issue 127559

[Mcnamara, John]

> -Original Message-
> From: Rahul Lakkireddy [mailto:rahul.lakkireddy at chelsio.com]
> Sent: Tuesday, July 19, 2016 9:16 AM
> To: Mcnamara, John ; dev at dpdk.org
> Cc: Kumar Sanghvi ; Nirranjan Kirubaharan
> ; Arjun V 
> Subject: Re: DPDK Coverity issue 127559
> 
> Hi all,
> 
> > 907 if (err)
> > 908 goto out;
> > 909
> > >>> CID 127559:(TAINTED_SCALAR)
> > >>> Assigning: "p" = "(u32 *)buf". Both are now tainted.
> > 910 for (p = (u32 *)buf; !err && aligned_len; aligned_len -= 4,
> p++) {
> > 911 err = eeprom_wr_phys(adapter, aligned_offset, *p);
> > 912 aligned_offset += 4;
> > 913 }
> > 914
> > 915 if (!err)
> >
> 
> I'm not an expert in Coverity and am having trouble understanding what the
> defect is and need some clarification.  Is it telling me that "buf"
> is being used without doing lower and upper bounds check?


Hi,

There is a lot more context when you view the defect through the Coverity web 
interface.

Basically it is saying that the data in buf comes from the user ("is tainted") 
and as such can't be trusted. Usually you need to provide some bound, or other, 
checks to protect against/untaint the data. However, in this case it looks like 
the data is coming from an eeprom rather than a "user" so it is probably a 
false positive.

However, you should look at the full context online and decide for yourself. 
Then update the status in the Coverity interface and add a comment on your 
decision.

John

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

[Lu, Wenzhuo]

Hi Adrien,
Thanks for your clarification.  Most of my questions are clear, but still 
something may need to be discussed, comment below.


> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Thursday, July 7, 2016 6:27 PM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org; Thomas Monjalon; Zhang, Helin; Wu, Jingjing; Rasesh Mody;
> Ajit Khaparde; Rahul Lakkireddy; Jan Medala; John Daley; Chen, Jing D; 
> Ananyev,
> Konstantin; Matej Vido; Alejandro Lucero; Sony Chacko; Jerin Jacob; De Lara
> Guarch, Pablo; Olga Shern
> Subject: Re: [RFC] Generic flow director/filtering/classification API
> 
> Hi Lu Wenzhuo,
> 
> Thanks for your feedback, I'm replying below as well.
> 
> On Thu, Jul 07, 2016 at 07:14:18AM +, Lu, Wenzhuo wrote:
> > Hi Adrien,
> > I have some questions, please see inline, thanks.
> >
> > > -Original Message-
> > > From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> > > Sent: Wednesday, July 6, 2016 2:17 AM
> > > To: dev at dpdk.org
> > > Cc: Thomas Monjalon; Zhang, Helin; Wu, Jingjing; Rasesh Mody; Ajit
> > > Khaparde; Rahul Lakkireddy; Lu, Wenzhuo; Jan Medala; John Daley;
> > > Chen, Jing D; Ananyev, Konstantin; Matej Vido; Alejandro Lucero;
> > > Sony Chacko; Jerin Jacob; De Lara Guarch, Pablo; Olga Shern
> > > Subject: [RFC] Generic flow director/filtering/classification API
> > >
> > >
> > > Requirements for a new API:
> > >
> > > - Flexible and extensible without causing API/ABI problems for existing
> > >   applications.
> > > - Should be unambiguous and easy to use.
> > > - Support existing filtering features and actions listed in `Filter 
> > > types`_.
> > > - Support packet alteration.
> > > - In case of overlapping filters, their priority should be well 
> > > documented.
> > Does that mean we don't guarantee the consistent of priority? The priority 
> > can
> be different on different NICs. So the behavior of the actions  can be 
> different.
> Right?
> 
> No, the intent is precisely to define what happens in order to get a 
> consistent
> result across different devices, and document cases with undefined behavior.
> There must be no room left for interpretation.
> 
> For example, the API must describe what happens when two overlapping filters
> (e.g. one matching an Ethernet header, another one matching an IP header)
> match a given packet at a given priority level.
> 
> It is documented in section 4.1.1 (priorities) as "undefined behavior".
> Applications remain free to do it and deal with consequences, at least they 
> know
> they cannot expect a consistent outcome, unless they use different priority
> levels for both rules, see also 4.4.5 (flow rules priority).
> 
> > Seems the users still need to aware the some details of the HW? Do we need
> to add the negotiation for the priority?
> 
> Priorities as defined in this document may not be directly mappable to HW
> capabilities (e.g. HW does not support enough priorities, or that some corner
> case make them not work as described), in which case the PMD may choose to
> simulate priorities (again 4.4.5), as long as the end result follows the
> specification.
> 
> So users must not be aware of some HW details, the PMD does and must
> perform the needed workarounds to suit their expectations. Users may only be
> impacted by errors while attempting to create rules that are either 
> unsupported
> or would cause them (or existing rules) to diverge from the spec.
The problem is sometime the priority of the filters is fixed according to HW's 
implementation. For example, on ixgbe, n-tuple has a higher priority than flow 
director. What's the right behavior of PMD if APP want to create a flow 
director rule which has a higher or even equal priority than an existing 
n-tuple rule? Should PMD return fail? 
If so, do we need more fail reasons? According to this RFC, I think we need 
return " EEXIST: collision with an existing rule. ", but it's not very clear, 
APP doesn't know the problem is priority, maybe more detailed reason is helpful.


> > > Behavior
> > > 
> > >
> > > - API operations are synchronous and blocking (``EAGAIN`` cannot be
> > >   returned).
> > >
> > > - There is no provision for reentrancy/multi-thread safety, although 
> > > nothing
> > >   should prevent different devices from being configured at the same
> > >   time. PMDs may protect their control path functions accordingly.
> > >
> > > - Stopping the data path (TX/RX) should not be necessary when managing
> flow
> > >   rules. If this cannot be achieved naturally or with workarounds (such as
> > >   temporarily replacing the burst function pointers), an appropriate error
> > >   code must be returned (``EBUSY``).
> > PMD cannot stop the data path without adding lock. So I think if some rules
> cannot be applied without stopping rx/tx, PMD has to return fail.
> > Or let the APP to stop the data path.
> 
> Agreed, that is the intent. If the PMD cannot touch flow rules for some reason
> even after 

[dpdk-dev] [PATCH] net: virtio: clear reserved vring properly at setup time

[Maxime Coquelin]

On 07/19/2016 03:39 AM, Yuanhan Liu wrote:
> On Mon, Jul 18, 2016 at 07:09:24PM +0200, Maxime Coquelin wrote:
>> After vring reservation, only the first bytes of the vring were
>> cleared.
>>
>> This patch fixes this to clear the real size fo the vring.
>>
>> Signed-off-by: Maxime Coquelin 
>> ---
>>
>> Note: I found this bug while doing some code review,
>
> Nice catch!
>
>> it is not a fix for
>> a problem I encountered.
>
> Yes, there should be no problem: vring memory is completely zero-ed
> at port start stage by virtio_dev_vring_start().

Ok, thanks for the pointer.

>
>> ---
>>  drivers/net/virtio/virtio_ethdev.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/virtio/virtio_ethdev.c 
>> b/drivers/net/virtio/virtio_ethdev.c
>> index 850e3ba..336b3fc 100644
>> --- a/drivers/net/virtio/virtio_ethdev.c
>> +++ b/drivers/net/virtio/virtio_ethdev.c
>> @@ -387,7 +387,7 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
>>  }
>>  }
>>
>> -memset(mz->addr, 0, sizeof(mz->len));
>> +memset(mz->addr, 0, mz->len);
>
> Actually, I think we could simply drop the memset here. It's redundant,
> as stated.
We can skip this patch then.

>
> And to Thomas, I don't find a good reason to have this in 16.07. Let's
> delay the apply to v16.11.
Yes, that's why I mentioned it didn't fixed any problem on my side.

So I propose we skip this patch, I'll resend one removing the memset for 
v16.11.

Thanks,
Maxime

>
>   --yliu
>
>>  vq->vq_ring_mem = mz->phys_addr;
>>  vq->vq_ring_virt_mem = mz->addr;
>> --
>> 2.7.4