Hi, In regard of the problem that missed packets counted on all rings instead of on the relevant ring only: We use a quite simple configuration: We use PF_RING_Aware, splitting the incoming traffic to multiple queues (just like the tester pfcount_multichannel does), currently we have 2 ixgbe interfaces, and the packets physically arrive to only one of them.
Amir On Thu, Dec 3, 2015 at 3:41 PM, Alfredo Cardigliano <[email protected]> wrote: > > 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] > > wrote: > >> >> On 17 Nov 2015, at 15:54, Amir Kaduri <[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]> 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 >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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
