netdev - Re: [PATCH v3 net-next 0/3] flow_offload: Re-add per-action statistics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a959986d-47bb-03cd-d408-854c25084529@mojatatu.com>
Date:   Fri, 24 May 2019 13:59:54 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Edward Cree <ecree@...arflare.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        Michael Chan <michael.chan@...adcom.com>,
        Vishal Kulkarni <vishal@...lsio.com>
Subject: Re: [PATCH v3 net-next 0/3] flow_offload: Re-add per-action
 statistics

On 2019-05-24 11:09 a.m., Edward Cree wrote:

> Oh, a push rather than pull model?
Right. I thought the switchdev (or what used to be called switchdev)
did a push of some of the tables periodically.

> That could work, but I worry about the overhead in the case of very large
>   numbers of rules (the OVS people talk about 1 million plus) each pushing
>   a stats update to the kernel every few seconds.  I'd much rather only
>   fetch stats when the kernel asks for them.  (Although admittedly drivers
>   already have to periodically fetch at least the stats of encap actions
>   so that they know whether to keepalive the ARP entries.)

So that is part of the challenge. We had this discussion in Prague in
the tc workshop. Andy (on Cc) presented and a discussion ensued
(recorded on the video, about minute 24).

If you are going to poll the hardware from the kernel then, if possible,
you should put a time filter for "last changed" and only get things
that have changed in the last delta.
If you are using a model where the hardware pushes then ability to set
a time filter for "last changed" would be needed.

Note, Ive had to deal with this problem with tc actions from kernel-user
point of view.
See commit e62e484df049 - the idea is to not retrieve the 1M+ stats
but rather only things that have changed since last attempt.

> Also, getting from the cookie back to the action wouldn't be trivial; if
>   there were only TC it would (just cast cookie back to a struct
>   tc_action *) but soon some of these will be NF actions instead.  So
>   something slightly smarter will be required.

Well - this is that issue i was raising earlier as a concern.
I think netfilter should have called into the tc api instead
of directly.

cheers,
jamal