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. -----Original Message----- From: Taras Kondratiuk [mailto:[email protected]] Sent: Thursday, April 16, 2015 4:11 PM To: Bulie Radu-Andrei-B37577 Cc: [email protected]; [email protected]; [email protected] Subject: Re: [lng-odp] [API-NEXT PATCH] api: classification: connect PMR on creation 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
