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
