linux-kernel - Re: [net-next, 07/10] bng_en: Add resource management support

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: <CAHLZf_s1gk_GOuVkp7T_s-iYn8t+g-a-9c=SQue+g+2vRhgHxw@mail.gmail.com>
Date: Tue, 24 Jun 2025 16:01:57 +0530
From: Vikas Gupta <vikas.gupta@...adcom.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
	michael.chan@...adcom.com, pavan.chebbi@...adcom.com, 
	vsrama-krishna.nemani@...adcom.com, 
	Bhargava Chenna Marreddy <bhargava.marreddy@...adcom.com>, 
	Rajashekar Hudumula <rajashekar.hudumula@...adcom.com>
Subject: Re: [net-next, 07/10] bng_en: Add resource management support

On Thu, Jun 19, 2025 at 7:09 PM Vadim Fedorenko
<vadim.fedorenko@...ux.dev> wrote:
>
> On 18/06/2025 15:47, Vikas Gupta wrote:
> > Get the resources and capabilities from the firmware.
> > Add functions to manage the resources with the firmware.
> > These functions will help netdev reserve the resources
> > with the firmware before registering the device in future
> > patches. The resources and their information, such as
> > the maximum available and reserved, are part of the members
> > present in the bnge_hw_resc struct.
> > The bnge_reserve_rings() function also populates
> > the RSS table entries once the RX rings are reserved with
> > the firmware.
> >
>
> [...]
>
> > diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_hwrm.h b/drivers/net/ethernet/broadcom/bnge/bnge_hwrm.h
> > index c14f03daab4b..9dd13c5219a5 100644
> > --- a/drivers/net/ethernet/broadcom/bnge/bnge_hwrm.h
> > +++ b/drivers/net/ethernet/broadcom/bnge/bnge_hwrm.h
> > @@ -104,4 +104,14 @@ void hwrm_req_alloc_flags(struct bnge_dev *bd, void *req, gfp_t flags);
> >   void *hwrm_req_dma_slice(struct bnge_dev *bd, void *req, u32 size,
> >                        dma_addr_t *dma);
> >
> > +static inline int
> > +bnge_hwrm_func_cfg_short_req_init(struct bnge_dev *bdev,
> > +                               struct hwrm_func_cfg_input **req)
> > +{
> > +     u32 req_len;
> > +
> > +     req_len = min_t(u32, sizeof(**req), bdev->hwrm_max_ext_req_len);
> > +     return __hwrm_req_init(bdev, (void **)req, HWRM_FUNC_CFG, req_len);
> > +}
> > +
>
> Could you please explain how does this suppose to work? If the size of
> request will be bigger than the max request length, the HWRM request
> will be prepared with smaller size and then partially transferred to FW?

Thanks for pointing that out. After checking the firmware code, I
understand that
 bnge_hwrm_func_cfg_short_req_init() is not required. I’ll consider
removing this function in v2.
However, to explain your comment, this was aligned with the firmware's
behaviour.
if hwrm_max_ext_req_len is less than the command length, then only a few members
 are accessed by the firmware.


Thanks,
Vikas

>
> [...]

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4193 bytes)