On 31 March 2015 at 16:56, Savolainen, Petri (Nokia - FI/Espoo) <
[email protected]> wrote:
> 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
>
Or with template code that uses the classification API.
- easy start for the user and for the implementer
>
Easy end as well.
> - lack of dynamic configuration minimizes need for SW emulation => most
> NICs could be utilized as is
>
If the NIC supports the classification rules actually being used (e.g. some
simple IP five-tuple hashing), it should be possible to offload the
classification to the NIC. This is an implementation issue.
- implementation decides number of queues
>
So define a symbolic constant that gives the implementation the
responsibility to decide the number of queues.
- all queues are same type, priority, sync and group
>
Simple to achieve if the implementation is responsible for creating the
queues that the packets are distributed to.
> - hashing/number of queues can be changed only when interface is not
> active (after open or stop)
>
Whether classification rules can be changed while the system is running is
an interesting question. Some SoC's support it, others may not. With
classification and spreading defined in the pktio API as well, we will have
to worry about the problem in two places.
I think you are only creating the opportunity for ODP implementers to go
for a simplified implementation and not bother about proper classification
support. You are lowering the bar and the end result may be that there will
be no reason to support the full feature set (as defined by the ODP
classification API) because that will not be universally supported and
applications that depend on proper classification and distribution will not
be portable.
> - spreading and classification have different targets
>
Spreading and distribution are just orthogonal functions.
First you classify to select suitable packets (e.g. all IPv4 with TCP and
UDP payloads). Then you (deterministically) spread (distribute) the packets
onto a set of queues. Your simplified spreading proposal still requires
classification (you can only perform your five-tuple hash on IP packets so
non-IP packets or IP packets with other L4 protocols will have to be
filtered away), it is just that the classification rules will be implicit.
What happens when those implicit classification rules are not enough? E.g.
combine five-tuple hash-based spreading with different VLAN ids? Do you add
another "simplified" pktio spreading configuration?
It's like defining a CPU that can only run specific programs. When you need
to run another program, you need to ask your vendor to update your CPU (or
provide another one) which supports one more program.
- 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.
>
I don't understand this. Do you mean that the current ODP classification
infrastructure is overkill for some simple spreading scenarios?
Does any SoC vendor (except Intel) think this proposal is a great idea?
> -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
