There are some issues queue groups in the classification API : Distribution is too restrictive (based on ranges) and it may not be widely supported. "This means that when the classifier matches an inbound packet to the specified CoS, the packet will be distributed among the queues of the specified queue group based on the index value of the PMR range. If the range value runs [startval..endval] for a field then a packet assigned to this CoS that has a field value of val in this range will be enqueued to queue val-startval of the queue group."
Packet field value matching has to be performed before doing the distribution. Using only packet field type in the distribution spec does not involve any matching (only information the provided by parser - field present/not present). Alex On 31 March 2015 at 14:48, Ola Liljedahl <[email protected]> wrote: > On 31 March 2015 at 13:39, Alexandru Badicioiu < > [email protected]> wrote: > >> In my understanding of the terms, distribution computes the queue id from >> the various packet fields/bytes (and maybe other data like port id) usually >> with a hashing function. Classification uses table lookup to find the queue >> id associated with a given key.Classification tables can be cascaded while >> distributions cannot. Distribution is used typically for spreading the load >> to a group of cores while classification deals with separating logical >> flows with different processing requirements (e.g. different IPsec SA, >> VLANs, etc). >> > It is not a question which terms to use or what they mean. > I claim that this distribution functionality is already supported in the > classification API (where you can specify a range of queues as the > destination, not only one queue). So do we need to add a similar feature to > the pktio API? > > I think the abstraction level is too low if we think we need to add such a > feature to different API's. How different ODP implementations implement > this feature is a different thing. Maybe some ODP implementation only > supports five-tuple hashing in the NIC (which corresponds to the pktio) but > this should still be possible to control using the classification API. The > idea is that ODP abstracts the underlying HW, not exposes it. > > Perhaps we should rename it to classification and distribution API if this > eases the confusion? > >> >> Alex >> >> On 31 March 2015 at 14:15, Ola Liljedahl <[email protected]> >> wrote: >> >>> On 31 March 2015 at 10:56, Savolainen, Petri (Nokia - FI/Espoo) < >>> [email protected]> wrote: >>> >>>> Hi Alex, >>>> >>>> >>>> >>>> Could you explain a bit more what you mean with extracts here. >>>> Detailed classification (packet field + mask/range => queue / set of >>>> queues) would be still handled with classification API. This API would >>>> offer an easy way to spread typical flows (e.g. 5-tuple) into multiple >>>> queues (same queue type, priority, sync, group). >>>> >>> Yes I was thinking that hash-based distribution is already supported (or >>> at least the rudiments are in place to support it) by the classification >>> API. >>> Isn't this pktio support redundant? Why have it in both places? >>> >>> -- Ola >>> >>> >>> >>>> >>>> >>>> -Petri >>>> >>>> >>>> >>>> >>>> >>>> *From:* ext Alexandru Badicioiu [mailto:[email protected]] >>>> >>>> *Sent:* Tuesday, March 31, 2015 11:37 AM >>>> *To:* Savolainen, Petri (Nokia - FI/Espoo) >>>> *Cc:* LNG ODP Mailman List >>>> *Subject:* Re: [lng-odp] [RFC 5/8] api: packet_io: added packet input >>>> queue API definitions >>>> >>>> >>>> >>>> Hi Petri, >>>> >>>> I think it would be useful (for hardware which supports) to be able to >>>> specify generic packet extracts in addition to protocol related fields. >>>> While hash works well for uniform distribution, having generic extracts >>>> from the packet helps in directly selecting the input queue. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Alex >>>> >>>> _______________________________________________ >>>> lng-odp mailing list >>>> [email protected] >>>> https://lists.linaro.org/mailman/listinfo/lng-odp >>>> >>>> >>> >> >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
