From: Manivannan Sadhasivam <mani@kernel.org>
To: Frank Li <Frank.Li@nxp.com>
Cc: mie@igel.co.jp, imx@lists.linux.dev, bhelgaas@google.com,
jasowang@redhat.com, jdmason@kudzu.us, kishon@kernel.org,
kw@linux.com, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, lpieralisi@kernel.org,
mani@kernel.org, mst@redhat.com, renzhijie2@huawei.com,
taki@igel.co.jp, virtualization@lists.linux-foundation.org
Subject: Re: PCIe RC\EP virtio rdma solution discussion.
Date: Wed, 15 Feb 2023 13:53:43 +0530 [thread overview]
Message-ID: <20230215082343.GA6224@thinkpad> (raw)
In-Reply-To: <20230207194527.4071169-1-Frank.Li@nxp.com>
On Tue, Feb 07, 2023 at 02:45:27PM -0500, Frank Li wrote:
> From: Frank Li <Frank.li@nxp.com>
>
> Recently more and more people are interested in PCI RC and EP connection,
> especially network usage cases. I upstreamed a vntb solution last year.
> But the transfer speed is not good enough. I initialized a discussion
> at https://lore.kernel.org/imx/d098a631-9930-26d3-48f3-8f95386c8e50@ti.com/T/#t
>
> ┌─────────────────────────────────┐ ┌──────────────┐
> │ │ │ │
> │ │ │ │
> │ VirtQueue RX │ │ VirtQueue │
> │ TX ┌──┐ │ │ TX │
> │ ┌─────────┐ │ │ │ │ ┌─────────┐ │
> │ │ SRC LEN ├─────┐ ┌──┤ │◄────┼───┼─┤ SRC LEN │ │
> │ ├─────────┤ │ │ │ │ │ │ ├─────────┤ │
> │ │ │ │ │ │ │ │ │ │ │ │
> │ ├─────────┤ │ │ │ │ │ │ ├─────────┤ │
> │ │ │ │ │ │ │ │ │ │ │ │
> │ └─────────┘ │ │ └──┘ │ │ └─────────┘ │
> │ │ │ │ │ │
> │ RX ┌───┼──┘ TX │ │ RX │
> │ ┌─────────┐ │ │ ┌──┐ │ │ ┌─────────┐ │
> │ │ │◄┘ └────►│ ├─────┼───┼─┤ │ │
> │ ├─────────┤ │ │ │ │ ├─────────┤ │
> │ │ │ │ │ │ │ │ │ │
> │ ├─────────┤ │ │ │ │ ├─────────┤ │
> │ │ │ │ │ │ │ │ │ │
> │ └─────────┘ │ │ │ │ └─────────┘ │
> │ virtio_net └──┘ │ │ virtio_net │
> │ Virtual PCI BUS EDMA Queue │ │ │
> ├─────────────────────────────────┤ │ │
> │ PCI EP Controller with eDMA │ │ PCI Host │
> └─────────────────────────────────┘ └──────────────┘
>
> Basic idea is
> 1. Both EP and host probe virtio_net driver
> 2. There are two queues, one is the EP side(EQ), the other is the Host side.
> 3. EP side epf driver map Host side’s queue into EP’s space. Called HQ.
> 4. One working thread
> 5. pick one TX from EQ and RX from HQ, combine and generate EDMA requests,
> and put into the DMA TX queue.
> 6. Pick one RX from EQ and TX from HQ, combine and generate EDMA requests,
> and put into the DMA RX queue.
> 7. EDMA done irq will mark related item in EP and HQ finished.
>
> The whole transfer is zero copied and uses a DMA queue.
>
> The Shunsuke Mie implemented the above idea.
> https://lore.kernel.org/linux-pci/CANXvt5q_qgLuAfF7dxxrqUirT_Ld4B=POCq8JcB9uPRvCGDiKg@mail.gmail.com/T/#t
>
>
> Similar solution posted at 2019, except use memcpy from/to PCI EP map windows.
> Using DMA should be simpler because EDMA can access the whole HOST\EP side memory space.
> https://lore.kernel.org/linux-pci/9f8e596f-b601-7f97-a98a-111763f966d1@ti.com/T/
>
> Solution 1 (Based on shunsuke):
>
> Both EP and Host side use virtio.
> Using EDMA to simplify data transfer and improve transfer speed.
> RDMA implement based on RoCE
> - proposal: https://lore.kernel.org/all/20220511095900.343-1-xieyongji@bytedance.com/T/
> - presentation on kvm forum: https://youtu.be/Qrhv6hC_YK4
>
> Solution 2(2020, Kishon)
>
> Previous https://lore.kernel.org/linux-pci/20200702082143.25259-1-kishon@ti.com/
> EP side use vhost, RC side use virtio.
> I don’t think anyone works on this thread now.
> If using eDMA, it needs both sides to have a transfer queue.
> I don't know how to easily implement it on the vhost side.
>
> Solution 3(I am working on)
>
> Implement infiniband rdma driver at both EP and RC side.
> EP side build EDMA hardware queue based on EP/RC side’s send and receive
> queue and when eDMA finished, write status to complete queue for both EP/RC
> side. Use ipoib implement network transfer.
>
>
> The whole upstream effort is quite huge for these. I don’t want to waste
> time and efforts because direction is wrong.
>
> I think Solution 1 is an easy path.
>
I didn't had time to look into Shunsuke's series, but from the initial look
of the proposed solutions, option 1 seems to be the best for me.
Thanks,
Mani
>
>
--
மணிவண்ணன் சதாசிவம்
prev parent reply other threads:[~2023-02-15 8:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 19:45 PCIe RC\EP virtio rdma solution discussion Frank Li
2023-02-14 3:24 ` Shunsuke Mie
2023-02-14 15:28 ` [EXT] " Frank Li
2023-02-15 8:23 ` Manivannan Sadhasivam [this message]
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=20230215082343.GA6224@thinkpad \
--to=mani@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=bhelgaas@google.com \
--cc=imx@lists.linux.dev \
--cc=jasowang@redhat.com \
--cc=jdmason@kudzu.us \
--cc=kishon@kernel.org \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mie@igel.co.jp \
--cc=mst@redhat.com \
--cc=renzhijie2@huawei.com \
--cc=taki@igel.co.jp \
--cc=virtualization@lists.linux-foundation.org \
/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