Hi, > Version Details DPDK Version : 19.11.10 Architecture : s390x (Big-Endian) Linux OS Kernel : 5.4.0-128-generic Ubuntu Version : 18.04.6 LTS > Issue: We are using ACL Library apis as part of DPDK application. As part of our application we are trying to set following simple egress rule using function rte_acl_add_rules(): src: 0.0.0.0/0 dst: 0.0.0.0/0 src port: 0:65535 dst port: 1:65535 protocol/mask: 6/255 category mask: 1 priority: 1 userdata: 536870912 (0x20000000) The setting and building of rules are success. We are then passing tcp packet to check if the same is getting matched. When rte_acl_classify() is invoked with tcp(0x6) data as argument, we are getting result as 0 instead of 0x2. So, a mismatch on the protocol rule is observed and therefore packet is dropped on egress. > Additional Query: Also, Is it possible to tell what is and how wildness is calculated for each field in a rule? Can you provide some insights with the issue and query ? Also, I am new to this DPDK bugzilla, is it possible to share any forum/community where we can ask code-related queries (about the terms used in code) for the purpose of debugging ? Regards, Utsav
*** Bug 1186 has been marked as a duplicate of this bug. ***
*** Bug 1187 has been marked as a duplicate of this bug. ***
*** Bug 1188 has been marked as a duplicate of this bug. ***
Sorry my Mistake. I am new to bugzilla, I was updating query with more details and not sure how to do it. In doing so created multiple ticket.
*** Bug 1190 has been marked as a duplicate of this bug. ***
*** Bug 1191 has been marked as a duplicate of this bug. ***
You are opening a bug for s390x which is not merged upstream. Please ask around in your team and tell us why there is no follow-up on getting s390x upstream?
Hi Thomas Monjalon, Thank you for response. I have not come in contact with anyone in my team who has worked previously on dpdk yet. I will still try to find out and update here my findings. Please give me some time. By any chance do you have the request details and person name who was in contact earlier ? If yes, can you please share ? It will be easier to find out whether the person is still there or not. Regards, Utsav
You can check previous patches: https://patches.dpdk.org/project/dpdk/list/?state=*&q=s390&archive=both The emails are: David Miller <dmiller423@gmail.com> Mathew S Thoennes <tardis@us.ibm.com> Vivian Kong <vivkong@ca.ibm.com>
there is a special test-tool within dodk: test-acl that allows you to verify does acl works correctly with your ipv4/ipv6 5 tuple rules. Let say for your example: $ cat ./t2.rule @0.0.0.0/0 0.0.0.0/0 0 : 65535 1 : 65535 0x06/0xFF $ cat ./t2.trace 0x02010204 0x10200103 100 100 6 0 0 0 1 6 0 0 0 0 6 $ ./x86_64-default-linuxapp-gcc-dbg/app/dpdk-test-acl --lcores=15 --no-pci --no-huge --log-level=acl,debug -- --rulesf=./t2.rule --tracef=./t2.trace .... ipv4_5tuple: 1, category: 0, result: 0 ipv4_5tuple: 2, category: 0, result: 0 ipv4_5tuple: 3, category: 0, result: 4294967295 search_ip5tuples_once(1, 256, default) returns 3 search_ip5tuples @lcore 15: 1 iterations, 3 pkts, 1 categories, 49068 cycles (0.00 sec), 16356.00 cycles/pkt, 110051.36 pkt/sec As you can see, all quieries finished as epxected - first two returned rule idx that matches (zero), last one failed - as there is no match for it. If you believe there is a bug in ACL lib, can you try to reproduce it with test-acl?
Thank you Konstantin Ananyev for your response. I am able to find and compile testacl tool. But when I am running it on our platform I am getting error as below: EAL: FATAL: Cannot get hugepage information. EAL: Cannot get hugepage information. PANIC in main(): Cannot init EAL Do you have any documentation about installation and running process of test-acl ?
Hi Konstantin Ananyev, Regarding the test-tool, Can you please clarify following understanding: Packet1 is a mismatch (result:0) because Destination Port is not 1 Packet2 should be a match because Destination Port is 1 and Protocol also is 6. Packet2 should be a mismatch because Destination Port is 0 . Shouldn't the result be like: ipv4_5tuple: 1, category: 0, result: 0 ipv4_5tuple: 2, category: 0, result: 0xFFFFFFFF ipv4_5tuple: 3, category: 0, result: 0
(In reply to Utsav . from comment #12) > Hi Konstantin Ananyev, > > Regarding the test-tool, Can you please clarify following understanding: > > Packet1 is a mismatch (result:0) because Destination Port is not 1 > Packet2 should be a match because Destination Port is 1 and Protocol also is > 6. > Packet*3 should be a mismatch because Destination Port is 0 . > > Shouldn't the result be like: > ipv4_5tuple: 1, category: 0, result: 0 > ipv4_5tuple: 2, category: 0, result: 0xFFFFFFFF > ipv4_5tuple: 3, category: 0, result: 0
Sorry, my misunderstanding . Got it clarified. I am able to run the test tool on my system. I am getting all mismatch. ipv4_5tuple: 1, category: 0, result: 4294967295 ipv4_5tuple: 2, category: 0, result: 4294967295 ipv4_5tuple: 3, category: 0, result: 4294967295
then it means that either test-acl or even acl lib itself is not working properly on your platform. Can I ask you to try few other things: 1) run exactly the same test but with extra cmd-line parameter: '--alg=scalar' 2) run ACL auto-test: $ echo acl_autotest | ./x86_64-default-linuxapp-gcc-dbg/app/test/dpdk-test --lcores=15 --no-pci --no-huge --log-level=acl,debug and see what would be the output.
$ sudo ./testacl --no-pci --no-huge --log-level=acl,debug -- --rulesf=./t2.rule --tracef=./t2.trace --alg=scalar ... dump_config: rulesf:./t2.rule tracef:./t2.trace rulenum:65536 tracenum:65536 tracestep:256 bldcat:3 runcat:1 maxsize:0 iter:1 verbose:3 alg:1(scalar) ipv6:0 ACL: Gen phase for ACL "TESTACL": runtime memory footprint on socket -1: single nodes/bytes used: 4/32 quad nodes/vectors/bytes used: 1/4/32 DFA nodes/group64/bytes used: 1/4/4104 match nodes/bytes used: 1/128 total: 6496 bytes max limit: 18446744073709551615 bytes ACL: Build phase for ACL "TESTACL": node limit for tree split: 2048 nodes created: 7 memory consumed: 8388615 ACL: trie 0: number of rules: 1, indexes: 2 rte_acl_build(3) finished with 0 acl context <TESTACL>@0x103adda80 socket_id=-1 alg=1 max_rules=65536 rule_size=96 num_rules=1 num_categories=3 num_tries=1 ipv4_5tuple: 1, category: 0, result: 4294967295 ipv4_5tuple: 2, category: 0, result: 4294967295 ipv4_5tuple: 3, category: 0, result: 4294967295 search_ip5tuples_once(1, 256, scalar) returns 3 search_ip5tuples @lcore 1: 1 iterations, 3 pkts, 1 categories, 37888 cycles, 12629.333333 cycles/pkt ... $ echo acl_autotest | sudo ./test --no-pci --no-huge --log-level=acl,debug ... APP: HPET is not enabled, using TSC as default timer RTE>>acl_autotest ACL: rte_acl_ipv4vlan_add_rules: rule #1 is invalid ACL: rte_acl_ipv4vlan_add_rules: rule #1 is invalid ACL: rte_acl_ipv4vlan_add_rules: rule #1 is invalid ACL: rte_acl_ipv4vlan_add_rules: rule #1 is invalid ACL: Gen phase for ACL "acl_ctx": runtime memory footprint on socket -1: single nodes/bytes used: 4/32 quad nodes/vectors/bytes used: 0/0/0 DFA nodes/group64/bytes used: 1/4/4104 match nodes/bytes used: 1/128 total: 6464 bytes max limit: 18446744073709551615 bytes ACL: Build phase for ACL "acl_ctx": node limit for tree split: 2048 nodes created: 6 memory consumed: 8388615 ACL: trie 0: number of rules: 16, indexes: 2 ACL: Gen phase for ACL "acl_ctx": runtime memory footprint on socket -1: single nodes/bytes used: 30/240 quad nodes/vectors/bytes used: 30/104/832 DFA nodes/group64/bytes used: 6/19/11784 match nodes/bytes used: 6/768 total: 15824 bytes max limit: 18446744073709551615 bytes ACL: Build phase for ACL "acl_ctx": node limit for tree split: 2048 nodes created: 72 memory consumed: 8388615 ACL: trie 0: number of rules: 6000, indexes: 5 acl context <acl_ctx>@0x10275c9c0 socket_id=-1 alg=6 max_rules=196608 rule_size=128 num_rules=0 num_categories=0 num_tries=0 acl context <acl_ctx>@0x10275c9c0 socket_id=-1 alg=6 max_rules=196608 rule_size=128 num_rules=0 num_categories=0 num_tries=0 ACL: Gen phase for ACL "acl_ctx": runtime memory footprint on socket -1: single nodes/bytes used: 1171/9368 quad nodes/vectors/bytes used: 920/2794/22352 DFA nodes/group64/bytes used: 197/531/273928 match nodes/bytes used: 1093/139904 total: 447760 bytes max limit: 18446744073709551615 bytes ACL: Build phase for ACL "acl_ctx": node limit for tree split: 2048 nodes created: 3381 memory consumed: 8388615 ACL: trie 0: number of rules: 14, indexes: 3 ACL: trie 1: number of rules: 13, indexes: 5 Line 305: Error in allow results at 25 (expected 14 got 0)! Line 431, iter: 0: test_classify failed! Test Failed
Thanks for running more tests. So both are failing right? So first impression acl library doesn't work at that platform at all. That makes me wonder did we ever run any acl tests on powerpc platform? According to the git log we do have some specific AltiVec optimization for ACL classify methods, which makes me think at least ACL autotest has to pass on powerpc? Or is that platform differs somehow? Or ...?
Another ask for the author - can you rerun same tests with one of latest dpdk release (22.11)? I expect it to fail also, but for the sake of completeness it would be good to know for sure.
Hi Konstantin Ananyev, > So both are failing right? Yes. >That makes me wonder did we ever run any acl tests on powerpc platform? >According to the git log we do have some specific AltiVec optimization for ACL >classify methods, which makes me think at least ACL autotest has to pass on >powerpc? > Or is that platform differs somehow? Or ...? I am working on IBM zseries s390x. The above test are run on s390x architecture. I don't have any information on powerpc. >Another ask for the author - can you rerun same tests with one of latest dpdk >release (22.11)? Porting needs to be done for 22.11. The porting for current version was done by some team earlier and it seems that team is not available any more. I am still trying to get answers on this.
(In reply to Utsav . from comment #19) > Hi Konstantin Ananyev, > > > So both are failing right? > Yes. > > >That makes me wonder did we ever run any acl tests on powerpc platform? > >According to the git log we do have some specific AltiVec optimization for > ACL > >classify methods, which makes me think at least ACL autotest has to pass on > >powerpc? > > Or is that platform differs somehow? Or ...? > I am working on IBM zseries s390x. The above test are run on s390x > architecture. I don't have any information on powerpc. Yes, acl_autotest has run correctly on POWER systems. The recent segmentation fault issue reported in bug 1197 appears to be related to changes in more recent gcc versions rather than a functional issue in the Altivec optimized code section.
> That makes me wonder did we ever run any acl tests on powerpc platform? > According to the git log we do have some specific AltiVec optimization for > ACL classify methods, which makes me think at least ACL autotest has to pass > on powerpc? > Or is that platform differs somehow? Or ...? Ran the same test on POWER for reference: ./build/app/dpdk-test-acl --lcores=15 --no-pci --no-huge --log-level=acl,debug -- --rulesf=./t2.rule --tracef=./t2.trace EAL: Detected CPU lcores: 128 EAL: Detected NUMA nodes: 2 EAL: Static memory layout is selected, amount of reserved memory can be adjusted with -m or --socket-mem EAL: Detected static linkage of DPDK EAL: Multi-process socket /run/user/1000/dpdk/rte/mp_socket EAL: Selected IOVA mode 'VA' TELEMETRY: No legacy callbacks, legacy socket not created dump_config: rulesf:./t2.rule tracef:./t2.trace rulenum:65536 tracenum:65536 tracestep:256 bldcat:3 runcat:1 maxsize:0 iter:1 verbose:3 alg:0(default) ipv6:0 ACL: Gen phase for ACL "TESTACL": runtime memory footprint on socket -1: single nodes/bytes used: 3/24 quad nodes/vectors/bytes used: 2/6/48 DFA nodes/group64/bytes used: 1/4/4104 match nodes/bytes used: 1/128 total: 8560 bytes max limit: 18446744073709551615 bytes ACL: Build phase for ACL "TESTACL": node limit for tree split: 2048 nodes created: 7 memory consumed: 8388615 ACL: trie 0: number of rules: 1, indexes: 2 rte_acl_build(3) finished with 0 acl context <TESTACL>@0x103ae9a00 socket_id=-1 alg=5 first_load_sz=4 max_rules=65536 rule_size=96 num_rules=1 num_categories=3 num_tries=1 ipv4_5tuple: 1, category: 0, result: 0 ipv4_5tuple: 2, category: 0, result: 0 ipv4_5tuple: 3, category: 0, result: 4294967295 search_ip5tuples_once(1, 256, default) returns 3 search_ip5tuples @lcore 15: 1 iterations, 3 pkts, 1 categories, 6678 cycles (0.00 sec), 2226.00 cycles/pkt, 230008.98 pkt/sec Functional results seem to match x86 in this case.
Thanks David for confirming that it works on powerpc as expected. Sorry, it seems that at previous iteration I didn't read carefully previous comments. Ustav, so did I get it right - you are running some private port of DPDK for the platform that is not officially supported?
> Ustav, so did I get it right - you are running some private port of DPDK for > the platform that is not officially supported? There was a patch developed by IBM internally in 2019 and posted to the dev list here: https://patchwork.dpdk.org/project/dpdk/patch/20190409190630.31975-2-vivkong@ca.ibm.com/ The proposal didn't move forward at the time. Not sure which patchset Ustav might be using for his development.
> Ustav, so did I get it right - you are running some private port of DPDK for > the platform that is not officially supported? Yes, understanding is correct.
So the arch was never supported, and probably ACL library never worked on it. Considering that I don't know much about s390 arch, don't see how I can help with it at that stage.
Given the status of this architecture port, there is nothing more to do about this report. Closing as WONTFIX.