Hi, Since we have the concept of a default CoS in classification, why cant we associate the above APIs to default CoS, in that way we can avoid linking this hash function directly to pktio.
coz there comes a discrepancy now as to what happens when both this API and classification are configured at the same time. Regards, Bala On 31 March 2015 at 18:57, Alexandru Badicioiu <[email protected]> wrote: > > > On 31 March 2015 at 16:09, Ola Liljedahl <[email protected]> wrote: >> >> 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? > > Queue & scheduler API - > https://docs.google.com/a/linaro.org/document/d/1h0g7OEQst_PlOauNIHKmIyqK9Bofiv9L-bn9slRaBZ8/edit# >> >> >>> >>> >>> 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 > _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
