On 04/16/2015 02:04 PM, Radu-Andrei Bulie wrote:
Hi,Can you clarify the following: "1. The same PMR can be applied into different places in a classification tree, but there is no way to modify each of its applications separately. One can only destroy a rule completely which should destroy all of its instances in a classification tree." You mean that you have one pmr, lets say on a pktio (which is a physical port) and on another pktio you use the same pmr? If this is the case, you could impose restrictions in API due to your Hw configuration and thus the user will be provided with an error in case he tries to have such a configuration.
This item is not related to a HW or its limitation. It is an API design issue. Let's take your example. How can application detach PMR from the first PktIO, but leave it connected to the second one?
Regarding the 2nd point: I don't think that the pmr should be 1 to 1 with the HW resource for the simple fact that you use just a handle. What I mean to say is that you could use different pmrs that inside maps to the same input structure given to the HW. For example two pmrs with ipv4.ipsrc are created with different selector values. Obviously on some platforms the same HW resource will point to to each of the pmrs. So if no abstraction is made for pmrs, that means that two HW resources will be created - but doing basically the same thing.
I'm not saying that PMR should map 1:1 to HW resource. Actually the point was exactly opposite: you can't assume direct mapping between PMR and HW resource, so in a current form PMR abstraction is pointless. In this proposal PMR abstraction is changed to represent a logical link (filter) between CoS'es. Maybe I'm missing a point of your last sentence, but proposed change should not cause any additional HW resources usage. _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
