The logic here is:
- packet input is useless without a way to distribute incoming packet into
multiple queues (now we have one default input queue)
- it's desirable that ODP APIs can be used "a la carte", for example:
- packet input -> crypto -> packet output, OR
- packet input + classification -> schedule -> crypto -> schedule -> output
shaping/scheduling + packet output
- minimum/most common packet input spreading (RSS style) could be defined as
fixed function
- easy start for the user and for the implementer
- lack of dynamic configuration minimizes need for SW emulation => most NICs
could be utilized as is
- implementation decides number of queues
- all queues are same type, priority, sync and group
- hashing/number of queues can be changed only when interface is not active
(after open or stop)
- spreading and classification have different targets
- spreading
- increase parallelism (throughput)
- number of input queues (or flows) is not important (used only for scaling)
- application SW runs the classification/parsing itself (e.g. port 3rd
party SW like OVS on top of ODP)
- classification
- fine grained flow/priority selection offloaded to HW (ODP)
- number of input queues (or flows) is important (e.g. a queue per flow, or
flow A -> queue A)
- native ODP application (utilizes ODP to the max)
- we can define that input queue hashing cannot co-exist with classification
- use / don't use classification as pktio parameter
Simple spreading (set of predefined tuples) could be defined under
classification API, but wouldn't it waste a lot of the classification
infrastructure.
-Petri
> -----Original Message-----
> From: ext Bala Manoharan [mailto:[email protected]]
> Sent: Tuesday, March 31, 2015 4:36 PM
> To: Alexandru Badicioiu
> Cc: Ola Liljedahl; Savolainen, Petri (Nokia - FI/Espoo); LNG ODP Mailman
> List
> Subject: Re: [lng-odp] [RFC 5/8] api: packet_io: added packet input queue
> API definitions
>
> 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_PlOauNIHKmIyqK9
> Bofiv9L-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
