From: Jason Gunthorpe <jgg@ziepe.ca>
To: Oded Gabbay <oded.gabbay@gmail.com>
Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Christian König" <christian.koenig@amd.com>,
"Gal Pressman" <galpress@amazon.com>,
sleybo@amazon.com, linux-rdma <linux-rdma@vger.kernel.org>,
"Oded Gabbay" <ogabbay@kernel.org>,
"Christoph Hellwig" <hch@lst.de>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
"moderated list:DMA BUFFER SHARING FRAMEWORK"
<linaro-mm-sig@lists.linaro.org>,
"Doug Ledford" <dledford@redhat.com>,
"Tomer Tayar" <ttayar@habana.ai>,
"amd-gfx list" <amd-gfx@lists.freedesktop.org>,
"Greg KH" <gregkh@linuxfoundation.org>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Leon Romanovsky" <leonro@nvidia.com>,
"open list:DMA BUFFER SHARING FRAMEWORK"
<linux-media@vger.kernel.org>
Subject: Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF
Date: Wed, 23 Jun 2021 15:50:45 -0300 [thread overview]
Message-ID: <20210623185045.GY1096940@ziepe.ca> (raw)
In-Reply-To: <CAFCwf111O0_YB_tixzEUmaKpGAHMNvMaOes2AfMD4x68Am4Yyg@mail.gmail.com>
On Wed, Jun 23, 2021 at 09:43:04PM +0300, Oded Gabbay wrote:
> Can you please explain why it is so important to (allow) access them
> through the CPU ?
It is not so much important, as it reflects significant design choices
that are already tightly baked into alot of our stacks.
A SGL is CPU accessible by design - that is baked into this thing and
places all over the place assume it. Even in RDMA we have
RXE/SWI/HFI1/qib that might want to use the CPU side (grep for sg_page
to see)
So, the thing at the top of the stack - in this case the gaudi driver
- simply can't assume what the rest of the stack is going to do and
omit the CPU side. It breaks everything.
Logan's patch series is the most fully developed way out of this
predicament so far.
> The whole purpose is that the other device accesses my device,
> bypassing the CPU.
Sure, but you don't know that will happen, or if it is even possible
in any given system configuration. The purpose is to allow for that
optimization when possible, not exclude CPU based approaches.
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Oded Gabbay <oded.gabbay@gmail.com>
Cc: linux-rdma <linux-rdma@vger.kernel.org>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
sleybo@amazon.com, "Leon Romanovsky" <leonro@nvidia.com>,
"Gal Pressman" <galpress@amazon.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Christian König" <christian.koenig@amd.com>,
"moderated list:DMA BUFFER SHARING FRAMEWORK"
<linaro-mm-sig@lists.linaro.org>,
"Doug Ledford" <dledford@redhat.com>,
"Tomer Tayar" <ttayar@habana.ai>,
"amd-gfx list" <amd-gfx@lists.freedesktop.org>,
"Greg KH" <gregkh@linuxfoundation.org>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christoph Hellwig" <hch@lst.de>,
"Oded Gabbay" <ogabbay@kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"open list:DMA BUFFER SHARING FRAMEWORK"
<linux-media@vger.kernel.org>
Subject: Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF
Date: Wed, 23 Jun 2021 15:50:45 -0300 [thread overview]
Message-ID: <20210623185045.GY1096940@ziepe.ca> (raw)
In-Reply-To: <CAFCwf111O0_YB_tixzEUmaKpGAHMNvMaOes2AfMD4x68Am4Yyg@mail.gmail.com>
On Wed, Jun 23, 2021 at 09:43:04PM +0300, Oded Gabbay wrote:
> Can you please explain why it is so important to (allow) access them
> through the CPU ?
It is not so much important, as it reflects significant design choices
that are already tightly baked into alot of our stacks.
A SGL is CPU accessible by design - that is baked into this thing and
places all over the place assume it. Even in RDMA we have
RXE/SWI/HFI1/qib that might want to use the CPU side (grep for sg_page
to see)
So, the thing at the top of the stack - in this case the gaudi driver
- simply can't assume what the rest of the stack is going to do and
omit the CPU side. It breaks everything.
Logan's patch series is the most fully developed way out of this
predicament so far.
> The whole purpose is that the other device accesses my device,
> bypassing the CPU.
Sure, but you don't know that will happen, or if it is even possible
in any given system configuration. The purpose is to allow for that
optimization when possible, not exclude CPU based approaches.
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Oded Gabbay <oded.gabbay@gmail.com>
Cc: linux-rdma <linux-rdma@vger.kernel.org>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
sleybo@amazon.com, "Leon Romanovsky" <leonro@nvidia.com>,
"Gal Pressman" <galpress@amazon.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Christian König" <christian.koenig@amd.com>,
"moderated list:DMA BUFFER SHARING FRAMEWORK"
<linaro-mm-sig@lists.linaro.org>,
"Doug Ledford" <dledford@redhat.com>,
"Tomer Tayar" <ttayar@habana.ai>,
"amd-gfx list" <amd-gfx@lists.freedesktop.org>,
"Greg KH" <gregkh@linuxfoundation.org>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christoph Hellwig" <hch@lst.de>,
"Oded Gabbay" <ogabbay@kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"open list:DMA BUFFER SHARING FRAMEWORK"
<linux-media@vger.kernel.org>
Subject: Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF
Date: Wed, 23 Jun 2021 15:50:45 -0300 [thread overview]
Message-ID: <20210623185045.GY1096940@ziepe.ca> (raw)
In-Reply-To: <CAFCwf111O0_YB_tixzEUmaKpGAHMNvMaOes2AfMD4x68Am4Yyg@mail.gmail.com>
On Wed, Jun 23, 2021 at 09:43:04PM +0300, Oded Gabbay wrote:
> Can you please explain why it is so important to (allow) access them
> through the CPU ?
It is not so much important, as it reflects significant design choices
that are already tightly baked into alot of our stacks.
A SGL is CPU accessible by design - that is baked into this thing and
places all over the place assume it. Even in RDMA we have
RXE/SWI/HFI1/qib that might want to use the CPU side (grep for sg_page
to see)
So, the thing at the top of the stack - in this case the gaudi driver
- simply can't assume what the rest of the stack is going to do and
omit the CPU side. It breaks everything.
Logan's patch series is the most fully developed way out of this
predicament so far.
> The whole purpose is that the other device accesses my device,
> bypassing the CPU.
Sure, but you don't know that will happen, or if it is even possible
in any given system configuration. The purpose is to allow for that
optimization when possible, not exclude CPU based approaches.
Jason
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2021-06-23 18:50 UTC|newest]
Thread overview: 143+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-18 12:36 [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF Oded Gabbay
2021-06-18 12:36 ` Oded Gabbay
2021-06-18 12:36 ` [PATCH v3 2/2] habanalabs: add support for dma-buf exporter Oded Gabbay
2021-06-18 12:36 ` Oded Gabbay
2021-06-21 12:28 ` [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF Daniel Vetter
2021-06-21 12:28 ` Daniel Vetter
2021-06-21 12:28 ` Daniel Vetter
2021-06-21 13:02 ` Greg KH
2021-06-21 13:02 ` Greg KH
2021-06-21 13:02 ` Greg KH
2021-06-21 14:12 ` Jason Gunthorpe
2021-06-21 14:12 ` Jason Gunthorpe
2021-06-21 14:12 ` Jason Gunthorpe
2021-06-21 16:26 ` Oded Gabbay
2021-06-21 16:26 ` Oded Gabbay
2021-06-21 16:26 ` Oded Gabbay
2021-06-21 17:55 ` Jason Gunthorpe
2021-06-21 17:55 ` Jason Gunthorpe
2021-06-21 17:55 ` Jason Gunthorpe
2021-06-21 18:27 ` Daniel Vetter
2021-06-21 18:27 ` Daniel Vetter
2021-06-21 18:27 ` Daniel Vetter
2021-06-21 19:24 ` Oded Gabbay
2021-06-21 19:24 ` Oded Gabbay
2021-06-21 19:24 ` Oded Gabbay
2021-06-21 23:29 ` Jason Gunthorpe
2021-06-21 23:29 ` Jason Gunthorpe
2021-06-21 23:29 ` Jason Gunthorpe
2021-06-22 6:37 ` [Linaro-mm-sig] " Christian König
2021-06-22 6:37 ` Christian König
2021-06-22 6:37 ` Christian König
2021-06-22 8:42 ` Oded Gabbay
2021-06-22 8:42 ` Oded Gabbay
2021-06-22 8:42 ` Oded Gabbay
2021-06-22 12:01 ` Jason Gunthorpe
2021-06-22 12:01 ` Jason Gunthorpe
2021-06-22 12:01 ` Jason Gunthorpe
2021-06-22 12:04 ` Oded Gabbay
2021-06-22 12:04 ` Oded Gabbay
2021-06-22 12:04 ` Oded Gabbay
2021-06-22 12:15 ` Jason Gunthorpe
2021-06-22 12:15 ` Jason Gunthorpe
2021-06-22 12:15 ` Jason Gunthorpe
2021-06-22 13:12 ` Oded Gabbay
2021-06-22 13:12 ` Oded Gabbay
2021-06-22 13:12 ` Oded Gabbay
2021-06-22 15:11 ` Jason Gunthorpe
2021-06-22 15:11 ` Jason Gunthorpe
2021-06-22 15:11 ` Jason Gunthorpe
2021-06-22 15:24 ` Christian König
2021-06-22 15:24 ` Christian König
2021-06-22 15:24 ` Christian König
2021-06-22 15:28 ` Jason Gunthorpe
2021-06-22 15:28 ` Jason Gunthorpe
2021-06-22 15:28 ` Jason Gunthorpe
2021-06-22 15:31 ` Oded Gabbay
2021-06-22 15:31 ` Oded Gabbay
2021-06-22 15:31 ` Oded Gabbay
2021-06-22 15:31 ` Christian König
2021-06-22 15:31 ` Christian König
2021-06-22 15:31 ` Christian König
2021-06-22 15:40 ` Oded Gabbay
2021-06-22 15:40 ` Oded Gabbay
2021-06-22 15:40 ` Oded Gabbay
2021-06-22 15:49 ` Christian König
2021-06-22 15:49 ` Christian König
2021-06-22 15:49 ` Christian König
2021-06-22 15:24 ` Oded Gabbay
2021-06-22 15:24 ` Oded Gabbay
2021-06-22 15:24 ` Oded Gabbay
2021-06-22 15:34 ` Jason Gunthorpe
2021-06-22 15:34 ` Jason Gunthorpe
2021-06-22 15:34 ` Jason Gunthorpe
2021-06-22 12:23 ` Christian König
2021-06-22 12:23 ` Christian König
2021-06-22 12:23 ` Christian König
2021-06-22 15:23 ` Jason Gunthorpe
2021-06-22 15:23 ` Jason Gunthorpe
2021-06-22 15:23 ` Jason Gunthorpe
2021-06-22 15:29 ` Christian König
2021-06-22 15:29 ` Christian König
2021-06-22 15:29 ` Christian König
2021-06-22 15:40 ` Jason Gunthorpe
2021-06-22 15:40 ` Jason Gunthorpe
2021-06-22 15:40 ` Jason Gunthorpe
2021-06-22 15:48 ` Christian König
2021-06-22 15:48 ` Christian König
2021-06-22 15:48 ` Christian König
2021-06-22 16:05 ` Jason Gunthorpe
2021-06-22 16:05 ` Jason Gunthorpe
2021-06-22 16:05 ` Jason Gunthorpe
2021-06-23 8:57 ` Christian König
2021-06-23 8:57 ` Christian König
2021-06-23 8:57 ` Christian König
2021-06-23 9:14 ` Oded Gabbay
2021-06-23 9:14 ` Oded Gabbay
2021-06-23 9:14 ` Oded Gabbay
2021-06-23 18:24 ` Jason Gunthorpe
2021-06-23 18:24 ` Jason Gunthorpe
2021-06-23 18:24 ` Jason Gunthorpe
2021-06-23 18:43 ` Oded Gabbay
2021-06-23 18:43 ` Oded Gabbay
2021-06-23 18:43 ` Oded Gabbay
2021-06-23 18:50 ` Jason Gunthorpe [this message]
2021-06-23 18:50 ` Jason Gunthorpe
2021-06-23 18:50 ` Jason Gunthorpe
2021-06-23 19:00 ` Oded Gabbay
2021-06-23 19:00 ` Oded Gabbay
2021-06-23 19:00 ` Oded Gabbay
2021-06-23 19:34 ` Jason Gunthorpe
2021-06-23 19:34 ` Jason Gunthorpe
2021-06-23 19:34 ` Jason Gunthorpe
2021-06-23 19:39 ` Oded Gabbay
2021-06-23 19:39 ` Oded Gabbay
2021-06-23 19:39 ` Oded Gabbay
2021-06-24 0:45 ` Jason Gunthorpe
2021-06-24 0:45 ` Jason Gunthorpe
2021-06-24 0:45 ` Jason Gunthorpe
2021-06-24 5:40 ` Christoph Hellwig
2021-06-24 5:40 ` Christoph Hellwig
2021-06-24 5:34 ` Christoph Hellwig
2021-06-24 5:34 ` Christoph Hellwig
2021-06-24 8:07 ` Christian König
2021-06-24 8:07 ` Christian König
2021-06-24 8:07 ` Christian König
2021-06-24 8:12 ` Christoph Hellwig
2021-06-24 8:12 ` Christoph Hellwig
2021-06-24 9:52 ` Christian König
2021-06-24 9:52 ` Christian König
2021-06-24 9:52 ` Christian König
2021-06-24 13:22 ` Christoph Hellwig
2021-06-24 13:22 ` Christoph Hellwig
2021-06-22 16:50 ` Felix Kuehling
2021-06-22 16:50 ` Felix Kuehling
2021-06-22 16:50 ` Felix Kuehling
2021-06-21 14:20 ` Daniel Vetter
2021-06-21 14:20 ` Daniel Vetter
2021-06-21 14:20 ` Daniel Vetter
2021-06-21 14:49 ` Jason Gunthorpe
2021-06-21 14:49 ` Jason Gunthorpe
2021-06-21 14:17 ` Jason Gunthorpe
2021-06-21 14:17 ` Jason Gunthorpe
2021-06-21 14:17 ` 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=20210623185045.GY1096940@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dledford@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=galpress@amazon.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=leonro@nvidia.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=oded.gabbay@gmail.com \
--cc=ogabbay@kernel.org \
--cc=sleybo@amazon.com \
--cc=ttayar@habana.ai \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.