On 31 March 2015 at 14:49, Alexandru Badicioiu < [email protected]> wrote:
> There are some issues queue groups in the classification API : > Then I think we should clean up those issues in that API. Not invent similar (queue distribution) support in a different API. > Distribution is too restrictive (based on ranges) and it may not be widely > supported. > Exactly to what level the classification API is supported is implementation specific. But perhaps some things are too specific and will not be widely supported. We need feedback from the SoC vendors. I can imagine that when a packet has been successfully matched, the CoS could specify a contiguous set of bits (i.e. a bit field) in the packet which is used for distributing matching packets to a range of queues. I know we discussed this but currently it is only possible to assign *one* queue to a CoS. Lots of things didn't make it to the 1.0 API. "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." > Where is this text from? I can't find it in the header files. Is it from the original classification design document? > > 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
