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.liljed...@linaro.org> wrote: > On 20 April 2015 at 21:49, Bill Fischofer <bill.fischo...@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.liljed...@linaro.org> >> wrote: >> >>> On 17 April 2015 at 22:55, Rosenboim, Leonid < >>> leonid.rosenb...@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 >>> >>> >> >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
