On 17 December 2014 at 13:31, Savolainen, Petri (NSN - FI/Espoo) < [email protected]> wrote: > > The first requirement is that packets of the same **flow** produce the > same hash value. > But the hardware (ODP implementation) won't know what constitutes a flow unless we tell it.
> As long as same packet header fields are used for hash calculation this > will be the case. > Not if the ODP implementation includes header fields in the hash calculation which are not part of the application's definition of a flow. I don't think this behavior can be accepted. > The second requirement is how the user can control which fields are taken > into the hash calculation. This capability is HW dependent and thus harder > to abstract (and is potentially linked to classification terms). > The application should define the flow signature, this specifies which packet fields are used to uniquely identify a flow. The ODP implementation may use a hash of the flow signature in order to simplify its implementation. The flow hash need not to include all fields of the flow signature, this will potentially lead to more frequent collisions and less ideal distribution of packets onto queues. Since we accept that the ODP implementation uses some kind of flow hash and that packets from different flows (i.e. using different flow signatures) may (and will) end up on the same queue, it is the responsibility of the application to make the final unique decision of which flow a packet belongs to. > > > > -Petri > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *ext Alexandru Badicioiu > *Sent:* Wednesday, December 17, 2014 1:09 PM > *To:* Ola Liljedahl > *Cc:* lng-odp-forward > *Subject:* Re: [lng-odp] Fwd: Weekly ODP Design Discussion Call - Call > Summary > > > > > > > > On 17 December 2014 at 12:39, Ola Liljedahl <[email protected]> > wrote: > > On 17 December 2014 at 11:21, Alexandru Badicioiu < > [email protected]> wrote: > > > > > > On 17 December 2014 at 12:16, Ola Liljedahl <[email protected]> > wrote: > > On 17 December 2014 at 09:14, Alexandru Badicioiu < > [email protected]> wrote: > > Could you please clarify the following : > > "Implementations are free to define flow signatures however they wish. > The only API requirement is that the same packet produce the same > signature." > > Using the previously agreed terminology, this should read "Implementations > are free to define flow hashes however they wish". This is what Petri meant > by saying some platforms may use "weak" hashes (don't remember his exact > words). > > > > > > Is the requirement that for a given packet, the flow signature is the > same for any platform conforming to ODP specs? > > The flow hash for a given packet can differ between different ODP > implementations. If we require the same flow hash value to be computed, we > would have to define how to compute it. And we are not. > > [Alex] The same packet on the same platform is very likely to produce the > same flow signature. It may produce different flow signature if there's > other data involved in flow signature computation (e.g. input port id). > This is why I wanted to double check. > > Now we are on to something (else). > > Who defines the flow *signature*? The application by configuring the > classifier. > > Should the input port be part of the flow signature? I don't have a > general answer for this. I guess it depends. In some situations, the > application might not care on which input port a packet is received, > packets should be processed in the same way regardless of input port. In > this case, input port is not part of the flow signature and should not be > part of the flow hash calculation. > > Could there be other situations where the input port should make a > difference? We need someone with a wider experience of actual use cases > have an opinion here, maybe Petri or Robbie. > > [Alex] If the application only defines the flow signature and the input is > packet data only, then the immediate consequence is that same packet will > always produce the same signature (so how this can be a "requirement"?). I > wanted to understand the requirement that "the same packet will produce the > same signature". Port id is used for example by policy routing (see Linux > command ip rule syntax). > > > > > > > > Thanks, > > Alex > > > > > > > > > > On 16 December 2014 at 19:10, Ola Liljedahl <[email protected]> > wrote: > > On 16 December 2014 at 17:54, Bill Fischofer <[email protected]> > wrote: > > Thanks to all who participated in today's ODP call. As discussed there > will be a call next Tuesday, December 23rd, however there will be no call > on Tuesday, December 30th, due to the end of year holidays. Calls in 2015 > will resume on Tuesday, January 6th. > > > > Highlights from today's discussions: > > - ODP v0.5 tagged today. This is a major milestone on the road to ODP > v1.0. Thanks to all who contributed to it. > > > - ODP v0.6 targeted for next week (Monday) > > > - Discussed classification questions from Freescale. Implementations > are free to define flow signatures however they wish. The only API > requirement is that the same packet produce the same signature. > > We defined the related terminology back in June. Someone even > documented this, either in a Google doc or photographically. Below is what > I remember. > > > > flow signature != flow hash > > > > The application specifies the flow signature (e.g. when programming the > classifier). The flow signature consists of selected L2/L3/L4 (etc) fields > (a variable number of bits) as specified by the application and supported > by the implementation. The flow signature uniquely identifies a flow, i.e. > all packets with the same flow signature belong to the same flow and must > be put on the same queue (by the classifier). > > > > The implementation may use a flow hash for simplified processing. The flow > hash is computed from the flow signature and compresses it down to some > fixed suitable size, e.g. 32 bits. The flow hash does not uniquely identify > a flow but possibly the risk for collisions is low. It is the application's > responsibility to make sure packets with the same flow hash are processed > properly, e.g. mapped to the corresponding flow context (state associated > with the flow). > > > > I don't see any reason for not using these definitions of flow signature > and flow hash. > > > > > - Synchronizer test questions and discussion. Barry and Mario to > resolve outstanding packaging questions and post final patches this week. > > > - Crypto event RFC discussion. Robbie has posted v3 of his patch. > Review comments expected. > > > - Positioning for introduction of strong typing for ODP abstract > types. Implementations and applications should avoid use of C comparator > operators. Patch will be forthcoming with proposed handle comparison and > display APIs. > > Bill > > > > ---------- Forwarded message ---------- > From: *UberConference* <[email protected]> > Date: Tue, Dec 16, 2014 at 10:09 AM > Subject: Weekly ODP Design Discussion Call - Call Summary > To: [email protected] > > > > [image: Image removed by sender.] > > > > > > [image: Image removed by sender.] > > > > *Weekly ODP Design Discussion Call * > > December 16, 7:58AM - 9:07AM MST > > [image: Image removed by sender.]69 minutes > > *Shared Files * > > Chat Transcript > <http://www.uberconference.com/chatdownload/6105455928016896> > > Recording #1 > <http://www.uberconference.com/getmp3/AMIfv948IJu4HYs7M95-nS7jW_VzdecRIKVzu2WbTj0EXcnzfEG7RXU7xqxMkmNHsobs3hyQH_L1TTSupGXyZ9qhgkQK7CJyTAE7nJGtPHpLKTje5O6CcdAGSL8JYTmJ-H5SzaEO0FCwry-vAdHEG31BcH40Alfb0A.mp3> > > 44.9 MB > ------------------------------ > > *Participants* > > In order of appearance > > [image: Image removed by sender.] > > *Stuart Haslam * > > [image: Image removed by sender.]7:58AM - 9:07AM > > [image: Image removed by sender.]1 min > > [image: Image removed by sender.] > > *Bill Fischofer * > > [image: Image removed by sender.]7:58AM - 9:05AM > > [image: Image removed by sender.]15 min > > [image: Image removed by sender.] > > *Arm Inc * > > [image: Image removed by sender.]8:00AM - 9:05AM > > [image: Image removed by sender.] > > [image: Image removed by sender.]1 min > > [image: Image removed by sender.] > > *Barry Spinney * > > [image: Image removed by sender.]8:01AM - 9:05AM > > [image: Image removed by sender.] > > > > [image: Image removed by sender.]8 min > > [image: Image removed by sender.] > <https://plus.google.com/104842017912892599536> > > [image: Image removed by sender.] > > *Mike Holmes * > > [image: Image removed by sender.]8:01AM - 9:07AM > > [image: Image removed by sender.]2 min > > [image: Image removed by sender.] > <https://plus.google.com/117524006040986883990> > > [image: Image removed by sender.] > > *Leonard Bush * > > [image: Image removed by sender.]8:01AM - 9:05AM > > [image: Image removed by sender.] > > > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] > > *Taras Kondratiuk * > > [image: Image removed by sender.]8:01AM - 9:05AM > > [image: Image removed by sender.]1 min > > [image: Image removed by sender.] > <https://plus.google.com/107577698119732590769> > > [image: Image removed by sender.] > > *Ola Liljedahl * > > [image: Image removed by sender.]8:02AM - 9:05AM > > [image: Image removed by sender.]2 min > > [image: Image removed by sender.] > > *Cisco Systems * > > [image: Image removed by sender.]8:02AM - 9:05AM > > [image: Image removed by sender.] > > > > [image: Image removed by sender.]8 min > > [image: Image removed by sender.] > > *Jerin Jacob * > > [image: Image removed by sender.]8:02AM - 9:05AM > > [image: Image removed by sender.]1 min > > [image: Image removed by sender.] > <http://www.linkedin.com/in/jerinjacob>[image: > Image removed by sender.] <https://plus.google.com/112192941551127946856> > > [image: Image removed by sender.] > > *Anders Roxell * > > [image: Image removed by sender.]8:02AM - 8:59AM > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] > <https://plus.google.com/104412829600273375417> > > [image: Image removed by sender.] > > *Maxim Uvarov * > > [image: Image removed by sender.]8:02AM - 9:05AM > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] > <https://plus.google.com/107909139112066426665> > > [image: Image removed by sender.] > > *Ciprian Barbu * > > [image: Image removed by sender.]8:03AM - 8:32AM > > [image: Image removed by sender.] > > > > [image: Image removed by sender.]8 min > > [image: Image removed by sender.] > <https://plus.google.com/116074040956370734345> > > [image: Image removed by sender.] > > *Marshall Guillory * > > [image: Image removed by sender.]8:03AM - 9:05AM > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] > <http://www.linkedin.com/in/marshallguillory>[image: Image removed by > sender.] <https://plus.google.com/111357621776735070930> > > [image: Image removed by sender.] > > *Kari Sundback * > > [image: Image removed by sender.]8:03AM - 9:05AM > > [image: Image removed by sender.] > > > > [image: Image removed by sender.]7 min > > [image: Image removed by sender.] > > *Bala Manoharan * > > [image: Image removed by sender.]8:03AM - 8:19AM > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] > <https://plus.google.com/101798775278741634979> > > [image: Image removed by sender.] > > *Kamensky Victor * > > [image: Image removed by sender.]8:05AM - 9:05AM > > [image: Image removed by sender.] > > > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] > > *Gilad Ben-Yossef * > > [image: Image removed by sender.]8:07AM - 9:04AM > > +972 4-959-6666 > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] <http://www.linkedin.com/in/giladby> > > [image: Image removed by sender.] > > *Job * > > [image: Image removed by sender.]8:08AM - 8:09AM > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] > > *Raj Murali * > > [image: Image removed by sender.]8:09AM - 9:05AM > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] > <https://plus.google.com/101661069368932371920> > > [image: Image removed by sender.] > > *Job * > > [image: Image removed by sender.]8:10AM - 8:12AM > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] > > *Job * > > [image: Image removed by sender.]8:13AM - 9:05AM > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] > > *Bala Manoharan * > > [image: Image removed by sender.]8:20AM - 9:05AM > > [image: Image removed by sender.]2 min > > [image: Image removed by sender.] > <https://plus.google.com/101798775278741634979> > > [image: Image removed by sender.] > > *702-913-1399 <702-913-1399> * > > [image: Image removed by sender.]8:28AM - 8:29AM > > [image: Image removed by sender.] > > > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] > > *Ciprian Barbu * > > [image: Image removed by sender.]8:30AM - 9:05AM > > [image: Image removed by sender.] > > > > [image: Image removed by sender.]0 min > > [image: Image removed by sender.] > <https://plus.google.com/116074040956370734345> > > [image: Image removed by sender.] > > *40213052000 * > > [image: Image removed by sender.]8:32AM - 9:05AM > > [image: Image removed by sender.] > > > > [image: Image removed by sender.]3 min > > *Tip: Social profile * > > [image: Image removed by sender.] > > Get to know your conference participants by clicking on their social > profiles. > > > <https://uberconference.zendesk.com/entries/22586117-Integrated-Social-Profiles> > > Learn More > <https://uberconference.zendesk.com/entries/22586117-Integrated-Social-Profiles> > > > > *UberConference * > > If you'd like to stop getting emails from UberConference, click here > <http://www.uberconference.com/unsubscribe/LLvfhTQDtLP9qpEQ3y3qFART3suxGq> > > > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp > > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
