On 6 April 2018 at 20:56, Bill Fischofer <bill.fischo...@linaro.org> wrote:
> 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. Regards, Bala > > 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 certain > > 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 provide > > synchronization for millions of different flows > > 3) There arises a need to create a lightweight queue (flow) which can be > > configured by the application without any need to rely on the underlying > 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 into > > 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 to > 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 flow > > within each queue > > > > Regards, > > Bala >
