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

[Pavel Begunkov <asml.silence@gmail.com>]

On 8/19/25 20:27, Mina Almasry wrote:
> On Tue, Aug 19, 2025 at 8:51 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>
>> On 8/19/25 01:07, Mina Almasry wrote:
>>> On Mon, Aug 18, 2025 at 6:56 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>>>
>>>> From: Jakub Kicinski <kuba@kernel.org>
>>>>
>>>> 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@kernel.org>
>>>> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
>>>
>>> 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@google.com>
>>
>> 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