Re: [net-next PATCH v5 1/4] octeontx2-af: npa: cn20k: Add NPA Halo support

[Subbaraya Sundeep <sbhatta@marvell.com>]

On 2026-04-09 at 20:39:02, Alexander Lobakin (aleksander.lobakin@intel.com) wrote:
> From: Subbaraya Sundeep <sbhatta@marvell.com>
> Date: Thu, 9 Apr 2026 15:23:21 +0530
> 
> > From: Linu Cherian <lcherian@marvell.com>
> > 
> > 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@marvell.com>
> > Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
> 
> [...]
> 
> > 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