On 21 April 2015 at 18:15, Ola Liljedahl <ola.liljed...@linaro.org> wrote: > On 21 April 2015 at 14:26, Maxim Uvarov <maxim.uva...@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.liljed...@linaro.org >>> <mailto:ola.liljed...@linaro.org>> wrote: >>> >>> On 20 April 2015 at 21:49, Bill Fischofer >>> <bill.fischo...@linaro.org <mailto: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 <mailto:ola.liljed...@linaro.org>> >>> wrote: >>> >>> On 17 April 2015 at 22:55, Rosenboim, Leonid >>> <leonid.rosenb...@caviumnetworks.com >>> <mailto: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 >>> <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
