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? 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
