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

[David Ahern <dsahern@gmail.com>]

On 12/6/21 2:17 PM, 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?
> 
>   [1] https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data#section-5.4.2.12
> 
> Signed-off-by: Justin Iurman <justin.iurman@uliege.be>
> ---
>  include/linux/slab.h | 15 +++++++++++++++
>  mm/slab.h            | 14 --------------
>  net/ipv6/ioam6.c     | 13 ++++++++++++-
>  3 files changed, 27 insertions(+), 15 deletions(-)
> 

this should be 2 patches - one that moves the slabinfo struct and
function across header files and then the ioam6 change.

[ I agree with Jakub's line of questioning - how useful is this across
nodes with different OS'es and s/w versions. ]