In the case of DPI, I came across this.
Did you consider :
- a symetric hash option so that uplink and downlink packets of a single
flow (either TCP or UDP) give the same hash value?
- an offset so that HW calculates the hash starting at a specific packet
- an option that would calculate the hash starting at the most inner IP
header (passing as much as encapsulations possible such as GRE, VxLAN...)
- an option to include or not the VLAN in the hash
in addition to SPI, do you envision fields like GTP tunnelid?
On 6 April 2018 at 17:35, Bala Manoharan <bala.manoha...@linaro.org> wrote:
> On 6 April 2018 at 20:56, Bill Fischofer <bill.fischo...@linaro.org>
> > Thanks, Bala. I like this direction. One point to discuss is the idea
> > of flow hashes vs. flow ids or labels. A hash is an
> > implementation-defined value that is derived from some
> > application-specified set of fields (e.g., based on tuples). A flow id
> > or label is an application-chosen value that is used to "tag" related
> > packets based on some application-defined criteria.
> > Do we need to consider both?
> Yes Bill. This value proposed could be considered as either of these two.
> for eg the flow is usually generated for the incoming packet by the HW
> based on the tuple configured by the application.
> Once the application receives the incoming packet based on the HW generate
> flow he might switch the packet to a SW generated flow in the next phase
> which could be based on a hash generated from set of fields or a "tag" like
> SPI index.
> > On Fri, Apr 6, 2018 at 8:35 AM, Bala Manoharan
> > <bala.manoha...@linaro.org> wrote:
> > > Hi,
> > >
> > > Based on the requirements from our customers, we have come across
> > > limitations in the current scheduler design,
> > >
> > > 1) Creating a huge number of odp_queue_t is very expensive operation
> > since
> > > each queue contains a context and having millions of queues creates
> > memory
> > > constraints in the platform
> > > 2) ORDERED and ATOMIC synchronization is currently handled at the queue
> > > level which is not sufficient since there are platforms which can
> > > synchronization for millions of different flows
> > > 3) There arises a need to create a lightweight queue (flow) which can
> > > configured by the application without any need to rely on the
> > HW
> > > memory constraints
> > >
> > > The proposal to handle these limitations are as follows,
> > >
> > > 1) create a lightweight flow handling similar to the queue.
> > > 2) The flow will be a lightweight entity and the flow number can be
> > > configured by the application on the fly before enqueuing the packet
> > > the schedule operation.
> > > 3) We will be re-using the odp_packet_flow_hash() API, the idea is that
> > the
> > > application will configure the packet flow value before enqueuing the
> > > packet into the schedule operation and if the scheduler is configured
> > be
> > > flow aware then the synchronization will be done at the flow level
> > instead
> > > of queue level in the existing ODP design.
> > > 3) This will not change the current ODP design as this will be a
> > capability
> > > parameter and the current ODP design can be seen as having a single
> > > within each queue
> > >
> > > Regards,
> > > Bala
[image: Linaro] <http://www.linaro.org/>
François-Frédéric Ozog | *Director Linaro Networking Group*
francois.o...@linaro.org | Skype: ffozog