On 7 July 2015 at 18:34, Benoît Ganne <bga...@kalray.eu> wrote: > 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. >> > > Ok, in that case I suppose it should be even simpler: we need to add a > configuration parameter in config.h.
Yes. Adding to config is what I was also tying to imply in my reply. > > > 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". >> > > > Hmm ok. If I understand correctly, you need to start with those rules > (because of the absolute offset), but you cannot mix it with subsequent > rules because it will automatically advance the packet pointer possibly > beyond the next one. In my example, you will have to implement the > ODP_PMR_OFFSET PMR before the ODP_PMR_DMAC PMR (because of absolute > offset), but as offset > ODP_PMR_DMAC, you can no longer match it when its > time has come. > Let me try to clarify, I can match ODP_PMR_DMAC if it is placed after ODP_PMR_OFFSET but not if it is placed before PMR_OFFSET. > I think we have several solution: > a) restrict PMR combination so that it is either a combination of > ODP_PMR_OFFSET PMR or "standard" PMR, but not both. In that case, you can > sort them by offset, calculate relative offsets for each but the 1st and > apply this. If I understood correctly this should work fine for you > b) no specific restriction: in that case, if there are only > ODP_PMR_OFFSET rules (no "standard" PMR), (a) applies, otherwise you need > to apply OFFSET rules in software (those should be relatively cheap though, > thanks to absolute offset). This is not much different of a HW not > supporting eg. ODP_PMR_LD_VNI. > I would prefer that platforms do not perform a SW match when an underlying HW support is available otherwise it would defeat the purpose of ODP. If the platforms do not have an HW support then SW match is an option. This issue could be easily solved if we describe the position of ODP_PMR_OFFSET term with relation to other PMR terms. Since all the other PMR terms have an inherent preference order i.e application knows that for a better performance it has to check an L2 term before L3 terms. So the only requirement form my side is to define an preference order for ODP_PMR_OFFSET term and since this term is always from the start of L2 it would be better to add a description that this term should be added at the beginning of an PMR chain or that the preference order is ODP_PMR_OFFSET > ODP_PMR_L2_TERMS > PMR_L3_TERMS > PMR_L4_TERMS. Hope this clears up the confusion. Regards, Bala > Is my understanding correct? > > I have an agenda conflict and won't be able to follow today call but > Nicolas will. > > ben >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
