Re: [PATCH net-next v3 04/23] net: use zero value to restore rx_buf_len to default

[Pavel Begunkov]

On 8/19/25 20:27, Mina Almasry wrote:
> On Tue, Aug 19, 2025 at 8:51 AM Pavel Begunkov <asml.silence@xxxxxxxxx> wrote:
> > On 8/19/25 01:07, Mina Almasry wrote:
> > > On Mon, Aug 18, 2025 at 6:56 AM Pavel Begunkov <asml.silence@xxxxxxxxx> wrote:
> > > > From: Jakub Kicinski <kuba@xxxxxxxxxx>
> > > >
> > > > Distinguish between rx_buf_len being driver default vs user config.
> > > > Use 0 as a special value meaning "unset" or "restore driver default".
> > > > This will be necessary later on to configure it per-queue, but
> > > > the ability to restore defaults may be useful in itself.
> > > >
> > > > Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
> > > > Signed-off-by: Pavel Begunkov <asml.silence@xxxxxxxxx>
> > >
> > > I wonder if it should be extended to the other driver using
> > > rx_buf_len, hns3. For that, I think the default buf size would be
> > > HNS3_DEFAULT_RX_BUF_LEN.
> >
> > I'd rather avoid growing the series even more, let's follow up on
> > that in a separate patch on top, that should be just fine. And
> > thanks for the review
> >
> > > Other than that, seems fine to me,
> > >
> > > Reviewed-by: Mina Almasry <almasrymina@xxxxxxxxxx>
> >
> > With the said above, do you want me to retain the review tag?
>
> I initially thought adding my reviewed-by would be fine, but on closer
> look, doesn't this series break rx_buf_len setting for hns3? AFAICT so
> far, in patch 3 you're adding a check to ethnl_set_rings where it'll
> be an error if rx_buf_len > rx_buf_len_max, and i'm guessing if the
> driver never sets rx_buf_len_max it'll be 0 initialized and that check
> would always fail? Or did I miss something?

Good point, it'll need to be fixed then. I'll take a closer look

--
Pavel Begunkov