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

[Alexander Lobakin]

From: Subbaraya Sundeep <sbhatta@xxxxxxxxxxx>
Date: Fri, 10 Apr 2026 15:05:36 +0530

> 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.

But the mailbox is shared between the SoC and the host or HW or not? Is
it possible that one client of the mailbox will have LE and the second
will have BE?

> 
>  Thanks,
>  Sundeep

Thanks,
Olek