From: Simon Horman <horms@kernel.org>
To: Srujana Challa <schalla@marvell.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kuba@kernel.org, davem@davemloft.net, pabeni@redhat.com,
sgoutham@marvell.com, lcherian@marvell.com, gakula@marvell.com,
jerinj@marvell.com, hkelam@marvell.com, sbhatta@marvell.com
Subject: Re: [PATCH net,2/6] octeontx2-af: reduce cpt flt interrupt vectors for cn10kb
Date: Tue, 2 Jul 2024 11:28:43 +0100 [thread overview]
Message-ID: <20240702102843.GE598357@kernel.org> (raw)
In-Reply-To: <20240701090746.2171565-3-schalla@marvell.com>
On Mon, Jul 01, 2024 at 02:37:42PM +0530, Srujana Challa wrote:
> On new silicon(cn10kb), the number of FLT interrupt vectors has
> been reduced. Hence, this patch modifies the code to make
> it work for both cn10ka and cn10kb.
>
I am tempted to think this is more about enabling new hardware
than fixing a bug. But I do also see how one might argue otherwise.
In any case, if this is a fix then a fixes tag should go here.
> Signed-off-by: Srujana Challa <schalla@marvell.com>
> ---
> .../net/ethernet/marvell/octeontx2/af/mbox.h | 5 +-
> .../ethernet/marvell/octeontx2/af/rvu_cpt.c | 73 ++++++++++++++++---
> .../marvell/octeontx2/af/rvu_struct.h | 5 +-
> 3 files changed, 65 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> index 4a77f6fe2622..41b46724cb3d 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> @@ -1848,8 +1848,9 @@ struct cpt_flt_eng_info_req {
>
> struct cpt_flt_eng_info_rsp {
> struct mbox_msghdr hdr;
> - u64 flt_eng_map[CPT_10K_AF_INT_VEC_RVU];
> - u64 rcvrd_eng_map[CPT_10K_AF_INT_VEC_RVU];
> +#define CPT_AF_MAX_FLT_INT_VECS 3
> + u64 flt_eng_map[CPT_AF_MAX_FLT_INT_VECS];
> + u64 rcvrd_eng_map[CPT_AF_MAX_FLT_INT_VECS];
> u64 rsvd;
> };
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cpt.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cpt.c
> index 98440a0241a2..38363ea56c6c 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cpt.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cpt.c
> @@ -37,6 +37,38 @@
> (_rsp)->free_sts_##etype = free_sts; \
> })
>
> +#define MAX_AE GENMASK_ULL(47, 32)
> +#define MAX_IE GENMASK_ULL(31, 16)
> +#define MAX_SE GENMASK_ULL(15, 0)
> +static u32 cpt_max_engines_get(struct rvu *rvu)
> +{
> + u16 max_ses, max_ies, max_aes;
> + u64 reg;
> +
> + reg = rvu_read64(rvu, BLKADDR_CPT0, CPT_AF_CONSTANTS1);
> + max_ses = FIELD_GET(MAX_SE, reg);
> + max_ies = FIELD_GET(MAX_IE, reg);
> + max_aes = FIELD_GET(MAX_AE, reg);
> +
> + return max_ses + max_ies + max_aes;
> +}
> +
> +/* Number of flt interrupt vectors are depends on number of engines that
> + * the chip has. Each flt vector represents 64 engines.
> + */
> +static int cpt_10k_flt_nvecs_get(struct rvu *rvu)
> +{
> + u32 max_engs;
> + int flt_vecs;
> +
> + max_engs = cpt_max_engines_get(rvu);
> +
> + flt_vecs = (max_engs / 64);
> + flt_vecs += (max_engs % 64) ? 1 : 0;
> +
> + return flt_vecs;
> +}
> +
I think the callers of this function assume it will never return a value
greater than 3. Perhaps it would be worth enforcing that, or WARNing if it
not so. I'm thinking of a case a fw/hw revision comes along and this
assumption no longer holds.
> static irqreturn_t cpt_af_flt_intr_handler(int vec, void *ptr)
> {
> struct rvu_block *block = ptr;
...
next prev parent reply other threads:[~2024-07-02 10:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 9:07 [PATCH net,0/6] Fixes for CPT and RSS configuration Srujana Challa
2024-07-01 9:07 ` [PATCH net,1/6] octeontx2-af: replace cpt slot with lf id on reg write Srujana Challa
2024-07-02 12:54 ` Michal Kubiak
2024-07-09 10:56 ` [EXTERNAL] " Srujana Challa
2024-07-01 9:07 ` [PATCH net,2/6] octeontx2-af: reduce cpt flt interrupt vectors for cn10kb Srujana Challa
2024-07-02 10:28 ` Simon Horman [this message]
2024-07-09 11:20 ` [EXTERNAL] " Srujana Challa
2024-07-01 9:07 ` [PATCH net,3/6] Fix CPT_LF_ALLOC mailbox error due to incompatible mailbox message format Srujana Challa
2024-07-02 3:58 ` Kalesh Anakkur Purayil
2024-07-01 9:07 ` [PATCH net,4/6] octeontx2-af: Fix issue with IPv6 ext match for RSS Srujana Challa
2024-07-02 3:57 ` Kalesh Anakkur Purayil
2024-07-01 9:07 ` [PATCH net,5/6] octeontx2-af: fix issue with IPv4 " Srujana Challa
2024-07-01 9:07 ` [PATCH net,6/6] octeontx2-af: fix detection of IP layer Srujana Challa
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=20240702102843.GE598357@kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=gakula@marvell.com \
--cc=hkelam@marvell.com \
--cc=jerinj@marvell.com \
--cc=kuba@kernel.org \
--cc=lcherian@marvell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sbhatta@marvell.com \
--cc=schalla@marvell.com \
--cc=sgoutham@marvell.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.