On 2025/1/21 2:16, Stephen Hemminger wrote:
> On Mon, 20 Jan 2025 19:14:48 +0800
> "WanRenyong" <wa...@yunsilicon.com> wrote:
>
>> +struct __rte_packed_begin xsc_send_wqe_ctrl_seg {
>> +    rte_le32_t      msg_opcode:8;
>> +    rte_le32_t      with_immdt:1;
>> +    rte_le32_t      csum_en:2;
>> +    rte_le32_t      ds_data_num:5;
>> +    rte_le32_t      wqe_id:16;
>> +    rte_le32_t      msg_len;
>> +    union __rte_packed_begin {
>> +            rte_le32_t              opcode_data;
>> +            struct __rte_packed_begin {
>> +                    rte_le16_t      has_pph:1;
>> +                    rte_le16_t      so_type:1;
>> +                    rte_le16_t      so_data_size:14;
>> +                    rte_le16_t      rsv1:8;
>> +                    rte_le16_t      so_hdr_len:8;
>> +            } __rte_packed_end;
>> +            struct __rte_packed_begin {
>> +                    rte_le16_t      desc_id;
>> +                    rte_le16_t      is_last_wqe:1;
>> +                    rte_le16_t      dst_qp_id:15;
>> +            } __rte_packed_end;
>> +    } __rte_packed_end;
>> +    rte_le32_t      se:1;
> If the whole structure is marked with packed attribute,
> don't think you also need to mark the sub structures and unions
> as packed.
>
> This is what is confusing the checkpatch check for __rte_packed_begin / 
> __rte_packed_end
Hello, Stephen Hemminger,

Thanks for your review.

Initially, we did not mark sub structures and unions with the packed 
attribute. However, when we encountered checkpatch errors due to 
unmatched|__rte_packed_begin|/|__rte_packed_end|pairs,
we referred to other PMD codes in DPDK and marked the sub structures and 
unions with the packed attribute as well. Unfortunately, this did not 
resolve the checkpatch errors.
I think that might be a bug in the|checkpatch|tool, so I have submitted 
a patch to address this 
issue:https://inbox.dpdk.org/dev/20250120112654.1049456-1-wa...@yunsilicon.com/.

Regardless, I will remove the packed attribute from sub structures and 
unions in the next verion.

-- 
Best regards,
WanRenyong

Reply via email to