netdev - Re: TC stats / hw offload question

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]

Date:   Mon, 18 Feb 2019 18:56:06 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>,
        netdev <netdev@...r.kernel.org>
CC:     Jiri Pirko <jiri@...nulli.us>,
        Cong Wang <xiyou.wangcong@...il.com>,
        "Or Gerlitz" <gerlitz.or@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        "PJ Waskiewicz" <pjwaskiewicz@...il.com>,
        Anjali Singhai Jain <anjali.singhai@...el.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>
Subject: Re: TC stats / hw offload question

On 14/02/19 12:39, Jamal Hadi Salim wrote:
> On 2019-02-11 6:44 a.m., Edward Cree wrote:
>> My end goal is to implement TC offload in some hw we're designing
>>   here at Solarflare.  So I'm trying to determine what hardware is
>>   expected/required to do.
>> It might be possible to design our new hw so that we can attach a
>>   counter to every action, if that's what TC wants. 
>
> It makes sense to have a counter on every action - even if it is
> for debugging purposes. The two most basic actions are "drop" or
> "accept". In TC speak the default action is "classid x:y" which
> typically is to select a queue or give the flow some identity
Perhaps I was insufficiently clear; we're only looking at the switching
 side of things (e.g. OVS offload) right now; we don't yet have a plan
 for 'delivery' filters (I imagine we'll probably initially port over
 our ethtool ntuple filter handling from ef10, though we may end up
 going down the TC route there).
So I think at the moment 'classid' isn't relevant (?)

> Note, your counters should also be shareable; example, count all
> the drops in one counter across multiple flows as in the following
> case where counter index 1 is used.
>
> tc flower match foo action drop index 1
> tc flower match bar action drop index 1
[...]
> allow them to specify
> the counter index (assuming you architecture has an indexed table
> of counters).
Our architecture allocates objects (including counters) and returns
 opaque handles to them, so we'd need a software table to connect
 counter index to FW counter ID.
Also, sharing counters in hw causes extra work for the driver code
 that keeps track of which encap actions are getting hit (so it can
 keep the neighbour entries alive).  Maybe summing the shared
 counters in sw is easier than that, I'm not sure (or maybe encap
 action counters should just be kept separate from the counters we
 report to TC).

TBH I'm coming to the conclusion that what we should do for the first
 version of our driver is just to create a counter per rule and report
 it against the first action (only), and for now ignore the index (or
 maybe require it to be set to some distinguished value, like 0, to
 mean 'allocate', so that as a future extension we can support
 shareable counters).

-Ed