Re: [dpdk-users] A confusion caused by the inconsistency in the source code of acl_gen.c. A possible bug?

[Wu, Xiaoban]

Dear James,

If it is only these two for-loops, then indeed the dfa[128] is never checked 
against the index, and it might be the problem.

But, before these two for-loops, there is one assignment

index = dfa[128];
*node_a++ = index;
for (x = QRANGE_MIN + 1; x < UINT8_MAX + 1; x++) {
if (dfa[x] != index) {
index = dfa[x];
*node_a++ = index;
node->transitions[m++] = (uint8_t)(x - 1);
}
}

for (x = 0; x < INT8_MAX + 1; x++) {
if (dfa[x] != index) {
index = dfa[x];
*node_a++ = index;
node->transitions[m++] = (uint8_t)(x - 1);
}
}

for (; m < RTE_ACL_QUAD_SIZE; m++)
node->transitions[m] = INT8_MAX;


Hence, it starts with the comparison between dfa[128] and dfa[129], and finally 
ends up with the comparison between index and dfa[127]. The only thing left 
behind is the comparison between index and dfa[128], but for the purpose of 
this part of the codes, we don't need to have such comparison.

Actually, since this part is used to generate several ranges (maximum 4) for 
transition and dfa[128] has been already written into the transition target 
(*node_a++ = index), and with "node->transitions[m] = INT8_MAX;" for 
completion, so I think logically it is correct.

Once again, thanks very much for clearing off my confusion.

Best wishes,
Xiaoban



From: James Cape 
Sent: Wednesday, February 8, 2017 1:44:56 PM
To: Wu, Xiaoban; users@dpdk.org
Subject: Re: [dpdk-users] A confusion caused by the inconsistency in the source 
code of acl_gen.c. A possible bug?


Please note there's still a bug in this function if dfa[128] is not some kind 
of magic value, because that position will never be checked against the "index" 
variable.


James Cape  Platform Team
IEX Group, Inc.  |  4 World Trade Center, 150 Greenwich St, 44th Floor, New 
York, NY 10007  |  w. 646.343.2242  |  
www.iextrading.com


From: Wu, Xiaoban 
Sent: Wednesday, February 8, 2017 1:41:03 PM
To: James Cape; users@dpdk.org
Subject: Re: [dpdk-users] A confusion caused by the inconsistency in the source 
code of acl_gen.c. A possible bug?


Dear James,


Thank you very much for your reply. You are right, I am so sorry that I did not 
pay attention to the difference between "x < UINT8_MAX + 1" and "x < INT8_MAX + 
1". The two for-loops will never overlap. The confusion now is cleared off.


Best wishes,

Xiaoban





From: James Cape 
Sent: Wednesday, February 8, 2017 9:18:43 AM
To: Wu, Xiaoban; users@dpdk.org
Subject: Re: [dpdk-users] A confusion caused by the inconsistency in the source 
code of acl_gen.c. A possible bug?


[Disclaimer: I'm not at all familiar with this code, or what it's doing, and 
I'm also probably an idiot [?] ]



I can't answer your specific question, but the loops aren't overlapping because 
QRANGE_MIN is defined as 0x80. However, it also looks like it's never going to 
check the (dfa[0x80] != index) case, because the +1's make the loops [0x081 - 
0x100), and [0x00 - 0x80).



James Cape  Platform Team
IEX Group, Inc.  |  4 World Trade Center, 150 Greenwich St, 44th Floor, New 
York, NY 10007  |  w. 646.343.2242  |  
www.iextrading.com


From: users  on behalf of Wu, Xiaoban 

Sent: Wednesday, February 8, 2017 3:26:14 AM
To: users@dpdk.org
Subject: [dpdk-users] A confusion caused by the inconsistency in the source 
code of acl_gen.c. A possible bug?

Dear DPDK users,


I have been reading and studying the source codes of the librte_acl, since I am 
very curious to know how to algorithmically implement a fast lookup process.


When I read the function acl_add_ptrs() in the acl_gen.c, there is one comment 
saying that

/*
* Rather than going from 0 to 256, the range count and
* the layout are from 80-ff then 0-7f due to signed compare
* for SSE (cmpgt).
*/


However, in the following codes, it is


  for (x = QRANGE_MIN + 1; x < UINT8_MAX + 1; x++) {
if (dfa[x] != index) {
index = dfa[x];
*node_a++ = index;
node->transitions[m++] = (uint8_t)(x - 1);
}
}

for (x = 0; x < INT8_MAX + 1; x++) {
if (dfa[x] != index) {
index = dfa[x];
*node_a++ = index;
node->transitions[m++] = (uint8_t)(x - 1);
}
}


As you can see that there are two for-loops, and the second for-loop include 
the first for-loop. And, this is not consistent with the comment. If the 
comment is followed, in the second for-loop, it should be "for (x = 0; x < 
QRANGE_MIN + 1; x++)", if we assume QRANGE_MIN is ff?


Moreover, due to that the first for-loop is included in the second for-loop and 
the "m" variable is increased by 1 whenever the if-statement is true, I am 
thinking about a case in which during the first for-loop, the "m" is increased 
by 3, hence after the second for-loop, the "m" is at least 6, this will finally 
break the check 

Re: [dpdk-users] Unable to bind intel NIC 82599ES to vfio-pci, uio_pci_generic

[Shyam Shrivastav]

Please ignore my previous messages. I was using command line options
wrongly, being my first day with dpdk, missed the "--" separating EAL and
app options, caught it only going through code !
Still I am unable to make vfio-pci work bind to ports, uio_pci_generic as
well as igb_uio are working.

Thanks and rgds
Shyam

Re: [dpdk-users] Need your help on pdump

[Pattan, Reshma]

Yes.

From: Clarylin L [mailto:clear...@gmail.com]
Sent: Tuesday, February 7, 2017 6:24 PM
To: Pattan, Reshma 
Subject: Re: Need your help on pdump

Hi Reshma,

Thank you for replying!

So if there's a failure to allocate memory for dpdk-pdump, instead of 
allocating more hugepages in the system, we could increase the memory for 
primary process. For example, if we are running testpmd as the primary, we 
could increase --socket-mem so that the hugepage memory for both processes is 
increased. Is that right?

Thanks,

Clarylin

On Tue, Feb 7, 2017 at 5:48 AM, Pattan, Reshma 
> wrote:
Hi,

Please see my comments inline.

Thanks,
Reshma

From: Clarylin L [mailto:clear...@gmail.com]
Sent: Friday, February 3, 2017 7:54 PM
To: Pattan, Reshma >
Subject: Need your help on pdump

Hi Reshma,

I am currently working on dpdk pdump and got some issues with it. Tried to 
research online but there were not many documents/discussions on it. On the 
mailing list I found you have been helping with someone on pdump, so drop you 
this email trying to seek help.


1. I believe dpdk-pdump would take hugepages. However, number of free 
hugepages does not change at all after dpdk-pdump start running. Is this 
expected?  for example, before starting dpdk-pdump, I have


[Reshma]: dpdk-pdump is a secondary process hence itself will not take any huge 
pages, instead it will be attached to the same huge page memory of the primary 
process.



host# cat /proc/meminfo | grep uge

AnonHugePages:712704 kB

HugePages_Total:1336

HugePages_Free:  661

HugePages_Rsvd:0

HugePages_Surp:0

Hugepagesize:   2048 kB

After dpdk-pdump starts (and it's running fine), the numbers remain the same.



2.   Since Hugepages do not change, it gives me no hint when "cannot 
reserve memory" error comes up on some system. Generally this error is due to 
insufficient hugepages. However, the system shows



[Reshma]: Though huge pages are available the reason for cannot reserve memory 
could be because they are not contiguous huge pages.

Please check the section 2.3.2.1 in 
http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html to allocate contiguous huge 
pages.





host# cat /proc/meminfo | grep uge

AnonHugePages:   1036288 kB

HugePages_Total: 768

HugePages_Free:  376

HugePages_Rsvd:0

HugePages_Surp:0

Hugepagesize:   2048 kB



3. Even when dpdk-pdump is running fine, I got quite a few "PDUMP: User 
mempool: insufficient data_len of mbuf "messages on the server side. I tried to 
increase the mbuf-size for dpdk-pdump and it didn't fix it.





[Reshma]: The mbuf size option that you pass to the dpdk-pdump command line 
option should be equal or greater than the packet size (This is related to the 
internals of design) .

So I suggest you try once again with enough size.





Appreciate your help. Thanks a lot.



Clarylin

Re: [dpdk-users] kni compile failed with Linux-3.10.0-514.6.1.el7.x86_64

[Thomas Monjalon]

2017-02-08 11:52, Cao Tong:
> hi,
> 
> KNI compile failed with kernel "Linux-3.10.0-514.6.1.el7.x86_64" under 
> CentOS 7.
> 
> DPDK version is 'dpdk-stable-16.07.2'

In order to build with recent kernel versions, you must use a recent DPDK 
version.

Please try 16.11 or master.

[dpdk-users] A confusion caused by the inconsistency in the source code of acl_gen.c. A possible bug?

[Wu, Xiaoban]

Dear DPDK users,


I have been reading and studying the source codes of the librte_acl, since I am 
very curious to know how to algorithmically implement a fast lookup process.


When I read the function acl_add_ptrs() in the acl_gen.c, there is one comment 
saying that

/*
* Rather than going from 0 to 256, the range count and
* the layout are from 80-ff then 0-7f due to signed compare
* for SSE (cmpgt).
*/


However, in the following codes, it is


  for (x = QRANGE_MIN + 1; x < UINT8_MAX + 1; x++) {
if (dfa[x] != index) {
index = dfa[x];
*node_a++ = index;
node->transitions[m++] = (uint8_t)(x - 1);
}
}

for (x = 0; x < INT8_MAX + 1; x++) {
if (dfa[x] != index) {
index = dfa[x];
*node_a++ = index;
node->transitions[m++] = (uint8_t)(x - 1);
}
}


As you can see that there are two for-loops, and the second for-loop include 
the first for-loop. And, this is not consistent with the comment. If the 
comment is followed, in the second for-loop, it should be "for (x = 0; x < 
QRANGE_MIN + 1; x++)", if we assume QRANGE_MIN is ff?


Moreover, due to that the first for-loop is included in the second for-loop and 
the "m" variable is increased by 1 whenever the if-statement is true, I am 
thinking about a case in which during the first for-loop, the "m" is increased 
by 3, hence after the second for-loop, the "m" is at least 6, this will finally 
break the check RTE_ACL_VERIFY(m <= RTE_ACL_QUAD_SIZE) in the following code, 
since RTE_ACL_QUAD_SIZE is 4. I am wondering if this case will ever happen?


Am I missing something here? Thanks very much for your help.


Best wishes,

Xiaoban