On 2 July 2015 at 21:17, Benoît Ganne <bga...@kalray.eu> wrote: > Hi Bala, > > I'd define it like this, >>> odp_pmr_t odp_pmr_create_custom(uint32_t offset, const void *val, >>> const void *mask, uint32_t val_sz); >>> >>> It would fail if the requested custom rule is not supported or too >>> many custom rules are used. >>> >> > 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. 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. Regards, Bala > ben >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
