Hi Alfredo, Please let us know whether these changes are released or not.
Regards, On Fri, Feb 3, 2017 at 9:00 AM, Chandrika Gautam < [email protected]> wrote: > 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
