From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Vikas Gupta <vikas.gupta@broadcom.com>,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, andrew+netdev@lunn.ch, horms@kernel.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
michael.chan@broadcom.com, pavan.chebbi@broadcom.com,
vsrama-krishna.nemani@broadcom.com,
Bhargava Chenna Marreddy <bhargava.marreddy@broadcom.com>,
Rajashekar Hudumula <rajashekar.hudumula@broadcom.com>
Subject: Re: [net-next, 06/10] bng_en: Add backing store support
Date: Thu, 19 Jun 2025 14:02:20 +0100 [thread overview]
Message-ID: <decb802a-7327-4a9a-8a4a-74970474f42c@linux.dev> (raw)
In-Reply-To: <20250618144743.843815-7-vikas.gupta@broadcom.com>
On 18/06/2025 15:47, Vikas Gupta wrote:
> Backing store or context memory on the host helps the
> device to manage rings, stats and other resources.
> Context memory is allocated with the help of ring
> alloc/free functions.
>
> Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
> Reviewed-by: Bhargava Chenna Marreddy <bhargava.marreddy@broadcom.com>
> Reviewed-by: Rajashekar Hudumula <rajashekar.hudumula@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/bnge/bnge.h | 18 +
> .../ethernet/broadcom/bnge/bnge_hwrm_lib.c | 168 +++++++++
> .../ethernet/broadcom/bnge/bnge_hwrm_lib.h | 4 +
> .../net/ethernet/broadcom/bnge/bnge_rmem.c | 337 ++++++++++++++++++
> .../net/ethernet/broadcom/bnge/bnge_rmem.h | 153 ++++++++
> 5 files changed, 680 insertions(+)
>
> diff --git a/drivers/net/ethernet/broadcom/bnge/bnge.h b/drivers/net/ethernet/broadcom/bnge/bnge.h
> index 60af0517c45e..01f64a10729c 100644
> --- a/drivers/net/ethernet/broadcom/bnge/bnge.h
> +++ b/drivers/net/ethernet/broadcom/bnge/bnge.h
> @@ -9,6 +9,7 @@
>
> #include <linux/etherdevice.h>
> #include "../bnxt/bnxt_hsi.h"
> +#include "bnge_rmem.h"
>
> #define DRV_VER_MAJ 1
> #define DRV_VER_MIN 15
> @@ -52,6 +53,13 @@ enum {
> BNGE_FW_CAP_VNIC_RE_FLUSH = BIT_ULL(26),
> };
>
> +enum {
> + BNGE_EN_ROCE_V1 = BIT_ULL(0),
> + BNGE_EN_ROCE_V2 = BIT_ULL(1),
> +};
> +
> +#define BNGE_EN_ROCE (BNGE_EN_ROCE_V1 | BNGE_EN_ROCE_V2)
> +
> struct bnge_dev {
> struct device *dev;
> struct pci_dev *pdev;
> @@ -89,6 +97,16 @@ struct bnge_dev {
> #define BNGE_STATE_DRV_REGISTERED 0
>
> u64 fw_cap;
> +
> + /* Backing stores */
> + struct bnge_ctx_mem_info *ctx;
> +
> + u64 flags;
> };
>
> +static inline bool bnge_is_roce_en(struct bnge_dev *bd)
> +{
> + return bd->flags & BNGE_EN_ROCE;
> +}
> +
> #endif /* _BNGE_H_ */
> diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c b/drivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c
> index 567376a407df..e5f32ac8a69f 100644
> --- a/drivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c
> +++ b/drivers/net/ethernet/broadcom/bnge/bnge_hwrm_lib.c
> @@ -10,6 +10,7 @@
> #include "../bnxt/bnxt_hsi.h"
> #include "bnge_hwrm.h"
> #include "bnge_hwrm_lib.h"
> +#include "bnge_rmem.h"
>
> int bnge_hwrm_ver_get(struct bnge_dev *bd)
> {
> @@ -211,3 +212,170 @@ int bnge_hwrm_func_drv_unrgtr(struct bnge_dev *bd)
> return rc;
> return hwrm_req_send(bd, req);
> }
> +
> +static void bnge_init_ctx_initializer(struct bnge_ctx_mem_type *ctxm,
> + u8 init_val, u8 init_offset,
> + bool init_mask_set)
> +{
> + ctxm->init_value = init_val;
> + ctxm->init_offset = BNGE_CTX_INIT_INVALID_OFFSET;
> + if (init_mask_set)
> + ctxm->init_offset = init_offset * 4;
> + else
> + ctxm->init_value = 0;
> +}
> +
> +static int bnge_alloc_all_ctx_pg_info(struct bnge_dev *bd, int ctx_max)
> +{
> + struct bnge_ctx_mem_info *ctx = bd->ctx;
> + u16 type;
> +
> + for (type = 0; type < ctx_max; type++) {
> + struct bnge_ctx_mem_type *ctxm = &ctx->ctx_arr[type];
> + int n = 1;
> +
> + if (!ctxm->max_entries)
> + continue;
> +
> + if (ctxm->instance_bmap)
> + n = hweight32(ctxm->instance_bmap);
> + ctxm->pg_info = kcalloc(n, sizeof(*ctxm->pg_info), GFP_KERNEL);
> + if (!ctxm->pg_info)
> + return -ENOMEM;
It's a bit hard to be absolutely sure without full chain of calls, but
it looks like some of the memory can be leaked in case of allocation
fail. Direct callers do not clear allocated contextes in the error path.
> + }
> +
> + return 0;
> +}
> +
next prev parent reply other threads:[~2025-06-19 13:02 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-18 14:47 [net-next, 00/10] Introducing Broadcom BNGE Ethernet Driver Vikas Gupta
2025-06-18 14:47 ` [net-next, 01/10] bng_en: Add PCI interface Vikas Gupta
2025-06-19 12:25 ` Vadim Fedorenko
2025-06-18 14:47 ` [net-next, 02/10] bng_en: Add devlink interface Vikas Gupta
2025-06-19 12:34 ` Vadim Fedorenko
2025-06-18 14:47 ` [net-next, 03/10] bng_en: Add firmware communication mechanism Vikas Gupta
2025-06-19 9:46 ` kernel test robot
2025-06-19 12:43 ` Vadim Fedorenko
2025-06-24 10:23 ` Vikas Gupta
2025-06-18 14:47 ` [net-next, 04/10] bng_en: Add initial interaction with firmware Vikas Gupta
2025-06-19 12:53 ` Vadim Fedorenko
2025-06-24 10:26 ` Vikas Gupta
2025-06-24 12:11 ` Vadim Fedorenko
2025-06-25 9:29 ` Vikas Gupta
2025-06-25 10:24 ` Vadim Fedorenko
2025-06-18 14:47 ` [net-next, 05/10] bng_en: Add ring memory allocation support Vikas Gupta
2025-06-18 14:47 ` [net-next, 06/10] bng_en: Add backing store support Vikas Gupta
2025-06-19 13:02 ` Vadim Fedorenko [this message]
2025-06-24 10:29 ` Vikas Gupta
2025-06-24 12:12 ` Vadim Fedorenko
2025-06-18 14:47 ` [net-next, 07/10] bng_en: Add resource management support Vikas Gupta
2025-06-19 13:39 ` Vadim Fedorenko
2025-06-24 10:31 ` Vikas Gupta
2025-06-18 14:47 ` [net-next, 08/10] bng_en: Add irq allocation support Vikas Gupta
2025-06-19 13:52 ` Vadim Fedorenko
2025-06-19 21:25 ` kernel test robot
2025-06-22 5:21 ` kernel test robot
2025-06-23 6:11 ` kernel test robot
2025-06-25 9:17 ` kernel test robot
2025-06-18 14:47 ` [net-next, 09/10] bng_en: Initialize default configuration Vikas Gupta
2025-06-18 20:16 ` kernel test robot
2025-06-19 13:57 ` Vadim Fedorenko
2025-06-20 9:08 ` kernel test robot
2025-06-22 12:39 ` kernel test robot
2025-06-26 8:47 ` kernel test robot
2025-06-18 14:47 ` [net-next, 10/10] bng_en: Add a network device Vikas Gupta
2025-06-24 0:42 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=decb802a-7327-4a9a-8a4a-74970474f42c@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=andrew+netdev@lunn.ch \
--cc=bhargava.marreddy@broadcom.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=rajashekar.hudumula@broadcom.com \
--cc=vikas.gupta@broadcom.com \
--cc=vsrama-krishna.nemani@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.