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
