Hi Alfredo, Are these changes released?
Regards On Fri, Dec 16, 2016 at 2:15 PM, Alfredo Cardigliano <[email protected]> wrote: > Hi Chandrika > since we have other activities to clone by the ned of the year and this > has lower priority > for us, we will probably come back on this by the end of Jan, please open > an issue on github > to keep track of the status. Thank you. > > Regards > Alfredo > > On 16 Dec 2016, at 04:57, Chandrika Gautam <[email protected]> > wrote: > > Hi Alfredo, > > When would you be able to release this change ? > > Regards, > Chandrika > > On Wed, Dec 7, 2016 at 9:35 PM, Chandrika Gautam < > [email protected]> wrote: > >> Yes I need only two tuple cluster hashing mechanism. I checked the PFRing >> code and made sense to disable the coherence flag. So I tested with latest >> package taken from GitHub and enable_frag_coherence set to 0 and it seems >> to be working fine. I will be doing some more testing to test this further. >> Thanks for your support ! >> >> Regards >> Chandrika >> >> Sent from my iPhone >> >> On Dec 7, 2016, at 7:53 PM, Alfredo Cardigliano <[email protected]> >> wrote: >> >> >> On 7 Dec 2016, at 06:59, Chandrika Gautam <[email protected]> >> wrote: >> >> Hi Alfredo, >> >> Shall I take the code from github ? >> >> >> Github or dev packages. >> >> Have you checked the point #2 also mentioned in my last email ? >> >> >> Out of order fragments are not handled atm, we will add it asap, however >> you said you are using a 2-tuple hash thus no need for the hash right? >> >> Alfredo >> >> >> Regards, >> Chandrika >> >> Sent from my iPhone >> >> On Nov 28, 2016, at 5:28 PM, Alfredo Cardigliano <[email protected]> >> wrote: >> >> Hi Chandrika >> 1. I reworked the hash to explicitly handle ip v4 vs v6 now, however the >> result should be the same as the non v4 portion in case of v4 should be >> 0’ed, thus not affecting the hash. >> 2. there is no need to comment the code, you just need to pass >> enable_frag_coherence=0 to pf_ring.ko (at insmod time, or using the >> configuration file if you are using packages) >> >> Alfredo >> >> On 23 Nov 2016, at 06:37, Chandrika Gautam <[email protected]> >> wrote: >> >> Hi Alfredo, >> >> While debugging this issue, I have found out two issues - >> >> 1. Below API using s6_addr32 which is an array of type uint32_t of size 4 >> and hence calculated hash gives a garbage value. >> I mentioned in my previous email that hash value getting generated >> are different and hash values are exceeding the Integer limit also >> Is there any specific reason to use s6_addr32 rather than using >> s6_addr. >> >> struct in6_addr { >> union { >> uint8_t __u6_addr8[16]; >> uint16_t __u6_addr16[8]; >> uint32_t __u6_addr32[4]; >> } __u6_addr; /* 128-bit IP6 address */ >> }; >> #define s6_addr __u6_addr.__u6_addr8 >> #ifdef _KERNEL /* XXX nonstandard */ >> #define s6_addr8 __u6_addr.__u6_addr8 >> #define s6_addr16 __u6_addr.__u6_addr16 >> #define s6_addr32 __u6_addr.__u6_addr32 >> #endif >> >> static inline u_int32_t hash_pkt(u_int16_t vlan_id, u_int8_t proto, >> ip_addr host_peer_a, ip_addr >> host_peer_b, >> u_int16_t port_peer_a, u_int16_t >> port_peer_b) >> { >> return(vlan_id+proto+ >> host_peer_a.v6.s6_addr32[0]+host_peer_a.v6.s6_addr32[1]+ >> host_peer_a.v6.s6_addr32[2]+host_peer_a.v6.s6_addr32[3]+ >> host_peer_b.v6.s6_addr32[0]+host_peer_b.v6.s6_addr32[1]+ >> host_peer_b.v6.s6_addr32[2]+host_peer_b.v6.s6_addr32[3]+ >> port_peer_a+port_peer_b); >> } >> >> So I changed the above code to below and it started giving a value which >> make sense. I matched the hash value generated for few packets manually and >> it is matching. >> >> static inline u_int32_t hash_pkt(u_int16_t vlan_id, u_int8_t proto, >> ip_addr host_peer_a, ip_addr >> host_peer_b, >> u_int16_t port_peer_a, u_int16_t >> port_peer_b) >> { >> return(vlan_id+proto+ >> host_peer_a.v6.s6_addr[0]+host_peer_a.v6.s6_addr[1]+ >> host_peer_a.v6.s6_addr[2]+host_peer_a.v6.s6_addr[3]+ >> host_peer_b.v6.s6_addr[0]+host_peer_b.v6.s6_addr[1]+ >> host_peer_b.v6.s6_addr[2]+host_peer_b.v6.s6_addr[3]+ >> port_peer_a+port_peer_b); >> } >> >> 2. Clustering logic is not working as expected for out of order >> fragments. >> If non first fragment received first, then below snippet of code will >> enqueue this packet to an index 0 always. >> Existing code creates an entry in hash only when first fragment is >> received. I tried to modified this code to first search a fragment in hash >> and if not found, then insert in into the hash irrespective of the order of >> the fragment. But It did not work for some reason. >> >> Before even working on that piece of code, for our requirement of using >> cluster_2_tuple, I feel that we don't even require to use the cluster >> fragment hash at all since we need only source and destination IP address >> which will be present in each and every packet >> including fragments also. >> >> So I went ahead commenting whole piece of below code and just used "skb_hash >> = hash_pkt_cluster(cluster_ptr, &hdr);" >> to calculate the hash and it seems to work perfect. Even this will remove >> the overhead of using hashing. >> >> if (enable_frag_coherence && fragment_not_first) { >> if (skb_hash == -1) { /* read hash once */ >> skb_hash = >> get_fragment_app_id(hdr.extended_hdr.parsed_pkt.ipv4_src, >> hdr.extended_hdr.parsed_pkt.ipv4_dst, ip_id, more_fragments); >> if (skb_hash < 0) >> skb_hash = 0; >> } >> } >> else if (!(enable_frag_coherence && first_fragment) || skb_hash == >> -1) { >> /* compute hash once for all clusters in case of first >> fragment */ >> skb_hash = hash_pkt_cluster(cluster_ptr, &hdr); >> >> if (skb_hash < 0) >> skb_hash = -skb_hash; >> >> if (enable_frag_coherence && first_fragment) { >> add_fragment_app_id(hdr.extended_hdr.parsed_pkt.ipv4_src, >> hdr.extended_hdr.parsed_pkt.ipv4_dst, >> ip_id, skb_hash % num_cluster_elements); >> } >> } >> >> >> Do you foresee any issue if we go ahead with the mentioned above changes? >> >> Regards, >> Gautam >> >> On Thu, Nov 17, 2016 at 4:40 PM, Alfredo Cardigliano < >> [email protected]> wrote: >> >>> Hi Gautam >>> I will come back on this asap. >>> >>> Alfredo >>> >>> On 17 Nov 2016, at 07:47, Chandrika Gautam < >>> [email protected]> wrote: >>> >>> Hi Guys, >>> >>> Please help to resolve this. >>> >>> Regards, >>> Gautam >>> >>> >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> >> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> >> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> >> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> >> > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc >
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
