I don't completely agree with your assessment. The fact that it ends up in a uint64_t is linux-generic specific. More precisely because uint64_t was already used in the pmr_term_value_t struct. Nothing prevents another implementation to support any size of ODP_PMR_CUSTOM_FRAME (ie more than 64b) In this case, Endianness doesn't make much sense (how would you convert a 9B wide data?)
I'd rather see something added to the documentation to warn that the data and mask provided to the PMR need to be in network order. Nicolas On 01/30/2016 09:31 AM, huanggaoyang wrote: > I think it's a bug in classification:When verifying the pmr_term > ODP_PMR_CUSTOM_FRAME, > the big-endian packet data shouldn't directly memcpy and used as a uint64_t > on little-endian machine. > We should make a transition here when it's on little-endian machine. > Or we have to turn the value to big-endian when creating a > ODP_PMR_CUSTOM_FRAME pmr, it's different > from other pmr term and make no sense. > And I also add a test case for this ODP_PMR_CUSTOM_FRAME term in validation > test. > > huanggaoyang (2): > linux-generic:classification: on little endian machine, a transition > should take after memcpy from a packet > linux-generic:classification:test: add a test case for term > ODP_PMR_CUSTOM_FRAME > > .../include/odp_classification_inlines.h | 5 + > test/validation/classification/classification.h | 1 + > .../classification/odp_classification_test_pmr.c | 114 > ++++++++++++++++++++- > 3 files changed, 118 insertions(+), 2 deletions(-) > _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
