Hi Alfredo,

Thanks for that.
1. stats per socket means stats per ring, correct?
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.

Thanks,
Amir

On Mon, Nov 16, 2015 at 6:36 PM, Alfredo Cardigliano <[email protected]>
wrote:

> Added to git code, please note stats are per socket, not per interface.
>
> Alfredo
>
> On 16 Nov 2015, at 13:48, Amir Kaduri <[email protected]> wrote:
>
> Hi Alfredo,
>
> Having it per interface under /proc is excellent.
>
> Thanks,
> Amir
>
> On Mon, Nov 16, 2015 at 11:56 AM, Alfredo Cardigliano <
> [email protected]> wrote:
>
>>
>> On 16 Nov 2015, at 10:53, Amir Kaduri <[email protected]> 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 <
>> [email protected]> wrote:
>>
>>>
>>> On 11 Nov 2015, at 18:02, Amir Kaduri <[email protected]> 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 <[email protected]>
>>> 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 <
>>>> [email protected]> 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 <[email protected]> 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 <interface>:
>>>>>
>>>>> 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
>>>>> [email protected]
>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>>>>
>>>>>
_______________________________________________
Ntop-misc mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

Reply via email to