Hello,
I suggest adding another function:
void odp_pktin_mq_ensure_fairness(odp_pktin_queue_t queues[], unsigned num_q);
Then instead of this:
for (;;)
{
ret = odp_pktin_recv_mq_tmo(queues, sizeof(queues)/sizeof(*queues), NULL,
packets, sizeof(packets)/sizeof(*packets), ODP_PKTIN_WAIT);
/* process packets */
}
… the application would do this in a loop:
for (;;)
{
odp_pktin_mq_ensure_fairness(queues, sizeof(queues)/sizeof(*queues));
ret = odp_pktin_recv_mq_tmo(queues, sizeof(queues)/sizeof(*queues), NULL,
packets, sizeof(packets)/sizeof(*packets), ODP_PKTIN_WAIT);
/* process packets */
}
The actual “ensure fairness” implementation could be left unspecified, but for
the linux-generic, it would be implemented by simply rotating from {q1, q2, q3,
q4} to {q2, q3, q4, q1}. For other implementations, it might be even a no-op.
The idea is that “ensure fairness” would be called once before each recv_mq_tmo
call, and if this is done, each input queue would have approximately the same
priority when averaged over time. What ensure_fairness can do is to adjust the
order of the queues in the array, or adjust the queues themselves.
odp_pktin_recv_mq_tmo cannot do the ensure fairness step, because the queues
argument is a const argument.
Note that this proposal doesn’t require the recv_mq_tmo call to specify the
priority as 0, 1, 2, 3, … because the actual implementations of the recv_mq_tmo
and ensure_fairness calls would be left unspecified.
An alternative to this would be to change the queues argument to a non-const
argument so that recv_mq_tmo could do the ensure_fairness step, but I don’t
like this solution much. In my opinion, it is much better to have the queues
argument as a const argument.
From: EXT Bill Fischofer [mailto:[email protected]]
Sent: Sunday, March 06, 2016 11:13 AM
To: Savolainen, Petri (Nokia - FI/Espoo)
Cc: EXT Bala Manoharan; Tilli, Juha-Matti (Nokia - FI/Espoo); LNG ODP Mailman
List
Subject: Re: [lng-odp] [API-NEXT PATCH 1/2] api: pktio: add recv from multiple
queues with tmo
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]<mailto:[email protected]>> wrote:
From: EXT Bala Manoharan
[mailto:[email protected]<mailto:[email protected]>]
Sent: Friday, March 04, 2016 2:39 PM
To: Tilli, Juha-Matti (Nokia - FI/Espoo)
<[email protected]<mailto:[email protected]>>
Cc: Savolainen, Petri (Nokia - FI/Espoo)
<[email protected]<mailto:[email protected]>>; LNG ODP
Mailman List <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
