netdev - Re: [PATCH net-next v2 0/4] Implement classifier-action terse dump mode

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:   Sat, 23 May 2020 07:06:34 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Vlad Buslov <vlad@...lov.dev>, Jakub Kicinski <kuba@...nel.org>
Cc:     Vlad Buslov <vladbu@...lanox.com>,
        Edward Cree <ecree@...arflare.com>, xiyou.wangcong@...il.com,
        netdev@...r.kernel.org, davem@...emloft.net, jiri@...nulli.us,
        dcaratti@...hat.com, marcelo.leitner@...il.com
Subject: Re: [PATCH net-next v2 0/4] Implement classifier-action terse dump
 mode

On 2020-05-22 12:16 p.m., Vlad Buslov wrote:
> On Thu 21 May 2020 at 20:02, Jakub Kicinski <kuba@...nel.org> wrote:
>> On Thu, 21 May 2020 17:36:12 +0300 Vlad Buslov wrote:
>>> Hi Edward, Cong,
>>>

>> Do you really need to dump classifiers? If you care about stats
>> the actions could be sufficient if the offload code was fixed
>> appropriately... Sorry I had to say that.
> 
> Technically I need neither classifier nor action. All I need is cookie
> and stats of single terminating action attached to filter (redirect,
> drop, etc.). This can be achieved by making terse dump output that data
> for last extension on filter. However, when I discussed my initial terse
> dump idea with Jamal he asked me not to ossify such behavior to allow
> for implementation of offloaded shared actions in future.
> 

Trying to recollect our discussion (please forgive me if i am
rehashing). old skule hardware model typically is ACL style with one
action - therefore concept of tying a counter with with
a classifier is common.

Other hardware i am familiar with tends to have a table of counters.
More an array with indices.
In the shared case using the same counter index from multiple
tables implies it is shared. Note "old skule" does not have
a concept of sharing.

So i was more worried about assuming the "old skule" model
at the expense of other hardware models.
We should be able to dump different tables from hardware.
Mostly these could be tables of actions. And counter tables
look like a gact action.

 From s/w:
If what is needed is to just dump explicit stats a gact
action with a cookie and an index would suffice.
i.e tc match foobar \
action continue cookie blah index 15 \
action ...
action mirred redirect ...

of course this now adds extra cycles in the s/w datapath but
advantage is it means you can cheaply either get
individual counters (get action gact index 15) or dump all gact actions
and filter in user space for your cookie. Or introduce a dump
cookie filter in the kernel (similar to the "time since" action
dump filter).

cheers,
jamal

> Speaking about shared action offload, I remember looking at some RFC
> patches by Edward implementing such functionality and allowing action
> stats update directly from act, as opposed to current design that relies
> on classifier to update action stats from hardware. Is that what you
> mean by appropriately fixing offload code? With such implementation,
> just dumping relevant action types would also work. My only concern is
> that the only way to dump actions is per-namespace as opposed to
> per-Qdisc of filters, which would clash with any other cls/act users on
> same machine/hypervisor.
> 
> 
> [...]
>