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, 3 Dec 2018 17:15:03 -0700
From:   David Ahern <dsahern@...il.com>
To:     David Miller <davem@...emloft.net>, toke@...e.dk
Cc:     brouer@...hat.com, saeedm@...lanox.com, mst@...hat.com,
        netdev@...r.kernel.org, pstaszewski@...are.pl, jasowang@...hat.com
Subject: Re: consistency for statistics with XDP mode

On 12/3/18 5:00 PM, David Miller wrote:
> From: Toke Høiland-Jørgensen <toke@...e.dk>
> Date: Mon, 03 Dec 2018 22:00:32 +0200
> 
>> I wonder if it would be possible to support both the "give me user
>> normal stats" case and the "let me do whatever I want" case by a
>> combination of userspace tooling and maybe a helper or two?
>>
>> I.e., create a "do_stats()" helper (please pick a better name), which
>> will either just increment the desired counters, or set a flag so the
>> driver can do it at napi poll exit. With this, the userspace tooling
>> could have a "--give-me-normal-stats" switch (or some other interface),
>> which would inject a call instruction to that helper at the start of the
>> program.
>>
>> This would enable the normal counters in a relatively painless way,
>> while still letting people opt out if they don't want to pay the cost in
>> terms of overhead. And having the userspace tooling inject the helper
>> call helps support the case where the admin didn't write the XDP
>> programs being loaded.
>>
>> Any reason why that wouldn't work?
> 
> I think this is a good idea, or even an attribute tag that gets added
> to the XDP program that controls stats handling.
> 

My argument is that the ebpf program writer should *not* get that
choice; the admin of the box should. Program writers make mistakes. Box
admins / customer support are the ones that have to deal with those
mistakes. Program writers - especially for xdp - are going to be focused
on benchmarks; admins are focused on the big picture and should be given
the option of trading a small amount of performance for simpler management.

So, instead of a program tag which the program writer controls, how
about some config knob that an admin controls that says at attach time
use standard stats?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ