> On 03 Dec 2015, at 13:44, Amir Kaduri <[email protected]> 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 <[email protected] > <mailto:[email protected]>> wrote: > >> On 17 Nov 2015, at 15:54, Amir Kaduri <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[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] >>> <mailto:[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] >>> <mailto:[email protected]>> wrote: >>> >>>> On 16 Nov 2015, at 10:53, Amir Kaduri <[email protected] >>>> <mailto:[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] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> On 11 Nov 2015, at 18:02, Amir Kaduri <[email protected] >>>>> <mailto:[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 >>>>> <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] >>>>> <mailto:[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 >>>>> <https://github.com/ntop/PF_RING/issues/52> >>>>> >>>>> Amir >>>>> >>>>> >>>>> On Mon, Nov 9, 2015 at 7:34 PM, Alfredo Cardigliano <[email protected] >>>>> <mailto:[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] >>>>>> <mailto:[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] <mailto:[email protected]> >>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc>_______________________________________________ >> Ntop-misc mailing list >> [email protected] <mailto:[email protected]> >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> > > _______________________________________________ > Ntop-misc mailing list > [email protected] <mailto:[email protected]> > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > <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
