From: Stephen Hemminger <stephen@networkplumber.org>
To: Mohammad Shuab Siddique <mohammad-shuab.siddique@broadcom.com>
Cc: dev@dpdk.org, kishore.padmanabha@broadcom.com
Subject: Re: [PATCH] net/bnxt: add support for driver mapping layer
Date: Mon, 21 Sep 2026 09:20:42 -0700 [thread overview]
Message-ID: <20260921092042.439df1aa@phoenix.local> (raw)
In-Reply-To: <20260921030932.1034887-1-Mohammad-Shuab.Siddique@broadcom.com>
On Sun, 20 Sep 2026 21:09:32 -0600
Mohammad Shuab Siddique <mohammad-shuab.siddique@broadcom.com> wrote:
> From: Mohammad Shuab Siddique <mohammad-shuab.siddique@broadcom.com>
>
> Add a driver mapping layer that abstracts HWRM send-message, FW
> status register mapping, and doorbell setup/write operations behind
> a per-mode operations table (struct bnxt_drv_api_ops), selected at
> runtime via a new bp->drv_map_ctx context. This lays the groundwork
> for supporting an additional driver backend alongside the current
> native mode, without disturbing existing native call sites.
>
> Only the native backend is implemented here. Each abstracted
> operation keeps a fallback to calling its native implementation
> directly when bp->drv_map_ctx has not been initialized, so behavior
> is unchanged for any code path that doesn't go through
> bnxt_drv_init(). The higher-frequency doorbell ring/arm operations
> (bnxt_db_write/_epoch_write/_mpc_write/_nq/_nq_arm/_cq/_mpc_cq) stay
> static inline and call their native implementation directly rather
> than through the ops table, to avoid adding an indirect call to the
> per-packet doorbell path; only the control-path operations (HWRM
> send, FW status register mapping, doorbell setup) actually dispatch
> through bp->drv_map_ctx->ops.
>
> Signed-off-by: Kishore Padmanabha <kishore.padmanabha@broadcom.com>
> Signed-off-by: Mohammad Shuab Siddique <mohammad-shuab.siddique@broadcom.com>
> ---
[PATCH] net/bnxt: add support for driver mapping layer
Error: this breaks multi-process. drv_map_ctx is rte_zmalloc()'d
and hung off bp, which is shared dev_private, and it stores
ops = &bnxt_drv_native_ops, a primary-process address.
bnxt_hwrm_send_message() dispatches through it whenever drv_map_ctx
is non-NULL, which is also true in a secondary. Any dev op issuing
HWRM from a secondary jumps through the primary's pointer, e.g.
stats_get -> bnxt_hwrm_ring_stats() from dpdk-proc-info. Function
pointers must not live in shared memory. Store only the mode and
select the ops table per process.
Warning: much of the code is dead. The bnxt_drv_db_* wrappers and
their ops slots are never called; the commit states doorbells stay
inline. mode and priv_data are unused, and the
BNXT_DRV_MAP_INVALID() failure paths are unreachable after init.
This is infrastructure with one backend and no consumer. Post it
with the backend that needs it, and add only the ops that backend
uses.
prev parent reply other threads:[~2026-09-21 16:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 3:09 [PATCH] net/bnxt: add support for driver mapping layer Mohammad Shuab Siddique
2026-09-21 16:20 ` Stephen Hemminger [this message]
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=20260921092042.439df1aa@phoenix.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=kishore.padmanabha@broadcom.com \
--cc=mohammad-shuab.siddique@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox