Re: [PATCH 08/20] octeontx2-af: Alloc and config NPC MCAM entry at a time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 9, 2018 at 2:13 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Thu, Nov 8, 2018 at 7:37 PM <sunil.kovvuri@xxxxxxxxx> wrote:
> > @@ -666,4 +668,20 @@ struct npc_mcam_unmap_counter_req {
> >         u8  all;   /* Unmap all entries using this counter ? */
> >  };
> >
> > +struct npc_mcam_alloc_and_write_entry_req {
> > +       struct mbox_msghdr hdr;
> > +       struct mcam_entry entry_data;
> > +       u16 ref_entry;
> > +       u8  priority;    /* Lower or higher w.r.t ref_entry */
> > +       u8  intf;        /* Rx or Tx interface */
> > +       u8  enable_entry;/* Enable this MCAM entry ? */
> > +       u8  alloc_cntr;  /* Allocate counter and map ? */
> > +};
>
> I noticed that this structure requires padding at the end because
> struct mbox_msghdr has a 32-bit alignment requirement. For
> data structures in an interface, I'd recommend avoiding that kind
> of padding and adding reserved fields or widening the types
> accordingly.
>

When there are multiple messages in the mailbox, each message starts
at a 16byte aligned offset. So struct mbox_msghdr is always aligned.
I think adding reserved fields is not needed here.

===
struct mbox_msghdr *otx2_mbox_alloc_msg_rsp(struct otx2_mbox *mbox, int devid,
                                            int size, int size_rsp)
{
        size = ALIGN(size, MBOX_MSG_ALIGN);
===

Is this what you were referring to ?

Sunil.

> I also noticed a similar problem in struct mbox_msghdr. Maybe
> use the 'pahole' tool to check for this kind of padding in the
> API structures.
>
>          Arnd



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux