Re: [Ntop-misc] Possible bug on rss rehash
Hi Amir I am able to receive all the packets also with RSS=6,6,6,6 with the pcap you provided and pfcount_multichannel -r Alfredo On 02 Jul 2015, at 18:08, Amir Kaduri akadur...@gmail.com wrote: Hi Alfredo, I would like to add that I repeated the test with RSS=8,8,8,8,8,8,8,8 like you, and now it works. I guess that If you'll do it like with (with RSS 6) you'll notice the problem as well. Thanks, Amir On Thu, Jul 2, 2015 at 6:06 PM, Amir Kaduri akadur...@gmail.com mailto:akadur...@gmail.com wrote: Hi Alfredo, Per your suggestion, I've downloaded today the latest (dev) pf_ring code, compiled and repeated the test. Unfortunately, the problem repeats itself: without -r the pfcount_multichannel receives the packets, while with -r, it doesn't. Any thoughts will be much appreciated. Thanks, Amir On Wed, Jul 1, 2015 at 7:22 AM, Amir Kaduri akadur...@gmail.com mailto:akadur...@gmail.com wrote: Thank you Alfredo for your response. Soon I'll test again with latest code. Amir On Tue, Jun 30, 2015 at 7:54 PM, Alfredo Cardigliano cardigli...@ntop.org mailto:cardigli...@ntop.org wrote: Hi Amir sorry I didn’t have the testbed for testing this before, I ran some test with your traffic and your configuration (actually I used 8 RSS queues) and I am able to receive all traffic with pfcount_multichannel -r. Please try with latest code. Best Regards Alfredo On 02 Jun 2015, at 08:25, Amir Kaduri akadur...@gmail.com mailto:akadur...@gmail.com wrote: Hi Alfredo, Any chance that you'll take a look at this issue? At least give an indication whether its a real problem or not? Thanks, Amir On Wed, May 27, 2015 at 4:59 PM, Amir Kaduri akadur...@gmail.com mailto:akadur...@gmail.com wrote: I'll appreciate validating that the following is a real problem that I've found: Problem description: When I use the tester “pfcount_multichannel” with the –r argument (i.e. enable rss rehash), the application doesn’t receive the packets of some sessions. When I remove the “-r” argument from the command line, all packets received as expected. Additional information: 1. 1. I’m using pf_ring dev downloaded from github on 13/05/2015. 2. 2. The command-line I’m using is: pfcount_multichannel -i eth3 –r 3. 3. A sample pcap file of a single session, that I don’t receive its packets, can be found in the following link: https://drive.google.com/open?id=0B10Ms5GOXgCxbnJSUHNrUXhLazAauthuser=0 https://drive.google.com/open?id=0B10Ms5GOXgCxbnJSUHNrUXhLazAauthuser=0 4. 4. Machine has 24 cores. 5. 5. Eth3, the receiving interface, is configured to use 6 cores. 6. 6. Machine details: Linux 2.6.32-504.8.1.el6.x86_64 #1 SMP Wed Jan 28 21:11:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux 7. 7. Interface details: eth3 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01) Subsystem: Intel Corporation Ethernet Server Adapter X520-2 [8086:000c] MAC: 2, PHY: 12, SFP+: 6, PBA No: FF-0FF 8. 8. The ixgbe.ko has been loaded with RSS=6,6,6,6,6,6,6 9. 9. cat /proc/net/pf_ring/info PF_RING Version : 6.1.0 () Total rings : 6 Standard (non DNA/ZC) Options Ring slots : 4096 Slot version : 16 Capture TX : Yes [RX+TX] IP Defragment: No Socket Mode : Standard Total plugins: 0 Cluster Fragment Queue : 0 Cluster Fragment Discard : 0 Additional remarks: 1. 1. In function pfring_hash_pkt(..) in file pfring_utils.c, the fact that tunnel.tunneled_ip_src.v6.s6_addr32[0] is missing, looks like a bug. 2. 2. By reviewing the code, it looks that the functions hash_pkt_header(..) + hash_pkt(..) in file pf_ring.c, and function pfring_hash_pkt(..) in file pfring_utils.c, can somehow be unified. Regards, Amir ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it mailto:Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc http://listgateway.unipi.it/mailman/listinfo/ntop-misc ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it mailto:Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc http://listgateway.unipi.it/mailman/listinfo/ntop-misc ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc signature.asc Description: Message signed with OpenPGP using GPGMail ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc
Re: [Ntop-misc] Possible bug on rss rehash
Hi Alfredo, Per your suggestion, I've downloaded today the latest (dev) pf_ring code, compiled and repeated the test. Unfortunately, the problem repeats itself: without -r the pfcount_multichannel receives the packets, while with -r, it doesn't. Any thoughts will be much appreciated. Thanks, Amir On Wed, Jul 1, 2015 at 7:22 AM, Amir Kaduri akadur...@gmail.com wrote: Thank you Alfredo for your response. Soon I'll test again with latest code. Amir On Tue, Jun 30, 2015 at 7:54 PM, Alfredo Cardigliano cardigli...@ntop.org wrote: Hi Amir sorry I didn’t have the testbed for testing this before, I ran some test with your traffic and your configuration (actually I used 8 RSS queues) and I am able to receive all traffic with pfcount_multichannel -r. Please try with latest code. Best Regards Alfredo On 02 Jun 2015, at 08:25, Amir Kaduri akadur...@gmail.com wrote: Hi Alfredo, Any chance that you'll take a look at this issue? At least give an indication whether its a real problem or not? Thanks, Amir On Wed, May 27, 2015 at 4:59 PM, Amir Kaduri akadur...@gmail.com wrote: I'll appreciate validating that the following is a real problem that I've found: *Problem description:* When I use the tester “pfcount_multichannel” with the –r argument (i.e. enable rss rehash), the application doesn’t receive the packets of some sessions. When I remove the “-r” argument from the command line, all packets received as expected. *Additional information:* 1. 1. I’m using pf_ring dev downloaded from github on 13/05/2015. 2. 2. The command-line I’m using is: pfcount_multichannel -i eth3 –r 3. 3. A sample pcap file of a single session, that I don’t receive its packets, can be found in the following link: https://drive.google.com/open?id=0B10Ms5GOXgCxbnJSUHNrUXhLazAauthuser=0 4. 4. Machine has 24 cores. 5. 5. Eth3, the receiving interface, is configured to use 6 cores. 6. 6. Machine details: Linux 2.6.32-504.8.1.el6.x86_64 #1 SMP Wed Jan 28 21:11:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux 7. 7. Interface details: eth3 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01) Subsystem: Intel Corporation Ethernet Server Adapter X520-2 [8086:000c] MAC: 2, PHY: 12, SFP+: 6, PBA No: FF-0FF 8. 8. The ixgbe.ko has been loaded with RSS=6,6,6,6,6,6,6 9. 9. cat /proc/net/pf_ring/info PF_RING Version : 6.1.0 () Total rings : 6 Standard (non DNA/ZC) Options Ring slots : 4096 Slot version : 16 Capture TX : Yes [RX+TX] IP Defragment: No Socket Mode : Standard Total plugins: 0 Cluster Fragment Queue : 0 Cluster Fragment Discard : 0 *Additional remarks:* 1. 1. In function pfring_hash_pkt(..) in file pfring_utils.c, the fact that tunnel.tunneled_ip_src.v6.s6_addr32[0] is missing, looks like a bug. 2. 2. By reviewing the code, it looks that the functions hash_pkt_header(..) + hash_pkt(..) in file pf_ring.c, and function pfring_hash_pkt(..) in file pfring_utils.c, can somehow be unified. Regards, Amir ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc
Re: [Ntop-misc] Possible bug on rss rehash
Hi Alfredo, I would like to add that I repeated the test with RSS=8,8,8,8,8,8,8,8 like you, and now it works. I guess that If you'll do it like with (with RSS 6) you'll notice the problem as well. Thanks, Amir On Thu, Jul 2, 2015 at 6:06 PM, Amir Kaduri akadur...@gmail.com wrote: Hi Alfredo, Per your suggestion, I've downloaded today the latest (dev) pf_ring code, compiled and repeated the test. Unfortunately, the problem repeats itself: without -r the pfcount_multichannel receives the packets, while with -r, it doesn't. Any thoughts will be much appreciated. Thanks, Amir On Wed, Jul 1, 2015 at 7:22 AM, Amir Kaduri akadur...@gmail.com wrote: Thank you Alfredo for your response. Soon I'll test again with latest code. Amir On Tue, Jun 30, 2015 at 7:54 PM, Alfredo Cardigliano cardigli...@ntop.org wrote: Hi Amir sorry I didn’t have the testbed for testing this before, I ran some test with your traffic and your configuration (actually I used 8 RSS queues) and I am able to receive all traffic with pfcount_multichannel -r. Please try with latest code. Best Regards Alfredo On 02 Jun 2015, at 08:25, Amir Kaduri akadur...@gmail.com wrote: Hi Alfredo, Any chance that you'll take a look at this issue? At least give an indication whether its a real problem or not? Thanks, Amir On Wed, May 27, 2015 at 4:59 PM, Amir Kaduri akadur...@gmail.com wrote: I'll appreciate validating that the following is a real problem that I've found: *Problem description:* When I use the tester “pfcount_multichannel” with the –r argument (i.e. enable rss rehash), the application doesn’t receive the packets of some sessions. When I remove the “-r” argument from the command line, all packets received as expected. *Additional information:* 1. 1. I’m using pf_ring dev downloaded from github on 13/05/2015. 2. 2. The command-line I’m using is: pfcount_multichannel -i eth3 –r 3. 3. A sample pcap file of a single session, that I don’t receive its packets, can be found in the following link: https://drive.google.com/open?id=0B10Ms5GOXgCxbnJSUHNrUXhLazAauthuser=0 4. 4. Machine has 24 cores. 5. 5. Eth3, the receiving interface, is configured to use 6 cores. 6. 6. Machine details: Linux 2.6.32-504.8.1.el6.x86_64 #1 SMP Wed Jan 28 21:11:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux 7. 7. Interface details: eth3 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01) Subsystem: Intel Corporation Ethernet Server Adapter X520-2 [8086:000c] MAC: 2, PHY: 12, SFP+: 6, PBA No: FF-0FF 8. 8. The ixgbe.ko has been loaded with RSS=6,6,6,6,6,6,6 9. 9. cat /proc/net/pf_ring/info PF_RING Version : 6.1.0 () Total rings : 6 Standard (non DNA/ZC) Options Ring slots : 4096 Slot version : 16 Capture TX : Yes [RX+TX] IP Defragment: No Socket Mode : Standard Total plugins: 0 Cluster Fragment Queue : 0 Cluster Fragment Discard : 0 *Additional remarks:* 1. 1. In function pfring_hash_pkt(..) in file pfring_utils.c, the fact that tunnel.tunneled_ip_src.v6.s6_addr32[0] is missing, looks like a bug. 2. 2. By reviewing the code, it looks that the functions hash_pkt_header(..) + hash_pkt(..) in file pf_ring.c, and function pfring_hash_pkt(..) in file pfring_utils.c, can somehow be unified. Regards, Amir ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc
Re: [Ntop-misc] Possible bug on rss rehash
Hi Amir sorry I didn’t have the testbed for testing this before, I ran some test with your traffic and your configuration (actually I used 8 RSS queues) and I am able to receive all traffic with pfcount_multichannel -r. Please try with latest code. Best Regards Alfredo On 02 Jun 2015, at 08:25, Amir Kaduri akadur...@gmail.com wrote: Hi Alfredo, Any chance that you'll take a look at this issue? At least give an indication whether its a real problem or not? Thanks, Amir On Wed, May 27, 2015 at 4:59 PM, Amir Kaduri akadur...@gmail.com mailto:akadur...@gmail.com wrote: I'll appreciate validating that the following is a real problem that I've found: Problem description: When I use the tester “pfcount_multichannel” with the –r argument (i.e. enable rss rehash), the application doesn’t receive the packets of some sessions. When I remove the “-r” argument from the command line, all packets received as expected. Additional information: 1. 1. I’m using pf_ring dev downloaded from github on 13/05/2015. 2. 2. The command-line I’m using is: pfcount_multichannel -i eth3 –r 3. 3. A sample pcap file of a single session, that I don’t receive its packets, can be found in the following link: https://drive.google.com/open?id=0B10Ms5GOXgCxbnJSUHNrUXhLazAauthuser=0 https://drive.google.com/open?id=0B10Ms5GOXgCxbnJSUHNrUXhLazAauthuser=0 4. 4. Machine has 24 cores. 5. 5. Eth3, the receiving interface, is configured to use 6 cores. 6. 6. Machine details: Linux 2.6.32-504.8.1.el6.x86_64 #1 SMP Wed Jan 28 21:11:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux 7. 7. Interface details: eth3 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01) Subsystem: Intel Corporation Ethernet Server Adapter X520-2 [8086:000c] MAC: 2, PHY: 12, SFP+: 6, PBA No: FF-0FF 8. 8. The ixgbe.ko has been loaded with RSS=6,6,6,6,6,6,6 9. 9. cat /proc/net/pf_ring/info PF_RING Version : 6.1.0 () Total rings : 6 Standard (non DNA/ZC) Options Ring slots : 4096 Slot version : 16 Capture TX : Yes [RX+TX] IP Defragment: No Socket Mode : Standard Total plugins: 0 Cluster Fragment Queue : 0 Cluster Fragment Discard : 0 Additional remarks: 1. 1. In function pfring_hash_pkt(..) in file pfring_utils.c, the fact that tunnel.tunneled_ip_src.v6.s6_addr32[0] is missing, looks like a bug. 2. 2. By reviewing the code, it looks that the functions hash_pkt_header(..) + hash_pkt(..) in file pf_ring.c, and function pfring_hash_pkt(..) in file pfring_utils.c, can somehow be unified. Regards, Amir ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc signature.asc Description: Message signed with OpenPGP using GPGMail ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc
Re: [Ntop-misc] Possible bug on rss rehash
Hi Alfredo, Any chance that you'll take a look at this issue? At least give an indication whether its a real problem or not? Thanks, Amir On Wed, May 27, 2015 at 4:59 PM, Amir Kaduri akadur...@gmail.com wrote: I'll appreciate validating that the following is a real problem that I've found: *Problem description:* When I use the tester “pfcount_multichannel” with the –r argument (i.e. enable rss rehash), the application doesn’t receive the packets of some sessions. When I remove the “-r” argument from the command line, all packets received as expected. *Additional information:* 1. 1. I’m using pf_ring dev downloaded from github on 13/05/2015. 2. 2. The command-line I’m using is: pfcount_multichannel -i eth3 –r 3. 3. A sample pcap file of a single session, that I don’t receive its packets, can be found in the following link: https://drive.google.com/open?id=0B10Ms5GOXgCxbnJSUHNrUXhLazAauthuser=0 4. 4. Machine has 24 cores. 5. 5. Eth3, the receiving interface, is configured to use 6 cores. 6. 6. Machine details: Linux 2.6.32-504.8.1.el6.x86_64 #1 SMP Wed Jan 28 21:11:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux 7. 7. Interface details: eth3 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01) Subsystem: Intel Corporation Ethernet Server Adapter X520-2 [8086:000c] MAC: 2, PHY: 12, SFP+: 6, PBA No: FF-0FF 8. 8. The ixgbe.ko has been loaded with RSS=6,6,6,6,6,6,6 9. 9. cat /proc/net/pf_ring/info PF_RING Version : 6.1.0 () Total rings : 6 Standard (non DNA/ZC) Options Ring slots : 4096 Slot version : 16 Capture TX : Yes [RX+TX] IP Defragment: No Socket Mode : Standard Total plugins: 0 Cluster Fragment Queue : 0 Cluster Fragment Discard : 0 *Additional remarks:* 1. 1. In function pfring_hash_pkt(..) in file pfring_utils.c, the fact that tunnel.tunneled_ip_src.v6.s6_addr32[0] is missing, looks like a bug. 2. 2. By reviewing the code, it looks that the functions hash_pkt_header(..) + hash_pkt(..) in file pf_ring.c, and function pfring_hash_pkt(..) in file pfring_utils.c, can somehow be unified. Regards, Amir ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc
[Ntop-misc] Possible bug on rss rehash
I'll appreciate validating that the following is a real problem that I've found: *Problem description:* When I use the tester “pfcount_multichannel” with the –r argument (i.e. enable rss rehash), the application doesn’t receive the packets of some sessions. When I remove the “-r” argument from the command line, all packets received as expected. *Additional information:* 1. 1. I’m using pf_ring dev downloaded from github on 13/05/2015. 2. 2. The command-line I’m using is: pfcount_multichannel -i eth3 –r 3. 3. A sample pcap file of a single session, that I don’t receive its packets, can be found in the following link: https://drive.google.com/open?id=0B10Ms5GOXgCxbnJSUHNrUXhLazAauthuser=0 4. 4. Machine has 24 cores. 5. 5. Eth3, the receiving interface, is configured to use 6 cores. 6. 6. Machine details: Linux 2.6.32-504.8.1.el6.x86_64 #1 SMP Wed Jan 28 21:11:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux 7. 7. Interface details: eth3 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01) Subsystem: Intel Corporation Ethernet Server Adapter X520-2 [8086:000c] MAC: 2, PHY: 12, SFP+: 6, PBA No: FF-0FF 8. 8. The ixgbe.ko has been loaded with RSS=6,6,6,6,6,6,6 9. 9. cat /proc/net/pf_ring/info PF_RING Version : 6.1.0 () Total rings : 6 Standard (non DNA/ZC) Options Ring slots : 4096 Slot version : 16 Capture TX : Yes [RX+TX] IP Defragment: No Socket Mode : Standard Total plugins: 0 Cluster Fragment Queue : 0 Cluster Fragment Discard : 0 *Additional remarks:* 1. 1. In function pfring_hash_pkt(..) in file pfring_utils.c, the fact that tunnel.tunneled_ip_src.v6.s6_addr32[0] is missing, looks like a bug. 2. 2. By reviewing the code, it looks that the functions hash_pkt_header(..) + hash_pkt(..) in file pf_ring.c, and function pfring_hash_pkt(..) in file pfring_utils.c, can somehow be unified. Regards, Amir ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc
