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: <7c472cb2-f98d-d25b-1b4a-9ecef99a20a3@solarflare.com>
Date:   Fri, 24 May 2019 16:09:33 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Jamal Hadi Salim <jhs@...atatu.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 24/05/2019 15:44, Jamal Hadi Salim wrote:
> On 2019-05-24 9:57 a.m., Edward Cree wrote:
>> Argh, there's a problem: an action doesn't have a (directly) associated
>>  block, and all the TC offload machinery nowadays is built around blocks.
>> Since this action might have been used in _any_ block (and afaik there's
>>  no way, from the action, to find which) we'd have to make callbacks on
>>  _every_ block in the system, which sounds like it'd perform even worse
>>  than the rule-dumping approach.
>> Any ideas?
>
> If you have the hardware just send the stats periodically to the kernel
> and manage to map each stat to an action type/index (which i think your
> cookie seemed able to do) wouldnt this solve the problem?
Oh, a push rather than pull model?
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.)
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.

-Ed