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
