All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Daley <johndale@cisco.com>
To: ferruh.yigit@intel.com
Cc: dev@dpdk.org, Hyong Youb Kim <hyonkim@cisco.com>
Subject: [PATCH 2/6] net/enic: fix the MTU handler to rely on max packet length
Date: Thu,  3 May 2018 12:37:09 -0700	[thread overview]
Message-ID: <20180503193713.20622-2-johndale@cisco.com> (raw)
In-Reply-To: <20180503193713.20622-1-johndale@cisco.com>

From: Hyong Youb Kim <hyonkim@cisco.com>

The RQ setup functions (enic_alloc_rq and enic_alloc_rx_queue_mbufs)
have changed to rely on max_rx_pkt_len to determine the use of scatter
and buffer size. But, the MTU handler only updates ethdev's MTU
value. So make it update max_rx_pkt_len as well. Other PMDs also
update both mtu and max_rx_pkt_len in their MTU handlers.

Also the condition for taking a short cut (scatter is disabled) in the
MTU handler is wrong. Even when scatter is disabled, a change in
max_rx_pkt_len may affect the buffer size posted to the NIC. So remove
that condition.

Finally, fix a comment and a warning message condition.

Fixes: 422ba91716a7 ("net/enic: heed the requested max Rx packet size")

Signed-off-by: Hyong Youb Kim <hyonkim@cisco.com>
Reviewed-by: John Daley <johndale@cisco.com>
Reviewed-by: Aaron Conole <aconole@redhat.com>
---
 drivers/net/enic/enic_main.c | 34 +++++++++++++++++++---------------
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index e2adadcc9..b3b4e9626 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -287,7 +287,7 @@ enic_alloc_rx_queue_mbufs(struct enic *enic, struct vnic_rq *rq)
 		  rq->ring.desc_count);
 
 	/*
-	 * If *not* using scatter and the mbuf size is smaller than the
+	 * If *not* using scatter and the mbuf size is greater than the
 	 * requested max packet size (max_rx_pkt_len), then reduce the
 	 * posted buffer size to max_rx_pkt_len. HW still receives packets
 	 * larger than max_rx_pkt_len, but they will be truncated, which we
@@ -730,7 +730,7 @@ int enic_alloc_rq(struct enic *enic, uint16_t queue_idx,
 		 * See enic_alloc_rx_queue_mbufs().
 		 */
 		if (max_rx_pkt_len <
-		    enic_mtu_to_max_rx_pktlen(enic->rte_dev->data->mtu)) {
+		    enic_mtu_to_max_rx_pktlen(enic->max_mtu)) {
 			dev_warning(enic, "rxmode.max_rx_pkt_len is ignored"
 				    " when scatter rx mode is in use.\n");
 		}
@@ -1416,20 +1416,26 @@ int enic_set_mtu(struct enic *enic, uint16_t new_mtu)
 			"MTU (%u) is greater than value configured in NIC (%u)\n",
 			new_mtu, config_mtu);
 
-	/* The easy case is when scatter is disabled. However if the MTU
-	 * becomes greater than the mbuf data size, packet drops will ensue.
+	/* Update the MTU and maximum packet length */
+	eth_dev->data->mtu = new_mtu;
+	eth_dev->data->dev_conf.rxmode.max_rx_pkt_len =
+		enic_mtu_to_max_rx_pktlen(new_mtu);
+
+	/*
+	 * If the device has not started (enic_enable), nothing to do.
+	 * Later, enic_enable() will set up RQs reflecting the new maximum
+	 * packet length.
 	 */
-	if (!(enic->rte_dev->data->dev_conf.rxmode.offloads &
-	      DEV_RX_OFFLOAD_SCATTER)) {
-		eth_dev->data->mtu = new_mtu;
+	if (!eth_dev->data->dev_started)
 		goto set_mtu_done;
-	}
 
-	/* Rx scatter is enabled so reconfigure RQ's on the fly. The point is to
-	 * change Rx scatter mode if necessary for better performance. I.e. if
-	 * MTU was greater than the mbuf size and now it's less, scatter Rx
-	 * doesn't have to be used and vice versa.
-	  */
+	/*
+	 * The device has started, re-do RQs on the fly. In the process, we
+	 * pick up the new maximum packet length.
+	 *
+	 * Some applications rely on the ability to change MTU without stopping
+	 * the device. So keep this behavior for now.
+	 */
 	rte_spinlock_lock(&enic->mtu_lock);
 
 	/* Stop traffic on all RQs */
@@ -1454,8 +1460,6 @@ int enic_set_mtu(struct enic *enic, uint16_t new_mtu)
 
 	/* now it is safe to reconfigure the RQs */
 
-	/* update the mtu */
-	eth_dev->data->mtu = new_mtu;
 
 	/* free and reallocate RQs with the new MTU */
 	for (rq_idx = 0; rq_idx < enic->rq_count; rq_idx++) {
-- 
2.16.2

  reply	other threads:[~2018-05-03 19:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03 19:37 [PATCH 1/6] net/enic: enable RQ first and then post Rx buffers John Daley
2018-05-03 19:37 ` John Daley [this message]
2018-05-03 19:37 ` [PATCH 3/6] net/enic: set rte errno to positive value John Daley
2018-05-03 19:37 ` [PATCH 4/6] doc: update the enic guide and features John Daley
2018-05-03 19:37 ` [PATCH 5/6] net/enic: fix RSS hash type advertisement John Daley
2018-05-03 19:37 ` [PATCH 6/6] net/enic: update UDP RSS controls John Daley
2018-05-09 18:50 ` [PATCH 1/6] net/enic: enable RQ first and then post Rx buffers Ferruh Yigit

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=20180503193713.20622-2-johndale@cisco.com \
    --to=johndale@cisco.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=hyonkim@cisco.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.