Seems I have misunderstood its usage, it's better to use uint8_t[]
rather than uint64_t when creating a ODP_PMR_CUSTOM_FRAME.
Thank you for your explaining.
在 2016/2/1 15:56, Nicolas Morey-Chaisemartin 写道:
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
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
