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
