Hi Alfredo, Even if these two issues are not going to be fixed soon, I just want to know that you are aware of them.
Thanks, Amir On Tue, Dec 8, 2015 at 9:53 AM, Amir Kaduri <[email protected]> wrote: > Hi, > > Another problem in the counters (that were added to > function add_skb_to_ring()) is that it doesn't refer to rss-rehash: > If rss-rehash is disabled, and there are 2 rings involved in a session > (each for a direction), and each of them holds a sw-hash-rule, > then the sw_filtering_hash_match counter will be incremented in both of > them. > For example: Assume rss-rehash is disabled, and the machine receives > 10,000 packets of a single session (5000 packets of each direction). > Each ring actually received 5000 packets, but each of them will report > 10,000 packets filtered which is a total of 20,000 packets. > > So to summarize the problems in the fix in add_skb_to_ring(): > 1. On miss, each ring that has at least 1 rule will increment the counter > ("Sw Filt Hash Miss" in /proc) > 2. On match, when rss is disabled, both rings of both directions will > increment their counter ("Sw Filt Hash Match" in /proc) > > Thanks, > Amir > > > > > On Mon, Dec 7, 2015 at 2:10 PM, Amir Kaduri <[email protected]> wrote: > >> 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
