On 04/16/2015 04:24 PM, Radu-Andrei Bulie wrote:
Looking strictly at the patch I cannot understand the initial issue. Can you
give me a simple example using this new modified API?
Regarding the assertion ". How can application detach PMR from the first PktIO, but
leave it connected to the second one?"
One possible solution is to limit this from the API. (you cannot assign a pmr
to multiple physical ports).
Things could get more complicated
if we have a pmr chain and somewhere in the middle we have a pmr that is
reached from two ports for example.
Let me try to rephrase it.
In short current design has two issues:
1. Changes to classification tree cannot be reverted.
cos1 = odp_cos_create(...);
cos2 = odp_cos_create(...);
cos3 = odp_cos_create(...);
odp_pktio_default_cos_set(pktio1, cos1);
odp_pktio_default_cos_set(pktio2, cos2);
pmr1 = odp_pmr_create_match(...);
odp_cos_pmr_cos(pmr1, cos1, cos3);
odp_cos_pmr_cos(pmr1, cos2, cos3);
+--------+ +------+
| pktio1 |----| cos1 |-+
+--------+ +------+ \ +------+ +------+
-->| pmr1 |-->| cos3 |
+--------+ +------+ / +------+ +------+
| pktio2 |----| cos2 |-+
+--------+ +------+
PMR can be destroyed completely, but there is no way to detach PMR
from only one PktIO. Sure you can add restriction in documentation
which prevents application from using the same PMR twice, but it
just highlights the issue in API design.
2. Current PMR abstraction is pointless.
PMR represents only a set of user-specified parameters.
What is the point to abstract them?
To show usage example of modified API let's modify an example above.
A difference in a code is minor.
cos1 = odp_cos_create(...);
cos2 = odp_cos_create(...);
cos3 = odp_cos_create(...);
odp_pktio_default_cos_set(pktio1, cos1);
odp_pktio_default_cos_set(pktio2, cos2);
pmr1 = odp_pmr_create_match(..., cos1, cos3);
pmr2 = odp_pmr_create_match(..., cos2, cos3);
+--------+ +------+ pmr1
| pktio1 |----| cos1 |------+
+--------+ +------+ \ +------+
->| cos3 |
+--------+ +------+ pmr2 / +------+
| pktio2 |----| cos2 |------+
+--------+ +------+
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
