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.fischo...@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.manoha...@linaro.org > > wrote: > >> 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 >> > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
