From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 A0FCA288C2D; Tue, 26 May 2026 05:35:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779773710; cv=none; b=rH++ALKnQGMx90/t9l7+wEq99Q1QMgvsRLSp0SnWzfUPJeLYqFneJ7EAKN0JMqhU9IUu9tI1F9lCDGta2VTbaTHXogycSuK6pVfC+wFvZv7pi5iU55sGA4pIJWqRzJDgfuhgoXEfMnxRm7nFsX6HlckelQK3QPpNsKNBSGxplt0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779773710; c=relaxed/simple; bh=BCZ2U2fo+yH+zZPLh+gZxROwJlkA/+J2mSkfKof/QbA=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=HDFyGNJGpLHcb/TASFwjB9V7zn8b0mIVfoPlJSFrlLFT9lXuAusAmkeCIQ6yeANJsBw5YeXoyBN9B62zSqIBW4rot7/wf/sjR6EU6T1qAW52dAtHmdwqyIzwRT5i2JcKvPtplweKRD87sCGviPU45SvTr6p02sIGHwnBNBPbqmo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NZeGcnLF; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NZeGcnLF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7A5A91F000E9; Tue, 26 May 2026 05:35:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779773709; bh=BZeCFiWwomXsNSoC7p5OXyKFyX+acoYY9otOOgn2FJ0=; h=Date:From:To:CC:Subject:In-Reply-To:References; b=NZeGcnLFvKxmYXoy9mb+eGDs/eV9D6KkS6d2B7ZuB8Anx/O02L34gwFNZdAVS71TX XTW1hnNcj4J56+d7gK8TB9YH6l/C2obr78iLkmzLBdm0wvMkFaF88R2eT2WIRmqkIH Xxfgpsii4SR9c7k4uKh/acFZ0FQT7oVENeg3/o20veqXPIXIjA40GlDtDwfF/CViA3 65vPTnSawSXL6e0de5d/ANoutOuSivQPH8qOinWjntbcmMME5qw2ypDrCjkztDcRZe jNEauHN4jBCD9pMPe/6PJVK7BQokskE24Mw5S5Du2jOCsXDiWOpAWZP/bE3/dcxGfy 2IP02AT77tIcA== Date: Tue, 26 May 2026 07:35:06 +0200 From: Niklas Cassel To: Koichiro Den CC: Manivannan Sadhasivam , Frank Li , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Kishon Vijay Abraham I , Bjorn Helgaas , Jonathan Corbet , Shuah Khan , Vinod Koul , Arnd Bergmann , Damien Le Moal , Marek Vasut , Yoshihiro Shimoda , linux-pci@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v2_0/3=5D_PCI=3A_endpoint=3A_Add?= =?US-ASCII?Q?_PCI_DMA_endpoint_function_=28part_3/3=29?= User-Agent: Thunderbird for Android In-Reply-To: References: <20260525063456.3317509-1-den@valinux.co.jp> <3dkicfydmrlm2i6ks34kwjdmlvb22ryftkfw2yj62o4rtj5xvl@f4gby5vlwtdf> Message-ID: Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Koichiro, On 26 May 2026 04:04:07 CEST, Koichiro Den wrote: >On Mon, May 25, 2026 at 10:32:06PM +0200, Niklas Cassel wrote: >> On 25 May 2026 16:03:35 CEST, Koichiro Den wrot= e: >> >On Mon, May 25, 2026 at 10:35:46AM +0200, Niklas Cassel wrote: >> >> On Mon, May 25, 2026 at 04:05:02PM +0900, Koichiro Den wrote: >> >>=20 >> >That restriction should be documented with the new NTB transport, whic= h I will >> >submit if the direction taken by this series is acceptable=2E >>=20 >> This is easy for me to say, since I am not the NTB maintainer, but it w= ould be nice if we could somehow come up with a design where we don't only = support EPCs that have 'max-functions' !=3D 1, because IIRC, most PCI EPCs = have 'max-functions' =3D=3D 1=2E > >Yes, that's fair point=2E As a quick check on v7=2E1-rc5, among DWC-based= EP nodes, >only 6 out of 45 set max-functions > 1 (about 13%)=2E Assuming there are = no cases >where the hardware supports more functions than the DT advertises, that m= eans only >about 13% of DWC-based EP instances described in DT could support the "NT= B >transport backed by PCI EP DMA" use case=2E If I also count non-DWC EP no= des, I >get 15 out of 64 (about 23%)=2E The only DMA "backend" added in your 3-part series is the eDMA in DWC-base= d controllers=2E So if all three of your series lands, then 13% of the DWC-based endpoint c= ontrollers can theoretically use this new feature=2E > >If supporting single-function EPCs is a requirement, then the separate PC= I DMA >EPF model is not a good choice for that NTB transport use case=2E We woul= d need to >keep the DMA delegation metadata inside the vNTB function, or use some ot= her >single-function design=2E > >That is basically option 2 from my earlier mail: >https://lore=2Ekernel=2Eorg/linux-pci/xnfnxv64hpil6if4ikyohxnarvsekbmjcc3= 7k5zej264ix46z3@qtu6xj2uy3xi/ > > [snip] > 2=2E Treat endpoint DMA as a first-class part of vNTB=2E The RC-side = ntb_hw_epf > would create an auxiliary device, and a new dw-edma-aux driver wou= ld create > the delegated DMA channels on the RC side=2E > =20 > [PATCH 00/15] PCI: endpoint: Remote DMA support via vNTB > https://lore=2Ekernel=2Eorg/linux-pci/20260312165005=2E1148676-1-d= en@valinux=2Eco=2Ejp/ > =20 > I added an ASCII diagram for the overview as a follow-up comment h= ere: > https://lore=2Ekernel=2Eorg/all/sn67hi7kljh7cgmgodatb3naz2astlaklq= fobdbxyyzgoohxqb@4nnetbhqwba4/ > [snip] > >Do you prefer the vNTB-integrated model over this series? My take: I do think that the design in this series is more elegant that the vNTB-i= ntegrated model=2E However, if the design in this series only supports 13% of DWC-based endpo= int controllers, when the vNTB-integrated model can support 100% of DWC-bas= ed endpoint controllers=2E=2E=2E What good it is to have an elegant design if in reality, it supports drast= ically fewer SoCs? But please don't listen only to my opinion, Mani is the maintainer, so it = would be interesting to hear his thoughts as well=2E Kind regards, Niklas