On 31 March 2015 at 20:15, Bill Fischofer <[email protected]> wrote:
> I think we should work within the classification framework we've already > defined. Since NIC-based systems will most typically do RSS > classification, we should extend the ODP classification API to encompass > RSS semantics by surfacing Toeplitz hashing (as well as other types of > hashes that are in use by member platforms) and also support the notion of > implementation-predefined classification rules. The range of > classification rules supportable by implementations will vary, and this > will translate into the performance that a given application may see on a > given platform for a given workload, but that's just normal variability. > The point is that some part of the classification will be offloaded to HW > (either the SoC itself or a NIC) with the remaining being filled in in SW > by the ODP implementation so that the application sees the same functional > semantics across all ODP implementations. > We could define ODP classification (helper) functions that create complex PMR's that directly describe common RSS-style classification & distribution patterns. > On Tue, Mar 31, 2015 at 10:26 AM, Ola Liljedahl <[email protected]> > wrote: > >> 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 >> >> >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
