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
