public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Wathsala Vithanage <wathsala.vithanage@arm.com>
To: linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
	acpica-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
	lenb@kernel.org, robert.moore@intel.com, bhelgaas@google.com
Cc: wei.huang2@amd.com, honnappa.nagarahalli@arm.com,
	dhruv.tripathi@arm.com, rob.herring@arm.com,
	jeremy.linton@arm.com,
	Wathsala Vithanage <wathsala.vithanage@arm.com>
Subject: [RFC 0/2] GENL interface for ACPI _DSM methods
Date: Mon,  6 Jan 2025 16:30:43 +0000	[thread overview]
Message-ID: <20250106163045.508959-1-wathsala.vithanage@arm.com> (raw)

Linux v6.13-rc1 added support for PCIe TPH and direct cache injection.
As already described in the patch set[1] that introduced this feature,
the cache injection in supported hardware allows optimal utilization of
platform resources for specific requests on the PCIe bus. However, the
patch set [1] implements the functionality for usage within the kernel.
But certain user space applications, especially those whose performance
is sensitive to the latency of inbound writes as seen by a CPU core, may
benefit from using this information (E.g., the DPDK cache stashing
feature discussed in RFC [2]). This RFC is an attempt to obtain the PCIe
steering tag information from the kernel to be used by user mode
applications. We understand that there is more than one way to provide
this information. Please review and suggest alternatives if necessary.

The first of the two patches introduced in this RFC attempts to overcome
the kernel-only limitation by providing an API to kernel subsystems to
hook up relevant _DSM methods to a GENL interface. User space
applications can invoke a _DSM hooked up to this interface via the
"acpi-event" GENL family socket, granted they have the minimum
capabilities and message formats demanded by the kernel subsystem that
hooked up the _DSM method. This feature is added by extending the
"acpi-event" GENL family that multicasts ACPI events to the user-space
applications such as acpid.

The second patch of this RFC hooks up the PCIe root-port TLP Processing
Hints (TPH) _DSM to the ACPI GENL interface. User space applications
like [2] can now request the kernel to execute the _DSM on their behalf
and return steering-tag information.

[1] lore.kernel.org/linux-pci/20241002165954.128085-1-wei.huang2@amd.com
[2] inbox.dpdk.org/dev/20241021015246.304431-2-wathsala.vithanage@arm.com

Wathsala Vithanage (2):
  ACPI: Add support for invoking select _DSM methods from user space
  PCI: Add generic netlink interface to TPH _DSM

 drivers/acpi/Makefile                 |   3 +-
 drivers/acpi/{event.c => acpi_genl.c} | 110 ++++++++++++++++++++++-
 drivers/acpi/acpi_genl_dsm.c          |  76 ++++++++++++++++
 drivers/pci/tph.c                     | 121 ++++++++++++++++++++++++++
 include/acpi/acpi_genl.h              |  54 ++++++++++++
 include/linux/acpi.h                  |   1 +
 6 files changed, 360 insertions(+), 5 deletions(-)
 rename drivers/acpi/{event.c => acpi_genl.c} (63%)
 create mode 100644 drivers/acpi/acpi_genl_dsm.c
 create mode 100644 include/acpi/acpi_genl.h

-- 
2.43.0


             reply	other threads:[~2025-01-06 16:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-06 16:30 Wathsala Vithanage [this message]
2025-01-06 16:30 ` [RFC PATCH 1/2] ACPI: Add support for invoking select _DSM methods from user space Wathsala Vithanage
2025-01-06 16:30 ` [RFC PATCH 2/2] PCI: Add generic netlink interface to TPH _DSM Wathsala Vithanage
2025-01-06 18:01 ` [RFC 0/2] GENL interface for ACPI _DSM methods Jonathan Cameron
2025-01-07 17:37   ` Jeremy Linton
2025-01-07 17:48     ` Jason Gunthorpe
2025-01-08 19:59       ` Jeremy Linton
2025-01-08 20:50         ` Jason Gunthorpe
2025-01-09  0:34           ` Wathsala Wathawana Vithanage
2025-01-09 13:38             ` Jason Gunthorpe
2025-01-09 13:42               ` Wathsala Wathawana Vithanage
2025-01-09 13:46                 ` Jason Gunthorpe

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=20250106163045.508959-1-wathsala.vithanage@arm.com \
    --to=wathsala.vithanage@arm.com \
    --cc=acpica-devel@lists.linux.dev \
    --cc=bhelgaas@google.com \
    --cc=dhruv.tripathi@arm.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=jeremy.linton@arm.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rob.herring@arm.com \
    --cc=robert.moore@intel.com \
    --cc=wei.huang2@amd.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