On Tue, Oct 06, 2020 at 08:17:05PM +0200, Daniel Vetter wrote:
> So on the gpu we pipeline this all. So step 4 doesn't happen on the
> cpu, but instead we queue up a bunch of command buffers so that the
> gpu writes these pagetables (and the flushes tlbs and then does the
> actual stuff userspace
On Tue, Oct 06, 2020 at 11:22:14AM +0200, Daniel Vetter wrote:
>
> For reinstanting the pages you need:
>
> - dma_resv_lock, this prevents anyone else from issuing new moves or
> anything like that
> - dma_resv_get_excl + dma_fence_wait to wait for any pending moves to
> finish. gpus
On Tue, Oct 06, 2020 at 07:24:30PM +0200, Daniel Vetter wrote:
> On Tue, Oct 6, 2020 at 6:34 PM Daniel Vetter wrote:
> >
> > On Tue, Oct 06, 2020 at 12:49:56PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 06, 2020 at 11:22:14AM +0200, Daniel Vetter wrote:
> > > >
> > > > For reinstanting the
Hi guys,
maybe it becomes clearer to understand when you see this as two
different things:
1. The current location where the buffer is.
2. If the data inside the buffer can be accessed.
The current location is returned back by dma_buf_map_attachment() and
the result of it can be used to fill
On Tue, Oct 6, 2020 at 8:38 PM Jason Gunthorpe wrote:
>
> On Tue, Oct 06, 2020 at 08:17:05PM +0200, Daniel Vetter wrote:
>
> > So on the gpu we pipeline this all. So step 4 doesn't happen on the
> > cpu, but instead we queue up a bunch of command buffers so that the
> > gpu writes these
On Tue, Oct 6, 2020 at 8:02 PM Jason Gunthorpe wrote:
>
> On Tue, Oct 06, 2020 at 07:24:30PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 6, 2020 at 6:34 PM Daniel Vetter wrote:
> > >
> > > On Tue, Oct 06, 2020 at 12:49:56PM -0300, Jason Gunthorpe wrote:
> > > > On Tue, Oct 06, 2020 at 11:22:14AM
On Tue, Oct 6, 2020 at 6:34 PM Daniel Vetter wrote:
>
> On Tue, Oct 06, 2020 at 12:49:56PM -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 06, 2020 at 11:22:14AM +0200, Daniel Vetter wrote:
> > >
> > > For reinstanting the pages you need:
> > >
> > > - dma_resv_lock, this prevents anyone else from
> > Ledford ; Leon Romanovsky
> > ; Sumit Semwal ; Christian Koenig
> > ; Vetter, Daniel
> >
> > Subject: Re: [RFC PATCH v3 1/4] RDMA/umem: Support importing dma-buf as
> > user memory region
> >
> > On Sun, Oct 04, 2020 at 12:12:28PM -0700, Jianxin
On Tue, Oct 06, 2020 at 12:49:56PM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 06, 2020 at 11:22:14AM +0200, Daniel Vetter wrote:
> >
> > For reinstanting the pages you need:
> >
> > - dma_resv_lock, this prevents anyone else from issuing new moves or
> > anything like that
> > -
er 05, 2020 6:13 AM
> > > To: Xiong, Jianxin
> > > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > > Doug Ledford ; Leon Romanovsky
> > > ; Sumit Semwal ; Christian
> > > Koenig ; Vetter, Daniel
> > >
> > > Subject:
> > Ledford ; Leon Romanovsky
> > ; Sumit Semwal ; Christian Koenig
> > ; Vetter, Daniel
> >
> > Subject: Re: [RFC PATCH v3 1/4] RDMA/umem: Support importing dma-buf as
> > user memory region
> >
> > On Sun, Oct 04, 2020 at 12:12:28PM -0700, Jianxin
On Sun, Oct 04, 2020 at 12:12:28PM -0700, Jianxin Xiong wrote:
> Dma-buf is a standard cross-driver buffer sharing mechanism that can be
> used to support peer-to-peer access from RDMA devices.
>
> Device memory exported via dma-buf is associated with a file descriptor.
> This is passed to the
On Mon, Oct 05, 2020 at 04:18:11PM +, Xiong, Jianxin wrote:
> > The implementation in mlx5 will be much more understandable, it would just
> > do dma_buf_dynamic_attach() and program the XLT exactly
> > the same as a normal umem.
> >
> > The move_notify() simply zap's the XLT and triggers a
l
>
> Subject: Re: [RFC PATCH v3 1/4] RDMA/umem: Support importing dma-buf as user
> memory region
>
> On Mon, Oct 05, 2020 at 04:18:11PM +, Xiong, Jianxin wrote:
>
> > > The implementation in mlx5 will be much more understandable, it
> > > would
iel
> Subject: Re: [RFC PATCH v3 1/4] RDMA/umem: Support importing dma-buf as user
> memory region
>
> Hi Jianxin,
>
> Am 04.10.20 um 21:12 schrieb Jianxin Xiong:
> > Dma-buf is a standard cross-driver buffer sharing mechanism that can
> > be used to support peer-t
l
>
> Subject: Re: [RFC PATCH v3 1/4] RDMA/umem: Support importing dma-buf as user
> memory region
>
> On Sun, Oct 04, 2020 at 12:12:28PM -0700, Jianxin Xiong wrote:
> > Dma-buf is a standard cross-driver buffer sharing mechanism that can
> > be used to support peer-to-p
Hi Jianxin,
Am 04.10.20 um 21:12 schrieb Jianxin Xiong:
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a property associated with the
buffer allocation. When the
18 matches
Mail list logo
