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:   Tue, 19 May 2020 18:17:24 +0300
From:   Vlad Buslov <vladbu@...lanox.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Vlad Buslov <vladbu@...lanox.com>, netdev@...r.kernel.org,
        davem@...emloft.net, jhs@...atatu.com, xiyou.wangcong@...il.com,
        jiri@...nulli.us, dcaratti@...hat.com, marcelo.leitner@...il.com,
        kuba@...nel.org
Subject: Re: [PATCH net-next v2 0/4] Implement classifier-action terse dump mode

On Tue 19 May 2020 at 17:30, Edward Cree <ecree@...arflare.com> wrote:
> On 19/05/2020 10:04, Vlad Buslov wrote:
>> On Mon 18 May 2020 at 18:37, Edward Cree <ecree@...arflare.com> wrote:
>>> I.e. if next year it turns out that some
>>>  user needs one parameter that's been omitted here, but not the whole dump,
>>>  are they going to want to add another mode to the uapi?
>> Why not just extend terse dump? I won't break user land unless you are
>> removing something from it.
> But then all terse dump users pay the performance cost for thatone
>  app's extra need.

Yes. However reducing amount of data per filter is only part of
optimization. Skipping fl_dump_key() in flower and completely omitting
calling any of the tc_action_ops callbacks is also a major improvement.
So as long as outputting new parameter doesn't require calling one of
those (and it shouldn't, otherwise the parameter represent something
very cls or action type specific) it shouldn't impact performance
significantly.

>
>> - Generic data is covered by current terse dump implementation.
>>   Everything else will be act or cls specific
> Fair point.
> I don't suppose something something BPF mumble solve this? I haven't
>  been following the BPF dumping work in detail but it sounds like it
>  might be a cheap way to get the 'more performant next step' that
>  was mentioned in the subthread with David.  Just a thought.

I'm very interested in ideas how to use BPF to improve dump performance
so any comments/suggestions from resident BPF experts are welcome. Don't
think it will as fast as what David suggested though.