Akhil Goyal writes:
>> >>> Now added inline APIs for getting the list end which need to be updated
>> >>> for each new entry to the enum. This shall help in avoiding ABI break
>> >>> for adding new algo.
>> >>>
>> >>
>> >> Hi Akhil,
>> >>
>> >> *I think* this hides the problem instead of fixing i
Hello,
Akhil Goyal writes:
[...]
>> I believe that if you want to know if an enumerator value is *USED* by a
>> type (which I believe is at the root of what you are alluding to), then
>> you would need a static analysis tool that works at the source level.
>> Or, you need a human review of the
Hello,
Ferruh Yigit writes:
[...]
>> This change cause the value of the the FOOD_END enumerator to increase.
>> And that increase might be problematic. At the moment, for it being
>> problematic or not has to be the result of a careful review.
>>
>
> As you said, FOOD_END value change can be
> >>> Now added inline APIs for getting the list end which need to be updated
> >>> for each new entry to the enum. This shall help in avoiding ABI break
> >>> for adding new algo.
> >>>
> >>
> >> Hi Akhil,
> >>
> >> *I think* this hides the problem instead of fixing it, and this may be
> >> partia
On 10/4/2024 8:04 AM, David Marchand wrote:
> On Fri, Oct 4, 2024 at 5:55 AM Ferruh Yigit wrote:
>>
>> On 9/5/2024 11:14 AM, Akhil Goyal wrote:
>>> Replace *_LIST_END enumerators from asymmetric crypto
>>> lib to avoid ABI breakage for every new addition in
>>> enums with inline APIs.
>>>
>>> Sign
On 10/4/2024 10:38 AM, Dodji Seketeli wrote:
> Hello,
>
> Ferruh Yigit writes:
>
>> On 9/5/2024 11:14 AM, Akhil Goyal wrote:
>>> Replace *_LIST_END enumerators from asymmetric crypto
>>> lib to avoid ABI breakage for every new addition in
>>> enums with inline APIs.
>>>
>>> Signed-off-by: Akhil
> > From: Akhil Goyal [mailto:gak...@marvell.com]
> > Sent: Thursday, 3 October 2024 09.01
> >
> > Hi Morten,
> > >
> > > Apologies for delayed response.
> > > > Maybe a combination, returning the lowest end of the two versions
> > of the list,
> > > > would work...
> > > >
> > > > ---
> From: Akhil Goyal [mailto:gak...@marvell.com]
> Sent: Thursday, 3 October 2024 09.01
>
> Hi Morten,
> >
> > Apologies for delayed response.
> > > Maybe a combination, returning the lowest end of the two versions
> of the list,
> > > would work...
> > >
> > > --
>
> Hello,
>
> Ferruh Yigit writes:
>
> > On 9/5/2024 11:14 AM, Akhil Goyal wrote:
> >> Replace *_LIST_END enumerators from asymmetric crypto
> >> lib to avoid ABI breakage for every new addition in
> >> enums with inline APIs.
> >>
> >> Signed-off-by: Akhil Goyal
> >> ---
> >> This patch was dis
> On Fri, Oct 4, 2024 at 5:55 AM Ferruh Yigit wrote:
> >
> > On 9/5/2024 11:14 AM, Akhil Goyal wrote:
> > > Replace *_LIST_END enumerators from asymmetric crypto
> > > lib to avoid ABI breakage for every new addition in
> > > enums with inline APIs.
> > >
> > > Signed-off-by: Akhil Goyal
> > > --
> > If we want to make it a generic thing in rte_common.h
> > Will the below change be ok?
> > --
> > Common header file (rte_common.h):
> > --
> > #define rte_define_enum_list_end(name, last_value) \
> > static inline int name ## _enu
Hello,
Ferruh Yigit writes:
> On 9/5/2024 11:14 AM, Akhil Goyal wrote:
>> Replace *_LIST_END enumerators from asymmetric crypto
>> lib to avoid ABI breakage for every new addition in
>> enums with inline APIs.
>>
>> Signed-off-by: Akhil Goyal
>> ---
>> This patch was discussed in ML long time
On Fri, Oct 4, 2024 at 5:55 AM Ferruh Yigit wrote:
>
> On 9/5/2024 11:14 AM, Akhil Goyal wrote:
> > Replace *_LIST_END enumerators from asymmetric crypto
> > lib to avoid ABI breakage for every new addition in
> > enums with inline APIs.
> >
> > Signed-off-by: Akhil Goyal
> > ---
> > This patch w
On 9/23/2024 9:41 PM, Akhil Goyal wrote:
> Hi Morten,
>
> Apologies for delayed response.
>> Maybe a combination, returning the lowest end of the two versions of the
>> list,
>> would work...
>>
>> --
>> Common header file (rte_common.h):
>> ---
On 9/6/2024 8:45 AM, Akhil Goyal wrote:
>>>
>>> Here's an idea...
>>>
>>> We can introduce a generic design pattern where we keep the _LIST_END enum
>> value at the end, somehow marking it private (and not part of the API/ABI),
>> and
>> move the _list_end() function inside the C file, so it uses
On 9/5/2024 11:14 AM, Akhil Goyal wrote:
> Replace *_LIST_END enumerators from asymmetric crypto
> lib to avoid ABI breakage for every new addition in
> enums with inline APIs.
>
> Signed-off-by: Akhil Goyal
> ---
> This patch was discussed in ML long time back.
> https://patches.dpdk.org/project
Hi Morten,
>
> Apologies for delayed response.
> > Maybe a combination, returning the lowest end of the two versions of the
> > list,
> > would work...
> >
> > --
> > Common header file (rte_common.h):
> > --
> >
> > /* Add at end o
Hi Morten,
Apologies for delayed response.
> Maybe a combination, returning the lowest end of the two versions of the list,
> would work...
>
> --
> Common header file (rte_common.h):
> --
>
> /* Add at end of enum list in the heade
> From: fengchengwen [mailto:fengcheng...@huawei.com]
> Sent: Friday, 6 September 2024 08.33
>
> On 2024/9/5 23:09, Morten Brørup wrote:
> >> +++ b/app/test/test_cryptodev_asym.c
> >> @@ -581,7 +581,7 @@ static inline void print_asym_capa(
> >>rte_cryptodev_asym_get_xform_strin
> >
> > Here's an idea...
> >
> > We can introduce a generic design pattern where we keep the _LIST_END enum
> value at the end, somehow marking it private (and not part of the API/ABI),
> and
> move the _list_end() function inside the C file, so it uses the _LIST_END enum
> value that the library
On 2024/9/5 23:09, Morten Brørup wrote:
>> +++ b/app/test/test_cryptodev_asym.c
>> @@ -581,7 +581,7 @@ static inline void print_asym_capa(
>> rte_cryptodev_asym_get_xform_string(capa->xform_type));
>> printf("operation supported -");
>>
>> -for (i = 0; i < RTE_CRYPTO_A
gt; Doherty, Declan ; ma...@nvidia.com;
> g.si...@nxp.com; fanzhang@gmail.com; jianjay.z...@huawei.com;
> asoma...@amd.com; ruifeng.w...@arm.com;
> konstantin.v.anan...@yandex.ru; Nicolau, Radu ;
> ajit.khapa...@broadcom.com; rnagadhee...@marvell.com; m...@ashroe.eu
> Subject: RE: [P
> +++ b/app/test/test_cryptodev_asym.c
> @@ -581,7 +581,7 @@ static inline void print_asym_capa(
> rte_cryptodev_asym_get_xform_string(capa->xform_type));
> printf("operation supported -");
>
> - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> + for (i = 0
23 matches
Mail list logo
