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] [day] [month] [year] [list]

Message-ID: <CALALjgyifKX3==tv-nx-mVFdsngVF0WEqy0tmawcWvSoPsyGNw@mail.gmail.com>
Date:   Tue, 1 Mar 2022 09:00:08 -0800
From:   Joe Damato <jdamato@...tly.com>
To:     Toke Høiland-Jørgensen <toke@...hat.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

On Tue, Mar 1, 2022 at 3:23 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> 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).

Fair enough.

> > 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... :)

Sure, that's fine with me.

I'll give it a few days - hoping to hear back from the mellanox folks
on what they prefer before submitting a v8 with the changes I
mentioned above.

My goal is to avoid a few extra rounds of back and forth if possible :)

Thanks,
Joe