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] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Weekly ODP Design Discussion Call >>>>>> December 16, 7:58AM - 9:07AM MST >>>>>> 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 >>>>>> Stuart Haslam >>>>>> 7:58AM - 9:07AM >>>>>> 1 min >>>>>> Bill Fischofer >>>>>> 7:58AM - 9:05AM >>>>>> 15 min >>>>>> Arm Inc >>>>>> 8:00AM - 9:05AM >>>>>> 1 min >>>>>> Barry Spinney >>>>>> 8:01AM - 9:05AM >>>>>> >>>>>> 8 min >>>>>> <https://plus.google.com/104842017912892599536> >>>>>> Mike Holmes >>>>>> 8:01AM - 9:07AM >>>>>> 2 min >>>>>> <https://plus.google.com/117524006040986883990> >>>>>> Leonard Bush >>>>>> 8:01AM - 9:05AM >>>>>> >>>>>> 0 min >>>>>> Taras Kondratiuk >>>>>> 8:01AM - 9:05AM >>>>>> 1 min >>>>>> <https://plus.google.com/107577698119732590769> >>>>>> Ola Liljedahl >>>>>> 8:02AM - 9:05AM >>>>>> 2 min >>>>>> Cisco Systems >>>>>> 8:02AM - 9:05AM >>>>>> >>>>>> 8 min >>>>>> Jerin Jacob >>>>>> 8:02AM - 9:05AM >>>>>> 1 min >>>>>> <http://www.linkedin.com/in/jerinjacob> >>>>>> <https://plus.google.com/112192941551127946856> >>>>>> Anders Roxell >>>>>> 8:02AM - 8:59AM >>>>>> 0 min >>>>>> <https://plus.google.com/104412829600273375417> >>>>>> Maxim Uvarov >>>>>> 8:02AM - 9:05AM >>>>>> 0 min >>>>>> <https://plus.google.com/107909139112066426665> >>>>>> Ciprian Barbu >>>>>> 8:03AM - 8:32AM >>>>>> >>>>>> 8 min >>>>>> <https://plus.google.com/116074040956370734345> >>>>>> Marshall Guillory >>>>>> 8:03AM - 9:05AM >>>>>> 0 min >>>>>> <http://www.linkedin.com/in/marshallguillory> >>>>>> <https://plus.google.com/111357621776735070930> >>>>>> Kari Sundback >>>>>> 8:03AM - 9:05AM >>>>>> >>>>>> 7 min >>>>>> Bala Manoharan >>>>>> 8:03AM - 8:19AM >>>>>> 0 min >>>>>> <https://plus.google.com/101798775278741634979> >>>>>> Kamensky Victor >>>>>> 8:05AM - 9:05AM >>>>>> >>>>>> 0 min >>>>>> Gilad Ben-Yossef >>>>>> 8:07AM - 9:04AM >>>>>> +972 4-959-6666 >>>>>> 0 min >>>>>> <http://www.linkedin.com/in/giladby> >>>>>> Job >>>>>> 8:08AM - 8:09AM >>>>>> 0 min >>>>>> Raj Murali >>>>>> 8:09AM - 9:05AM >>>>>> 0 min >>>>>> <https://plus.google.com/101661069368932371920> >>>>>> Job >>>>>> 8:10AM - 8:12AM >>>>>> 0 min >>>>>> Job >>>>>> 8:13AM - 9:05AM >>>>>> 0 min >>>>>> Bala Manoharan >>>>>> 8:20AM - 9:05AM >>>>>> 2 min >>>>>> <https://plus.google.com/101798775278741634979> >>>>>> 702-913-1399 >>>>>> 8:28AM - 8:29AM >>>>>> >>>>>> 0 min >>>>>> Ciprian Barbu >>>>>> 8:30AM - 9:05AM >>>>>> >>>>>> 0 min >>>>>> <https://plus.google.com/116074040956370734345> >>>>>> 40213052000 >>>>>> 8:32AM - 9:05AM >>>>>> >>>>>> 3 min >>>>>> Tip: Social profile Get to know your conference >>>>>> participants by clicking on their 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
