* [dpdk-dev] [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul @ 2021-03-11 21:08 Tyler Retzlaff 2021-03-12 0:40 ` Ranjit Menon 2021-03-12 8:07 ` David Marchand 0 siblings, 2 replies; 10+ messages in thread From: Tyler Retzlaff @ 2021-03-11 21:08 UTC (permalink / raw) To: dev; +Cc: thomas Avoid expanding v and mul parameters multiple times in the macro. based on usage of the macro it seems like side effects were not intended. For example: ``return RTE_ALIGN_MUL_NEAR(rte_rdtsc() - start, CYC_PER_10MHZ);'' Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com> --- lib/librte_eal/include/rte_common.h | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lib/librte_eal/include/rte_common.h b/lib/librte_eal/include/rte_common.h index 1b630baf1..640befee2 100644 --- a/lib/librte_eal/include/rte_common.h +++ b/lib/librte_eal/include/rte_common.h @@ -345,9 +345,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void) */ #define RTE_ALIGN_MUL_NEAR(v, mul) \ ({ \ - typeof(v) ceil = RTE_ALIGN_MUL_CEIL(v, mul); \ - typeof(v) floor = RTE_ALIGN_MUL_FLOOR(v, mul); \ - (ceil - (v)) > ((v) - floor) ? floor : ceil; \ + typeof(v) _v = (v); \ + typeof(v) _m = (mul); \ + typeof(v) ceil = RTE_ALIGN_MUL_CEIL(_v, _m); \ + typeof(v) floor = RTE_ALIGN_MUL_FLOOR(_v, _m); \ + (ceil - (_v)) > ((_v) - floor) ? floor : ceil; \ }) /** -- 2.30.0.vfs.0.2 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul 2021-03-11 21:08 [dpdk-dev] [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul Tyler Retzlaff @ 2021-03-12 0:40 ` Ranjit Menon 2021-03-12 1:34 ` Tyler Retzlaff 2021-03-12 8:07 ` David Marchand 1 sibling, 1 reply; 10+ messages in thread From: Ranjit Menon @ 2021-03-12 0:40 UTC (permalink / raw) To: Tyler Retzlaff, dev; +Cc: thomas On 3/11/2021 1:08 PM, Tyler Retzlaff wrote: > Avoid expanding v and mul parameters multiple times in the macro. based > on usage of the macro it seems like side effects were not intended. > > For example: > ``return RTE_ALIGN_MUL_NEAR(rte_rdtsc() - start, CYC_PER_10MHZ);'' > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com> > --- > lib/librte_eal/include/rte_common.h | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/lib/librte_eal/include/rte_common.h b/lib/librte_eal/include/rte_common.h > index 1b630baf1..640befee2 100644 > --- a/lib/librte_eal/include/rte_common.h > +++ b/lib/librte_eal/include/rte_common.h > @@ -345,9 +345,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void) > */ > #define RTE_ALIGN_MUL_NEAR(v, mul) \ > ({ \ > - typeof(v) ceil = RTE_ALIGN_MUL_CEIL(v, mul); \ > - typeof(v) floor = RTE_ALIGN_MUL_FLOOR(v, mul); \ > - (ceil - (v)) > ((v) - floor) ? floor : ceil; \ > + typeof(v) _v = (v); \ > + typeof(v) _m = (mul); \ For consistency sake, can this variable be changed to '_mul'? > + typeof(v) ceil = RTE_ALIGN_MUL_CEIL(_v, _m); \ > + typeof(v) floor = RTE_ALIGN_MUL_FLOOR(_v, _m); \ > + (ceil - (_v)) > ((_v) - floor) ? floor : ceil; \ > }) > > /** ranjit m. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul 2021-03-12 0:40 ` Ranjit Menon @ 2021-03-12 1:34 ` Tyler Retzlaff 2021-03-12 4:41 ` Ranjit Menon 0 siblings, 1 reply; 10+ messages in thread From: Tyler Retzlaff @ 2021-03-12 1:34 UTC (permalink / raw) To: Ranjit Menon; +Cc: dev, thomas On Thu, Mar 11, 2021 at 04:40:58PM -0800, Ranjit Menon wrote: > > On 3/11/2021 1:08 PM, Tyler Retzlaff wrote: > >diff --git a/lib/librte_eal/include/rte_common.h b/lib/librte_eal/include/rte_common.h > >index 1b630baf1..640befee2 100644 > >--- a/lib/librte_eal/include/rte_common.h > >+++ b/lib/librte_eal/include/rte_common.h > >@@ -345,9 +345,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void) > > */ > > #define RTE_ALIGN_MUL_NEAR(v, mul) \ > > ({ \ > >- typeof(v) ceil = RTE_ALIGN_MUL_CEIL(v, mul); \ > >- typeof(v) floor = RTE_ALIGN_MUL_FLOOR(v, mul); \ > >- (ceil - (v)) > ((v) - floor) ? floor : ceil; \ > >+ typeof(v) _v = (v); \ > >+ typeof(v) _m = (mul); \ > For consistency sake, can this variable be changed to '_mul'? sure, i can do that. it will hit another tab stop below though. i'll submit a v2 with the requested change. > >+ typeof(v) ceil = RTE_ALIGN_MUL_CEIL(_v, _m); \ > >+ typeof(v) floor = RTE_ALIGN_MUL_FLOOR(_v, _m); \ > >+ (ceil - (_v)) > ((_v) - floor) ? floor : ceil; \ > > }) > > /** > > > ranjit m. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul 2021-03-12 1:34 ` Tyler Retzlaff @ 2021-03-12 4:41 ` Ranjit Menon 2021-03-12 6:28 ` Tyler Retzlaff 0 siblings, 1 reply; 10+ messages in thread From: Ranjit Menon @ 2021-03-12 4:41 UTC (permalink / raw) To: Tyler Retzlaff; +Cc: dev, thomas On 3/11/2021 5:34 PM, Tyler Retzlaff wrote: > On Thu, Mar 11, 2021 at 04:40:58PM -0800, Ranjit Menon wrote: >> On 3/11/2021 1:08 PM, Tyler Retzlaff wrote: >>> diff --git a/lib/librte_eal/include/rte_common.h b/lib/librte_eal/include/rte_common.h >>> index 1b630baf1..640befee2 100644 >>> --- a/lib/librte_eal/include/rte_common.h >>> +++ b/lib/librte_eal/include/rte_common.h >>> @@ -345,9 +345,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void) >>> */ >>> #define RTE_ALIGN_MUL_NEAR(v, mul) \ >>> ({ \ >>> - typeof(v) ceil = RTE_ALIGN_MUL_CEIL(v, mul); \ >>> - typeof(v) floor = RTE_ALIGN_MUL_FLOOR(v, mul); \ >>> - (ceil - (v)) > ((v) - floor) ? floor : ceil; \ >>> + typeof(v) _v = (v); \ >>> + typeof(v) _m = (mul); \ >> For consistency sake, can this variable be changed to '_mul'? > sure, i can do that. it will hit another tab stop below though. > i'll submit a v2 with the requested change. Ugh! In that case, let it be. If others insist on the change, we can do it. ranjit m. > >>> + typeof(v) ceil = RTE_ALIGN_MUL_CEIL(_v, _m); \ >>> + typeof(v) floor = RTE_ALIGN_MUL_FLOOR(_v, _m); \ >>> + (ceil - (_v)) > ((_v) - floor) ? floor : ceil; \ >>> }) >>> /** >> >> ranjit m. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul 2021-03-12 4:41 ` Ranjit Menon @ 2021-03-12 6:28 ` Tyler Retzlaff 0 siblings, 0 replies; 10+ messages in thread From: Tyler Retzlaff @ 2021-03-12 6:28 UTC (permalink / raw) To: Ranjit Menon; +Cc: dev, thomas On Thu, Mar 11, 2021 at 08:41:58PM -0800, Ranjit Menon wrote: > > On 3/11/2021 5:34 PM, Tyler Retzlaff wrote: > >On Thu, Mar 11, 2021 at 04:40:58PM -0800, Ranjit Menon wrote: > >>On 3/11/2021 1:08 PM, Tyler Retzlaff wrote: > >>>diff --git a/lib/librte_eal/include/rte_common.h b/lib/librte_eal/include/rte_common.h > >>>index 1b630baf1..640befee2 100644 > >>>--- a/lib/librte_eal/include/rte_common.h > >>>+++ b/lib/librte_eal/include/rte_common.h > >>>@@ -345,9 +345,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void) > >>> */ > >>> #define RTE_ALIGN_MUL_NEAR(v, mul) \ > >>> ({ \ > >>>- typeof(v) ceil = RTE_ALIGN_MUL_CEIL(v, mul); \ > >>>- typeof(v) floor = RTE_ALIGN_MUL_FLOOR(v, mul); \ > >>>- (ceil - (v)) > ((v) - floor) ? floor : ceil; \ > >>>+ typeof(v) _v = (v); \ > >>>+ typeof(v) _m = (mul); \ > >>For consistency sake, can this variable be changed to '_mul'? > >sure, i can do that. it will hit another tab stop below though. > >i'll submit a v2 with the requested change. > > Ugh! In that case, let it be. If others insist on the change, we can do it. heh, yeah painful. okay i will leave the patch as it is and wait a bit for someone with a strong opinion. > > ranjit m. > > > > >>>+ typeof(v) ceil = RTE_ALIGN_MUL_CEIL(_v, _m); \ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul 2021-03-11 21:08 [dpdk-dev] [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul Tyler Retzlaff 2021-03-12 0:40 ` Ranjit Menon @ 2021-03-12 8:07 ` David Marchand 2021-03-12 18:49 ` Tyler Retzlaff 2021-05-05 16:30 ` Tyler Retzlaff 1 sibling, 2 replies; 10+ messages in thread From: David Marchand @ 2021-03-12 8:07 UTC (permalink / raw) To: Tyler Retzlaff; +Cc: dev, Thomas Monjalon, Aaron Conole On Thu, Mar 11, 2021 at 10:08 PM Tyler Retzlaff <roretzla@linux.microsoft.com> wrote: > > Avoid expanding v and mul parameters multiple times in the macro. based > on usage of the macro it seems like side effects were not intended. > > For example: > ``return RTE_ALIGN_MUL_NEAR(rte_rdtsc() - start, CYC_PER_10MHZ);'' That's the beauty of macros. How about updating the unit tests so that this kind of issue is not reintroduced? Are other RTE_ALIGN_* macro affected with similar issues? Like mul expression passed to RTE_ALIGN_MUL_FLOOR and RTE_ALIGN_MUL_CEIL. -- David Marchand ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul 2021-03-12 8:07 ` David Marchand @ 2021-03-12 18:49 ` Tyler Retzlaff 2021-05-05 16:30 ` Tyler Retzlaff 1 sibling, 0 replies; 10+ messages in thread From: Tyler Retzlaff @ 2021-03-12 18:49 UTC (permalink / raw) To: David Marchand; +Cc: dev, Thomas Monjalon, Aaron Conole On Fri, Mar 12, 2021 at 09:07:22AM +0100, David Marchand wrote: > On Thu, Mar 11, 2021 at 10:08 PM Tyler Retzlaff > <roretzla@linux.microsoft.com> wrote: > > > > Avoid expanding v and mul parameters multiple times in the macro. based > > on usage of the macro it seems like side effects were not intended. > > > > For example: > > ``return RTE_ALIGN_MUL_NEAR(rte_rdtsc() - start, CYC_PER_10MHZ);'' > > That's the beauty of macros. > How about updating the unit tests so that this kind of issue is not > reintroduced? i would like to. if i can find time i will but i can't promise. > > > Are other RTE_ALIGN_* macro affected with similar issues? > Like mul expression passed to RTE_ALIGN_MUL_FLOOR and RTE_ALIGN_MUL_CEIL. it is possible. i did look at a number of these macros while evaluating something else but until i ran into this looking for side effects wasn't on my radar. > > > -- > David Marchand ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul 2021-03-12 8:07 ` David Marchand 2021-03-12 18:49 ` Tyler Retzlaff @ 2021-05-05 16:30 ` Tyler Retzlaff 2021-05-05 20:28 ` David Marchand 1 sibling, 1 reply; 10+ messages in thread From: Tyler Retzlaff @ 2021-05-05 16:30 UTC (permalink / raw) To: David Marchand; +Cc: dev, Thomas Monjalon, Aaron Conole On Fri, Mar 12, 2021 at 09:07:22AM +0100, David Marchand wrote: > On Thu, Mar 11, 2021 at 10:08 PM Tyler Retzlaff > <roretzla@linux.microsoft.com> wrote: > > > > Avoid expanding v and mul parameters multiple times in the macro. based > > on usage of the macro it seems like side effects were not intended. > > > > For example: > > ``return RTE_ALIGN_MUL_NEAR(rte_rdtsc() - start, CYC_PER_10MHZ);'' > > That's the beauty of macros. > How about updating the unit tests so that this kind of issue is not > reintroduced? i'm afraid i don't have the schedule budget to do this. i get very little dpdk time. do you want me to withdraw the fix? > > > Are other RTE_ALIGN_* macro affected with similar issues? > Like mul expression passed to RTE_ALIGN_MUL_FLOOR and RTE_ALIGN_MUL_CEIL. > > > -- > David Marchand ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul 2021-05-05 16:30 ` Tyler Retzlaff @ 2021-05-05 20:28 ` David Marchand 2021-05-06 12:24 ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula 0 siblings, 1 reply; 10+ messages in thread From: David Marchand @ 2021-05-05 20:28 UTC (permalink / raw) To: Tyler Retzlaff; +Cc: dev, Thomas Monjalon, Aaron Conole, Pavan Nikhilesh On Wed, May 5, 2021 at 6:30 PM Tyler Retzlaff <roretzla@linux.microsoft.com> wrote: > > On Fri, Mar 12, 2021 at 09:07:22AM +0100, David Marchand wrote: > > On Thu, Mar 11, 2021 at 10:08 PM Tyler Retzlaff > > <roretzla@linux.microsoft.com> wrote: > > > > > > Avoid expanding v and mul parameters multiple times in the macro. based > > > on usage of the macro it seems like side effects were not intended. > > > > > > For example: > > > ``return RTE_ALIGN_MUL_NEAR(rte_rdtsc() - start, CYC_PER_10MHZ);'' > > > > That's the beauty of macros. > > How about updating the unit tests so that this kind of issue is not > > reintroduced? > > i'm afraid i don't have the schedule budget to do this. i get very > little dpdk time. I started to write a test earlier (see below) but I did not finish either. We can wait until somebody has the time to investigate/finish the work. I copied Pavan who authored RTE_ALIGN_MUL_*. There are more macros affected than the one you fixed (see commented lines with FIXME:), and there are probably more macros to check in rte_common.h: diff --git a/app/test/test_common.c b/app/test/test_common.c index 12bd1cad90..44770722a7 100644 --- a/app/test/test_common.c +++ b/app/test/test_common.c @@ -18,6 +18,13 @@ {printf(x "() test failed!\n");\ return -1;} +static uintptr_t callcount; +static uintptr_t +inc_callcount(void) +{ + return callcount++; +} + /* this is really a sanity check */ static int test_macros(int __rte_unused unused_parm) @@ -28,8 +35,18 @@ test_macros(int __rte_unused unused_parm) #define FAIL_MACRO(x)\ {printf(#x "() test failed!\n");\ return -1;} +#define TEST_SIDE_EFFECT_2(macro, type1, type2) do { \ + callcount = 0; \ + (void)macro((type1)inc_callcount(), (type2)inc_callcount()); \ + if (callcount != 2) { \ + printf(#macro" has side effects: callcount=%u\n", \ + (unsigned int)callcount); \ + ret = -1; \ + } \ +} while (0) uintptr_t unused = 0; + int ret = 0; RTE_SET_USED(unused); @@ -47,7 +64,19 @@ test_macros(int __rte_unused unused_parm) if (strncmp(RTE_STR(test), "test", sizeof("test"))) FAIL_MACRO(RTE_STR); - return 0; + TEST_SIDE_EFFECT_2(RTE_PTR_ADD, void *, size_t); + TEST_SIDE_EFFECT_2(RTE_PTR_DIFF, void *, void *); + TEST_SIDE_EFFECT_2(RTE_PTR_SUB, void *, size_t); + /* FIXME: TEST_SIDE_EFFECT_2(RTE_PTR_ALIGN, void *, size_t); */ + /* FIXME: TEST_SIDE_EFFECT_2(RTE_PTR_ALIGN_CEIL, void *, size_t); */ + TEST_SIDE_EFFECT_2(RTE_PTR_ALIGN_FLOOR, void *, size_t); + /* FIXME: TEST_SIDE_EFFECT_2(RTE_ALIGN, unsigned int, unsigned int); */ + /* FIXME: TEST_SIDE_EFFECT_2(RTE_ALIGN_CEIL, unsigned int, unsigned int); */ + TEST_SIDE_EFFECT_2(RTE_ALIGN_FLOOR, unsigned int, unsigned int); + /* FIXME: TEST_SIDE_EFFECT_2(RTE_ALIGN_MUL_CEIL, unsigned int, unsigned int); */ + /* FIXME: TEST_SIDE_EFFECT_2(RTE_ALIGN_MUL_FLOOR, unsigned int, unsigned int); */ + /* FIXME: TEST_SIDE_EFFECT_2(RTE_ALIGN_MUL_NEAR, unsigned int, unsigned int); */ + return ret; } static int -- David Marchand ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [EXT] Re: [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul 2021-05-05 20:28 ` David Marchand @ 2021-05-06 12:24 ` Pavan Nikhilesh Bhagavatula 0 siblings, 0 replies; 10+ messages in thread From: Pavan Nikhilesh Bhagavatula @ 2021-05-06 12:24 UTC (permalink / raw) To: David Marchand, Tyler Retzlaff; +Cc: dev, Thomas Monjalon, Aaron Conole >On Wed, May 5, 2021 at 6:30 PM Tyler Retzlaff ><roretzla@linux.microsoft.com> wrote: >> >> On Fri, Mar 12, 2021 at 09:07:22AM +0100, David Marchand wrote: >> > On Thu, Mar 11, 2021 at 10:08 PM Tyler Retzlaff >> > <roretzla@linux.microsoft.com> wrote: >> > > >> > > Avoid expanding v and mul parameters multiple times in the >macro. based >> > > on usage of the macro it seems like side effects were not >intended. >> > > >> > > For example: >> > > ``return RTE_ALIGN_MUL_NEAR(rte_rdtsc() - start, >CYC_PER_10MHZ);'' >> > >> > That's the beauty of macros. >> > How about updating the unit tests so that this kind of issue is not >> > reintroduced? >> >> i'm afraid i don't have the schedule budget to do this. i get very >> little dpdk time. > >I started to write a test earlier (see below) but I did not finish either. >We can wait until somebody has the time to investigate/finish the work. >I copied Pavan who authored RTE_ALIGN_MUL_*. Hi David, I will send a patch to fix RTE_ALIGN_MUL_* + testcase to verify side-effect. I tried to fix the RTE_ALIGN_* too but looks like since they are used to statically set array sizes it’s a bit complicated to fix them ex. ../lib/eal/include/rte_common.h:311:2: error: braced-group within expression allowed only inside a function 311 | ({ \ | ^ ../lib/eal/include/rte_common.h:333:31: note: in expansion of macro ‘RTE_ALIGN_CEIL’ 333 | #define RTE_ALIGN(val, align) RTE_ALIGN_CEIL(val, align) | ^~~~~~~~~~~~~~ ../lib/ethdev/rte_eth_ctrl.h:435:3: note: in expansion of macro ‘RTE_ALIGN’ 435 | (RTE_ALIGN(RTE_ETH_FLOW_MAX, UINT64_BIT)/UINT64_BIT) | ^~~~~~~~~ ../lib/ethdev/rte_eth_ctrl.h:452:27: note: in expansion of macro ‘RTE_FLOW_MASK_ARRAY_SIZE’ 452 | uint64_t flow_types_mask[RTE_FLOW_MASK_ARRAY_SIZE]; I will send a separate patch to fix RTE_ALIGN* stuff and we can move forward based on acceptance. Regards, Pavan. > >There are more macros affected than the one you fixed (see >commented >lines with FIXME:), and there are probably more macros to check in >rte_common.h: > >diff --git a/app/test/test_common.c b/app/test/test_common.c >index 12bd1cad90..44770722a7 100644 >--- a/app/test/test_common.c >+++ b/app/test/test_common.c >@@ -18,6 +18,13 @@ > {printf(x "() test failed!\n");\ > return -1;} > >+static uintptr_t callcount; >+static uintptr_t >+inc_callcount(void) >+{ >+ return callcount++; >+} >+ > /* this is really a sanity check */ > static int > test_macros(int __rte_unused unused_parm) >@@ -28,8 +35,18 @@ test_macros(int __rte_unused unused_parm) > #define FAIL_MACRO(x)\ > {printf(#x "() test failed!\n");\ > return -1;} >+#define TEST_SIDE_EFFECT_2(macro, type1, type2) do { \ >+ callcount = 0; \ >+ (void)macro((type1)inc_callcount(), (type2)inc_callcount()); \ >+ if (callcount != 2) { \ >+ printf(#macro" has side effects: callcount=%u\n", \ >+ (unsigned int)callcount); \ >+ ret = -1; \ >+ } \ >+} while (0) > > uintptr_t unused = 0; >+ int ret = 0; > > RTE_SET_USED(unused); > >@@ -47,7 +64,19 @@ test_macros(int __rte_unused unused_parm) > if (strncmp(RTE_STR(test), "test", sizeof("test"))) > FAIL_MACRO(RTE_STR); > >- return 0; >+ TEST_SIDE_EFFECT_2(RTE_PTR_ADD, void *, size_t); >+ TEST_SIDE_EFFECT_2(RTE_PTR_DIFF, void *, void *); >+ TEST_SIDE_EFFECT_2(RTE_PTR_SUB, void *, size_t); >+ /* FIXME: TEST_SIDE_EFFECT_2(RTE_PTR_ALIGN, void *, size_t); >*/ >+ /* FIXME: TEST_SIDE_EFFECT_2(RTE_PTR_ALIGN_CEIL, void *, >size_t); */ >+ TEST_SIDE_EFFECT_2(RTE_PTR_ALIGN_FLOOR, void *, size_t); >+ /* FIXME: TEST_SIDE_EFFECT_2(RTE_ALIGN, unsigned int, >unsigned int); */ >+ /* FIXME: TEST_SIDE_EFFECT_2(RTE_ALIGN_CEIL, unsigned int, >unsigned int); */ >+ TEST_SIDE_EFFECT_2(RTE_ALIGN_FLOOR, unsigned int, unsigned >int); >+ /* FIXME: TEST_SIDE_EFFECT_2(RTE_ALIGN_MUL_CEIL, unsigned >int, >unsigned int); */ >+ /* FIXME: TEST_SIDE_EFFECT_2(RTE_ALIGN_MUL_FLOOR, >unsigned >int, unsigned int); */ >+ /* FIXME: TEST_SIDE_EFFECT_2(RTE_ALIGN_MUL_NEAR, unsigned >int, >unsigned int); */ >+ return ret; > } > > static int > > > >-- >David Marchand ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-05-06 12:24 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-11 21:08 [dpdk-dev] [PATCH] eal: avoid side effects in RTE_ALIGN_MUL_NEAR(v, mul) for v and mul Tyler Retzlaff 2021-03-12 0:40 ` Ranjit Menon 2021-03-12 1:34 ` Tyler Retzlaff 2021-03-12 4:41 ` Ranjit Menon 2021-03-12 6:28 ` Tyler Retzlaff 2021-03-12 8:07 ` David Marchand 2021-03-12 18:49 ` Tyler Retzlaff 2021-05-05 16:30 ` Tyler Retzlaff 2021-05-05 20:28 ` David Marchand 2021-05-06 12:24 ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).