We will discuss this during tomorrow's deep-dive covering remaining Monarch RC2 items. One further comment regarding the proposed implementation of this new API is that it should be using the ODP time APIs rather than nanosleep.
On Fri, Mar 4, 2016 at 9:09 AM, Savolainen, Petri (Nokia - FI/Espoo) < [email protected]> wrote: > > > From: EXT Bala Manoharan [mailto:[email protected]] > Sent: Friday, March 04, 2016 2:39 PM > To: Tilli, Juha-Matti (Nokia - FI/Espoo) <[email protected]> > Cc: Savolainen, Petri (Nokia - FI/Espoo) <[email protected]>; > LNG ODP Mailman List <[email protected]> > Subject: Re: [lng-odp] [API-NEXT PATCH 1/2] api: pktio: add recv from > multiple queues with tmo > > > On 4 March 2016 at 17:47, Tilli, Juha-Matti (Nokia - FI/Espoo) < > [email protected]> wrote: > Hi, > > The current algorithm indeed is unfair, because queue 0 has the highest > priority. There are at least two solutions to this: > 1. Leave the priority order unspecified > 2. Specify that queues are checked in the order they appear in the array > > I kind of like solution (2), because it allows the application to behave > in a round-robin manner by altering the order of the queues between the > calls: > - odp_pktin_recv_mq_tmo({q1, q2, q3, q4}, …) > - odp_pktin_recv_mq_tmo({q2, q3, q4, q1}, …) > - odp_pktin_recv_mq_tmo({q3, q4, q1, q2}, …) > - odp_pktin_recv_mq_tmo({q4, q1, q2, q3}, …) > … > > Then essentially the priority of all queues averages out to have > approximately the same average priority. > > So, you should perhaps consider in the API spec that the priority order > could be defined to be 0, 1, 2, …. I cannot foresee any implementation > which would use a different priority order. > > Agreed. We can improve the documentation to specify that priority is in > the order of input queue in the array with '0' being highest priority. > > Regards, > Bala > > > I'd add in a next step (if needed and feasible). > > The algorithm above works for fairness regardless if the first or any > other queue has highest priority. I'd like to first get verification that > strict priority specification would not cause performance issues. E.g. on > some platform it may optimize performance, if the next recv_mq() call > continues from the same queue the last finished, or any other relation > between queues (e.g. if two queues point to related interfaces, handle > those together: first all netmap interfaces, then all sockets, ...). > > -Petri > > > > > > > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
