On 04/17/2015 01:15 PM, Radu-Andrei Bulie wrote:
I agree with this but here is the following example:odp_pktio_default_cos_set(pktio1, cos1); pmr1 = odp_pmr_create_match(..., cos1, cos3); then pmr2 = = odp_pmr_create_match(..., cos3, cos4); This means: Pktio--->cos1--->pmr1--->cos3----->pmr2---->cos4 But nothing stops a user to first create pmr2, which at the beginning is not connected to anything- because the two cos-es are not bound to anything at the beginning. So in this case the pmr is a pure abstraction that will be initialized later.
That is a valid use-case and exact implementation depends on HW. For example on TI Keystone2 platform cos3->pmr2->cos4 part can be created in HW before it is connected to cos1. Please note that this example is not directly related to the patch. You can build this chain in the same way with a current API.
Looking at the proposed changes I finally understood that the pmr is a pair of input/output coses. So when I say (cos1, cos3) , there is a pmr and only one that has these coses assigned as source and dest.
Not exactly. Each PMR has only one input and one output CoSes. But CoS can have multiple input and output PMRs. So (cos1, cos3) may have several PMRs which connects them.
But this means that the pattern matching rule becomes dependent on input and output decision points(coses). In this case we are not able to have the initial flexibility and assign an input decision point to any created pmr. That means we could not have two different coses pointing to the same pmr. And this is a very likely scenario in an ACL example: there are multiple destinations (coses) which at a point in time can be changed to direct frames to a Specific filter rule. So there is no need to create multiple rules.
In fact in a current design you don't have that flexibility. Once created you can't change a links between CoSes and PMR to precisely direct your traffic. _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
