The first requirement is that packets of the same *flow* produce the same hash value. As long as same packet header fields are used for hash calculation this will be the case. 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).
-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]<mailto:[email protected]>> wrote: On 17 December 2014 at 11:21, Alexandru Badicioiu <[email protected]<mailto:[email protected]>> wrote: On 17 December 2014 at 12:16, Ola Liljedahl <[email protected]<mailto:[email protected]>> wrote: On 17 December 2014 at 09:14, Alexandru Badicioiu <[email protected]<mailto:[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]<mailto:[email protected]>> wrote: On 16 December 2014 at 17:54, Bill Fischofer <[email protected]<mailto:[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]<mailto:[email protected]>> Date: Tue, Dec 16, 2014 at 10:09 AM Subject: Weekly ODP Design Discussion Call - Call Summary To: [email protected]<mailto:[email protected]> [Image removed by sender.] [Image removed by sender.] Weekly ODP Design Discussion Call December 16, 7:58AM - 9:07AM MST [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 removed by sender.] Stuart Haslam [Image removed by sender.]7:58AM - 9:07AM [Image removed by sender.]1 min [Image removed by sender.] Bill Fischofer [Image removed by sender.]7:58AM - 9:05AM [Image removed by sender.]15 min [Image removed by sender.] Arm Inc [Image removed by sender.]8:00AM - 9:05AM [Image removed by sender.] [Image removed by sender.]1 min [Image removed by sender.] Barry Spinney [Image removed by sender.]8:01AM - 9:05AM [Image removed by sender.] [Image removed by sender.]8 min [Image removed by sender.]<https://plus.google.com/104842017912892599536> [Image removed by sender.] Mike Holmes [Image removed by sender.]8:01AM - 9:07AM [Image removed by sender.]2 min [Image removed by sender.]<https://plus.google.com/117524006040986883990> [Image removed by sender.] Leonard Bush [Image removed by sender.]8:01AM - 9:05AM [Image removed by sender.] [Image removed by sender.]0 min [Image removed by sender.] Taras Kondratiuk [Image removed by sender.]8:01AM - 9:05AM [Image removed by sender.]1 min [Image removed by sender.]<https://plus.google.com/107577698119732590769> [Image removed by sender.] Ola Liljedahl [Image removed by sender.]8:02AM - 9:05AM [Image removed by sender.]2 min [Image removed by sender.] Cisco Systems [Image removed by sender.]8:02AM - 9:05AM [Image removed by sender.] [Image removed by sender.]8 min [Image removed by sender.] Jerin Jacob [Image removed by sender.]8:02AM - 9:05AM [Image removed by sender.]1 min [Image removed by sender.]<http://www.linkedin.com/in/jerinjacob>[Image removed by sender.]<https://plus.google.com/112192941551127946856> [Image removed by sender.] Anders Roxell [Image removed by sender.]8:02AM - 8:59AM [Image removed by sender.]0 min [Image removed by sender.]<https://plus.google.com/104412829600273375417> [Image removed by sender.] Maxim Uvarov [Image removed by sender.]8:02AM - 9:05AM [Image removed by sender.]0 min [Image removed by sender.]<https://plus.google.com/107909139112066426665> [Image removed by sender.] Ciprian Barbu [Image removed by sender.]8:03AM - 8:32AM [Image removed by sender.] [Image removed by sender.]8 min [Image removed by sender.]<https://plus.google.com/116074040956370734345> [Image removed by sender.] Marshall Guillory [Image removed by sender.]8:03AM - 9:05AM [Image removed by sender.]0 min [Image removed by sender.]<http://www.linkedin.com/in/marshallguillory>[Image removed by sender.]<https://plus.google.com/111357621776735070930> [Image removed by sender.] Kari Sundback [Image removed by sender.]8:03AM - 9:05AM [Image removed by sender.] [Image removed by sender.]7 min [Image removed by sender.] Bala Manoharan [Image removed by sender.]8:03AM - 8:19AM [Image removed by sender.]0 min [Image removed by sender.]<https://plus.google.com/101798775278741634979> [Image removed by sender.] Kamensky Victor [Image removed by sender.]8:05AM - 9:05AM [Image removed by sender.] [Image removed by sender.]0 min [Image removed by sender.] Gilad Ben-Yossef [Image removed by sender.]8:07AM - 9:04AM +972 4-959-6666<tel:%2B972%204-959-6666> [Image removed by sender.]0 min [Image removed by sender.]<http://www.linkedin.com/in/giladby> [Image removed by sender.] Job [Image removed by sender.]8:08AM - 8:09AM [Image removed by sender.]0 min [Image removed by sender.] Raj Murali [Image removed by sender.]8:09AM - 9:05AM [Image removed by sender.]0 min [Image removed by sender.]<https://plus.google.com/101661069368932371920> [Image removed by sender.] Job [Image removed by sender.]8:10AM - 8:12AM [Image removed by sender.]0 min [Image removed by sender.] Job [Image removed by sender.]8:13AM - 9:05AM [Image removed by sender.]0 min [Image removed by sender.] Bala Manoharan [Image removed by sender.]8:20AM - 9:05AM [Image removed by sender.]2 min [Image removed by sender.]<https://plus.google.com/101798775278741634979> [Image removed by sender.] 702-913-1399<tel:702-913-1399> [Image removed by sender.]8:28AM - 8:29AM [Image removed by sender.] [Image removed by sender.]0 min [Image removed by sender.] Ciprian Barbu [Image removed by sender.]8:30AM - 9:05AM [Image removed by sender.] [Image removed by sender.]0 min [Image removed by sender.]<https://plus.google.com/116074040956370734345> [Image removed by sender.] 40213052000 [Image removed by sender.]8:32AM - 9:05AM [Image removed by sender.] [Image removed by sender.]3 min Tip: Social profile [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]<mailto:[email protected]> http://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list [email protected]<mailto:[email protected]> http://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
