From: Lukas Wunner <lukas@wunner.de>
To: Vidya Sagar <vidyas@nvidia.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Dongdong Liu <liudongdong3@huawei.com>,
"hch@infradead.org" <hch@infradead.org>,
"logang@deltatee.com" <logang@deltatee.com>,
"leon@kernel.org" <leon@kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"rajur@chelsio.com" <rajur@chelsio.com>,
Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Subject: Re: [PATCH V11 7/8] PCI: Enable 10-Bit Tag support for PCIe Endpoint device
Date: Sat, 24 Jan 2026 19:48:13 +0100 [thread overview]
Message-ID: <aXUT7Xg7V6Dusek8@wunner.de> (raw)
In-Reply-To: <53978a8a-18b6-419d-8a54-b7c16f98253d@nvidia.com>
On Sat, Jan 24, 2026 at 02:35:12PM +0000, Vidya Sagar wrote:
> On 05/11/21 23:09, Bjorn Helgaas wrote:
> > On Fri, Nov 05, 2021 at 04:24:24PM +0800, Dongdong Liu wrote:
> > > Current we use sysfs to enable/disable 10-bit tags for a requester also
> > > depend on the RP support 10-bit tag completer, so it will be ok.
> >
> > Ah, OK. So we can never *enable* 10-bit tags unless the Root Port
> > supports them.
> >
> > I misunderstood the purpose of this file. When the Root Port doesn't
> > support 10-bit tags, we won't enable them during enumeration. I
> > though the point was that if we want to do P2PDMA to a peer that
> > *does* support them, we could use this file to enable them.
> >
> > But my understanding was wrong -- the real purpose of the file is to
> > *disable* 10-bit tags for the case when a P2PDMA peer doesn't support
> > them.
[...]
> Hi Dongdong Liu,
> Thanks for pushing this patch series.
> I would like to know your plan to pursue this series in getting them merged.
> Given that there is no action on this series since 2021, I would like to
> take it up if you don't have an imminent plan.
Smita (+cc) took another stab at 10-bit tag support in 2023:
https://lore.kernel.org/all/20230828095429.GA17864@wunner.de/
The approach proposed by Dongdong Liu -- to disable 10-bit tag support
via sysfs -- doesn't seem right. The kernel has all the information
it needs to automatically determine when to enable or disable 10-bit tags.
User space has no business overriding that. There is an in-kernel API
to set up P2PDMA and it can automatically disable or re-enable 10-bit tags
when it is appropriate. I think the only reason why a sysfs interface
would be needed is to support setting up P2PDMA behind the kernel's back
for proprietary technologies such as Nvidia GPU Direct. I hereby
preemptively NAK patches that add a sysfs interface for this purpose.
Please help improve the existing in-kernel P2PDMA support instead
by plumbing 10-bit tag awareness into it.
Thanks,
Lukas
next prev parent reply other threads:[~2026-01-24 18:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-30 13:53 [PATCH V11 0/8] PCI: Enable 10-Bit tag support for PCIe devices Dongdong Liu
2021-10-30 13:53 ` [PATCH V11 1/8] PCI: Use cached devcap in more places Dongdong Liu
2021-10-30 13:53 ` [PATCH V11 2/8] PCI: Cache Device Capabilities 2 Register Dongdong Liu
2021-10-30 13:53 ` [PATCH V11 3/8] PCI: Add 10-Bit Tag register definitions Dongdong Liu
2021-10-30 13:53 ` [PATCH V11 4/8] PCI/sysfs: Add a tags sysfs file for PCIe Endpoint devices Dongdong Liu
2021-11-01 20:54 ` Bjorn Helgaas
2021-11-02 13:03 ` Dongdong Liu
2021-10-30 13:53 ` [PATCH V11 5/8] PCI/IOV: Add tags sysfs files for VF devices Dongdong Liu
2021-10-30 13:53 ` [PATCH V11 6/8] PCI/P2PDMA: Add a 10-Bit Tag check in P2PDMA Dongdong Liu
2021-10-30 13:53 ` [PATCH V11 7/8] PCI: Enable 10-Bit Tag support for PCIe Endpoint device Dongdong Liu
2021-11-01 22:02 ` Bjorn Helgaas
2021-11-01 22:33 ` Bjorn Helgaas
2021-11-03 10:05 ` Dongdong Liu
2021-11-03 16:02 ` Bjorn Helgaas
2021-11-05 8:24 ` Dongdong Liu
2021-11-05 17:39 ` Bjorn Helgaas
2026-01-24 14:35 ` Vidya Sagar
2026-01-24 18:48 ` Lukas Wunner [this message]
2026-01-25 17:03 ` Leon Romanovsky
2021-10-30 13:53 ` [PATCH V11 8/8] PCI/IOV: Enable 10-Bit Tag support for PCIe VF devices Dongdong Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aXUT7Xg7V6Dusek8@wunner.de \
--to=lukas@wunner.de \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=hch@infradead.org \
--cc=helgaas@kernel.org \
--cc=leon@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liudongdong3@huawei.com \
--cc=logang@deltatee.com \
--cc=rajur@chelsio.com \
--cc=vidyas@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox