Re: [Ntop-misc] How to get pf_ring packets filtering statistics

[Alfredo Cardigliano]

Added to git code, please note stats are per socket, not per interface.

Alfredo

> On 16 Nov 2015, at 13:48, Amir Kaduri  wrote:
> 
> Hi Alfredo,
> 
> Having it per interface under /proc is excellent.
> 
> Thanks,
> Amir
> 
> On Mon, Nov 16, 2015 at 11:56 AM, Alfredo Cardigliano  > wrote:
> 
>> On 16 Nov 2015, at 10:53, Amir Kaduri > > wrote:
>> 
>> Hi Alfredo,
>> 
>>  
>> I reviewed the implementation of the feature (great!) and I would like to 
>> clarify please:
>> 
>> 1. If I understood it correctly, the number of matched packets is per given 
>> rule, while the number of missed packets is per ring (and not per the given 
>> rule). Is it correct, or am I wrong?
>> 
>>  If I’m correct, can I provide a dummy rule and get the number of missed 
>> packets on the given ring?
>> 
> Correct
>> 2. When reading “ethtool –S ethX | grep fdir_miss” or “ethtool –S ethX | 
>> grep fdir_match” you actually get the aggregation of missed/matched packets 
>> on the interface (ethX).
>> 
>>  Is it possible to get the pf_ring statistics aggregated as well, per 
>> interface, or at least per ring?
>> 
> Is it ok for you if we write this stats under /proc instead of adding another 
> API call?
> 
> Alfredo
> 
>>  
>> Thanks,
>> 
>> Amir
>> 
>> 
>> On Wed, Nov 11, 2015 at 8:01 PM, Alfredo Cardigliano > > wrote:
>> 
>>> On 11 Nov 2015, at 18:02, Amir Kaduri >> > wrote:
>>> 
>>> Two following questions please:
>>> 1. fdir_miss (of ethtool -S) continues to increase even if my process 
>>> doesn't apply the filter rules. Do you know what else causes it to increase 
>>> if its not a result of a filter?
>>> I didn't find an answer for it in the following doc: 
>>> https://www.kernel.org/doc/Documentation/networking/ixgbe.txt 
>>> 
>> Please have a look at the datasheet for all cases.
>> 
>>> 2. Should I expect the mentioned feature request to be implemented in 
>>> pf_ring soon, or its most probably be there with many other prioritized 
>>> requests?
>> 
>> It is in queue with other feature requests, we handle them in best effort,
>> however I think it will not require too much (1-2 weeks at most)
>> 
>> Alfredo
>> 
>>> 
>>> Thanks,
>>> Amir
>>> 
>>> On Tue, Nov 10, 2015 at 3:32 PM, Amir Kaduri >> > wrote:
>>> Thanks for the answer. It looks to me very essential statistics for 
>>> user-space applications.
>>> Github feature request: https://github.com/ntop/PF_RING/issues/52 
>>> 
>>> 
>>> Amir
>>> 
>>> 
>>> On Mon, Nov 9, 2015 at 7:34 PM, Alfredo Cardigliano >> > wrote:
>>> Hi Amir
>>> there is no statistics by default (unless you code your own kernel plugin 
>>> and read stats via pfring_get_hash_filtering_rule_stats, but this is 
>>> overkilling for match/miss counters),
>>> please open a feature request on github.
>>> 
>>> Alfredo
>>> 
 On 09 Nov 2015, at 18:28, Amir Kaduri > wrote:
 
 Hi,
 
 In my application, I’m using pf_ring hash software filters (API: 
 pfring_handle_hash_filtering_rule()).
 
 How can I get statistics info regarding the quantity of the filtered 
 packets?
 
 I know that on ixgbe module, I can get the following parameters when using 
 ethtool –s :
 
 fdir_match, fdir_miss, fdir_overflow.
 
 Are there any pf_ring user-space APIs to get these parameters? Any code 
 examples?
 
  
 
 Thanks,
 
 Amir
 
 ___
 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 
>> 
>> 
>> 

Re: [Ntop-misc] Compiling PF_RING as root

[wang]

Actually I am also think about this, as I compiled it as root but so far, it 
looks like everything is ok.

Wang

> On Nov 16, 2015, at 9:39 PM, Christiaan Schade 
>  wrote:
> 
> 
> You guys show a warning when compiling PF_RING as root:
> ** WARNING WARNING WARNING ** * * Compiling PF_RING as root might 
> lead you to compile errors * Please compile PF_RING as unpriviliged user * 
> *
> 
> I'm wondering what the idea behind this warning is... I think it's been there 
> for a long time, but I can't think of a reason why there would be a problem 
> when compiling as root, other than the fact
> that a later 'make clean' etc. also needs to be run as root
> .
> We've created a .deb package for PF_RING, which is installed/compiled by 
> dpkg. When dpkg compiles PF_RING, it does so as the root user.
> 
> So far it has never caused problems, but I'd like to know if there's some 
> scenario where this could lead to problems.
> 
> Thank you,
> 
> Chris
> 
> -- 
> 
> ATTENTION:
> The information in this email message is confidential and may be legally
> privileged. It is intended solely for the addressee.
> 
> Should you receive this message by mistake, you are hereby notified that
> any disclosure, reproduction, distribution or use of this
> message is prohibited and may be unlawful.
> ___
> 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

Re: [Ntop-misc] Maximum limit of pfring_open

[Alfredo Cardigliano]

> On 16 Nov 2015, at 12:59, K Rahul  wrote:
> 
> On 11/13/2015 02:32 PM, Alfredo Cardigliano wrote:
>> Hi Rahul
>> did you set the default policy to drop?
>> 
>> pfring_toggle_filtering_policy(ring, 0);
>> 
>> Alfredo
>> 
>>> On 10 Nov 2015, at 11:39, K Rahul  wrote:
>>> 
>>> On 11/10/2015 01:35 PM, Alfredo Cardigliano wrote:
 Hi Raul
 any reason you are not using native pfring filters? They are more 
 efficient than bpf. See pfring_add_filtering_rule in pfcount.c as example. 
 You can change them at runtime.
 
 Alfredo
 
> On 10 Nov 2015, at 07:24, K Rahul  wrote:
> 
> On 11/06/2015 08:31 PM, Alfredo Cardigliano wrote:
>> Rahul
>> do you really need all those sockets, it looks like a bad design choice.
>> 
>> Alfredo
>> 
>>> On 06 Nov 2015, at 15:59, K Rahul  
>>> wrote:
>>> 
>>> On 11/05/2015 05:29 PM, K Rahul wrote:
 On 11/04/2015 08:58 PM, Alfredo Cardigliano wrote:
> Hi Rahul
> you should increase MAX_NUM_RING_SOCKETS in kernel/linux/pf_ring.h,
> currently it is set to 128.
> 
> Alfredo
> 
>> On 04 Nov 2015, at 16:00, K Rahul  
>> wrote:
>> 
>> Hi,
>> 
>> we are using pfring to capture multicast packets. We are not using 
>> DNA or ZC drivers as our NIC does not support the same.We are using 
>> Broadcom Netxtreme BCM5721 NIC. If I use pfring_open more than 64 
>> times, i.e  pfring_open is called for 64 different multicast 
>> streams, then it returns a NULL. Is there any limit to pfring 
>> handles? If there is a limit, how can I increase it?
>> 
>> Thanks
>> 
>> Regards,
>> Rahul
>> ___
>> 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
 Thank you for the prompt reply
 ___
 Ntop-misc mailing list
 Ntop-misc@listgateway.unipi.it
 http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>> Hi,
>>> 
>>> We have increased the limit of MAX_NUM_RING_SOCKETS to 128 from 64. 
>>> Now, after opening 50 handles and more we are observing packet drops. 
>>> Is there any other variable that need to be handle to capture all the 
>>> packets?
>>> 
>>> Thank you
>>> 
>>> Regards,
>>> K Rahul
>>> ___
>>> 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
> Hi,
> 
> Let me explain you the use of pfring in our module. We are using pfring 
> to capture mpeg2ts streams over multicast. We can have multiple multicast 
> streams joined and each one of these streams uses one pfring handle. Thus 
> as per our current design, if we need to capture 100 multicast streams, 
> we will require 100 pfring sockets, each with a specific bpf filter like 
> "udp and dst port  and src host (172.16.0.10) and dst host 
> 239.99.99.99".
> 
> The reason for choosing such a model is that our module can join or leave 
> multicast streams in runtime.For ex, if we are capturing a multicast 
> stream, we set the bpf filter specific to the stream. Now, in case we 
> need to capture another multicast stream using the same pfring handle, we 
> will need to modify the bpf filter at runtime. As per our current 
> understanding, this is not feasible. Thus, we decided to use one pfring 
> socket per multicast stream.
> 
> It would be very helpful if you can suggest any alternative approach.
> 
> Thank you
> 
> Regards,
> K Rahul
> ___
> 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
>>> Thank you for the reply Alfredo. I am trying to use 
>>> pfring_add_filtering_rule as you suggested.
>>> I want to receive all UDP with multicast IP 236.66.66.66 and dst_port = 
>>> 6663 and 

Re: [Ntop-misc] How to get pf_ring packets filtering statistics

[Amir Kaduri]

Hi Alfredo,

Having it per interface under /proc is excellent.

Thanks,
Amir

On Mon, Nov 16, 2015 at 11:56 AM, Alfredo Cardigliano 
wrote:

>
> On 16 Nov 2015, at 10:53, Amir Kaduri  wrote:
>
> Hi Alfredo,
>
>
> I reviewed the implementation of the feature (great!) and I would like to
> clarify please:
>
> 1. If I understood it correctly, the number of matched packets is per
> given rule, while the number of missed packets is per ring (and not per the
> given rule). Is it correct, or am I wrong?
>
>  If I’m correct, can I provide a dummy rule and get the number of
> missed packets on the given ring?
>
> Correct
>
> 2. When reading “ethtool –S ethX | grep fdir_miss” or “ethtool –S ethX |
> grep fdir_match” you actually get the aggregation of missed/matched packets
> on the interface (ethX).
>
>  Is it possible to get the pf_ring statistics aggregated as well, per
> interface, or at least per ring?
>
> Is it ok for you if we write this stats under /proc instead of adding
> another API call?
>
> Alfredo
>
>
>
> Thanks,
>
> Amir
>
> On Wed, Nov 11, 2015 at 8:01 PM, Alfredo Cardigliano  > wrote:
>
>>
>> On 11 Nov 2015, at 18:02, Amir Kaduri  wrote:
>>
>> Two following questions please:
>> 1. fdir_miss (of ethtool -S) continues to increase even if my process
>> doesn't apply the filter rules. Do you know what else causes it to increase
>> if its not a result of a filter?
>> I didn't find an answer for it in the following doc:
>> https://www.kernel.org/doc/Documentation/networking/ixgbe.txt
>>
>>
>> Please have a look at the datasheet for all cases.
>>
>> 2. Should I expect the mentioned feature request to be implemented in
>> pf_ring soon, or its most probably be there with many other prioritized
>> requests?
>>
>>
>> It is in queue with other feature requests, we handle them in best effort,
>> however I think it will not require too much (1-2 weeks at most)
>>
>> Alfredo
>>
>>
>> Thanks,
>> Amir
>>
>> On Tue, Nov 10, 2015 at 3:32 PM, Amir Kaduri  wrote:
>>
>>> Thanks for the answer. It looks to me very essential statistics for
>>> user-space applications.
>>> Github feature request: https://github.com/ntop/PF_RING/issues/52
>>>
>>> Amir
>>>
>>>
>>> On Mon, Nov 9, 2015 at 7:34 PM, Alfredo Cardigliano <
>>> cardigli...@ntop.org> wrote:
>>>
 Hi Amir
 there is no statistics by default (unless you code your own kernel
 plugin and read stats via pfring_get_hash_filtering_rule_stats, but this is
 overkilling for match/miss counters),
 please open a feature request on github.

 Alfredo

 On 09 Nov 2015, at 18:28, Amir Kaduri  wrote:

 Hi,

 In my application, I’m using pf_ring hash software filters (API:
 pfring_handle_hash_filtering_rule()).

 How can I get statistics info regarding the quantity of the filtered
 packets?

 I know that on ixgbe module, I can get the following parameters when
 using ethtool –s :

 fdir_match, fdir_miss, fdir_overflow.

 Are there any pf_ring user-space APIs to get these parameters? Any code
 examples?



 Thanks,

 Amir
 ___
 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
>
>
>
> ___
> 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] Compiling PF_RING as root

[Christiaan Schade]

You guys show a warning when compiling PF_RING as root:
 ** WARNING WARNING WARNING ** * * Compiling PF_RING as root might lead 
you to compile errors * Please compile PF_RING as unpriviliged user * 
*

I'm wondering what the idea behind this warning is... I think it's been there 
for a long time, but I can't think of a reason why there would be a problem 
when compiling as root, other than the fact
that a later 'make clean' etc. also needs to be run as root
.
We've created a .deb package for PF_RING, which is installed/compiled by dpkg. 
When dpkg compiles PF_RING, it does so as the root user.

So far it has never caused problems, but I'd like to know if there's some 
scenario where this could lead to problems.

Thank you,

Chris

-- 

ATTENTION:
The information in this email message is confidential and may be legally
privileged. It is intended solely for the addressee.

Should you receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is prohibited and may be unlawful.
___
Ntop-misc mailing list
Ntop-misc@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

[Ntop-misc] nProbe Wrong identification RTP flows

[Ohad Kleinman]

Hello,



We are using nProbe (version v.7.2.151021 ($Revision: 4468 $)) on ununtu ,
the nProbe fails to identify some of the devices (IP cameras) utilizing RTP
based on MPEG-4.

It does not identify the RTP L7 protocol. sometimes it appears as unknown
and sometimes as skype.

in the config file of the nProbe we are using the
--disable-l7-protocol-guess.



here are the links for both file:



1.
https://dl.dropboxusercontent.com/u/27973370/storagen2disketh01--storage-n2disk-eth0-1-25.pcap
in this pcap file it identify the RTP as unknown (just UDP)

2.
https://dl.dropboxusercontent.com/u/27973370/storagen2disketh01--storage-n2disk-eth0-1-32.pcap
in this pcap file it identify the RTP  as skype.





I have also open a bug on github.



Let me know if you need any more information.



Thanks



Ohad
___
Ntop-misc mailing list
Ntop-misc@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

Re: [Ntop-misc] Maximum limit of pfring_open

[K Rahul]

On 11/13/2015 02:32 PM, Alfredo Cardigliano wrote:

Hi Rahul
did you set the default policy to drop?

pfring_toggle_filtering_policy(ring, 0);

Alfredo


On 10 Nov 2015, at 11:39, K Rahul  wrote:

On 11/10/2015 01:35 PM, Alfredo Cardigliano wrote:

Hi Raul
any reason you are not using native pfring filters? They are more efficient 
than bpf. See pfring_add_filtering_rule in pfcount.c as example. You can change 
them at runtime.

Alfredo


On 10 Nov 2015, at 07:24, K Rahul  wrote:

On 11/06/2015 08:31 PM, Alfredo Cardigliano wrote:

Rahul
do you really need all those sockets, it looks like a bad design choice.

Alfredo


On 06 Nov 2015, at 15:59, K Rahul  wrote:

On 11/05/2015 05:29 PM, K Rahul wrote:

On 11/04/2015 08:58 PM, Alfredo Cardigliano wrote:

Hi Rahul
you should increase MAX_NUM_RING_SOCKETS in kernel/linux/pf_ring.h,
currently it is set to 128.

Alfredo


On 04 Nov 2015, at 16:00, K Rahul  wrote:

Hi,

we are using pfring to capture multicast packets. We are not using DNA or ZC 
drivers as our NIC does not support the same.We are using Broadcom Netxtreme 
BCM5721 NIC. If I use pfring_open more than 64 times, i.e  pfring_open is 
called for 64 different multicast streams, then it returns a NULL. Is there any 
limit to pfring handles? If there is a limit, how can I increase it?

Thanks

Regards,
Rahul
___
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

Thank you for the prompt reply
___
Ntop-misc mailing list
Ntop-misc@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

Hi,

We have increased the limit of MAX_NUM_RING_SOCKETS to 128 from 64. Now, after 
opening 50 handles and more we are observing packet drops. Is there any other 
variable that need to be handle to capture all the packets?

Thank you

Regards,
K Rahul
___
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

Hi,

Let me explain you the use of pfring in our module. We are using pfring to capture 
mpeg2ts streams over multicast. We can have multiple multicast streams joined and each 
one of these streams uses one pfring handle. Thus as per our current design, if we need 
to capture 100 multicast streams, we will require 100 pfring sockets, each with a 
specific bpf filter like "udp and dst port  and src host (172.16.0.10) and dst 
host 239.99.99.99".

The reason for choosing such a model is that our module can join or leave 
multicast streams in runtime.For ex, if we are capturing a multicast stream, we 
set the bpf filter specific to the stream. Now, in case we need to capture 
another multicast stream using the same pfring handle, we will need to modify 
the bpf filter at runtime. As per our current understanding, this is not 
feasible. Thus, we decided to use one pfring socket per multicast stream.

It would be very helpful if you can suggest any alternative approach.

Thank you

Regards,
K Rahul
___
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

Thank you for the reply Alfredo. I am trying to use pfring_add_filtering_rule 
as you suggested.
I want to receive all UDP with multicast IP 236.66.66.66 and dst_port = 6663 
and src_ip = 172.16.0.5 for which I am using the following code sample:

filtering_rule rule;
memset(, 0, sizeof(rule));
rule.rule_id = 1;
rule.rule_action = forward_packet_and_stop_rule_evaluation;
rule.core_fields.proto = 17 /* UDP */;

rule.core_fields.shost.v4 = 
ntohl(inet_addr("172.16.0.5")),rule.core_fields.shost_mask.v4 = 0x;
rule.core_fields.dhost.v4 = ntohl(inet_addr("236.66.66.66")), 
rule.core_fields.dhost_mask.v4 = 0x;
rule.core_fields.dport_low = rule.core_fields.dport_high = 6663;
rule.extended_fields.tunnel.tunnel_id = NO_TUNNEL_ID; /* Ignore the 
tunnel */

When I execute the code, I am getting packets from multiple sources other than 
the given source. I think the filter is not set properly. Is there anything 
that is wrong in this code snippet? Are there any compiler flags that are 
needed to be turned on for using the above filtering 

Re: [Ntop-misc] How to get pf_ring packets filtering statistics

[Amir Kaduri]

Hi Alfredo,



I reviewed the implementation of the feature (great!) and I would like to
clarify please:

1. If I understood it correctly, the number of matched packets is per given
rule, while the number of missed packets is per ring (and not per the given
rule). Is it correct, or am I wrong?

 If I’m correct, can I provide a dummy rule and get the number of
missed packets on the given ring?

2. When reading “ethtool –S ethX | grep fdir_miss” or “ethtool –S ethX |
grep fdir_match” you actually get the aggregation of missed/matched packets
on the interface (ethX).

 Is it possible to get the pf_ring statistics aggregated as well, per
interface, or at least per ring?



Thanks,

Amir

On Wed, Nov 11, 2015 at 8:01 PM, Alfredo Cardigliano 
wrote:

>
> On 11 Nov 2015, at 18:02, Amir Kaduri  wrote:
>
> Two following questions please:
> 1. fdir_miss (of ethtool -S) continues to increase even if my process
> doesn't apply the filter rules. Do you know what else causes it to increase
> if its not a result of a filter?
> I didn't find an answer for it in the following doc:
> https://www.kernel.org/doc/Documentation/networking/ixgbe.txt
>
>
> Please have a look at the datasheet for all cases.
>
> 2. Should I expect the mentioned feature request to be implemented in
> pf_ring soon, or its most probably be there with many other prioritized
> requests?
>
>
> It is in queue with other feature requests, we handle them in best effort,
> however I think it will not require too much (1-2 weeks at most)
>
> Alfredo
>
>
> Thanks,
> Amir
>
> On Tue, Nov 10, 2015 at 3:32 PM, Amir Kaduri  wrote:
>
>> Thanks for the answer. It looks to me very essential statistics for
>> user-space applications.
>> Github feature request: https://github.com/ntop/PF_RING/issues/52
>>
>> Amir
>>
>>
>> On Mon, Nov 9, 2015 at 7:34 PM, Alfredo Cardigliano > > wrote:
>>
>>> Hi Amir
>>> there is no statistics by default (unless you code your own kernel
>>> plugin and read stats via pfring_get_hash_filtering_rule_stats, but this is
>>> overkilling for match/miss counters),
>>> please open a feature request on github.
>>>
>>> Alfredo
>>>
>>> On 09 Nov 2015, at 18:28, Amir Kaduri  wrote:
>>>
>>> Hi,
>>>
>>> In my application, I’m using pf_ring hash software filters (API:
>>> pfring_handle_hash_filtering_rule()).
>>>
>>> How can I get statistics info regarding the quantity of the filtered
>>> packets?
>>>
>>> I know that on ixgbe module, I can get the following parameters when
>>> using ethtool –s :
>>>
>>> fdir_match, fdir_miss, fdir_overflow.
>>>
>>> Are there any pf_ring user-space APIs to get these parameters? Any code
>>> examples?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Amir
>>> ___
>>> 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

Re: [Ntop-misc] How to get pf_ring packets filtering statistics

[Alfredo Cardigliano]

> On 16 Nov 2015, at 10:53, Amir Kaduri  wrote:
> 
> Hi Alfredo,
> 
>  
> I reviewed the implementation of the feature (great!) and I would like to 
> clarify please:
> 
> 1. If I understood it correctly, the number of matched packets is per given 
> rule, while the number of missed packets is per ring (and not per the given 
> rule). Is it correct, or am I wrong?
> 
>  If I’m correct, can I provide a dummy rule and get the number of missed 
> packets on the given ring?
> 
Correct
> 2. When reading “ethtool –S ethX | grep fdir_miss” or “ethtool –S ethX | grep 
> fdir_match” you actually get the aggregation of missed/matched packets on the 
> interface (ethX).
> 
>  Is it possible to get the pf_ring statistics aggregated as well, per 
> interface, or at least per ring?
> 
Is it ok for you if we write this stats under /proc instead of adding another 
API call?

Alfredo

>  
> Thanks,
> 
> Amir
> 
> 
> On Wed, Nov 11, 2015 at 8:01 PM, Alfredo Cardigliano  > wrote:
> 
>> On 11 Nov 2015, at 18:02, Amir Kaduri > > wrote:
>> 
>> Two following questions please:
>> 1. fdir_miss (of ethtool -S) continues to increase even if my process 
>> doesn't apply the filter rules. Do you know what else causes it to increase 
>> if its not a result of a filter?
>> I didn't find an answer for it in the following doc: 
>> https://www.kernel.org/doc/Documentation/networking/ixgbe.txt 
>> 
> Please have a look at the datasheet for all cases.
> 
>> 2. Should I expect the mentioned feature request to be implemented in 
>> pf_ring soon, or its most probably be there with many other prioritized 
>> requests?
> 
> It is in queue with other feature requests, we handle them in best effort,
> however I think it will not require too much (1-2 weeks at most)
> 
> Alfredo
> 
>> 
>> Thanks,
>> Amir
>> 
>> On Tue, Nov 10, 2015 at 3:32 PM, Amir Kaduri > > wrote:
>> Thanks for the answer. It looks to me very essential statistics for 
>> user-space applications.
>> Github feature request: https://github.com/ntop/PF_RING/issues/52 
>> 
>> 
>> Amir
>> 
>> 
>> On Mon, Nov 9, 2015 at 7:34 PM, Alfredo Cardigliano > > wrote:
>> Hi Amir
>> there is no statistics by default (unless you code your own kernel plugin 
>> and read stats via pfring_get_hash_filtering_rule_stats, but this is 
>> overkilling for match/miss counters),
>> please open a feature request on github.
>> 
>> Alfredo
>> 
>>> On 09 Nov 2015, at 18:28, Amir Kaduri >> > wrote:
>>> 
>>> Hi,
>>> 
>>> In my application, I’m using pf_ring hash software filters (API: 
>>> pfring_handle_hash_filtering_rule()).
>>> 
>>> How can I get statistics info regarding the quantity of the filtered 
>>> packets?
>>> 
>>> I know that on ixgbe module, I can get the following parameters when using 
>>> ethtool –s :
>>> 
>>> fdir_match, fdir_miss, fdir_overflow.
>>> 
>>> Are there any pf_ring user-space APIs to get these parameters? Any code 
>>> examples?
>>> 
>>>  
>>> 
>>> Thanks,
>>> 
>>> Amir
>>> 
>>> ___
>>> 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

___
Ntop-misc mailing list
Ntop-misc@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-misc