Re: [RFC net-next 2/2] ipv6: ioam: Support for Buffer occupancy data field
From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-12-07 00:16:51
Also in:
linux-mm
On Mon, 6 Dec 2021 22:17:58 +0100 Justin Iurman wrote:
This patch is an attempt to support the buffer occupancy in IOAM trace data fields. Any feedback is appreciated, or any other idea if this one is not correct. The draft [1] says the following: The "buffer occupancy" field is a 4-octet unsigned integer field. This field indicates the current status of the occupancy of the common buffer pool used by a set of queues. The units of this field are implementation specific. Hence, the units are interpreted within the context of an IOAM-Namespace and/or node-id if used. The authors acknowledge that in some operational cases there is a need for the units to be consistent across a packet path through the network, hence it is recommended for implementations to use standard units such as Bytes. An existing function (i.e., get_slabinfo) is used to retrieve info about skbuff_head_cache. For that, both the prototype of get_slabinfo and struct definition of slabinfo were moved from mm/slab.h to include/linux/slab.h. Any objection on this? The function kmem_cache_size is used to retrieve the size of a slab object. Note that it returns the "object_size" field, not the "size" field. If needed, a new function (e.g., kmem_cache_full_size) could be added to return the "size" field. To match the definition from the draft, the number of bytes is computed as follows: slabinfo.active_objs * size Thoughts?
Implementing the standard is one thing but how useful is this in practice?