From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 41FD320B4C for ; Wed, 10 May 2023 11:49:03 +0000 (UTC) Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2EB8061B2 for ; Wed, 10 May 2023 04:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TLCqPWBv1H++JJR3ALZxd5CoLH0aDeulOSqhewhv5Dc=; b=TX7Gs8VZDvZ2pn57oqta85r5Re FH9GX/3412Jutffz0a8lE8oTd5KY6Vl/kzVmHYkzPWujPb+7WAMqhPvyGQ7W0C0yw1S8jIgteNeIw s/nJwKa9LunyO35IdngzYDUl5Fkj5ewt1r4SuaeD5UOyY9nAx/gY3QLlp3/MQxBvtDDbQxrFvLqpy pE+ZTkAN3fcYKzPrPVEF1floEv/XZyEiJmms4Upi5N66K05PZPEQL2DN5u95nxzuSH9/oKY/iLAnb easWsYED8YCu+MKtMHuvPmzIMIPp7f7qPDNtTYykin5UHNPYzQJTpQvq03KYt6/6J1ciBKx+O7Va1 AVvunFkQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:34442) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pwiJU-0004tw-6n; Wed, 10 May 2023 12:48:56 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1pwiJS-0002ya-PO; Wed, 10 May 2023 12:48:54 +0100 Date: Wed, 10 May 2023 12:48:54 +0100 From: "Russell King (Oracle)" To: Eric Dumazet Cc: Marek =?iso-8859-1?Q?Beh=FAn?= , "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, Paolo Abeni , Thomas Petazzoni Subject: Re: [PATCH net-next 5/5] net: mvneta: allocate TSO header DMA memory in chunks Message-ID: References: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: Russell King (Oracle) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On Wed, May 10, 2023 at 01:38:17PM +0200, Eric Dumazet wrote: > On Wed, May 10, 2023 at 12:16 PM Russell King (Oracle) > wrote: > > > > Now that we no longer need to check whether the DMA address is within > > the TSO header DMA memory range for the queue, we can allocate the TSO > > header DMA memory in chunks rather than one contiguous order-6 chunk, > > which can stress the kernel's memory subsystems to allocate. > > > > Instead, use order-1 (8k) allocations, which will result in 32 order-1 > > pages containing 32 TSO headers. > > I guess there is no IOMMU/SMMU/IOTLB involved on platforms using this driver. > > (Otherwise, attempting high-order allocations, then fallback to > low-order allocations > would provide better performance if the high-order allocation at init > time succeeded) On the hardware I have, that is correct. Maybe others with mvneta on different SoCs can comment? Thomas probably has an idea, but as he hasn't worked on Marvell hardware for some time, may have forgotten everything about Marvell hardware. On that point, I'm wondering whether there's much value keeping Thomas' maintainer's entries for Marvell stuff - any comment Thomas? Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!