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

Reply via email to