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

[Amir Kaduri]

Hi Alfredo,

(1) Per your fix to update /proc/net/pf_ring with match+miss+rules
statistics of sw hash rules, I've noticed the following:
A received packet that doesn't match any rule, will cause an increase of
the counter ("Sw Filt Hash Miss") of all rings that have at least 1 rule,
rather than the relevant ring only.
I assume its not the intention, right?
(2) ethtool have also the "fdir_overflow" property. Is it possible to add
this statistics to /proc per ring, together with the other statistics
you've added?
  (Note that I just want to know if pf_ring have enough info to do it
or not).

Thanks,
Amir

On Tue, Nov 17, 2015 at 5:04 PM, Alfredo Cardigliano 
wrote:

>
> On 17 Nov 2015, at 15:54, Amir Kaduri  wrote:
>
> Hi Alfredo,
>
> Thanks for that.
> 1. stats per socket means stats per ring, correct?
>
>
> Yes
>
> 2. I would like to know the best way to read this info from /proc.
> Is there any dedicated API for that?
> I took a look at /proc on a machine running an application using
> pf_ring, and found many files containing
> the stats that appear in function proc_get_info(..). I would like to
> better understand the convention of files
> to read, in order to have calculate accurate aggregated stats.
>
>
> /proc/net/pf_ring/* contains one file per ring, the name contains the
> process pid and ring id.
>
> Alfredo
>
>
> Thanks,
> Amir
>
> On Mon, Nov 16, 2015 at 6:36 PM, Alfredo Cardigliano  > wrote:
>
>> 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 <
>> cardigli...@ntop.org> 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 <
>>> cardigli...@ntop.org> 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 :
>>

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

[Alfredo Cardigliano]

> On 03 Dec 2015, at 13:44, Amir Kaduri  wrote:
> 
> Hi Alfredo,
> 
> (1) Per your fix to update /proc/net/pf_ring with match+miss+rules statistics 
> of sw hash rules, I've noticed the following:
> A received packet that doesn't match any rule, will cause an increase of the 
> counter ("Sw Filt Hash Miss") of all rings that have at least 1 rule, rather 
> than the relevant ring only.
> I assume its not the intention, right?

Are all those ring bound to the same interface the packet is coming from? 
Please provide more details about the configuration.

> (2) ethtool have also the "fdir_overflow" property. Is it possible to add 
> this statistics to /proc per ring, together with the other statistics you've 
> added?
>   (Note that I just want to know if pf_ring have enough info to do it or 
> not).

pf_ring does not usually use those info, they need to be retrieved somehow: do 
you really need the same stats in /proc?

Alfredo

> 
> Thanks,
> Amir
> 
> On Tue, Nov 17, 2015 at 5:04 PM, Alfredo Cardigliano  > wrote:
> 
>> On 17 Nov 2015, at 15:54, Amir Kaduri > > wrote:
>> 
>> Hi Alfredo,
>> 
>> Thanks for that.
>> 1. stats per socket means stats per ring, correct?
> 
> Yes
> 
>> 2. I would like to know the best way to read this info from /proc.
>> Is there any dedicated API for that?
>> I took a look at /proc on a machine running an application using 
>> pf_ring, and found many files containing
>> the stats that appear in function proc_get_info(..). I would like to 
>> better understand the convention of files
>> to read, in order to have calculate accurate aggregated stats.
> 
> /proc/net/pf_ring/* contains one file per ring, the name contains the process 
> pid and ring id.
> 
> Alfredo
> 
>> 
>> Thanks,
>> Amir
>> 
>> On Mon, Nov 16, 2015 at 6:36 PM, Alfredo Cardigliano > > wrote:
>> 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 
>