Netdev List
 help / color / mirror / Atom feed
From: Dave Jiang <dave.jiang@intel.com>
To: Koichiro Den <den@valinux.co.jp>, Jon Mason <jdmason@kudzu.us>,
	Frank Li <Frank.Li@kernel.org>, Allen Hubbe <allenbh@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Niklas Cassel <cassel@kernel.org>,
	Nicholas Bellinger <nab@linux-iscsi.org>
Cc: ntb@lists.linux.dev, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 08/16] NTB: ntb_transport: Add opt-in direct-DMA channel reservation
Date: Thu, 20 Aug 2026 13:03:45 -0700	[thread overview]
Message-ID: <60af3a30-dabd-4013-8324-f950d8add1fb@intel.com> (raw)
In-Reply-To: <20260810165136.2292436-9-den@valinux.co.jp>



On 8/10/26 9:51 AM, Koichiro Den wrote:
> Direct DMA is opt-in. Add 'use_direct_dma' module parameter to request
> it. Some endpoint integrations expose NTB and DMA through sibling PCI
> functions, so add direct_dma_func to select the DMA function when the
> NTB device cannot return the DMA device directly.
> 
> When use_direct_dma is set and negotiation scratchpads are available,
> locate the DMA device and reserve one suitable channel for every QP
> before registering clients. This avoids negotiating direct TX before a
> later-created QP discovers that no channel is available. If the full set
> is unavailable, leave direct TX disabled. Note that direct RX does not
> require these channels.
> 
> Signed-off-by: Koichiro Den <den@valinux.co.jp>
> ---
>  drivers/ntb/ntb_transport.c | 120 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 120 insertions(+)
> 
> diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
> index f873eacd532b..6051d8abfc0d 100644
> --- a/drivers/ntb/ntb_transport.c
> +++ b/drivers/ntb/ntb_transport.c
> @@ -98,6 +98,16 @@ static bool use_dma;
>  module_param(use_dma, bool, 0644);
>  MODULE_PARM_DESC(use_dma, "Use DMA engine to perform large data copy");
>  
> +static bool use_direct_dma;
> +module_param(use_direct_dma, bool, 0644);
> +MODULE_PARM_DESC(use_direct_dma,
> +		 "Use PCI endpoint DMA to transfer directly to peer RX buffers");
> +
> +static unsigned int direct_dma_func;
> +module_param(direct_dma_func, uint, 0644);
> +MODULE_PARM_DESC(direct_dma_func,
> +		 "PCI function number of a sibling endpoint DMA function");

This feel like very adhoc way of determining which DMA device to use. Is there a better way to do some sort of auto discovery without required user input?


> +
>  static unsigned int direct_dma_ring_entries = 64;
>  module_param(direct_dma_ring_entries, uint, 0644);
>  MODULE_PARM_DESC(direct_dma_ring_entries,
> @@ -147,6 +157,7 @@ struct ntb_transport_qp {
>  	void *cb_data;
>  	struct dma_chan *tx_dma_chan;
>  	struct dma_chan *rx_dma_chan;
> +	struct dma_chan *direct_dma_chan;
>  
>  	bool client_ready;
>  	bool link_is_up;
> @@ -269,6 +280,7 @@ struct ntb_transport_ctx {
>  	struct work_struct link_cleanup;
>  
>  	struct dentry *debugfs_node_dir;
> +	struct device *direct_dma_dev;
>  	u32 direct_features;
>  	u32 peer_direct_features;
>  	unsigned int direct_ring_entries;
> @@ -352,6 +364,97 @@ static inline u32 ntb_direct_ring_used(u32 head, u32 tail)
>  	return head - tail;
>  }
>  
> +static bool ntb_direct_dma_filter_fn(struct dma_chan *chan, void *data)
> +{
> +	struct dma_slave_caps caps;
> +
> +	if (chan->device->dev != data || dma_get_slave_caps(chan, &caps))
> +		return false;
> +
> +	/* Payload and completion descriptors must complete in order. */
> +	return caps.cmd_terminate &&
> +	       !dma_has_cap(DMA_COMPLETION_NO_ORDER, chan->device->cap_mask) &&
> +	       (caps.directions & BIT(DMA_MEM_TO_DEV));
> +}
> +
> +static struct device *ntb_direct_get_dma_dev(struct ntb_dev *ndev)
> +{
> +	struct pci_dev *pdev = ndev->pdev;
> +	struct pci_dev *dma_pdev;
> +	struct device *dev;
> +
> +	if (ndev->ops->get_dma_dev) {
> +		dev = ntb_get_dma_dev(ndev);
> +		return dev ? get_device(dev) : ERR_PTR(-ENODEV);
> +	}
> +
> +	if (!pdev || !pdev->bus || direct_dma_func > 7)
> +		return ERR_PTR(-ENODEV);
> +
> +	dma_pdev = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
> +					       pdev->bus->number,
> +					       PCI_DEVFN(PCI_SLOT(pdev->devfn),
> +							 direct_dma_func));
> +	if (!dma_pdev)
> +		return ERR_PTR(-ENODEV);
> +
> +	return &dma_pdev->dev;
> +}
> +
> +static void ntb_direct_dma_release_channels(struct ntb_transport_ctx *nt)
> +{
> +	unsigned int i;
> +
> +	for (i = 0; i < nt->qp_count; i++) {
> +		if (!nt->qp_vec[i].direct_dma_chan)
> +			continue;
> +
> +		dma_release_channel(nt->qp_vec[i].direct_dma_chan);
> +		nt->qp_vec[i].direct_dma_chan = NULL;
> +	}
> +}
> +
> +static void ntb_direct_dma_release(struct ntb_transport_ctx *nt)
> +{
> +	ntb_direct_dma_release_channels(nt);
> +	if (nt->direct_dma_dev) {
> +		put_device(nt->direct_dma_dev);
> +		nt->direct_dma_dev = NULL;
> +	}
> +}
> +
> +static void ntb_direct_dma_init(struct ntb_transport_ctx *nt)
> +{
> +	dma_cap_mask_t mask;
> +	unsigned int i;
> +
> +	if (!use_direct_dma)
> +		return;
> +
> +	nt->direct_dma_dev = ntb_direct_get_dma_dev(nt->ndev);
> +	if (IS_ERR(nt->direct_dma_dev)) {
> +		dev_info(&nt->ndev->dev, "direct DMA device unavailable: %pe\n",
> +			 nt->direct_dma_dev);
> +		nt->direct_dma_dev = NULL;
> +		return;
> +	}
> +
> +	dma_cap_zero(mask);
> +	dma_cap_set(DMA_SLAVE, mask);

Are only slave DMA usable in this case? Is it not possible to do DMA with host DMA engines?

My main concern in all of this is looking for a way to make this usable for all ntb_transport users if possible and not niche the generic code to a specific hardware vendor.

DJ
> +
> +	for (i = 0; i < nt->qp_count; i++) {
> +		nt->qp_vec[i].direct_dma_chan =
> +			dma_request_channel(mask, ntb_direct_dma_filter_fn,
> +					    nt->direct_dma_dev);
> +		if (!nt->qp_vec[i].direct_dma_chan) {
> +			dev_info(&nt->ndev->dev,
> +				 "not enough direct DMA channels for all QPs\n");
> +			ntb_direct_dma_release_channels(nt);
> +			return;
> +		}
> +	}
> +}
> +
>  struct ntb_payload_header {
>  	unsigned int ver;
>  	unsigned int len;
> @@ -1476,6 +1579,16 @@ static int ntb_transport_probe(struct ntb_client *self, struct ntb_dev *ndev)
>  		return -ENOMEM;
>  
>  	nt->ndev = ndev;
> +	if (use_direct_dma &&
> +	    (direct_dma_ring_entries < 2 ||
> +	     direct_dma_ring_entries > NTB_DIRECT_MAX_RING_ENTRIES ||
> +	     !is_power_of_2(direct_dma_ring_entries))) {
> +		dev_err(&ndev->dev,
> +			"direct DMA ring entries must be a power of two between 2 and %u\n",
> +			NTB_DIRECT_MAX_RING_ENTRIES);
> +		rc = -EINVAL;
> +		goto err;
> +	}
>  	nt->direct_ring_entries = direct_dma_ring_entries;
>  
>  	/*
> @@ -1582,6 +1695,11 @@ static int ntb_transport_probe(struct ntb_client *self, struct ntb_dev *ndev)
>  		if (rc)
>  			goto err2;
>  	}
> +	if (ntb_direct_spads_available(nt))
> +		ntb_direct_dma_init(nt);
> +	else if (use_direct_dma)
> +		dev_info(&ndev->dev,
> +			 "not enough scratchpads for direct DMA negotiation\n");
>  
>  	mutex_init(&nt->link_event_lock);
>  	INIT_DELAYED_WORK(&nt->link_work, ntb_transport_link_work);
> @@ -1605,6 +1723,7 @@ static int ntb_transport_probe(struct ntb_client *self, struct ntb_dev *ndev)
>  err3:
>  	ntb_clear_ctx(ndev);
>  err2:
> +	ntb_direct_dma_release(nt);
>  	kfree(nt->qp_vec);
>  err1:
>  	while (i--) {
> @@ -1648,6 +1767,7 @@ static void ntb_transport_free(struct ntb_client *self, struct ntb_dev *ndev)
>  		iounmap(nt->mw_vec[i].vbase);
>  	}
>  
> +	ntb_direct_dma_release(nt);
>  	kfree(nt->qp_vec);
>  	kfree(nt->mw_vec);
>  	kfree(nt);


  reply	other threads:[~2026-08-20 20:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-10 16:51 [PATCH 00/16] NTB: Add direct TX/RX using PCI endpoint DMA Koichiro Den
2026-08-10 16:51 ` [PATCH 01/16] NTB: ntb_transport: Abort link setup on QP MW allocation failure Koichiro Den
2026-08-10 18:41   ` Frank Li
2026-08-12  2:15     ` Koichiro Den
2026-08-12 14:59       ` Frank Li
2026-08-10 16:51 ` [PATCH 02/16] NTB: ntb_transport: Reject oversized TX buffers Koichiro Den
2026-08-10 16:51 ` [PATCH 03/16] NTB: ntb_transport: Start TX offload thread after queue setup Koichiro Den
2026-08-10 16:51 ` [PATCH 04/16] NTB: ntb_transport: Stop QP work before freeing a queue Koichiro Den
2026-08-10 16:51 ` [PATCH 05/16] NTB: ntb_transport: Run RX processing on system workqueue Koichiro Den
2026-08-10 16:51 ` [PATCH 06/16] NTB: ntb_transport: Define direct-DMA shared state Koichiro Den
2026-08-10 16:51 ` [PATCH 07/16] NTB: ntb_transport: Negotiate direct-DMA queue layout Koichiro Den
2026-08-10 16:51 ` [PATCH 08/16] NTB: ntb_transport: Add opt-in direct-DMA channel reservation Koichiro Den
2026-08-20 20:03   ` Dave Jiang [this message]
2026-08-21 14:38     ` Koichiro Den
2026-08-21 15:10       ` Dave Jiang
2026-08-10 16:51 ` [PATCH 09/16] NTB: ntb_transport: Allocate direct-DMA queue state Koichiro Den
2026-08-10 16:51 ` [PATCH 10/16] NTB: ntb_transport: Implement direct-DMA QP session handshake Koichiro Den
2026-08-10 16:51 ` [PATCH 11/16] NTB: ntb_transport: Implement direct-DMA RX buffer publication Koichiro Den
2026-08-10 16:51 ` [PATCH 12/16] NTB: ntb_transport: Implement direct-DMA TX submission Koichiro Den
2026-08-10 16:51 ` [PATCH 13/16] NTB: ntb_transport: Implement safe direct-DMA teardown Koichiro Den
2026-08-10 16:51 ` [PATCH 14/16] NTB: ntb_transport: Enable direct-DMA queues Koichiro Den
2026-08-10 17:04   ` Koichiro Den
2026-08-10 16:51 ` [PATCH 15/16] NTB: ntb_transport: Report the direct-DMA payload limit Koichiro Den
2026-08-10 16:51 ` [PATCH 16/16] NTB: ntb_transport: Add optional polling for direct-DMA RX Koichiro Den

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=60af3a30-dabd-4013-8324-f950d8add1fb@intel.com \
    --to=dave.jiang@intel.com \
    --cc=Frank.Li@kernel.org \
    --cc=allenbh@gmail.com \
    --cc=cassel@kernel.org \
    --cc=den@valinux.co.jp \
    --cc=gregkh@linuxfoundation.org \
    --cc=jdmason@kudzu.us \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nab@linux-iscsi.org \
    --cc=netdev@vger.kernel.org \
    --cc=ntb@lists.linux.dev \
    /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