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

Reply via email to