On 04/16/2015 07:53 PM, Rosenboim, Leonid wrote:
Regarding #1, if you assign a different CoS to pktio2, then pmr1 will only be
used for pktio1, e.g.:
cos4 = odp_cos_create(...);
odp_pktio_default_cos_set(pktio2, cos4);
This is a possible workaround, but it has unnecessary side effects.
pmr1 is still connected to cos2, so if some traffic (e.g. from pktio3)
is directed to cos2 it may be then redirected to cos3.
Another example with odp_pktio_pmr_cos()
cos1 = odp_cos_create(...);
pmr1 = odp_pmr_create_match(...);
odp_pktio_pmr_cos(pmr1, pktio1, cos1);
odp_pktio_pmr_cos(pmr1, pktio2, cos1);
Connection [pktio2] -> [pmr1] -> [cos1] can't be destroyed.
Basically you cannot undo odp_pktio_pmr_cos().
The real issue I see here is that if pmr1 must match packets with both cos1 and
cos2 assigned to them, then it is likely that pmr1 will need to use TWO
hardware resources, unless the hardware values for cos1 and cos2 can be
arranges such that both can be matched using a ternary rule, e.g. if they
differ only in one bit, and that can be difficult to implement. For this reason
I tend to agree that each PMR must have ONE source CoS, and assigned during PMR
creation.
Regarding #2, this is a bit philosophical, but also very important. The idea I
used to design these APIs was to not abstract any specific hardware, but to
create abstractions based on what an application need to do, i.e. top-down
instead of bottom-up.
In believing that all hardware implementation ultimately are designed to serve
roughly the same kind of application, albeit in a different way, basing
abstractions on the application would seem more likely to map to most hardware
implementation.
I have a couple more arguments on #2, but I agree it is a bit
philosophical. IMO issue #1 is enough to justify this API change, so we
can forgot about #2 for now.
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
