Hi Amir yes they are in queue. Alfredo
> On 15 Dec 2015, at 18:46, Amir Kaduri <[email protected]> wrote: > > 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] > <mailto:[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] > <mailto:[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] > <mailto:[email protected]>> wrote: > >> On 03 Dec 2015, at 13:44, Amir Kaduri <[email protected] >> <mailto:[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] <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
