Hi Chandrika we’ve been overwhelmed with higher priority activities, thus we had no time to handle this yet, did you open a feature request on github under “Issues”? Please do that to track it.
Alfredo > On 24 Mar 2017, at 09:38, Chandrika Gautam <[email protected]> > wrote: > > 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] <mailto:[email protected]>> wrote: > Hi Alfredo, > > Are these changes released? > > Regards > > On Fri, Dec 16, 2016 at 2:15 PM, Alfredo Cardigliano <[email protected] > <mailto:[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] >> <mailto:[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] <mailto:[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] >> <mailto:[email protected]>> wrote: >> >>> >>>> On 7 Dec 2016, at 06:59, Chandrika Gautam <[email protected] >>>> <mailto:[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] <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] <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
