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.
From: lng-odp [mailto:[email protected]] On Behalf Of EXT
Savolainen, Petri (Nokia - FI/Espoo)
Sent: Friday, March 04, 2016 12:46 PM
To: EXT Bala Manoharan
Cc: LNG ODP Mailman List
Subject: Re: [lng-odp] [API-NEXT PATCH 1/2] api: pktio: add recv from multiple
queues with tmo
From: EXT Bala Manoharan [mailto:[email protected]]
Sent: Friday, March 04, 2016 12:16 PM
To: Savolainen, Petri (Nokia - FI/Espoo)
<[email protected]<mailto:[email protected]>>
Cc: 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 15:21, Petri Savolainen
<[email protected]<mailto:[email protected]>> wrote:
Added odp_pktin_recv_mq_tmo() which allows application to
poll multiple input queues (interfaces) with single call.
The call includes timeout parameter which allows thread to
e.g. sleep while waiting for more packets to arrive and thus
avoid 100% CPU utilization when packet rate is low.
Signed-off-by: Petri Savolainen
<[email protected]<mailto:[email protected]>>
Signed-off-by: Juha-Matti Tilli
<[email protected]<mailto:[email protected]>>
---
include/odp/api/spec/packet_io.h | 55 ++++++++++++++++++++++
.../include/odp/api/plat/packet_io_types.h | 3 ++
2 files changed, 58 insertions(+)
diff --git a/include/odp/api/spec/packet_io.h b/include/odp/api/spec/packet_io.h
index 302d431..0932cf0 100644
--- a/include/odp/api/spec/packet_io.h
+++ b/include/odp/api/spec/packet_io.h
@@ -63,6 +63,15 @@ extern "C" {
* Actual MAC address sizes may be different.
*/
+/**
+ * @def ODP_PKTIN_NO_WAIT
+ * Do not wait on packet input
+ */
+
+/**
+ * @def ODP_PKTIN_WAIT
+ * Wait infinitely on packet input
+ */
/**
* Packet input mode
@@ -530,6 +539,52 @@ odp_pktio_t odp_pktio_lookup(const char *name);
int odp_pktin_recv(odp_pktin_queue_t queue, odp_packet_t packets[], int num);
/**
+ * Receive packets directly from multiple interface input queues
+ *
+ * Receives up to 'num' packets from one of the specified pktio interface input
+ * queues. The index of the source queue is stored into 'from' output
+ * parameter. If there are no packets available on any of the queues, waits for
+ * packets depeding on 'wait' parameter value. Returns the number of packets
+ * received.
A Minor query, since there are more than one input queue and 'num' packets are
returned from only one of the input queue what happens when more than one input
queue contains the packet? Is there any inherent priority order to be
maintained by the implementation? Correct me if I am wrong but these input
queues are created based on hash parameters and does not contain any priority
value.
Regards,
Bala
No priority order. We could say that queue[0] is checked always first, etc. But
I think we can leave it implementation specific in which order queues are
checked (at least for now). Application can use the plain recv() in between of
these calls to poll “high” priority queues more of than the others.
-Petri
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
