On Wednesday 17 December 2014 07:51 PM, Ola Liljedahl wrote:
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.
The application can configure the flow signature calculation either per
port or per CoS.
The flow signature per port is a mandatory param and per CoS is an
optional param.
The following are the fields which can be used to configure the flow
signature calculation by the application
*
ODP_COS_FHDR_IN_PKTIO,/**< Ingress port number */
ODP_COS_FHDR_L2_SAP,/**< Ethernet Source MAC address */
ODP_COS_FHDR_L2_DAP,/**< Ethernet Destination MAC address */
ODP_COS_FHDR_L2_VID,/**< Ethernet VLAN ID */
ODP_COS_FHDR_L3_FLOW/**< IPv6 flow_id */
ODP_COS_FHDR_L3_SAP,/**< IP source address */
ODP_COS_FHDR_L3_DAP,/**< IP destination address */
ODP_COS_FHDR_L4_PROTO,/**< IP protocol (e.g. TCP/UDP/ICMP) */
ODP_COS_FHDR_L4_SAP,/**< Transport source port */
ODP_COS_FHDR_L4_DAP,/**< Transport destination port */
ODP_COS_FHDR_IPSEC_SPI,/**< IPsec session identifier */
ODP_COS_FHDR_LD_VNI,/**< NVGRE/VXLAN network identifier */
ODP_COS_FHDR_USER/**< Application-specific header field(s) */*
When a packet gets associated to a specific CoS based on the PMR the
packet gets allocated
from the pool and delivered to the queue which are configured with the
associated CoS.
If the implementation allows flow signature calculation per CoS then the
flow signature for the packet is calculated after it
get allocated to the CoS else the flow signature is calculated based on
the value configured with the ingress port (odp_pktio_t)
The flow signature calculation APIs are not part of ODP 1.0 and have
been deferred after 1.0.
The association of a CoS with a queue group and how the packets are
distributed within a queue group is still not
yet finalised in the current design and has to be decided after 1.0.
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
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
