From patchwork Thu May 3 19:37:09 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "John Daley (johndale)" X-Patchwork-Id: 39360 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7074FDED; Thu, 3 May 2018 21:45:04 +0200 (CEST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by dpdk.org (Postfix) with ESMTP id B02B523C for ; Thu, 3 May 2018 21:45:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3813; q=dns/txt; s=iport; t=1525376702; x=1526586302; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=5twGtiYL5lCmuQWcWl8TKrAbTSnoU/AH5jiXIfPGa0Y=; b=OxWJbq+T9HDD/DrY1SLRmdLwfMu5PtSRI8A6PxfOfiot/MIl/Ft0b9px fTHu7Sqm8AxFLweA9orHEnD0sjN4g8EnrDnY/pBIpTpKJvqgFwtVgbKWm eoPPTkjWi5i6/58jYX1woduNP2isBVfh7y0x8lLcemMVQSg2dhvyeqp0H w=; X-IronPort-AV: E=Sophos;i="5.49,359,1520899200"; d="scan'208";a="109020113" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 19:45:00 +0000 Received: from cisco.com (savbu-usnic-a.cisco.com [10.193.184.48]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w43Jj0Z0021134; Thu, 3 May 2018 19:45:00 GMT Received: by cisco.com (Postfix, from userid 392789) id E412420F2001; Thu, 3 May 2018 12:44:59 -0700 (PDT) From: John Daley To: ferruh.yigit@intel.com Cc: dev@dpdk.org, Hyong Youb Kim Date: Thu, 3 May 2018 12:37:09 -0700 Message-Id: <20180503193713.20622-2-johndale@cisco.com> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180503193713.20622-1-johndale@cisco.com> References: <20180503193713.20622-1-johndale@cisco.com> Subject: [dpdk-dev] [PATCH 2/6] net/enic: fix the MTU handler to rely on max packet length X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Hyong Youb Kim 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 Reviewed-by: John Daley Reviewed-by: Aaron Conole --- 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++) {