Taras, I have seen similar limitations on other platforms, and in my opinion, the solution could be to simply decouple the odp_queue_t identifier from the HW queue number, and have each odp_queue_t identify a table entry, which contains a HW queue number, which can be changed by the implementation without application knowledge when it is necessary.
From another point of view, the odp_queue_t when initially created will not be associated with a real HW queue, until it is assigned to a CoS, at which point it is assigned with the hardware resources needed to pass traffic. An odp_queue_t that of the PKTIN type will not be able to pass traffic until it is assigned a CoS source anyway. Hope this helps, - Leo ________________________________________ From: Taras Kondratiuk <[email protected]> Sent: Thursday, April 2, 2015 8:29 AM To: Rosenboim, Leonid; Bala Manoharan; Petri Savolainen; Robbie King (robking) Cc: [email protected] Subject: Classification API implementation issue Hi I'm having an issue with implementation of some Classification API functions on Keystone2 platform: odp_cos_with_l2_priority() odp_cos_with_l3_qos() Keystone SDK has very similar functionality, but destination HW queue numbers are specified as base queue + offsets. Max offset is 128 while total number of queues is 16k. It is not possible to represent an arbitrary set of queues (passed to odp_cos_with_l*() inside of CoS) in form of base + offset. I couldn't find a way to workaround this limitation at implementation level, so API change may be needed. The least intrusive change is to allow implementation to create queues and assign them to CoS'es passed to odp_cos_with_l*() functions. So application should pass 'empty' CoS'es. odp_cos_queue() function will be needed to read created queue handles from CoS. Do you see possible issues with this approach? _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
