Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3606782pxu; Tue, 8 Dec 2020 17:09:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJxWaX3i3sJO68Wqnig/2m/em2B5Rrgn11gDs5+SoAV8NOkN2NxQoV3oyV4xU2GRNGqL5MPp X-Received: by 2002:a17:906:d101:: with SMTP id b1mr76131ejz.80.1607476140978; Tue, 08 Dec 2020 17:09:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607476140; cv=none; d=google.com; s=arc-20160816; b=Orx74fMR3NQ6L/+JQy0gCVt+7db7lP3UZCQZQHnwu6DbH2HdoYe2fuA2DVOV8zoAwb ttRzZ43aDGeV0ugDS39NYrJDZsyjPvyHafGfLtq6w2n5PC3n1ux1a1ITmMARvIRcVWrf 2oKzlQmXyruj6H6KoRJDTZCmxpYaA9Mp5F9IpZrrfqdhhyiZp/EK/ZIx3BRDN7F73Aoy oxfmaqBXEsJgJ7aUT9VCGroN0a4jbuCVFuMJSZ0SHv21+0EBnL3VIQVwIrCsgZUDSRei CThcFkfOu+c1PoD/J9eZzJMzCHEVusxazWoKYx8hMzecFQmVmNqeZ437ToMW/XUjcprU JxxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:dkim-signature :date; bh=nGerSc5L9x0/AgxmVmda5ZK4b9QBwM7pWgoEhNz4USA=; b=o8I19fdPCC4JBxOQvifeIDkUnWYvwOLbN+Y1cT5WDTLaojiUj5imMNceTuTAG6uPuX ltyWvk9zEPeeRfAd9zjh7y05O6/y5atGGjRRXJcfmujpvq1USzsrjHIFvS1Z9YDl/DFd aVdzJl+2KLNksGZRp/ON6GiB1larRHYur7ktYTOyoat7XEyt3qLqyruWdxMy1dJDVFOo jVK0Q3LdfWG179VwBGZtF02vafhCCpYewVh+Omz0VjxAyJ7Fh07ehwk6iyy1NKDzPe64 ZU4phffA1+AaO9rrwzBKjH0JDSpXEtg2yUnBPS8P/AiLuv58/T5gAmZpV7mXmJAzAr3s bKXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=K7YJJADg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jg30si106493ejc.353.2020.12.08.17.08.38; Tue, 08 Dec 2020 17:09:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=K7YJJADg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728562AbgLHUT1 (ORCPT + 99 others); Tue, 8 Dec 2020 15:19:27 -0500 Received: from mail.kernel.org ([198.145.29.99]:35948 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727801AbgLHUT0 (ORCPT ); Tue, 8 Dec 2020 15:19:26 -0500 Date: Tue, 8 Dec 2020 11:43:14 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1607456595; bh=0Z5bpu1nVbF3QnVaGuTjeixaoErw3LQOX5Pc9Y2x7xs=; h=From:To:Cc:Subject:In-Reply-To:References:From; b=K7YJJADgVoOQA4WFXTX0LzCxujAPmgBwZQVMoMeuXF27q3Qacsr3wPaVgtfytn1OO W5ENlYvhcNqu/ZKyYjBk/Q0ZCUuhUGc5n5hfUhASAniUtxNqo1jUjCYIoU8W4TIAHv hX5wgzNlkUwnRxfm1MnP0swTsLes2IUyt/hknJBirVZ5En18zJeBxEnVx8uzEY0zqT NHk2WVTFGR45S66SAiSUyfkfDAEAxa6SQyrzAA6uwF3U0bhZG6sdrEgx/Y5/FW9ce7 daA7EMlZCjbK9u/bxonV9cC1s5tyYA5akyDeip8MRcCK074w5MF5s1Zd9PDCg7tPj2 veGywUHWDdphg== From: Jakub Kicinski To: Sven Van Asbroeck Cc: Bryan Whitehead , Microchip Linux Driver Support , David S Miller , Andrew Lunn , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net v1 2/2] lan743x: boost performance: limit PCIe bandwidth requirement Message-ID: <20201208114314.743ee6ec@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com> In-Reply-To: <20201206034408.31492-2-TheSven73@gmail.com> References: <20201206034408.31492-1-TheSven73@gmail.com> <20201206034408.31492-2-TheSven73@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 5 Dec 2020 22:44:08 -0500 Sven Van Asbroeck wrote: > From: Sven Van Asbroeck > > To support jumbo frames, each rx ring dma buffer is 9K in size. > But the chip only stores a single frame per dma buffer. > > When the chip is working with the default 1500 byte MTU, a 9K > dma buffer goes from chip -> cpu per 1500 byte frame. This means > that to get 1G/s ethernet bandwidth, we need 6G/s PCIe bandwidth ! > > Fix by limiting the rx ring dma buffer size to the current MTU > size. I'd guess this is a memory allocate issue, not a bandwidth thing. for 9K frames the driver needs to do order-2 allocations of 16K. For 1500 2K allocations are sufficient (which is < 1 page, hence a lot cheaper). > Tested with iperf3 on a freescale imx6 + lan7430, both sides > set to mtu 1500 bytes. > > Before: > [ ID] Interval Transfer Bandwidth Retr > [ 4] 0.00-20.00 sec 483 MBytes 203 Mbits/sec 0 > After: > [ ID] Interval Transfer Bandwidth Retr > [ 4] 0.00-20.00 sec 1.15 GBytes 496 Mbits/sec 0 > > And with both sides set to MTU 9000 bytes: > Before: > [ ID] Interval Transfer Bandwidth Retr > [ 4] 0.00-20.00 sec 1.87 GBytes 803 Mbits/sec 27 > After: > [ ID] Interval Transfer Bandwidth Retr > [ 4] 0.00-20.00 sec 1.98 GBytes 849 Mbits/sec 0 > > Tested-by: Sven Van Asbroeck # lan7430 > Signed-off-by: Sven Van Asbroeck This is a performance improvement, not a fix, it really needs to target net-next. > diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c > index ebb5e0bc516b..2bded1c46784 100644 > --- a/drivers/net/ethernet/microchip/lan743x_main.c > +++ b/drivers/net/ethernet/microchip/lan743x_main.c > @@ -1957,11 +1957,11 @@ static int lan743x_rx_next_index(struct lan743x_rx *rx, int index) > > static struct sk_buff *lan743x_rx_allocate_skb(struct lan743x_rx *rx) > { > - int length = 0; > + struct net_device *netdev = rx->adapter->netdev; > > - length = (LAN743X_MAX_FRAME_SIZE + ETH_HLEN + 4 + RX_HEAD_PADDING); > - return __netdev_alloc_skb(rx->adapter->netdev, > - length, GFP_ATOMIC | GFP_DMA); > + return __netdev_alloc_skb(netdev, > + netdev->mtu + ETH_HLEN + 4 + RX_HEAD_PADDING, > + GFP_ATOMIC | GFP_DMA); > } > > static int lan743x_rx_init_ring_element(struct lan743x_rx *rx, int index, > @@ -1969,9 +1969,10 @@ static int lan743x_rx_init_ring_element(struct lan743x_rx *rx, int index, > { > struct lan743x_rx_buffer_info *buffer_info; > struct lan743x_rx_descriptor *descriptor; > - int length = 0; > + struct net_device *netdev = rx->adapter->netdev; > + int length; > > - length = (LAN743X_MAX_FRAME_SIZE + ETH_HLEN + 4 + RX_HEAD_PADDING); > + length = netdev->mtu + ETH_HLEN + 4 + RX_HEAD_PADDING; > descriptor = &rx->ring_cpu_ptr[index]; > buffer_info = &rx->buffer_info[index]; > buffer_info->skb = skb; > @@ -2157,8 +2158,8 @@ static int lan743x_rx_process_packet(struct lan743x_rx *rx) > int index = first_index; > > /* multi buffer packet not supported */ > - /* this should not happen since > - * buffers are allocated to be at least jumbo size > + /* this should not happen since buffers are allocated > + * to be at least the mtu size configured in the mac. > */ > > /* clean up buffers */ > @@ -2632,9 +2633,13 @@ static int lan743x_netdev_change_mtu(struct net_device *netdev, int new_mtu) > struct lan743x_adapter *adapter = netdev_priv(netdev); > int ret = 0; > > + if (netif_running(netdev)) > + return -EBUSY; That may cause a regression to users of the driver who expect to be able to set the MTU when the device is running. You need to disable the NAPI, pause the device, swap the buffers for smaller / bigger ones and restart the device. > ret = lan743x_mac_set_mtu(adapter, new_mtu); > if (!ret) > netdev->mtu = new_mtu; > + > return ret; > } >