From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lynxeye.de (ns.lynxeye.de [87.118.118.114]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3F88B15D5C4; Tue, 28 Jan 2025 20:12:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=87.118.118.114 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738095175; cv=none; b=jj1zXHMM6lyhr9NtfPltyx8/K7r+PCfn5NeocN0o+0qHSVQfgNH7lx2KEegx/MObik5uRPtou+FRFSgKspHBu7QeUQB/vx3E2Ilfs56lF11XJXOeU7ckU96JuDiAnOPpNjb1qQTDPvxjirCMi92cq3D5UM3Kk+hOKhQ5OlvLSE8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738095175; c=relaxed/simple; bh=rEer5Vac7kMVgv5bwbnGzchPKoqx1kUftnZtMdARFIA=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=db0W+sR7wRENmOcadHDmMhuU9Vr2KG9Me9+GIrhOt3vOn86p94zb5xNX2zsFm/r6ukFGLagY4MAzFEz1rV4XgK0D9vIcaW5qo0vCaUeeAKdgk3VSAtKbd3DGVcH60b2ZY2g5NjbTkq/cVXRHFUmZWQLVvc64dfsD94+H9HJcHh0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lynxeye.de; spf=none smtp.mailfrom=lynxeye.de; arc=none smtp.client-ip=87.118.118.114 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lynxeye.de Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=lynxeye.de Received: by lynxeye.de (Postfix, from userid 501) id 6F899E74071; Tue, 28 Jan 2025 21:04:58 +0100 (CET) X-Spam-Level: Received: from [192.168.178.25] (a89-182-99-197.net-htp.de [89.182.99.197]) by lynxeye.de (Postfix) with ESMTPSA id 0A738E74067; Tue, 28 Jan 2025 21:04:57 +0100 (CET) Message-ID: Subject: Re: [PATCH net-next v3 1/4] net: stmmac: Switch to zero-copy in non-XDP RX path From: Lucas Stach To: Thierry Reding , Furong Xu <0x1207@gmail.com> Cc: Andrew Lunn , Brad Griffis , Jon Hunter , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Alexander Lobakin , Joe Damato , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , xfr@outlook.com, "linux-tegra@vger.kernel.org" Date: Tue, 28 Jan 2025 21:04:56 +0100 In-Reply-To: References: <20250124003501.5fff00bc@orangepi5-plus> <20250124104256.00007d23@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) Precedence: bulk X-Mailing-List: linux-tegra@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Am Freitag, dem 24.01.2025 um 14:15 +0100 schrieb Thierry Reding: >=20 [...] > > The dma-coherent property in device tree node is SoC specific, so only = the > > vendors know if their stmmac ethernet controller is dma coherent and > > whether their device tree are missing the critical dma-coherent propert= y. >=20 > What I fail to understand is how dma-coherent can make a difference in > this case. If it's not present, then the driver is supposed to maintain > caches explicitly. But it seems like explicit cache maintenance actually > causes things to break. So do we need to assume that DMA coherent > devices in generally won't work if the driver manages caches explicitly? >=20 > I always figured dma-coherent was more of an optimization, but this > seems to indicate it isn't. There is a real=C2=A0failure scenario when the device is actually dma- coherent, but the DT claims it isn't: If a location from e.g. a receive buffer is already allocated in the cache, the write from the device will update the cache line and not go out to memory. If you then do the usual non-coherent cache maintenance, i.e. invalidate the RX buffer area after the device indicated the reception of the buffer, you will destroy the updated data in the cache and read stale data from memory. Regards, Lucas