> 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] > <mailto:[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] >>> <mailto:[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] >>> <mailto:[email protected]>> wrote: >>> Hi Gautam >>> I will come back on this asap. >>> >>> Alfredo >>> >>>> On 17 Nov 2016, at 07:47, Chandrika Gautam <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi Guys, >>>> >>>> Please help to resolve this. >>>> >>>> Regards, >>>> Gautam >>> >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> [email protected] <mailto:[email protected]> >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> [email protected] <mailto:[email protected]> >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] <mailto:[email protected]> >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> <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
