From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 280D81EF091; Wed, 10 Sep 2025 16:22:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757521333; cv=none; b=ANr5heKsNg/UzyOLRPat5Q5cZ+urEFX5dKv0EVjh5aTZzeizKifDZgYvut04Lho5mPTnLidGBvrNjvhosLDbiUnv0VS6er4IzeHe5wShn5D84KXpsw+xGUeyZIFpFWPLpqOiWKJQ3n2CidQmj7vtGMS5unMImjfYtgAcJwsESc8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757521333; c=relaxed/simple; bh=PYI6dtOT/CwSIUL6uAP6xtAEqE1iA9VJzX34pPBFuwk=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=S5RR7KEFVavTS+lRCwTME2UHjXVCgqyF92eom4eECJSzs81KiAryTknHnuNW8lbGPGrawABqpeGghL60Pk9dlnrgCTAPoxF5/zs/BQr1kGQdzjmz0oHm0+KCjIEMTJacs7di3i7Bs1kMyvy6AhV3Zhz+B9D71onzZs3BYM2G8s4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=jC4TLgrH; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="jC4TLgrH" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 640C71A0C6B; Wed, 10 Sep 2025 16:22:09 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 451AE606D4; Wed, 10 Sep 2025 16:22:09 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 28D50102F28CF; Wed, 10 Sep 2025 18:22:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1757521328; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=ZctRQ7ts/8TVQPiO2r4kt975iBBgUJD5+xfPFF8APxs=; b=jC4TLgrHH0tSuMTXzghrf6gN9uTFLcQX1gNuQiind9B9slKj9lsPIcFJfqODhIDpQb10Rd rrxr5QiGq3cuB/TLVuGEoCdLetVHHBvpzxxwUtYxQjuc90/HlgbAHVqMKAoOGX51x3JsJT dc8aoTvd5NAZ8s6Q9OiZPNGKrjz1d0+uYz2U6BzohIxJjaw5UEcd+RlE+4rBFhUSLU2lBw nJHgWnm8zeAhMSy4LcZydyn0b//0KbpxDLWVsfWN7FZ37x+uWI2hgYR7n5p2ykT86+waYp gGMAWYaiAbLYmGNOIWz29nXdU6fHl+y205i9z9dcG53iASupTIGcEe5FBm1jOA== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 10 Sep 2025 18:22:03 +0200 Message-Id: Subject: Re: [PATCH net v4 4/5] net: macb: single dma_alloc_coherent() for DMA descriptors Cc: , , , "Thomas Petazzoni" , "Tawfik Bayouk" , "Sean Anderson" To: "Nicolas Ferre" , "Andrew Lunn" , "David S. Miller" , "Eric Dumazet" , "Jakub Kicinski" , "Paolo Abeni" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "Claudiu Beznea" , "Geert Uytterhoeven" , "Harini Katakam" , "Richard Cochran" , "Russell King" From: =?utf-8?q?Th=C3=A9o_Lebrun?= X-Mailer: aerc 0.20.1-0-g2ecb8770224a-dirty References: <20250820-macb-fixes-v4-0-23c399429164@bootlin.com> <20250820-macb-fixes-v4-4-23c399429164@bootlin.com> <010e0551-58b8-4b61-8ad7-2f03ecc6baa3@microchip.com> In-Reply-To: <010e0551-58b8-4b61-8ad7-2f03ecc6baa3@microchip.com> X-Last-TLS-Session-Version: TLSv1.3 Hello Nicolas, On Tue Aug 26, 2025 at 5:23 PM CEST, Nicolas Ferre wrote: > On 20/08/2025 at 16:55, Th=C3=A9o Lebrun wrote: >> Move from 2*NUM_QUEUES dma_alloc_coherent() for DMA descriptor rings to >> 2 calls overall. >>=20 >> Issue is with how all queues share the same register for configuring the >> upper 32-bits of Tx/Rx descriptor rings. Taking Tx, notice how TBQPH >> does *not* depend on the queue index: >>=20 >> #define GEM_TBQP(hw_q) (0x0440 + ((hw_q) << 2)) >> #define GEM_TBQPH(hw_q) (0x04C8) >>=20 >> queue_writel(queue, TBQP, lower_32_bits(queue->tx_ring_dma)); >> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT >> if (bp->hw_dma_cap & HW_DMA_CAP_64B) >> queue_writel(queue, TBQPH, upper_32_bits(queue->tx_ring= _dma)); >> #endif >>=20 >> To maximise our chances of getting valid DMA addresses, we do a single >> dma_alloc_coherent() across queues. This improves the odds because >> alloc_pages() guarantees natural alignment. Other codepaths (IOMMU or >> dev/arch dma_map_ops) don't give high enough guarantees >> (even page-aligned isn't enough). >>=20 >> Two consideration: >>=20 >> - dma_alloc_coherent() gives us page alignment. Here we remove this >> constraint meaning each queue's ring won't be page-aligned anymore. > > However... We must guarantee alignement depending on the controller's=20 > bus width (32 or 64 bits)... but being page aligned and having=20 > descriptors multiple of 64 bits anyway, we're good for each descriptor=20 > (might be worth explicitly adding). Sorry, your comment was unclear to me. - I don't see how we can guarantee bus alignment using dma_alloc_coherent() which doesn't ask for desired alignment. In what case can the DMA APIs return something with less than the tolerated bus alignment? - What does "having descriptors multiple of 64 bits anyway" mean? Thanks for your review and acks! V5 got published here: https://lore.kernel.org/lkml/20250910-macb-fixes-v5-0-f413a3601ce4@bootlin.= com/ Regards, -- Th=C3=A9o Lebrun, Bootlin Embedded Linux and Kernel engineering https://bootlin.com