diff mbox

[ARCH] Classification API Minor Format changes

Message ID 1413475440-14165-1-git-send-email-bala.manoharan@linaro.org
State New
Headers show

Commit Message

Balasubramanian Manoharan Oct. 16, 2014, 4:04 p.m. UTC
Signed-off-by: Balasubramanian Manoharan <bala.manoharan@linaro.org>
---
Removes struct definition from platform specific opaque handles
Corrects variable definition in odp_pktio_pmr_match_set_cos function

 classification_design.dox | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Bill Fischofer Oct. 16, 2014, 4:18 p.m. UTC | #1
The change to odp_pktio_pmr_match_set is a correction.  Not sure why the
other changes to the typedefs.  Typedefs in these documents are
illustrative, not normative.  Each implementation creates them to suit its
needs.

On Thu, Oct 16, 2014 at 11:04 AM, Balasubramanian Manoharan <
bala.manoharan@linaro.org> wrote:

> Signed-off-by: Balasubramanian Manoharan <bala.manoharan@linaro.org>
> ---
> Removes struct definition from platform specific opaque handles
> Corrects variable definition in odp_pktio_pmr_match_set_cos function
>
>  classification_design.dox | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/classification_design.dox b/classification_design.dox
> index 58d55a1..7d19ea7 100644
> --- a/classification_design.dox
> +++ b/classification_design.dox
> @@ -518,7 +518,7 @@ The following data structures SHOULD be implemented to
> support the definition of
>
>
>  #define        ODP_PMR_INVAL ((odp_pmr_t)NULL)
> -typedef struct odp_pmr_s *odp_pmr_t;
> +typedef uint32_t odp_pmr_t;
>  @endverbatim
>
>  @subsection terms Terms
> @@ -765,7 +765,7 @@ typedef struct odp_pmr_match_t {
>
>
>  /** An opaque handle to a composite packet match rule-set */
> -typedef struct odp_pmr_set_s *odp_pmr_set_t;
> +typedef uint32_t odp_pmr_set_t;
>  @endverbatim
>
>  The above structure is used with the following APIs to implement
> table-based PMRs:
> @@ -830,7 +830,7 @@ This routine destroys a PMR match set previously
> created by odp_pmr_match_set_cr
>   * @return Success or ODP_PARAMETER_ERROR
>   */
>
> -int odp_pktio_pmr_match_set_cos(odp_pmr_t pmr_id, odp_pktio_t src_pktio,
> +int odp_pktio_pmr_match_set_cos(odp_pmr_set_t pmr_set_id, odp_pktio_t
> src_pktio,
>                                  odp_cos_t dst_cos);
>  @endverbatim
>
> --
> 2.0.1.472.g6f92e5f
>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
Balasubramanian Manoharan Oct. 17, 2014, 7:45 a.m. UTC | #2
Hi,

We have followed the syntax of defining the opaque handles as typedefs
uint32_t (eg odp_cos_t ) and it seemed to create
a misunderstanding when defining odp_pmr_t and odp_pmr_set_t as structures
when the same are also opaque handles.
I believe this creates a uniform syntax across the whole document.

Regards.
Bala

On 16 October 2014 21:48, Bill Fischofer <bill.fischofer@linaro.org> wrote:

> The change to odp_pktio_pmr_match_set is a correction.  Not sure why the
> other changes to the typedefs.  Typedefs in these documents are
> illustrative, not normative.  Each implementation creates them to suit its
> needs.
>
> On Thu, Oct 16, 2014 at 11:04 AM, Balasubramanian Manoharan <
> bala.manoharan@linaro.org> wrote:
>
>> Signed-off-by: Balasubramanian Manoharan <bala.manoharan@linaro.org>
>> ---
>> Removes struct definition from platform specific opaque handles
>> Corrects variable definition in odp_pktio_pmr_match_set_cos function
>>
>>  classification_design.dox | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/classification_design.dox b/classification_design.dox
>> index 58d55a1..7d19ea7 100644
>> --- a/classification_design.dox
>> +++ b/classification_design.dox
>> @@ -518,7 +518,7 @@ The following data structures SHOULD be implemented
>> to support the definition of
>>
>>
>>  #define        ODP_PMR_INVAL ((odp_pmr_t)NULL)
>> -typedef struct odp_pmr_s *odp_pmr_t;
>> +typedef uint32_t odp_pmr_t;
>>  @endverbatim
>>
>>  @subsection terms Terms
>> @@ -765,7 +765,7 @@ typedef struct odp_pmr_match_t {
>>
>>
>>  /** An opaque handle to a composite packet match rule-set */
>> -typedef struct odp_pmr_set_s *odp_pmr_set_t;
>> +typedef uint32_t odp_pmr_set_t;
>>  @endverbatim
>>
>>  The above structure is used with the following APIs to implement
>> table-based PMRs:
>> @@ -830,7 +830,7 @@ This routine destroys a PMR match set previously
>> created by odp_pmr_match_set_cr
>>   * @return Success or ODP_PARAMETER_ERROR
>>   */
>>
>> -int odp_pktio_pmr_match_set_cos(odp_pmr_t pmr_id, odp_pktio_t src_pktio,
>> +int odp_pktio_pmr_match_set_cos(odp_pmr_set_t pmr_set_id, odp_pktio_t
>> src_pktio,
>>                                  odp_cos_t dst_cos);
>>  @endverbatim
>>
>> --
>> 2.0.1.472.g6f92e5f
>>
>>
>> _______________________________________________
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>
>
>
Bill Fischofer Oct. 17, 2014, 10:20 a.m. UTC | #3
I agree that having these as structs in the docs is confusing.  May I then
suggest that in the docs we adapt the convention of specifying these as:

typedef ... odp_objecttype_t;

which will make it clear that it is the implementation's responsibility to
fill in the ... with whatever it chooses?

On Fri, Oct 17, 2014 at 2:45 AM, Bala Manoharan <bala.manoharan@linaro.org>
wrote:

> Hi,
>
> We have followed the syntax of defining the opaque handles as typedefs
> uint32_t (eg odp_cos_t ) and it seemed to create
> a misunderstanding when defining odp_pmr_t and odp_pmr_set_t as structures
> when the same are also opaque handles.
> I believe this creates a uniform syntax across the whole document.
>
> Regards.
> Bala
>
> On 16 October 2014 21:48, Bill Fischofer <bill.fischofer@linaro.org>
> wrote:
>
>> The change to odp_pktio_pmr_match_set is a correction.  Not sure why the
>> other changes to the typedefs.  Typedefs in these documents are
>> illustrative, not normative.  Each implementation creates them to suit its
>> needs.
>>
>> On Thu, Oct 16, 2014 at 11:04 AM, Balasubramanian Manoharan <
>> bala.manoharan@linaro.org> wrote:
>>
>>> Signed-off-by: Balasubramanian Manoharan <bala.manoharan@linaro.org>
>>> ---
>>> Removes struct definition from platform specific opaque handles
>>> Corrects variable definition in odp_pktio_pmr_match_set_cos function
>>>
>>>  classification_design.dox | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/classification_design.dox b/classification_design.dox
>>> index 58d55a1..7d19ea7 100644
>>> --- a/classification_design.dox
>>> +++ b/classification_design.dox
>>> @@ -518,7 +518,7 @@ The following data structures SHOULD be implemented
>>> to support the definition of
>>>
>>>
>>>  #define        ODP_PMR_INVAL ((odp_pmr_t)NULL)
>>> -typedef struct odp_pmr_s *odp_pmr_t;
>>> +typedef uint32_t odp_pmr_t;
>>>  @endverbatim
>>>
>>>  @subsection terms Terms
>>> @@ -765,7 +765,7 @@ typedef struct odp_pmr_match_t {
>>>
>>>
>>>  /** An opaque handle to a composite packet match rule-set */
>>> -typedef struct odp_pmr_set_s *odp_pmr_set_t;
>>> +typedef uint32_t odp_pmr_set_t;
>>>  @endverbatim
>>>
>>>  The above structure is used with the following APIs to implement
>>> table-based PMRs:
>>> @@ -830,7 +830,7 @@ This routine destroys a PMR match set previously
>>> created by odp_pmr_match_set_cr
>>>   * @return Success or ODP_PARAMETER_ERROR
>>>   */
>>>
>>> -int odp_pktio_pmr_match_set_cos(odp_pmr_t pmr_id, odp_pktio_t src_pktio,
>>> +int odp_pktio_pmr_match_set_cos(odp_pmr_set_t pmr_set_id, odp_pktio_t
>>> src_pktio,
>>>                                  odp_cos_t dst_cos);
>>>  @endverbatim
>>>
>>> --
>>> 2.0.1.472.g6f92e5f
>>>
>>>
>>> _______________________________________________
>>> lng-odp mailing list
>>> lng-odp@lists.linaro.org
>>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>>
>>
>>
>
Balasubramanian Manoharan Oct. 17, 2014, 10:30 a.m. UTC | #4
Sounds Fair. Just a suggestion from my side should we replace "typedef ...
odp_objtype_t" with "typedef <platform_handle> odp_objtype_t". I am ok with
both approach whichever fits best.

Regards,
Bala

On 17 October 2014 15:50, Bill Fischofer <bill.fischofer@linaro.org> wrote:

> I agree that having these as structs in the docs is confusing.  May I then
> suggest that in the docs we adapt the convention of specifying these as:
>
> typedef ... odp_objecttype_t;
>
> which will make it clear that it is the implementation's responsibility to
> fill in the ... with whatever it chooses?
>
> On Fri, Oct 17, 2014 at 2:45 AM, Bala Manoharan <bala.manoharan@linaro.org
> > wrote:
>
>> Hi,
>>
>> We have followed the syntax of defining the opaque handles as typedefs
>> uint32_t (eg odp_cos_t ) and it seemed to create
>> a misunderstanding when defining odp_pmr_t and odp_pmr_set_t as
>> structures when the same are also opaque handles.
>> I believe this creates a uniform syntax across the whole document.
>>
>> Regards.
>> Bala
>>
>> On 16 October 2014 21:48, Bill Fischofer <bill.fischofer@linaro.org>
>> wrote:
>>
>>> The change to odp_pktio_pmr_match_set is a correction.  Not sure why the
>>> other changes to the typedefs.  Typedefs in these documents are
>>> illustrative, not normative.  Each implementation creates them to suit its
>>> needs.
>>>
>>> On Thu, Oct 16, 2014 at 11:04 AM, Balasubramanian Manoharan <
>>> bala.manoharan@linaro.org> wrote:
>>>
>>>> Signed-off-by: Balasubramanian Manoharan <bala.manoharan@linaro.org>
>>>> ---
>>>> Removes struct definition from platform specific opaque handles
>>>> Corrects variable definition in odp_pktio_pmr_match_set_cos function
>>>>
>>>>  classification_design.dox | 6 +++---
>>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/classification_design.dox b/classification_design.dox
>>>> index 58d55a1..7d19ea7 100644
>>>> --- a/classification_design.dox
>>>> +++ b/classification_design.dox
>>>> @@ -518,7 +518,7 @@ The following data structures SHOULD be implemented
>>>> to support the definition of
>>>>
>>>>
>>>>  #define        ODP_PMR_INVAL ((odp_pmr_t)NULL)
>>>> -typedef struct odp_pmr_s *odp_pmr_t;
>>>> +typedef uint32_t odp_pmr_t;
>>>>  @endverbatim
>>>>
>>>>  @subsection terms Terms
>>>> @@ -765,7 +765,7 @@ typedef struct odp_pmr_match_t {
>>>>
>>>>
>>>>  /** An opaque handle to a composite packet match rule-set */
>>>> -typedef struct odp_pmr_set_s *odp_pmr_set_t;
>>>> +typedef uint32_t odp_pmr_set_t;
>>>>  @endverbatim
>>>>
>>>>  The above structure is used with the following APIs to implement
>>>> table-based PMRs:
>>>> @@ -830,7 +830,7 @@ This routine destroys a PMR match set previously
>>>> created by odp_pmr_match_set_cr
>>>>   * @return Success or ODP_PARAMETER_ERROR
>>>>   */
>>>>
>>>> -int odp_pktio_pmr_match_set_cos(odp_pmr_t pmr_id, odp_pktio_t
>>>> src_pktio,
>>>> +int odp_pktio_pmr_match_set_cos(odp_pmr_set_t pmr_set_id, odp_pktio_t
>>>> src_pktio,
>>>>                                  odp_cos_t dst_cos);
>>>>  @endverbatim
>>>>
>>>> --
>>>> 2.0.1.472.g6f92e5f
>>>>
>>>>
>>>> _______________________________________________
>>>> lng-odp mailing list
>>>> lng-odp@lists.linaro.org
>>>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>>>
>>>
>>>
>>
>
Bill Fischofer Oct. 17, 2014, 10:34 a.m. UTC | #5
That works, but perhaps

typedef <implementation-definition> odp_objtype_t

to make it explicit what's expected?

On Fri, Oct 17, 2014 at 5:30 AM, Bala Manoharan <bala.manoharan@linaro.org>
wrote:

> Sounds Fair. Just a suggestion from my side should we replace "typedef ...
> odp_objtype_t" with "typedef <platform_handle> odp_objtype_t". I am ok with
> both approach whichever fits best.
>
> Regards,
> Bala
>
> On 17 October 2014 15:50, Bill Fischofer <bill.fischofer@linaro.org>
> wrote:
>
>> I agree that having these as structs in the docs is confusing.  May I
>> then suggest that in the docs we adapt the convention of specifying these
>> as:
>>
>> typedef ... odp_objecttype_t;
>>
>> which will make it clear that it is the implementation's responsibility
>> to fill in the ... with whatever it chooses?
>>
>> On Fri, Oct 17, 2014 at 2:45 AM, Bala Manoharan <
>> bala.manoharan@linaro.org> wrote:
>>
>>> Hi,
>>>
>>> We have followed the syntax of defining the opaque handles as typedefs
>>> uint32_t (eg odp_cos_t ) and it seemed to create
>>> a misunderstanding when defining odp_pmr_t and odp_pmr_set_t as
>>> structures when the same are also opaque handles.
>>> I believe this creates a uniform syntax across the whole document.
>>>
>>> Regards.
>>> Bala
>>>
>>> On 16 October 2014 21:48, Bill Fischofer <bill.fischofer@linaro.org>
>>> wrote:
>>>
>>>> The change to odp_pktio_pmr_match_set is a correction.  Not sure why
>>>> the other changes to the typedefs.  Typedefs in these documents are
>>>> illustrative, not normative.  Each implementation creates them to suit its
>>>> needs.
>>>>
>>>> On Thu, Oct 16, 2014 at 11:04 AM, Balasubramanian Manoharan <
>>>> bala.manoharan@linaro.org> wrote:
>>>>
>>>>> Signed-off-by: Balasubramanian Manoharan <bala.manoharan@linaro.org>
>>>>> ---
>>>>> Removes struct definition from platform specific opaque handles
>>>>> Corrects variable definition in odp_pktio_pmr_match_set_cos function
>>>>>
>>>>>  classification_design.dox | 6 +++---
>>>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/classification_design.dox b/classification_design.dox
>>>>> index 58d55a1..7d19ea7 100644
>>>>> --- a/classification_design.dox
>>>>> +++ b/classification_design.dox
>>>>> @@ -518,7 +518,7 @@ The following data structures SHOULD be
>>>>> implemented to support the definition of
>>>>>
>>>>>
>>>>>  #define        ODP_PMR_INVAL ((odp_pmr_t)NULL)
>>>>> -typedef struct odp_pmr_s *odp_pmr_t;
>>>>> +typedef uint32_t odp_pmr_t;
>>>>>  @endverbatim
>>>>>
>>>>>  @subsection terms Terms
>>>>> @@ -765,7 +765,7 @@ typedef struct odp_pmr_match_t {
>>>>>
>>>>>
>>>>>  /** An opaque handle to a composite packet match rule-set */
>>>>> -typedef struct odp_pmr_set_s *odp_pmr_set_t;
>>>>> +typedef uint32_t odp_pmr_set_t;
>>>>>  @endverbatim
>>>>>
>>>>>  The above structure is used with the following APIs to implement
>>>>> table-based PMRs:
>>>>> @@ -830,7 +830,7 @@ This routine destroys a PMR match set previously
>>>>> created by odp_pmr_match_set_cr
>>>>>   * @return Success or ODP_PARAMETER_ERROR
>>>>>   */
>>>>>
>>>>> -int odp_pktio_pmr_match_set_cos(odp_pmr_t pmr_id, odp_pktio_t
>>>>> src_pktio,
>>>>> +int odp_pktio_pmr_match_set_cos(odp_pmr_set_t pmr_set_id, odp_pktio_t
>>>>> src_pktio,
>>>>>                                  odp_cos_t dst_cos);
>>>>>  @endverbatim
>>>>>
>>>>> --
>>>>> 2.0.1.472.g6f92e5f
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> lng-odp mailing list
>>>>> lng-odp@lists.linaro.org
>>>>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>>>>
>>>>
>>>>
>>>
>>
>
Balasubramanian Manoharan Oct. 17, 2014, 10:36 a.m. UTC | #6
Okay. This is fine.
Will update the patch accordingly.

Regards,
Bala

On 17 October 2014 16:04, Bill Fischofer <bill.fischofer@linaro.org> wrote:

> That works, but perhaps
>
> typedef <implementation-definition> odp_objtype_t
>
> to make it explicit what's expected?
>
> On Fri, Oct 17, 2014 at 5:30 AM, Bala Manoharan <bala.manoharan@linaro.org
> > wrote:
>
>> Sounds Fair. Just a suggestion from my side should we replace "typedef
>> ... odp_objtype_t" with "typedef <platform_handle> odp_objtype_t". I am ok
>> with both approach whichever fits best.
>>
>> Regards,
>> Bala
>>
>> On 17 October 2014 15:50, Bill Fischofer <bill.fischofer@linaro.org>
>> wrote:
>>
>>> I agree that having these as structs in the docs is confusing.  May I
>>> then suggest that in the docs we adapt the convention of specifying these
>>> as:
>>>
>>> typedef ... odp_objecttype_t;
>>>
>>> which will make it clear that it is the implementation's responsibility
>>> to fill in the ... with whatever it chooses?
>>>
>>> On Fri, Oct 17, 2014 at 2:45 AM, Bala Manoharan <
>>> bala.manoharan@linaro.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> We have followed the syntax of defining the opaque handles as typedefs
>>>> uint32_t (eg odp_cos_t ) and it seemed to create
>>>> a misunderstanding when defining odp_pmr_t and odp_pmr_set_t as
>>>> structures when the same are also opaque handles.
>>>> I believe this creates a uniform syntax across the whole document.
>>>>
>>>> Regards.
>>>> Bala
>>>>
>>>> On 16 October 2014 21:48, Bill Fischofer <bill.fischofer@linaro.org>
>>>> wrote:
>>>>
>>>>> The change to odp_pktio_pmr_match_set is a correction.  Not sure why
>>>>> the other changes to the typedefs.  Typedefs in these documents are
>>>>> illustrative, not normative.  Each implementation creates them to suit its
>>>>> needs.
>>>>>
>>>>> On Thu, Oct 16, 2014 at 11:04 AM, Balasubramanian Manoharan <
>>>>> bala.manoharan@linaro.org> wrote:
>>>>>
>>>>>> Signed-off-by: Balasubramanian Manoharan <bala.manoharan@linaro.org>
>>>>>> ---
>>>>>> Removes struct definition from platform specific opaque handles
>>>>>> Corrects variable definition in odp_pktio_pmr_match_set_cos function
>>>>>>
>>>>>>  classification_design.dox | 6 +++---
>>>>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/classification_design.dox b/classification_design.dox
>>>>>> index 58d55a1..7d19ea7 100644
>>>>>> --- a/classification_design.dox
>>>>>> +++ b/classification_design.dox
>>>>>> @@ -518,7 +518,7 @@ The following data structures SHOULD be
>>>>>> implemented to support the definition of
>>>>>>
>>>>>>
>>>>>>  #define        ODP_PMR_INVAL ((odp_pmr_t)NULL)
>>>>>> -typedef struct odp_pmr_s *odp_pmr_t;
>>>>>> +typedef uint32_t odp_pmr_t;
>>>>>>  @endverbatim
>>>>>>
>>>>>>  @subsection terms Terms
>>>>>> @@ -765,7 +765,7 @@ typedef struct odp_pmr_match_t {
>>>>>>
>>>>>>
>>>>>>  /** An opaque handle to a composite packet match rule-set */
>>>>>> -typedef struct odp_pmr_set_s *odp_pmr_set_t;
>>>>>> +typedef uint32_t odp_pmr_set_t;
>>>>>>  @endverbatim
>>>>>>
>>>>>>  The above structure is used with the following APIs to implement
>>>>>> table-based PMRs:
>>>>>> @@ -830,7 +830,7 @@ This routine destroys a PMR match set previously
>>>>>> created by odp_pmr_match_set_cr
>>>>>>   * @return Success or ODP_PARAMETER_ERROR
>>>>>>   */
>>>>>>
>>>>>> -int odp_pktio_pmr_match_set_cos(odp_pmr_t pmr_id, odp_pktio_t
>>>>>> src_pktio,
>>>>>> +int odp_pktio_pmr_match_set_cos(odp_pmr_set_t pmr_set_id,
>>>>>> odp_pktio_t src_pktio,
>>>>>>                                  odp_cos_t dst_cos);
>>>>>>  @endverbatim
>>>>>>
>>>>>> --
>>>>>> 2.0.1.472.g6f92e5f
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> lng-odp mailing list
>>>>>> lng-odp@lists.linaro.org
>>>>>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
diff mbox

Patch

diff --git a/classification_design.dox b/classification_design.dox
index 58d55a1..7d19ea7 100644
--- a/classification_design.dox
+++ b/classification_design.dox
@@ -518,7 +518,7 @@  The following data structures SHOULD be implemented to support the definition of
 
 
 #define        ODP_PMR_INVAL ((odp_pmr_t)NULL)
-typedef struct odp_pmr_s *odp_pmr_t;
+typedef uint32_t odp_pmr_t;
 @endverbatim
 
 @subsection terms Terms
@@ -765,7 +765,7 @@  typedef struct odp_pmr_match_t {
 
 
 /** An opaque handle to a composite packet match rule-set */
-typedef struct odp_pmr_set_s *odp_pmr_set_t;
+typedef uint32_t odp_pmr_set_t;
 @endverbatim
 
 The above structure is used with the following APIs to implement table-based PMRs:
@@ -830,7 +830,7 @@  This routine destroys a PMR match set previously created by odp_pmr_match_set_cr
  * @return Success or ODP_PARAMETER_ERROR
  */
 
-int odp_pktio_pmr_match_set_cos(odp_pmr_t pmr_id, odp_pktio_t src_pktio,
+int odp_pktio_pmr_match_set_cos(odp_pmr_set_t pmr_set_id, odp_pktio_t src_pktio,
                                 odp_cos_t dst_cos);
 @endverbatim