Hi Alfredo,
When would you be able to release this change ?
Regards,
Chandrika
On Wed, Dec 7, 2016 at 9:35 PM, Chandrika Gautam <
chandrika.iitd.rock@gmail.com> 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 <cardigliano@ntop.org>
> wrote:
>
>
> On 7 Dec 2016, at 06:59, Chandrika Gautam <chandrika.iitd.rock@gmail.com>
> 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 <cardigliano@ntop.org>
> 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 <chandrika.iitd.rock@gmail.com>
> 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 <cardigliano@ntop.org
> > wrote:
>
>> Hi Gautam
>> I will come back on this asap.
>>
>> Alfredo
>>
>> On 17 Nov 2016, at 07:47, Chandrika Gautam <chandrika.iitd.rock@gmail.com>
>> wrote:
>>
>> Hi Guys,
>>
>> Please help to resolve this.
>>
>> Regards,
>> Gautam
>>
>>
>>
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc@listgateway.unipi.it
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
When would you be able to release this change ?
Regards,
Chandrika
On Wed, Dec 7, 2016 at 9:35 PM, Chandrika Gautam <
chandrika.iitd.rock@gmail.com> 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 <cardigliano@ntop.org>
> wrote:
>
>
> On 7 Dec 2016, at 06:59, Chandrika Gautam <chandrika.iitd.rock@gmail.com>
> 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 <cardigliano@ntop.org>
> 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 <chandrika.iitd.rock@gmail.com>
> 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 <cardigliano@ntop.org
> > wrote:
>
>> Hi Gautam
>> I will come back on this asap.
>>
>> Alfredo
>>
>> On 17 Nov 2016, at 07:47, Chandrika Gautam <chandrika.iitd.rock@gmail.com>
>> wrote:
>>
>> Hi Guys,
>>
>> Please help to resolve this.
>>
>> Regards,
>> Gautam
>>
>>
>>
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc@listgateway.unipi.it
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>