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);
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.
Hope this helps,
- Leo
________________________________________
From: Taras Kondratiuk <[email protected]>
Sent: Thursday, April 16, 2015 9:00 AM
To: Radu-Andrei Bulie
Cc: Rosenboim, Leonid; [email protected]; [email protected]
Subject: Re: [lng-odp] [API-NEXT PATCH] api: classification: connect PMR on
creation
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
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
