On 3 July 2015 at 21:22, Benoît Ganne <bga...@kalray.eu> wrote:
> Hi Bala,
>
> This signature should work fine. Can we additionally add the pktio
>>>> interface information also to this API so that the
>>>> implementation could
>>>> fail during creation itself if more than the supported numbers get
>>>> attached to the pktio interface.
>>>>
>>>
> I do not see why we should treat it differently from other rules.
>>> Eg. a platform which does not support eg. ODP_PMR_IPSEC_SPI should
>>> fail the same way. And it would defeat the whole discussion about
>>> classification rules contexts (Bill's patches).
>>>
>>
> In this case of ABS_OFFSET_L2 failure during creation is better as the
>> application can better handle the code for different implementations
>> supporting different number of OFFSET term values rather than failing in
>> the context in which case the application will have to redo the entire
>> context again.
>> In classification the responsibility is with the application to
>> configure the rules in an unambiguous way and the context management is
>> used to facilitate the implementation to better optimise and reuse any
>> HW resources if possible.
>> The reason being that the application should be intelligent enough to
>> configure for better performance across multiple implementations with
>> minimal change coz returning an error while applying the context is good
>> but not great since if each implementation returns an error for
>> different configurations then portability aspect of ODP will be lost.
>>
>
> Maybe we should add an API to get the max number of such rules an
> implementation support?
> Something like int odp_pmr_offset_max_get(void) or something.
> That being said, we do not have any mean to check the number of PMR an
> implementation support either, which in my point of view is the same
> problem...
This value of maximum PMRs supported by an implementation is available as a
configuration parameter in the config file.
But I think I need to move the same to config.h it is currently in the
internal header file.
>
> The issue here is to create this API in a way in which it avoid
>> ambiguity for the application. I would like to create the API in such a
>> way that it works efficiently in all the given platforms which will
>> generally help ODP so that more platforms will be able to migrate
>> easily. With the rest of the PMR terms there is an inherent preference
>> order which will be the order in which the packet gets received in the
>> interface eg L2 should be checked before L3 and the concern here is to
>> provide a knowledge for the application to be able to understand the
>> preference of this term ABS_OFFSET_L2. I believe we need to get an
>> opinion from the different existing implementations as to the extent to
>> which they can support this ABS_OFFSET_L2 and then take a call based on
>> what works will all of them.
>>
>
> For example, let's say an application want to define a CoS based on
> ODP_PMR_DMAC and ODP_PMR_OFFSET where offset > ODP_PMR_DMAC. If I
> understand correctly you need the application to tell you that the
> ODP_PMR_OFFSET PMR must be apply after ODP_PMR_DMAC PMR. Am I correct?
> If so, we could requests that PMR must be inserted in the correct order by
> the application.
>
Actually it is reverse ODP_PMR_OFFSET should be applied before DMAC
irrespective of the size of the "offset". Lets take the define API
odp_pmr_create_offset_abs()
*odp_pmr_t odp_pmr_create_offset_abs(odp_pmr_term_e term,
unsigned int offset, const void *val,
const void *mask, uint32_t val_sz);*
The parameter "offset" in the above API is not part of the term but it is
part of a value and this value can be different for different
ODP_PMR_OFFSET. In a HW packet parser the parsing pointer should be at the
start location for this term ODP_PMR_OFFSET.
Basically the HW automatically advances the packet pointer to read
predefined terms like Ethernet SMAC but you need to be at the start of the
packet to read PMR_OFFSET since this "offset" value is dynamic and can vary
per PMR.
Regards,
Bala
> ben
>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
