[EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion failure

[Vamsi Krishna Attunuru]

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit at intel.com>
> Sent: Friday, March 4, 2022 6:44 PM
> To: Vamsi Krishna Attunuru <vattunuru at marvell.com>; dev at dpdk.org
> Cc: Jerin Jacob Kollanukkaran <jerinj at marvell.com>; Nithin Kumar
> Dabilpuram <ndabilpuram at marvell.com>; yux.jiang at intel.com;
> stable at dpdk.org; Wei Ling <weix.ling at intel.com>; Srikanth Yalavarthi
> <syalavarthi at marvell.com>
> Subject: Re: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion
> failure
> 
> On 3/4/2022 10:20 AM, Vamsi Krishna Attunuru wrote:
> >
> >
> >> -----Original Message-----
> >> From: Ferruh Yigit <ferruh.yigit at intel.com>
> >> Sent: Thursday, March 3, 2022 10:52 PM
> >> To: Vamsi Krishna Attunuru <vattunuru at marvell.com>; dev at dpdk.org
> >> Cc: Jerin Jacob Kollanukkaran <jerinj at marvell.com>; Nithin Kumar
> >> Dabilpuram <ndabilpuram at marvell.com>; yux.jiang at intel.com;
> >> stable at dpdk.org; Wei Ling <weix.ling at intel.com>; Srikanth Yalavarthi
> >> <syalavarthi at marvell.com>
> >> Subject: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion
> >> failure
> >>
> >> External Email
> >>
> >> ---------------------------------------------------------------------
> >> - On 3/2/2022 1:46 PM, Vamsi Attunuru wrote:
> >>> Use dynamically allocated memory for storing soft expiry ring base
> >>> addresses which fixes the static assertion failure, as the size of
> >>> dynamic allocation depends on RTE_MAX_ETHPORTS which varies based
> on
> >>> the build config.
> >>>
> >>
> >> Hi Vamsi,
> >>
> >> "fix static assertion failure" is not enough descriptive.
> >> assertions already added to verify assumptions, and in this case it
> >> seems it failed, but what was actually wrong?
> >>
> >> Is it that allocated memory size for ring wrong? (this is what I got
> >> from commit log but I am not sure)
> >>
> >> Can you please describe what actually was wrong and fixed now?
> >>
> > Hi Ferruh,
> >
> > Earlier sa_soft_exp_ring struct member was an array of pointers and
> > it's size is linked to num RTE_MAX_ETHPORTS, and the whole struct size
> > is confined and protected by size assertion.  It resulted in build failure with -
> Dmax_ethports=1024 option and assertion caught that failure. V2 fixes the
> issues by allocating the required memory dynamically instead
> >   of using array of pointers.
> >
> 
> just to double check if I got it right,
> 
> The failing assertion is:
> PLT_STATIC_ASSERT(sizeof(struct nix_inl_dev) <= ROC_NIX_INL_MEM_SZ);
> 
Yes.
> Technically you can calculate the 'ROC_NIX_INL_MEM_SZ' as a function of
> 'RTE_MAX_ETHPORTS' and that would work (although need to calculate size
> for proper cache alignment).
> 
> But instead you prefer to convert array to function pointer to fix the struct
> size and make it independent from the configured 'RTE_MAX_ETHPORTS'
> config.
> 
Correct.
> 
> And I assume current magic number for the 'ROC_NIX_INL_MEM_SZ' is
> calculated based on max memory requirement of the cn9k & cn10k:
> #define ROC_NIX_INL_MEM_SZ (1280)
>
> If so it can be better to describe 'ROC_NIX_INL_MEM_SZ' as what it is
> calculated from, like following but it is up to you:
> max(sizeof(x), sizeof(y)) ...
> 
correct, I will check the better approach upon the usage.

> >>> Bugzilla ID: 940
> >>> Fixes: d26185716d3f ("net/cnxk: support outbound soft expiry
> >>> notification") Cc:stable at dpdk.org
> >>>
> >>> Reported-by: Wei Ling<weix.ling at intel.com>
> >>> Reported-by: Yu Jiang<yux.jiang at intel.com>
> >>> Signed-off-by: Vamsi Attunuru<vattunuru at marvell.com>
> >>> Signed-off-by: Srikanth Yalavarthi<syalavarthi at marvell.com>
> >>> ---
> >>> V2: Add bugzilla & reportee details, remove unused changes.
> >>> ---
> >