| Message ID | 1429178063-19859-1-git-send-email-taras.kondratiuk@linaro.org |
|---|---|
| State | New |
| Headers | show |
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.
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 |------+ +--------+ +------+
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.
On 04/17/2015 10:10 AM, Radu-Andrei Bulie wrote: > Hi Taras, > > Regarding #2, the initial API was creating a PMR that was bound to nothing. In that case the PMR represented > for some platforms a logical abstraction. > Now after this change the pmrs are bound to the cos "decision diamond" and so is no longer an abstraction. > Is that right? Yes, PMR represented an abstraction of a rule configuration (arguments of odp_pmr_create_*() functions. The only thing you can do with it is to connect to somewhere. So IMO it is just an redundant intermediate abstraction. As Leo pointed it is a bit philosophical, so let's focus on issue #1 instead. After the change PMR abstracts a filter link between CoS'es.
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.
On 04/17/2015 03:04 PM, Radu-Andrei Bulie wrote: > "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." > > > Maybe I didn't understand; how is possible to go from a cos to multiple pmrs? > A cos is a decision point. You may have a queue , a queue group or it may direct the traffic to a pmr.(this is the chaining case, when the cos acts not as a target but as a link point) With a current API you can do: pmr1 = odp_pmr_create_match(x..); pmr2 = odp_pmr_create_match(y..); odp_cos_pmr_cos(pmr1, cos1, cos2); odp_cos_pmr_cos(pmr2, cos1, cos2); After a proposed change code will be slightly different, but the basic idea is the same: there are two PMRs connected between cos1 and cos2 pmr1 = odp_pmr_create_match(x.., cos1, cos2); pmr2 = odp_pmr_create_match(y.., cos1, cos2); I think we have different understanding of a basic terminology. It seems there is no original Classification design document on opendataplane.org any more. Let me try to describe my view. Result of classification process is an assignment of Class of Service to a packet. So CoS is a destination (final or intermediate), but not a decision point. CoS doesn't decide to which PMRs packets is 'pushed' next. Instead PMRs 'pull' packet from source CoS to destination CoS if packet matches a rule. That is not necessary how it works it HW, but rather my mental model of the process. Maybe Leo can clarify it.
On 04/17/2015 11:55 PM, Rosenboim, Leonid wrote: > > Guys, > > There are several versions of the Classifier API document floating in Google docs, here is one such copy: > > https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing > > Here is a different perspective on what PMR and COS mean, perhaps in terms of an abstract hardware implementation: > > CoS is a meta-data field assigned to each packet as it traverses the classifier pipe-line. > > A packet is assigned an initial CoS by the pktio port which received it. > > Then, the packet is compared multiple times against a set of rules, and as it is common with TCAMs, each comparisons happens against all rules in parallel. > > Each rule has two values to match: 1. the current CoS meta-data field; and 2. a certain packet header field (value with a mask). > If both these values match, the packet met-data CoS field is changed (Action taken) with the destination CoS of the matching rule. > > It is assumed that up to one such rule has matched. > > If a rule has matched, CoS has changed, the process continues one more time. > > If NO MATCH occured, the classification process is finished, and the packet is delivered in accordance to the current CoS (i.e. the last matching rule or the pktio default CoS if the first rule match failed). > > According to CoS, the packet buffer pool and the destination queue are selected, and the packet is ready for application processing. > > Here are some additional observations with regads to use of CoS values: > > Multiple pktio may assign the same CoS initially. (eaming many pktio to one CoS) > > Multple rules can assign the same CoS as destination (action). (meaning multuple PMR to one destination CoS). > > Regarding the source CoS of a PMR, I can not rule out a PMR that can match multiple CoS values (that is creating a many-to-many src-CoS to PMR relationship), but this scheme seems problematic for ease of use as well as implementation, so I would recommend to assume that each PMR should only have a single source CoS. > > Multiple PMRs may have the same source-CoS, but different header fields ot value/mask (creating an OR combination of PMRs). > > I felt that I had to take this discussion ina completely different direction to avoid infinite recursion ;-) Thanks, Leo. This exactly matches my understanding. Could you please add Reviewed-by tag if you are ok with the patch?
On 17 April 2015 at 22:55, Rosenboim, Leonid < Leonid.Rosenboim@caviumnetworks.com> wrote: > > Guys, > > There are several versions of the Classifier API document floating in > Google docs, here is one such copy: > > > https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing > > Here is a different perspective on what PMR and COS mean, perhaps in > terms of an abstract hardware implementation: > > CoS is a meta-data field assigned to each packet as it traverses the > classifier pipe-line. > > A packet is assigned an initial CoS by the pktio port which received it. > > Then, the packet is compared multiple times against a set of rules, and as > it is common with TCAMs, each comparisons happens against all rules in > parallel. > > Each rule has two values to match: 1. the current CoS meta-data field; and > 2. a certain packet header field (value with a mask). > If both these values match, the packet met-data CoS field is changed > (Action taken) with the destination CoS of the matching rule. > > It is assumed that up to one such rule has matched. > > If a rule has matched, CoS has changed, the process continues one more > time. > > If NO MATCH occured, the classification process is finished, and the > packet is delivered in accordance to the current CoS (i.e. the last > matching rule or the pktio default CoS if the first rule match failed). > So partial matches are valid. Is this what we want, e.g. from application point of view and from HW point of view? Is partial matches what is commonly supported by HW classifiers? A classifier which supports these longest prefix matches can easily implement perfect matching (all partial matches just specify the "default" CoS). But a classifier which only supports perfect matching cannot directly support partial matches. I assume you would have to internally create rules/patterns for all (relevant) partial matches as well. The implementation can find all relevant partial matches (prefix rules which specify a CoS different from the default CoS) and add those to the list of rules. Longer prefix matches should be prioritized (however that is done) over shorter prefix matches. The reason I really want to understand the required semantics is that I am planning to design an optimized parser/classifier in SW. Pointer-chasing is a no-no, performance will come from cache-friendly access pattern and some kind of parallelism (e.g. SIMD). I don't know how good it can get. > According to CoS, the packet buffer pool and the destination queue are > selected, and the packet is ready for application processing. > > Here are some additional observations with regads to use of CoS values: > > Multiple pktio may assign the same CoS initially. (eaming many pktio to > one CoS) > > Multple rules can assign the same CoS as destination (action). (meaning > multuple PMR to one destination CoS). > > Regarding the source CoS of a PMR, I can not rule out a PMR that can match > multiple CoS values (that is creating a many-to-many src-CoS to PMR > relationship), but this scheme seems problematic for ease of use as well as > implementation, so I would recommend to assume that each PMR should only > have a single source CoS. > > Multiple PMRs may have the same source-CoS, but different header fields ot > value/mask (creating an OR combination of PMRs). > > I felt that I had to take this discussion ina completely different > direction to avoid infinite recursion ;-) > > Good weekend all, > > - Leo > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
Classification is a collaboration between the implementation and the application. It is the application's responsibility to write unambiguous classification rules and it is the implementation's job to perform the match as efficiently and as specifically as possible. On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl <ola.liljedahl@linaro.org> wrote: > On 17 April 2015 at 22:55, Rosenboim, Leonid < > Leonid.Rosenboim@caviumnetworks.com> wrote: > >> >> Guys, >> >> There are several versions of the Classifier API document floating in >> Google docs, here is one such copy: >> >> >> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing >> >> Here is a different perspective on what PMR and COS mean, perhaps in >> terms of an abstract hardware implementation: >> >> CoS is a meta-data field assigned to each packet as it traverses the >> classifier pipe-line. >> >> A packet is assigned an initial CoS by the pktio port which received it. >> >> Then, the packet is compared multiple times against a set of rules, and >> as it is common with TCAMs, each comparisons happens against all rules in >> parallel. >> >> Each rule has two values to match: 1. the current CoS meta-data field; >> and 2. a certain packet header field (value with a mask). >> If both these values match, the packet met-data CoS field is changed >> (Action taken) with the destination CoS of the matching rule. >> >> It is assumed that up to one such rule has matched. >> >> If a rule has matched, CoS has changed, the process continues one more >> time. >> >> If NO MATCH occured, the classification process is finished, and the >> packet is delivered in accordance to the current CoS (i.e. the last >> matching rule or the pktio default CoS if the first rule match failed). >> > So partial matches are valid. Is this what we want, e.g. from application > point of view and from HW point of view? > > Is partial matches what is commonly supported by HW classifiers? > > A classifier which supports these longest prefix matches can easily > implement perfect matching (all partial matches just specify the "default" > CoS). But a classifier which only supports perfect matching cannot directly > support partial matches. I assume you would have to internally create > rules/patterns for all (relevant) partial matches as well. The > implementation can find all relevant partial matches (prefix rules which > specify a CoS different from the default CoS) and add those to the list of > rules. Longer prefix matches should be prioritized (however that is done) > over shorter prefix matches. > > The reason I really want to understand the required semantics is that I am > planning to design an optimized parser/classifier in SW. Pointer-chasing is > a no-no, performance will come from cache-friendly access pattern and some > kind of parallelism (e.g. SIMD). I don't know how good it can get. > > > >> According to CoS, the packet buffer pool and the destination queue are >> selected, and the packet is ready for application processing. >> >> Here are some additional observations with regads to use of CoS values: >> >> Multiple pktio may assign the same CoS initially. (eaming many pktio to >> one CoS) >> >> Multple rules can assign the same CoS as destination (action). (meaning >> multuple PMR to one destination CoS). >> >> Regarding the source CoS of a PMR, I can not rule out a PMR that can >> match multiple CoS values (that is creating a many-to-many src-CoS to PMR >> relationship), but this scheme seems problematic for ease of use as well as >> implementation, so I would recommend to assume that each PMR should only >> have a single source CoS. >> >> Multiple PMRs may have the same source-CoS, but different header fields >> ot value/mask (creating an OR combination of PMRs). >> >> I felt that I had to take this discussion ina completely different >> direction to avoid infinite recursion ;-) >> >> Good weekend all, >> >> - Leo >> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > >
On 20 April 2015 at 21:49, Bill Fischofer <bill.fischofer@linaro.org> wrote: > Classification is a collaboration between the implementation and the > application. It is the application's responsibility to write unambiguous > classification rules and it is the implementation's job to perform the > match as efficiently and as specifically as possible. > What should an implementation do if the classification rules are ambiguous? E.g. if partial matches (of different partially overlapping rules) use different CoS? Is this an error already when creating the PMR rules? -- Ola > On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl <ola.liljedahl@linaro.org> > wrote: > >> On 17 April 2015 at 22:55, Rosenboim, Leonid < >> Leonid.Rosenboim@caviumnetworks.com> wrote: >> >>> >>> Guys, >>> >>> There are several versions of the Classifier API document floating in >>> Google docs, here is one such copy: >>> >>> >>> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing >>> >>> Here is a different perspective on what PMR and COS mean, perhaps in >>> terms of an abstract hardware implementation: >>> >>> CoS is a meta-data field assigned to each packet as it traverses the >>> classifier pipe-line. >>> >>> A packet is assigned an initial CoS by the pktio port which received it. >>> >>> Then, the packet is compared multiple times against a set of rules, and >>> as it is common with TCAMs, each comparisons happens against all rules in >>> parallel. >>> >>> Each rule has two values to match: 1. the current CoS meta-data field; >>> and 2. a certain packet header field (value with a mask). >>> If both these values match, the packet met-data CoS field is changed >>> (Action taken) with the destination CoS of the matching rule. >>> >>> It is assumed that up to one such rule has matched. >>> >>> If a rule has matched, CoS has changed, the process continues one more >>> time. >>> >>> If NO MATCH occured, the classification process is finished, and the >>> packet is delivered in accordance to the current CoS (i.e. the last >>> matching rule or the pktio default CoS if the first rule match failed). >>> >> So partial matches are valid. Is this what we want, e.g. from application >> point of view and from HW point of view? >> >> Is partial matches what is commonly supported by HW classifiers? >> >> A classifier which supports these longest prefix matches can easily >> implement perfect matching (all partial matches just specify the "default" >> CoS). But a classifier which only supports perfect matching cannot directly >> support partial matches. I assume you would have to internally create >> rules/patterns for all (relevant) partial matches as well. The >> implementation can find all relevant partial matches (prefix rules which >> specify a CoS different from the default CoS) and add those to the list of >> rules. Longer prefix matches should be prioritized (however that is done) >> over shorter prefix matches. >> >> The reason I really want to understand the required semantics is that I >> am planning to design an optimized parser/classifier in SW. Pointer-chasing >> is a no-no, performance will come from cache-friendly access pattern and >> some kind of parallelism (e.g. SIMD). I don't know how good it can get. >> >> >> >>> According to CoS, the packet buffer pool and the destination queue are >>> selected, and the packet is ready for application processing. >>> >>> Here are some additional observations with regads to use of CoS values: >>> >>> Multiple pktio may assign the same CoS initially. (eaming many pktio to >>> one CoS) >>> >>> Multple rules can assign the same CoS as destination (action). (meaning >>> multuple PMR to one destination CoS). >>> >>> Regarding the source CoS of a PMR, I can not rule out a PMR that can >>> match multiple CoS values (that is creating a many-to-many src-CoS to PMR >>> relationship), but this scheme seems problematic for ease of use as well as >>> implementation, so I would recommend to assume that each PMR should only >>> have a single source CoS. >>> >>> Multiple PMRs may have the same source-CoS, but different header fields >>> ot value/mask (creating an OR combination of PMRs). >>> >>> I felt that I had to take this discussion ina completely different >>> direction to avoid infinite recursion ;-) >>> >>> Good weekend all, >>> >>> - Leo >>> >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> https://lists.linaro.org/mailman/listinfo/lng-odp >>> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >
Behavior is undefined if rules are ambiguous. Consider the following rules: protocol == UDP --> CoS A port == 1234 --> CoS B What happens if a UDP packet for port 1234 arrives? Answer: undefined. The result may be either CoS A or CoS B. A better rule set would be: protocol == UDP --> CoS A CoS A && port == 1234 --> CoS B Now this is unambiguous. UDP packets go to CoS A unless they also specify port 1234, in which case they go to CoS B. On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl <ola.liljedahl@linaro.org> wrote: > On 20 April 2015 at 21:49, Bill Fischofer <bill.fischofer@linaro.org> > wrote: > >> Classification is a collaboration between the implementation and the >> application. It is the application's responsibility to write unambiguous >> classification rules and it is the implementation's job to perform the >> match as efficiently and as specifically as possible. >> > What should an implementation do if the classification rules are > ambiguous? E.g. if partial matches (of different partially overlapping > rules) use different CoS? Is this an error already when creating the PMR > rules? > > -- Ola > > >> On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl <ola.liljedahl@linaro.org> >> wrote: >> >>> On 17 April 2015 at 22:55, Rosenboim, Leonid < >>> Leonid.Rosenboim@caviumnetworks.com> wrote: >>> >>>> >>>> Guys, >>>> >>>> There are several versions of the Classifier API document floating in >>>> Google docs, here is one such copy: >>>> >>>> >>>> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing >>>> >>>> Here is a different perspective on what PMR and COS mean, perhaps in >>>> terms of an abstract hardware implementation: >>>> >>>> CoS is a meta-data field assigned to each packet as it traverses the >>>> classifier pipe-line. >>>> >>>> A packet is assigned an initial CoS by the pktio port which received it. >>>> >>>> Then, the packet is compared multiple times against a set of rules, and >>>> as it is common with TCAMs, each comparisons happens against all rules in >>>> parallel. >>>> >>>> Each rule has two values to match: 1. the current CoS meta-data field; >>>> and 2. a certain packet header field (value with a mask). >>>> If both these values match, the packet met-data CoS field is changed >>>> (Action taken) with the destination CoS of the matching rule. >>>> >>>> It is assumed that up to one such rule has matched. >>>> >>>> If a rule has matched, CoS has changed, the process continues one more >>>> time. >>>> >>>> If NO MATCH occured, the classification process is finished, and the >>>> packet is delivered in accordance to the current CoS (i.e. the last >>>> matching rule or the pktio default CoS if the first rule match failed). >>>> >>> So partial matches are valid. Is this what we want, e.g. from >>> application point of view and from HW point of view? >>> >>> Is partial matches what is commonly supported by HW classifiers? >>> >>> A classifier which supports these longest prefix matches can easily >>> implement perfect matching (all partial matches just specify the "default" >>> CoS). But a classifier which only supports perfect matching cannot directly >>> support partial matches. I assume you would have to internally create >>> rules/patterns for all (relevant) partial matches as well. The >>> implementation can find all relevant partial matches (prefix rules which >>> specify a CoS different from the default CoS) and add those to the list of >>> rules. Longer prefix matches should be prioritized (however that is done) >>> over shorter prefix matches. >>> >>> The reason I really want to understand the required semantics is that I >>> am planning to design an optimized parser/classifier in SW. Pointer-chasing >>> is a no-no, performance will come from cache-friendly access pattern and >>> some kind of parallelism (e.g. SIMD). I don't know how good it can get. >>> >>> >>> >>>> According to CoS, the packet buffer pool and the destination queue are >>>> selected, and the packet is ready for application processing. >>>> >>>> Here are some additional observations with regads to use of CoS values: >>>> >>>> Multiple pktio may assign the same CoS initially. (eaming many pktio to >>>> one CoS) >>>> >>>> Multple rules can assign the same CoS as destination (action). (meaning >>>> multuple PMR to one destination CoS). >>>> >>>> Regarding the source CoS of a PMR, I can not rule out a PMR that can >>>> match multiple CoS values (that is creating a many-to-many src-CoS to PMR >>>> relationship), but this scheme seems problematic for ease of use as well as >>>> implementation, so I would recommend to assume that each PMR should only >>>> have a single source CoS. >>>> >>>> Multiple PMRs may have the same source-CoS, but different header fields >>>> ot value/mask (creating an OR combination of PMRs). >>>> >>>> I felt that I had to take this discussion ina completely different >>>> direction to avoid infinite recursion ;-) >>>> >>>> Good weekend all, >>>> >>>> - Leo >>>> >>>> >>>> >>>> _______________________________________________ >>>> lng-odp mailing list >>>> lng-odp@lists.linaro.org >>>> https://lists.linaro.org/mailman/listinfo/lng-odp >>>> >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> https://lists.linaro.org/mailman/listinfo/lng-odp >>> >>> >> >
On 04/21/15 15:01, Bill Fischofer wrote: > Behavior is undefined if rules are ambiguous. Consider the following > rules: > > protocol == UDP --> CoS A > port == 1234 --> CoS B > > What happens if a UDP packet for port 1234 arrives? Answer: undefined. Isn't pmr created one by one to the table? And first match will return Cos A in that case. Maxim. > The result may be either CoS A or CoS B. > > A better rule set would be: > > protocol == UDP --> CoS A > > CoS A && port == 1234 --> CoS B > > Now this is unambiguous. UDP packets go to CoS A unless they also > specify port 1234, in which case they go to CoS B. > > On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl > <ola.liljedahl@linaro.org <mailto:ola.liljedahl@linaro.org>> wrote: > > On 20 April 2015 at 21:49, Bill Fischofer > <bill.fischofer@linaro.org <mailto:bill.fischofer@linaro.org>> wrote: > > Classification is a collaboration between the implementation > and the application. It is the application's responsibility to > write unambiguous classification rules and it is the > implementation's job to perform the match as efficiently and > as specifically as possible. > > What should an implementation do if the classification rules are > ambiguous? E.g. if partial matches (of different partially > overlapping rules) use different CoS? Is this an error already > when creating the PMR rules? > > -- Ola > > > On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl > <ola.liljedahl@linaro.org <mailto:ola.liljedahl@linaro.org>> > wrote: > > On 17 April 2015 at 22:55, Rosenboim, Leonid > <Leonid.Rosenboim@caviumnetworks.com > <mailto:Leonid.Rosenboim@caviumnetworks.com>> wrote: > > > Guys, > > There are several versions of the Classifier API > document floating in Google docs, here is one such copy: > > https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing > > Here is a different perspective on what PMR and COS > mean, perhaps in terms of an abstract hardware > implementation: > > CoS is a meta-data field assigned to each packet as it > traverses the classifier pipe-line. > > A packet is assigned an initial CoS by the pktio port > which received it. > > Then, the packet is compared multiple times against a > set of rules, and as it is common with TCAMs, each > comparisons happens against all rules in parallel. > > Each rule has two values to match: 1. the current CoS > meta-data field; and 2. a certain packet header field > (value with a mask). > If both these values match, the packet met-data CoS > field is changed (Action taken) with the destination > CoS of the matching rule. > > It is assumed that up to one such rule has matched. > > If a rule has matched, CoS has changed, the process > continues one more time. > > If NO MATCH occured, the classification process is > finished, and the packet is delivered in accordance to > the current CoS (i.e. the last matching rule or the > pktio default CoS if the first rule match failed). > > So partial matches are valid. Is this what we want, e.g. > from application point of view and from HW point of view? > > Is partial matches what is commonly supported by HW > classifiers? > > A classifier which supports these longest prefix matches > can easily implement perfect matching (all partial matches > just specify the "default" CoS). But a classifier which > only supports perfect matching cannot directly support > partial matches. I assume you would have to internally > create rules/patterns for all (relevant) partial matches > as well. The implementation can find all relevant partial > matches (prefix rules which specify a CoS different from > the default CoS) and add those to the list of rules. > Longer prefix matches should be prioritized (however that > is done) over shorter prefix matches. > > The reason I really want to understand the required > semantics is that I am planning to design an optimized > parser/classifier in SW. Pointer-chasing is a no-no, > performance will come from cache-friendly access pattern > and some kind of parallelism (e.g. SIMD). I don't know how > good it can get. > > > > According to CoS, the packet buffer pool and the > destination queue are selected, and the packet is > ready for application processing. > > Here are some additional observations with regads to > use of CoS values: > > Multiple pktio may assign the same CoS initially. > (eaming many pktio to one CoS) > > Multple rules can assign the same CoS as destination > (action). (meaning multuple PMR to one destination CoS). > > Regarding the source CoS of a PMR, I can not rule out > a PMR that can match multiple CoS values (that is > creating a many-to-many src-CoS to PMR relationship), > but this scheme seems problematic for ease of use as > well as implementation, so I would recommend to assume > that each PMR should only have a single source CoS. > > Multiple PMRs may have the same source-CoS, but > different header fields ot value/mask (creating an OR > combination of PMRs). > > I felt that I had to take this discussion ina > completely different direction to avoid infinite > recursion ;-) > > Good weekend all, > > - Leo > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/lng-odp > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp
On 21 April 2015 at 14:26, Maxim Uvarov <maxim.uvarov@linaro.org> wrote: > On 04/21/15 15:01, Bill Fischofer wrote: > >> Behavior is undefined if rules are ambiguous. Consider the following >> rules: >> >> protocol == UDP --> CoS A >> port == 1234 --> CoS B >> >> What happens if a UDP packet for port 1234 arrives? Answer: undefined. >> > > > Isn't pmr created one by one to the table? And first match will return Cos > A in that case. > Since we are having this discussion, it is obvious that we need a definition of the ODP classification that cannot be misunderstood or misinterpreted. Probably a formal definition. Or do everyone here agree that the (current) linux-generic implementation can serve as *the* definition? > > Maxim. > > The result may be either CoS A or CoS B. >> >> A better rule set would be: >> >> protocol == UDP --> CoS A >> >> CoS A && port == 1234 --> CoS B >> >> Now this is unambiguous. UDP packets go to CoS A unless they also >> specify port 1234, in which case they go to CoS B. >> >> On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl <ola.liljedahl@linaro.org >> <mailto:ola.liljedahl@linaro.org>> wrote: >> >> On 20 April 2015 at 21:49, Bill Fischofer >> <bill.fischofer@linaro.org <mailto:bill.fischofer@linaro.org>> wrote: >> >> Classification is a collaboration between the implementation >> and the application. It is the application's responsibility to >> write unambiguous classification rules and it is the >> implementation's job to perform the match as efficiently and >> as specifically as possible. >> >> What should an implementation do if the classification rules are >> ambiguous? E.g. if partial matches (of different partially >> overlapping rules) use different CoS? Is this an error already >> when creating the PMR rules? >> >> -- Ola >> >> >> On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl >> <ola.liljedahl@linaro.org <mailto:ola.liljedahl@linaro.org>> >> wrote: >> >> On 17 April 2015 at 22:55, Rosenboim, Leonid >> <Leonid.Rosenboim@caviumnetworks.com >> <mailto:Leonid.Rosenboim@caviumnetworks.com>> wrote: >> >> >> Guys, >> >> There are several versions of the Classifier API >> document floating in Google docs, here is one such copy: >> >> >> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing >> >> Here is a different perspective on what PMR and COS >> mean, perhaps in terms of an abstract hardware >> implementation: >> >> CoS is a meta-data field assigned to each packet as it >> traverses the classifier pipe-line. >> >> A packet is assigned an initial CoS by the pktio port >> which received it. >> >> Then, the packet is compared multiple times against a >> set of rules, and as it is common with TCAMs, each >> comparisons happens against all rules in parallel. >> >> Each rule has two values to match: 1. the current CoS >> meta-data field; and 2. a certain packet header field >> (value with a mask). >> If both these values match, the packet met-data CoS >> field is changed (Action taken) with the destination >> CoS of the matching rule. >> >> It is assumed that up to one such rule has matched. >> >> If a rule has matched, CoS has changed, the process >> continues one more time. >> >> If NO MATCH occured, the classification process is >> finished, and the packet is delivered in accordance to >> the current CoS (i.e. the last matching rule or the >> pktio default CoS if the first rule match failed). >> >> So partial matches are valid. Is this what we want, e.g. >> from application point of view and from HW point of view? >> >> Is partial matches what is commonly supported by HW >> classifiers? >> >> A classifier which supports these longest prefix matches >> can easily implement perfect matching (all partial matches >> just specify the "default" CoS). But a classifier which >> only supports perfect matching cannot directly support >> partial matches. I assume you would have to internally >> create rules/patterns for all (relevant) partial matches >> as well. The implementation can find all relevant partial >> matches (prefix rules which specify a CoS different from >> the default CoS) and add those to the list of rules. >> Longer prefix matches should be prioritized (however that >> is done) over shorter prefix matches. >> >> The reason I really want to understand the required >> semantics is that I am planning to design an optimized >> parser/classifier in SW. Pointer-chasing is a no-no, >> performance will come from cache-friendly access pattern >> and some kind of parallelism (e.g. SIMD). I don't know how >> good it can get. >> >> >> >> According to CoS, the packet buffer pool and the >> destination queue are selected, and the packet is >> ready for application processing. >> >> Here are some additional observations with regads to >> use of CoS values: >> >> Multiple pktio may assign the same CoS initially. >> (eaming many pktio to one CoS) >> >> Multple rules can assign the same CoS as destination >> (action). (meaning multuple PMR to one destination CoS). >> >> Regarding the source CoS of a PMR, I can not rule out >> a PMR that can match multiple CoS values (that is >> creating a many-to-many src-CoS to PMR relationship), >> but this scheme seems problematic for ease of use as >> well as implementation, so I would recommend to assume >> that each PMR should only have a single source CoS. >> >> Multiple PMRs may have the same source-CoS, but >> different header fields ot value/mask (creating an OR >> combination of PMRs). >> >> I felt that I had to take this discussion ina >> completely different direction to avoid infinite >> recursion ;-) >> >> Good weekend all, >> >> - Leo >> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org >> > >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> >> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
On 21 April 2015 at 18:15, Ola Liljedahl <ola.liljedahl@linaro.org> wrote: > On 21 April 2015 at 14:26, Maxim Uvarov <maxim.uvarov@linaro.org> wrote: >> >> On 04/21/15 15:01, Bill Fischofer wrote: >>> >>> Behavior is undefined if rules are ambiguous. Consider the following >>> rules: >>> >>> protocol == UDP --> CoS A >>> port == 1234 --> CoS B >>> >>> What happens if a UDP packet for port 1234 arrives? Answer: undefined. >> >> >> >> Isn't pmr created one by one to the table? And first match will return Cos >> A in that case. > > Since we are having this discussion, it is obvious that we need a definition > of the ODP classification that cannot be misunderstood or misinterpreted. > Probably a formal definition. Or do everyone here agree that the (current) > linux-generic implementation can serve as *the* definition? Shouldn't we use the classification design document as the definition of classification and the linux-generic implementation can be used as a reference and not "the" definition. Regards, Bala > > > >> >> >> Maxim. >> >>> The result may be either CoS A or CoS B. >>> >>> A better rule set would be: >>> >>> protocol == UDP --> CoS A >>> >>> CoS A && port == 1234 --> CoS B >>> >>> Now this is unambiguous. UDP packets go to CoS A unless they also >>> specify port 1234, in which case they go to CoS B. >>> >>> On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl <ola.liljedahl@linaro.org >>> <mailto:ola.liljedahl@linaro.org>> wrote: >>> >>> On 20 April 2015 at 21:49, Bill Fischofer >>> <bill.fischofer@linaro.org <mailto:bill.fischofer@linaro.org>> wrote: >>> >>> Classification is a collaboration between the implementation >>> and the application. It is the application's responsibility to >>> write unambiguous classification rules and it is the >>> implementation's job to perform the match as efficiently and >>> as specifically as possible. >>> >>> What should an implementation do if the classification rules are >>> ambiguous? E.g. if partial matches (of different partially >>> overlapping rules) use different CoS? Is this an error already >>> when creating the PMR rules? >>> >>> -- Ola >>> >>> >>> On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl >>> <ola.liljedahl@linaro.org <mailto:ola.liljedahl@linaro.org>> >>> wrote: >>> >>> On 17 April 2015 at 22:55, Rosenboim, Leonid >>> <Leonid.Rosenboim@caviumnetworks.com >>> <mailto:Leonid.Rosenboim@caviumnetworks.com>> wrote: >>> >>> >>> Guys, >>> >>> There are several versions of the Classifier API >>> document floating in Google docs, here is one such copy: >>> >>> >>> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing >>> >>> Here is a different perspective on what PMR and COS >>> mean, perhaps in terms of an abstract hardware >>> implementation: >>> >>> CoS is a meta-data field assigned to each packet as it >>> traverses the classifier pipe-line. >>> >>> A packet is assigned an initial CoS by the pktio port >>> which received it. >>> >>> Then, the packet is compared multiple times against a >>> set of rules, and as it is common with TCAMs, each >>> comparisons happens against all rules in parallel. >>> >>> Each rule has two values to match: 1. the current CoS >>> meta-data field; and 2. a certain packet header field >>> (value with a mask). >>> If both these values match, the packet met-data CoS >>> field is changed (Action taken) with the destination >>> CoS of the matching rule. >>> >>> It is assumed that up to one such rule has matched. >>> >>> If a rule has matched, CoS has changed, the process >>> continues one more time. >>> >>> If NO MATCH occured, the classification process is >>> finished, and the packet is delivered in accordance to >>> the current CoS (i.e. the last matching rule or the >>> pktio default CoS if the first rule match failed). >>> >>> So partial matches are valid. Is this what we want, e.g. >>> from application point of view and from HW point of view? >>> >>> Is partial matches what is commonly supported by HW >>> classifiers? >>> >>> A classifier which supports these longest prefix matches >>> can easily implement perfect matching (all partial matches >>> just specify the "default" CoS). But a classifier which >>> only supports perfect matching cannot directly support >>> partial matches. I assume you would have to internally >>> create rules/patterns for all (relevant) partial matches >>> as well. The implementation can find all relevant partial >>> matches (prefix rules which specify a CoS different from >>> the default CoS) and add those to the list of rules. >>> Longer prefix matches should be prioritized (however that >>> is done) over shorter prefix matches. >>> >>> The reason I really want to understand the required >>> semantics is that I am planning to design an optimized >>> parser/classifier in SW. Pointer-chasing is a no-no, >>> performance will come from cache-friendly access pattern >>> and some kind of parallelism (e.g. SIMD). I don't know how >>> good it can get. >>> >>> >>> >>> According to CoS, the packet buffer pool and the >>> destination queue are selected, and the packet is >>> ready for application processing. >>> >>> Here are some additional observations with regads to >>> use of CoS values: >>> >>> Multiple pktio may assign the same CoS initially. >>> (eaming many pktio to one CoS) >>> >>> Multple rules can assign the same CoS as destination >>> (action). (meaning multuple PMR to one destination CoS). >>> >>> Regarding the source CoS of a PMR, I can not rule out >>> a PMR that can match multiple CoS values (that is >>> creating a many-to-many src-CoS to PMR relationship), >>> but this scheme seems problematic for ease of use as >>> well as implementation, so I would recommend to assume >>> that each PMR should only have a single source CoS. >>> >>> Multiple PMRs may have the same source-CoS, but >>> different header fields ot value/mask (creating an OR >>> combination of PMRs). >>> >>> I felt that I had to take this discussion ina >>> completely different direction to avoid infinite >>> recursion ;-) >>> >>> Good weekend all, >>> >>> - Leo >>> >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> <mailto:lng-odp@lists.linaro.org> >>> https://lists.linaro.org/mailman/listinfo/lng-odp >>> >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >>> https://lists.linaro.org/mailman/listinfo/lng-odp >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
The design doc says what I've been saying here. It's the application's responsibility to ensure that the rule set specified is unambiguous. On Tue, Apr 21, 2015 at 8:08 AM, Bala Manoharan <bala.manoharan@linaro.org> wrote: > On 21 April 2015 at 18:15, Ola Liljedahl <ola.liljedahl@linaro.org> wrote: > > On 21 April 2015 at 14:26, Maxim Uvarov <maxim.uvarov@linaro.org> wrote: > >> > >> On 04/21/15 15:01, Bill Fischofer wrote: > >>> > >>> Behavior is undefined if rules are ambiguous. Consider the following > >>> rules: > >>> > >>> protocol == UDP --> CoS A > >>> port == 1234 --> CoS B > >>> > >>> What happens if a UDP packet for port 1234 arrives? Answer: undefined. > >> > >> > >> > >> Isn't pmr created one by one to the table? And first match will return > Cos > >> A in that case. > > > > Since we are having this discussion, it is obvious that we need a > definition > > of the ODP classification that cannot be misunderstood or misinterpreted. > > Probably a formal definition. Or do everyone here agree that the > (current) > > linux-generic implementation can serve as *the* definition? > > Shouldn't we use the classification design document as the definition > of classification and the linux-generic implementation can be used as > a reference and not "the" definition. > > Regards, > Bala > > > > > > > >> > >> > >> Maxim. > >> > >>> The result may be either CoS A or CoS B. > >>> > >>> A better rule set would be: > >>> > >>> protocol == UDP --> CoS A > >>> > >>> CoS A && port == 1234 --> CoS B > >>> > >>> Now this is unambiguous. UDP packets go to CoS A unless they also > >>> specify port 1234, in which case they go to CoS B. > >>> > >>> On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl < > ola.liljedahl@linaro.org > >>> <mailto:ola.liljedahl@linaro.org>> wrote: > >>> > >>> On 20 April 2015 at 21:49, Bill Fischofer > >>> <bill.fischofer@linaro.org <mailto:bill.fischofer@linaro.org>> > wrote: > >>> > >>> Classification is a collaboration between the implementation > >>> and the application. It is the application's responsibility to > >>> write unambiguous classification rules and it is the > >>> implementation's job to perform the match as efficiently and > >>> as specifically as possible. > >>> > >>> What should an implementation do if the classification rules are > >>> ambiguous? E.g. if partial matches (of different partially > >>> overlapping rules) use different CoS? Is this an error already > >>> when creating the PMR rules? > >>> > >>> -- Ola > >>> > >>> > >>> On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl > >>> <ola.liljedahl@linaro.org <mailto:ola.liljedahl@linaro.org>> > >>> wrote: > >>> > >>> On 17 April 2015 at 22:55, Rosenboim, Leonid > >>> <Leonid.Rosenboim@caviumnetworks.com > >>> <mailto:Leonid.Rosenboim@caviumnetworks.com>> wrote: > >>> > >>> > >>> Guys, > >>> > >>> There are several versions of the Classifier API > >>> document floating in Google docs, here is one such > copy: > >>> > >>> > >>> > https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing > >>> > >>> Here is a different perspective on what PMR and COS > >>> mean, perhaps in terms of an abstract hardware > >>> implementation: > >>> > >>> CoS is a meta-data field assigned to each packet as it > >>> traverses the classifier pipe-line. > >>> > >>> A packet is assigned an initial CoS by the pktio port > >>> which received it. > >>> > >>> Then, the packet is compared multiple times against a > >>> set of rules, and as it is common with TCAMs, each > >>> comparisons happens against all rules in parallel. > >>> > >>> Each rule has two values to match: 1. the current CoS > >>> meta-data field; and 2. a certain packet header field > >>> (value with a mask). > >>> If both these values match, the packet met-data CoS > >>> field is changed (Action taken) with the destination > >>> CoS of the matching rule. > >>> > >>> It is assumed that up to one such rule has matched. > >>> > >>> If a rule has matched, CoS has changed, the process > >>> continues one more time. > >>> > >>> If NO MATCH occured, the classification process is > >>> finished, and the packet is delivered in accordance to > >>> the current CoS (i.e. the last matching rule or the > >>> pktio default CoS if the first rule match failed). > >>> > >>> So partial matches are valid. Is this what we want, e.g. > >>> from application point of view and from HW point of view? > >>> > >>> Is partial matches what is commonly supported by HW > >>> classifiers? > >>> > >>> A classifier which supports these longest prefix matches > >>> can easily implement perfect matching (all partial matches > >>> just specify the "default" CoS). But a classifier which > >>> only supports perfect matching cannot directly support > >>> partial matches. I assume you would have to internally > >>> create rules/patterns for all (relevant) partial matches > >>> as well. The implementation can find all relevant partial > >>> matches (prefix rules which specify a CoS different from > >>> the default CoS) and add those to the list of rules. > >>> Longer prefix matches should be prioritized (however that > >>> is done) over shorter prefix matches. > >>> > >>> The reason I really want to understand the required > >>> semantics is that I am planning to design an optimized > >>> parser/classifier in SW. Pointer-chasing is a no-no, > >>> performance will come from cache-friendly access pattern > >>> and some kind of parallelism (e.g. SIMD). I don't know how > >>> good it can get. > >>> > >>> > >>> > >>> According to CoS, the packet buffer pool and the > >>> destination queue are selected, and the packet is > >>> ready for application processing. > >>> > >>> Here are some additional observations with regads to > >>> use of CoS values: > >>> > >>> Multiple pktio may assign the same CoS initially. > >>> (eaming many pktio to one CoS) > >>> > >>> Multple rules can assign the same CoS as destination > >>> (action). (meaning multuple PMR to one destination > CoS). > >>> > >>> Regarding the source CoS of a PMR, I can not rule out > >>> a PMR that can match multiple CoS values (that is > >>> creating a many-to-many src-CoS to PMR relationship), > >>> but this scheme seems problematic for ease of use as > >>> well as implementation, so I would recommend to assume > >>> that each PMR should only have a single source CoS. > >>> > >>> Multiple PMRs may have the same source-CoS, but > >>> different header fields ot value/mask (creating an OR > >>> combination of PMRs). > >>> > >>> I felt that I had to take this discussion ina > >>> completely different direction to avoid infinite > >>> recursion ;-) > >>> > >>> Good weekend all, > >>> > >>> - Leo > >>> > >>> > >>> > >>> _______________________________________________ > >>> lng-odp mailing list > >>> lng-odp@lists.linaro.org > >>> <mailto:lng-odp@lists.linaro.org> > >>> https://lists.linaro.org/mailman/listinfo/lng-odp > >>> > >>> > >>> > >>> _______________________________________________ > >>> lng-odp mailing list > >>> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> > >>> https://lists.linaro.org/mailman/listinfo/lng-odp > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> lng-odp mailing list > >>> lng-odp@lists.linaro.org > >>> https://lists.linaro.org/mailman/listinfo/lng-odp > >> > >> > >> _______________________________________________ > >> lng-odp mailing list > >> lng-odp@lists.linaro.org > >> https://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > https://lists.linaro.org/mailman/listinfo/lng-odp > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
Code rules IMHO - the compiler will ensure we follow the rules. Can we add test cases to prove the behavior across all platforms, linux-generic being one of them, and thus the code is correct no matter what is written anywhere else. Presumably the api documentation matches the code but it should be updated and clarified to match the behavior proven by the test cases. I do not think referencing the classification design document has any value any more it is no longer a maintained document, however I do recall as Bill says that we decided it was the applications responsibility be unambiguous. On 21 April 2015 at 17:33, Bill Fischofer <bill.fischofer@linaro.org> wrote: > The design doc says what I've been saying here. It's the application's > responsibility to ensure that the rule set specified is unambiguous. > > On Tue, Apr 21, 2015 at 8:08 AM, Bala Manoharan <bala.manoharan@linaro.org > > wrote: > >> On 21 April 2015 at 18:15, Ola Liljedahl <ola.liljedahl@linaro.org> >> wrote: >> > On 21 April 2015 at 14:26, Maxim Uvarov <maxim.uvarov@linaro.org> >> wrote: >> >> >> >> On 04/21/15 15:01, Bill Fischofer wrote: >> >>> >> >>> Behavior is undefined if rules are ambiguous. Consider the following >> >>> rules: >> >>> >> >>> protocol == UDP --> CoS A >> >>> port == 1234 --> CoS B >> >>> >> >>> What happens if a UDP packet for port 1234 arrives? Answer: undefined. >> >> >> >> >> >> >> >> Isn't pmr created one by one to the table? And first match will return >> Cos >> >> A in that case. >> > >> > Since we are having this discussion, it is obvious that we need a >> definition >> > of the ODP classification that cannot be misunderstood or >> misinterpreted. >> > Probably a formal definition. Or do everyone here agree that the >> (current) >> > linux-generic implementation can serve as *the* definition? >> >> Shouldn't we use the classification design document as the definition >> of classification and the linux-generic implementation can be used as >> a reference and not "the" definition. >> >> Regards, >> Bala >> > >> > >> > >> >> >> >> >> >> Maxim. >> >> >> >>> The result may be either CoS A or CoS B. >> >>> >> >>> A better rule set would be: >> >>> >> >>> protocol == UDP --> CoS A >> >>> >> >>> CoS A && port == 1234 --> CoS B >> >>> >> >>> Now this is unambiguous. UDP packets go to CoS A unless they also >> >>> specify port 1234, in which case they go to CoS B. >> >>> >> >>> On Tue, Apr 21, 2015 at 4:52 AM, Ola Liljedahl < >> ola.liljedahl@linaro.org >> >>> <mailto:ola.liljedahl@linaro.org>> wrote: >> >>> >> >>> On 20 April 2015 at 21:49, Bill Fischofer >> >>> <bill.fischofer@linaro.org <mailto:bill.fischofer@linaro.org>> >> wrote: >> >>> >> >>> Classification is a collaboration between the implementation >> >>> and the application. It is the application's responsibility to >> >>> write unambiguous classification rules and it is the >> >>> implementation's job to perform the match as efficiently and >> >>> as specifically as possible. >> >>> >> >>> What should an implementation do if the classification rules are >> >>> ambiguous? E.g. if partial matches (of different partially >> >>> overlapping rules) use different CoS? Is this an error already >> >>> when creating the PMR rules? >> >>> >> >>> -- Ola >> >>> >> >>> >> >>> On Mon, Apr 20, 2015 at 7:33 AM, Ola Liljedahl >> >>> <ola.liljedahl@linaro.org <mailto:ola.liljedahl@linaro.org>> >> >>> wrote: >> >>> >> >>> On 17 April 2015 at 22:55, Rosenboim, Leonid >> >>> <Leonid.Rosenboim@caviumnetworks.com >> >>> <mailto:Leonid.Rosenboim@caviumnetworks.com>> wrote: >> >>> >> >>> >> >>> Guys, >> >>> >> >>> There are several versions of the Classifier API >> >>> document floating in Google docs, here is one such >> copy: >> >>> >> >>> >> >>> >> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing >> >>> >> >>> Here is a different perspective on what PMR and COS >> >>> mean, perhaps in terms of an abstract hardware >> >>> implementation: >> >>> >> >>> CoS is a meta-data field assigned to each packet as it >> >>> traverses the classifier pipe-line. >> >>> >> >>> A packet is assigned an initial CoS by the pktio port >> >>> which received it. >> >>> >> >>> Then, the packet is compared multiple times against a >> >>> set of rules, and as it is common with TCAMs, each >> >>> comparisons happens against all rules in parallel. >> >>> >> >>> Each rule has two values to match: 1. the current CoS >> >>> meta-data field; and 2. a certain packet header field >> >>> (value with a mask). >> >>> If both these values match, the packet met-data CoS >> >>> field is changed (Action taken) with the destination >> >>> CoS of the matching rule. >> >>> >> >>> It is assumed that up to one such rule has matched. >> >>> >> >>> If a rule has matched, CoS has changed, the process >> >>> continues one more time. >> >>> >> >>> If NO MATCH occured, the classification process is >> >>> finished, and the packet is delivered in accordance to >> >>> the current CoS (i.e. the last matching rule or the >> >>> pktio default CoS if the first rule match failed). >> >>> >> >>> So partial matches are valid. Is this what we want, e.g. >> >>> from application point of view and from HW point of view? >> >>> >> >>> Is partial matches what is commonly supported by HW >> >>> classifiers? >> >>> >> >>> A classifier which supports these longest prefix matches >> >>> can easily implement perfect matching (all partial matches >> >>> just specify the "default" CoS). But a classifier which >> >>> only supports perfect matching cannot directly support >> >>> partial matches. I assume you would have to internally >> >>> create rules/patterns for all (relevant) partial matches >> >>> as well. The implementation can find all relevant partial >> >>> matches (prefix rules which specify a CoS different from >> >>> the default CoS) and add those to the list of rules. >> >>> Longer prefix matches should be prioritized (however that >> >>> is done) over shorter prefix matches. >> >>> >> >>> The reason I really want to understand the required >> >>> semantics is that I am planning to design an optimized >> >>> parser/classifier in SW. Pointer-chasing is a no-no, >> >>> performance will come from cache-friendly access pattern >> >>> and some kind of parallelism (e.g. SIMD). I don't know how >> >>> good it can get. >> >>> >> >>> >> >>> >> >>> According to CoS, the packet buffer pool and the >> >>> destination queue are selected, and the packet is >> >>> ready for application processing. >> >>> >> >>> Here are some additional observations with regads to >> >>> use of CoS values: >> >>> >> >>> Multiple pktio may assign the same CoS initially. >> >>> (eaming many pktio to one CoS) >> >>> >> >>> Multple rules can assign the same CoS as destination >> >>> (action). (meaning multuple PMR to one destination >> CoS). >> >>> >> >>> Regarding the source CoS of a PMR, I can not rule out >> >>> a PMR that can match multiple CoS values (that is >> >>> creating a many-to-many src-CoS to PMR relationship), >> >>> but this scheme seems problematic for ease of use as >> >>> well as implementation, so I would recommend to assume >> >>> that each PMR should only have a single source CoS. >> >>> >> >>> Multiple PMRs may have the same source-CoS, but >> >>> different header fields ot value/mask (creating an OR >> >>> combination of PMRs). >> >>> >> >>> I felt that I had to take this discussion ina >> >>> completely different direction to avoid infinite >> >>> recursion ;-) >> >>> >> >>> Good weekend all, >> >>> >> >>> - Leo >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> lng-odp mailing list >> >>> lng-odp@lists.linaro.org >> >>> <mailto:lng-odp@lists.linaro.org> >> >>> https://lists.linaro.org/mailman/listinfo/lng-odp >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> lng-odp mailing list >> >>> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org >> > >> >>> https://lists.linaro.org/mailman/listinfo/lng-odp >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> lng-odp mailing list >> >>> lng-odp@lists.linaro.org >> >>> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> >> >> >> _______________________________________________ >> >> lng-odp mailing list >> >> lng-odp@lists.linaro.org >> >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > >> > >> > >> > _______________________________________________ >> > lng-odp mailing list >> > lng-odp@lists.linaro.org >> > https://lists.linaro.org/mailman/listinfo/lng-odp >> > >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > >
On 04/22/2015 12:39 AM, Mike Holmes wrote: > Code rules IMHO - the compiler will ensure we follow the rules. > > Can we add test cases to prove the behavior across all platforms, > linux-generic being one of them, and thus the code is correct no matter > what is written anywhere else. Presumably the api documentation matches > the code but it should be updated and clarified to match the behavior > proven by the test cases. We can't check ambiguous rules by compiler or tests. IMO better to copy part of design document into classification.h to clarify the behavior. > > I do not think referencing the classification design document has any > value any more it is no longer a maintained document, however I > do recall as Bill says that we decided it was the applications > responsibility be unambiguous. I agree it should be application responsibility. Implementation may assist here and throw an error in case it detects an ambiguous combination.
On 22 April 2015 at 06:55, Taras Kondratiuk <taras.kondratiuk@linaro.org> wrote: > On 04/22/2015 12:39 AM, Mike Holmes wrote: > >> Code rules IMHO - the compiler will ensure we follow the rules. >> >> Can we add test cases to prove the behavior across all platforms, >> linux-generic being one of them, and thus the code is correct no matter >> what is written anywhere else. Presumably the api documentation matches >> the code but it should be updated and clarified to match the behavior >> proven by the test cases. >> > > We can't check ambiguous rules by compiler or tests. > IMO better to copy part of design document into classification.h to > clarify the behavior. That works for me as long as we do specify the behavior - should some element of that documentation improvement be attached to this patch since it spawned the discussion ? > > > >> I do not think referencing the classification design document has any >> value any more it is no longer a maintained document, however I >> do recall as Bill says that we decided it was the applications >> responsibility be unambiguous. >> > > I agree it should be application responsibility. Implementation may assist > here and throw an error in case it detects an ambiguous combination. >
On 04/20/2015 02:04 PM, Taras Kondratiuk wrote: > On 04/17/2015 11:55 PM, Rosenboim, Leonid wrote: >> >> Guys, >> >> There are several versions of the Classifier API document floating in Google docs, here is one such copy: >> >> https://docs.google.com/document/d/14KMqNPIgd7InwGzdP2EaI9g_V3o0_wxpgp3N-nd-RBE/edit?usp=sharing >> >> Here is a different perspective on what PMR and COS mean, perhaps in terms of an abstract hardware implementation: >> >> CoS is a meta-data field assigned to each packet as it traverses the classifier pipe-line. >> >> A packet is assigned an initial CoS by the pktio port which received it. >> >> Then, the packet is compared multiple times against a set of rules, and as it is common with TCAMs, each comparisons happens against all rules in parallel. >> >> Each rule has two values to match: 1. the current CoS meta-data field; and 2. a certain packet header field (value with a mask). >> If both these values match, the packet met-data CoS field is changed (Action taken) with the destination CoS of the matching rule. >> >> It is assumed that up to one such rule has matched. >> >> If a rule has matched, CoS has changed, the process continues one more time. >> >> If NO MATCH occured, the classification process is finished, and the packet is delivered in accordance to the current CoS (i.e. the last matching rule or the pktio default CoS if the first rule match failed). >> >> According to CoS, the packet buffer pool and the destination queue are selected, and the packet is ready for application processing. >> >> Here are some additional observations with regads to use of CoS values: >> >> Multiple pktio may assign the same CoS initially. (eaming many pktio to one CoS) >> >> Multple rules can assign the same CoS as destination (action). (meaning multuple PMR to one destination CoS). >> >> Regarding the source CoS of a PMR, I can not rule out a PMR that can match multiple CoS values (that is creating a many-to-many src-CoS to PMR relationship), but this scheme seems problematic for ease of use as well as implementation, so I would recommend to assume that each PMR should only have a single source CoS. >> >> Multiple PMRs may have the same source-CoS, but different header fields ot value/mask (creating an OR combination of PMRs). >> >> I felt that I had to take this discussion ina completely different direction to avoid infinite recursion ;-) > > Thanks, Leo. > This exactly matches my understanding. > > Could you please add Reviewed-by tag if you are ok with the patch? > Hi guys, Is there any additional comments/objections on this patch?
On 04/22/2015 04:39 PM, Radu-Andrei Bulie wrote: > Hi, > > One question. The operation of linking a pmr to a port is performed by pmr creation function > by providing as src_cos the default port cos? Right.
diff --git a/include/odp/api/classification.h b/include/odp/api/classification.h index 7db3645..ef7d81e 100644 --- a/include/odp/api/classification.h +++ b/include/odp/api/classification.h @@ -232,6 +232,9 @@ typedef enum odp_pmr_term { * @param[in] val_sz Size of the val and mask arguments, * that must match the value size requirement of the * specific term. + * @param[in] src_cos CoS to be filtered + * @param[in] dst_cos CoS to be assigned to packets filtered from src_cos + * that match this rule. * * @return Handle of the matching rule * @retval ODP_PMR_INVAL on failure @@ -239,7 +242,9 @@ typedef enum odp_pmr_term { odp_pmr_t odp_pmr_create_match(odp_pmr_term_e term, const void *val, const void *mask, - uint32_t val_sz); + uint32_t val_sz, + odp_cos_t src_cos, + odp_cos_t dst_cos); /** * Create a packet match rule with value range @@ -250,6 +255,9 @@ odp_pmr_t odp_pmr_create_match(odp_pmr_term_e term, * @param[in] val_sz Size of the val1 and val2 arguments, * that must match the value size requirement of the * specific term. + * @param[in] src_cos CoS to be filtered + * @param[in] dst_cos CoS to be assigned to packets filtered from src_cos + * that match this rule. * * @return Handle of the matching rule * @retval ODP_PMR_INVAL on failure @@ -258,7 +266,10 @@ odp_pmr_t odp_pmr_create_match(odp_pmr_term_e term, odp_pmr_t odp_pmr_create_range(odp_pmr_term_e term, const void *val1, const void *val2, - uint32_t val_sz); + uint32_t val_sz, + odp_cos_t src_cos, + odp_cos_t dst_cos); + /** * Invalidate a packet match rule and vacate its resources * @@ -270,32 +281,6 @@ odp_pmr_t odp_pmr_create_range(odp_pmr_term_e term, int odp_pmr_destroy(odp_pmr_t pmr_id); /** - * Apply a PMR to a pktio to assign a CoS. - * - * @param[in] pmr_id PMR to be activated - * @param[in] src_pktio pktio to which this PMR is to be applied - * @param[in] dst_cos CoS to be assigned by this PMR - * - * @retval 0 on success - * @retval <0 on failure - */ -int odp_pktio_pmr_cos(odp_pmr_t pmr_id, - odp_pktio_t src_pktio, odp_cos_t dst_cos); - -/** - * Cascade a PMR to refine packets from one CoS to another. - * - * @param[in] pmr_id PMR to be activated - * @param[in] src_cos CoS to be filtered - * @param[in] dst_cos CoS to be assigned to packets filtered - * from src_cos that match pmr_id. - * - * @retval 0 on success - * @retval <0 on failure - */ -int odp_cos_pmr_cos(odp_pmr_t pmr_id, odp_cos_t src_cos, odp_cos_t dst_cos); - -/** * Inquire about matching terms supported by the classifier * * @return A mask one bit per enumerated term, one for each of op_pmr_term_e @@ -356,6 +341,9 @@ typedef struct odp_pmr_match_t { * @param[in] num_terms Number of terms in the match rule. * @param[in] terms Array of num_terms entries, one entry per * term desired. + * @param[in] src_cos CoS to be filtered + * @param[in] dst_cos CoS to be assigned to packets filtered from + * src_cos that match all terms. * @param[out] pmr_set_id Returned handle to the composite rule set. * * @return the number of terms elements @@ -364,6 +352,7 @@ typedef struct odp_pmr_match_t { * @retval <0 on failure */ int odp_pmr_match_set_create(int num_terms, odp_pmr_match_t *terms, + odp_cos_t src_cos, odp_cos_t dst_cos, odp_pmr_set_t *pmr_set_id); /** @@ -385,20 +374,6 @@ int odp_pmr_match_set_create(int num_terms, odp_pmr_match_t *terms, int odp_pmr_match_set_destroy(odp_pmr_set_t pmr_set_id); /** - * Apply a PMR Match Set to a pktio to assign a CoS. - * - * @param[in] pmr_set_id PMR match set to be activated - * @param[in] src_pktio pktio to which this PMR match - * set is to be applied - * @param[in] dst_cos CoS to be assigned by this PMR match set - * - * @retval 0 on success - * @retval <0 on failure - */ -int odp_pktio_pmr_match_set_cos(odp_pmr_set_t pmr_set_id, odp_pktio_t src_pktio, - odp_cos_t dst_cos); - -/** * Get printable value for an odp_cos_t * * @param hdl odp_cos_t handle to be printed
Current odp_pmr_t usage model has several issues: 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. 2. Initial intention behind odp_pmr_t was to abstract a handle to some HW resource which imlements a PMR. But on platforms I'm aware of a separate HW resource should be allocated for each PRM application. So there is no 1:1 mapping between odp_pmr_t and HW resource. If odp_pmr_t doesn't map to HW resource directly, then it just represent a PRM description. It is an entry in some PRM descriptions 'database' which implementation have to maintain for no good reason. There are two possible solutions: 1. Create odp_pmr_t handle as a result of a rule application/connection. 2. Connect rule on odp_pmr_t creation (suggested by Leonid Rosenboim). I prefer a second solution because it is more compact and straight forward. Additional consequence of this solution: instead of connecting PMR to PktIO it is connected to PktIO's default CoS. Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> --- include/odp/api/classification.h | 59 ++++++++++++---------------------------- 1 file changed, 17 insertions(+), 42 deletions(-)