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


Reply via email to