DPDK patches and discussions
 help / color / mirror / Atom feed
From: Pablo de Lara <pablo.de.lara.guarch@intel.com>
To: dev@dpdk.org
Cc: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Subject: [dpdk-dev] [PATCH] examples/l3fwd-power: fix inappropiate Rx queue count method
Date: Fri,  4 Nov 2016 00:04:10 +0000	[thread overview]
Message-ID: <1478217850-77177-1-git-send-email-pablo.de.lara.guarch@intel.com> (raw)

Since commit b4f3c136a179 ("net/ixgbe: support checksum flags in SSE vector Rx"),
when HW IP Checksum is enabled, the RX vector function is available to use.
In case of L3fwd-power, since it is enabled, the RX vector function
was not used, but after this commit, it is. This has affected the way
to calculate how full an RX queue is, using rte_eth_rx_descriptor done
function, making the frequency to be at maximum, even when the frequency
is very low.

This commit reverts the way to know how full a queue is to the
previous way, using rte_eth_rx_queue_count(), making it work for both
vector and scalar RX functions.

Fixes: b451aa39db31 ("examples/l3fwd-power: use DD bit rather than RX queue count")

Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
 examples/l3fwd-power/main.c | 30 +++++++++++++++++++-----------
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index b65d683..74369bb 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -370,7 +370,7 @@ static struct rte_timer power_timers[RTE_MAX_LCORE];
 
 static inline uint32_t power_idle_heuristic(uint32_t zero_rx_packet_count);
 static inline enum freq_scale_hint_t power_freq_scaleup_heuristic( \
-			unsigned lcore_id, uint8_t port_id, uint16_t queue_id);
+			unsigned lcore_id, uint32_t rx_queue_count);
 
 /* exit signal handler */
 static void
@@ -705,9 +705,7 @@ power_idle_heuristic(uint32_t zero_rx_packet_count)
 }
 
 static inline enum freq_scale_hint_t
-power_freq_scaleup_heuristic(unsigned lcore_id,
-			     uint8_t port_id,
-			     uint16_t queue_id)
+power_freq_scaleup_heuristic(unsigned lcore_id, uint32_t rx_queue_count)
 {
 /**
  * HW Rx queue size is 128 by default, Rx burst read at maximum 32 entries
@@ -720,15 +718,12 @@ power_freq_scaleup_heuristic(unsigned lcore_id,
 #define FREQ_UP_TREND2_ACC   100
 #define FREQ_UP_THRESHOLD    10000
 
-	if (likely(rte_eth_rx_descriptor_done(port_id, queue_id,
-			FREQ_GEAR3_RX_PACKET_THRESHOLD) > 0)) {
+	if (likely(rx_queue_count > FREQ_GEAR3_RX_PACKET_THRESHOLD)) {
 		stats[lcore_id].trend = 0;
 		return FREQ_HIGHEST;
-	} else if (likely(rte_eth_rx_descriptor_done(port_id, queue_id,
-			FREQ_GEAR2_RX_PACKET_THRESHOLD) > 0))
+	} else if (likely(rx_queue_count > FREQ_GEAR2_RX_PACKET_THRESHOLD))
 		stats[lcore_id].trend += FREQ_UP_TREND2_ACC;
-	else if (likely(rte_eth_rx_descriptor_done(port_id, queue_id,
-			FREQ_GEAR1_RX_PACKET_THRESHOLD) > 0))
+	else if (likely(rx_queue_count > FREQ_GEAR1_RX_PACKET_THRESHOLD))
 		stats[lcore_id].trend += FREQ_UP_TREND1_ACC;
 
 	if (likely(stats[lcore_id].trend > FREQ_UP_THRESHOLD)) {
@@ -833,6 +828,7 @@ main_loop(__attribute__((unused)) void *dummy)
 	enum freq_scale_hint_t lcore_scaleup_hint;
 	uint32_t lcore_rx_idle_count = 0;
 	uint32_t lcore_idle_hint = 0;
+	uint32_t rx_ring_length;
 	int intr_en = 0;
 
 	const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1) / US_PER_S * BURST_TX_DRAIN_US;
@@ -923,6 +919,18 @@ start_rx:
 				rx_queue->zero_rx_packet_count = 0;
 
 				/**
+				 * get available descriptor number via
+				 * MMIO read is costly, so only do it when
+				 * recent poll returns maximum number.
+				 */
+				if (nb_rx >= MAX_PKT_BURST)
+					rx_ring_length =
+						rte_eth_rx_queue_count(portid,
+								queueid);
+				else
+					rx_ring_length = 0;
+
+				/**
 				 * do not scale up frequency immediately as
 				 * user to kernel space communication is costly
 				 * which might impact packet I/O for received
@@ -930,7 +938,7 @@ start_rx:
 				 */
 				rx_queue->freq_up_hint =
 					power_freq_scaleup_heuristic(lcore_id,
-							portid, queueid);
+							rx_ring_length);
 			}
 
 			/* Prefetch first packets */
-- 
2.5.5

             reply	other threads:[~2016-11-04  0:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-04  0:04 Pablo de Lara [this message]
2016-11-04 12:23 ` De Lara Guarch, Pablo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1478217850-77177-1-git-send-email-pablo.de.lara.guarch@intel.com \
    --to=pablo.de.lara.guarch@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).