On 17 December 2014 at 12:09, Alexandru Badicioiu < [email protected]> wrote: > > > > 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". > We need the person who stated this requirement to explain it.
> Port id is used for example by policy routing (see Linux command ip rule > syntax). > Good with a real-life example of this. Doesn't the ODP classification API allow the input port to be part of the classification rules? I have some weak memory of this but then bits and pieces have been dropped from this API. > >> >>> >>>> >>>> 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
