Re: [net-next PATCH v5 1/4] octeontx2-af: npa: cn20k: Add NPA Halo support
From: Subbaraya Sundeep
Date: Fri Apr 10 2026 - 05:55:21 EST
On 2026-04-09 at 20:39:02, Alexander Lobakin (aleksander.lobakin@xxxxxxxxx) wrote:
> From: Subbaraya Sundeep <sbhatta@xxxxxxxxxxx>
> Date: Thu, 9 Apr 2026 15:23:21 +0530
>
> > From: Linu Cherian <lcherian@xxxxxxxxxxx>
> >
> > CN20K silicon implements unified aura and pool context
> > type called Halo for better resource usage. Add support to
> > handle Halo context type operations.
> >
> > Signed-off-by: Linu Cherian <lcherian@xxxxxxxxxxx>
> > Signed-off-by: Subbaraya Sundeep <sbhatta@xxxxxxxxxxx>
>
> [...]
>
> > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/struct.h b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/struct.h
> > index 763f6cabd7c2..2364bafd329d 100644
> > --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/struct.h
> > +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/struct.h
> > @@ -377,4 +377,85 @@ struct npa_cn20k_pool_s {
> >
> > static_assert(sizeof(struct npa_cn20k_pool_s) == NIX_MAX_CTX_SIZE);
> >
> > +struct npa_cn20k_halo_s {
> > + u64 stack_base : 64;
>
> It's redundant to add : 64 to a 64-bit field.
Agreed. But this is for readability, it helps when checking HRM. For
instance HRM says [703:640] and we define as u64 reserved_640_703 : 64;
so that we do not have to count bits in mind.
> Moreover, on 32-bit systems, the compilers sometimes complain on
> bitfields > 32 bits.
This driver depends on 64BIT.
>
> > + u64 ena : 1;
> > + u64 nat_align : 1;
> > + u64 reserved_66_67 : 2;
> > + u64 stack_caching : 1;
> > + u64 reserved_69_71 : 3;
> > + u64 aura_drop_ena : 1;
> > + u64 reserved_73_79 : 7;
> > + u64 aura_drop : 8;
> > + u64 buf_offset : 12;
> > + u64 reserved_100_103 : 4;
> > + u64 buf_size : 12;
> > + u64 reserved_116_119 : 4;
> > + u64 ref_cnt_prof : 3;
> > + u64 reserved_123_127 : 5;
> > + u64 stack_max_pages : 32;
> > + u64 stack_pages : 32;
> > + u64 bp_0 : 7;
> > + u64 bp_1 : 7;
> > + u64 bp_2 : 7;
> > + u64 bp_3 : 7;
> > + u64 bp_4 : 7;
> > + u64 bp_5 : 7;
> > + u64 bp_6 : 7;
> > + u64 bp_7 : 7;
> > + u64 bp_ena_0 : 1;
> > + u64 bp_ena_1 : 1;
> > + u64 bp_ena_2 : 1;
> > + u64 bp_ena_3 : 1;
> > + u64 bp_ena_4 : 1;
> > + u64 bp_ena_5 : 1;
> > + u64 bp_ena_6 : 1;
> > + u64 bp_ena_7 : 1;
> > + u64 stack_offset : 4;
> > + u64 reserved_260_263 : 4;
> > + u64 shift : 6;
> > + u64 reserved_270_271 : 2;
> > + u64 avg_level : 8;
> > + u64 avg_con : 9;
> > + u64 fc_ena : 1;
> > + u64 fc_stype : 2;
> > + u64 fc_hyst_bits : 4;
> > + u64 fc_up_crossing : 1;
> > + u64 reserved_297_299 : 3;
> > + u64 update_time : 16;
> > + u64 reserved_316_319 : 4;
> > + u64 fc_addr : 64;
> > + u64 ptr_start : 64;
> > + u64 ptr_end : 64;
> > + u64 bpid_0 : 12;
> > + u64 reserved_524_535 : 12;
> > + u64 err_int : 8;
> > + u64 err_int_ena : 8;
> > + u64 thresh_int : 1;
> > + u64 thresh_int_ena : 1;
> > + u64 thresh_up : 1;
> > + u64 reserved_555 : 1;
> > + u64 thresh_qint_idx : 7;
> > + u64 reserved_563 : 1;
> > + u64 err_qint_idx : 7;
> > + u64 reserved_571_575 : 5;
> > + u64 thresh : 36;
> > + u64 reserved_612_615 : 4;
> > + u64 fc_msh_dst : 11;
> > + u64 reserved_627_630 : 4;
> > + u64 op_dpc_ena : 1;
> > + u64 op_dpc_set : 5;
> > + u64 reserved_637_637 : 1;
> > + u64 stream_ctx : 1;
> > + u64 unified_ctx : 1;
> > + u64 reserved_640_703 : 64;
> > + u64 reserved_704_767 : 64;
> > + u64 reserved_768_831 : 64;
> > + u64 reserved_832_895 : 64;
> > + u64 reserved_896_959 : 64;
> > + u64 reserved_960_1023 : 64;
> > +};
> > +
> > +static_assert(sizeof(struct npa_cn20k_halo_s) == NIX_MAX_CTX_SIZE);
>
> Now the main question:
>
> Is mailbox's Endianness fixed (LE/BE)? Or is it always the same as the
> host's ones (I doubt so)?
> If not, these need to be __le{8,16,32,64} (or __be if it's Big Endian)
> and you need to handle the conversions manually.
>
Yes endianness is LE and fixed. This is NOT a host side driver for an
endpoint card. This is driver for on chip PCI device of CN20K soc.
Hope I answered your question wrt host.
Thanks,
Sundeep
> Thanks,
> Olek