netdev - Re: [RFC net-next 2/2] ipv6: ioam: Support for Buffer occupancy data field

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: <20211207090700.55725775@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 7 Dec 2021 09:07:00 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Justin Iurman <justin.iurman@...ege.be>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, dsahern@...nel.org,
        yoshfuji@...ux-ipv6.org, linux-mm@...ck.org, cl@...ux.com,
        penberg@...nel.org, rientjes@...gle.com,
        iamjoonsoo kim <iamjoonsoo.kim@....com>,
        akpm@...ux-foundation.org, vbabka@...e.cz
Subject: Re: [RFC net-next 2/2] ipv6: ioam: Support for Buffer occupancy
 data field

On Tue, 7 Dec 2021 17:35:49 +0100 (CET) Justin Iurman wrote:
> > provides the best signal. Since the slab cache scales dynamically
> > (AFAIU) it's not really a big deal if it's full as long as there's
> > memory available on the system.  
> 
> Well, I got the same understanding as you. However, we do not provide a
> value meaning "X percent used" just because it wouldn't make much sense,
> as you pointed out. So I think it is sound to have the current value,
> even if it's a quite dynamic one. Indeed, what's important here is to
> know how many bytes are used and this is exactly what it does. If a node
> is under heavy load, the value would be hell high. The operator could
> define a threshold for each node resp. and detect abnormal values.

Hm, reading thru the quoted portion of the standard from the commit
message the semantics of the field are indeed pretty disappointing.
What's the value of defining a field in a standard if it's entirely
implementation specific? Eh.

> We probably want the metadata included for accuracy as well (e.g.,
> kmem_cache_size vs new function kmem_cache_full_size).

Does the standard support carrying arbitrary metadata?

Anyway, in general I personally don't have a good feeling about
implementing this field. Would be good to have a clear user who 
can justify the choice of slab vs something else. Wouldn't modern
deployments use some form of streaming telemetry for nodes within 
the same domain of control? I'm not sure I understand the value
of limited slab info in OAM when there's probably a more powerful
metric collection going on.

Patch 1 makes perfect sense, FWIW.