netdev - Re: [net-next v7 4/4] mlx5: add support for page_pool_get

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: <87a6e9dih5.fsf@toke.dk>
Date:   Tue, 01 Mar 2022 12:23:34 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Joe Damato <jdamato@...tly.com>
Cc:     Jesper Dangaard Brouer <jbrouer@...hat.com>,
        netdev@...r.kernel.org, kuba@...nel.org,
        ilias.apalodimas@...aro.org, davem@...emloft.net, hawk@...nel.org,
        saeed@...nel.org, ttoukan.linux@...il.com, brouer@...hat.com
Subject: Re: [net-next v7 4/4] mlx5: add support for page_pool_get_stats

Joe Damato <jdamato@...tly.com> writes:

> On Mon, Feb 28, 2022 at 1:17 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>>
>> Joe Damato <jdamato@...tly.com> writes:
>>
>> > On Sun, Feb 27, 2022 at 11:28 PM Jesper Dangaard Brouer
>> > <jbrouer@...hat.com> wrote:
>> >>
>> >>
>> >>
>> >> On 25/02/2022 18.41, Joe Damato wrote:
>> >> > +#ifdef CONFIG_PAGE_POOL_STATS
>> >> > +     { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, page_pool_fast) },
>> >> > +     { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, page_pool_slow) },
>> >> > +     { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, page_pool_slow_high_order) },
>> >> > +     { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, page_pool_empty) },
>> >> > +     { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, page_pool_refill) },
>> >> > +     { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, page_pool_waive) },
>> >> > +     { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, page_pool_rec_cached) },
>> >> > +     { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, page_pool_rec_cache_full) },
>> >> > +     { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, page_pool_rec_ring) },
>> >> > +     { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, page_pool_rec_ring_full) },
>> >> > +     { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, page_pool_rec_released_ref) },
>> >> > +#endif
>> >>
>> >> The naming: "page_pool_rec_xxx".
>> >> What does the "rec" stand for?
>> >
>> > rec stands for recycle.
>> >
>> > ethtool strings have a limited size (ETH_GSTRING_LEN - 32 bytes) and
>> > the full word "recycle" didn't fit for some of the stats once the
>> > queue number is prepended elsewhere in the driver code.
>> >
>> >> Users of ethtool -S stats... will they know "rec" is "recycle" ?
>> >
>> > I am open to other names or adding documentation to the driver docs to
>> > explain the meaning.
>>
>> You could shorten the 'page_pool_' prefix to 'ppool_' or even 'pp_' and
>> gain some characters that way?
>
> I had considered this, but I thought that 'pp' was possibly as terse as 'rec'.
>
> If you all think these are more clear, I can send a v8 of this series
> that changes the strings from the above to this instead:
>
> rx_pp_alloc_fast
> rx_pp_alloc_slow
> rx_pp_alloc_...
>
> and
>
> rx_pp_recyle_cached
> rx_pp_recycle_cache_full
> rx_pp_recycle_...
>
> With this name scheme, it looks like all the stat names seem to fit. I
> have no idea if this is more or less clear to the user though :)

My thinking was that at least 'pp_' is obviously opaque, so it will be
clear to readers that if they don't know what it is they have to look it
up. Whereas 'rec_' looks like it could be 'record' or something like
that, and it'll make people guess (wrongly).

> I'll leave it up to the mlx5 maintainers; I am happy to do whatever
> they prefer to get this series in.

Right, but this is also going to create precedence for other drivers
that add the page pool-based stats, so spending a bit of time agreeing
on the colour of the bikeshed may be worthwhile here... :)

-Toke