On 6/18/24 07:43, Christoph Hellwig wrote:
On Mon, Jun 17, 2024 at 07:04:43PM +0100, Pavel Begunkov wrote:
There should be no other memory source other than the page allocator
and dmabuf. If you need different life time control for your
zero copy proposal don't mix that up with the contol of th
On 6/10/24 23:15, Jason Gunthorpe wrote:
On Mon, Jun 10, 2024 at 08:20:08PM +0100, Pavel Begunkov wrote:
On 6/10/24 16:16, David Ahern wrote:
There is no reason you shouldn't be able to use your fast io_uring
completion and lifecycle flow with DMABUF backed memory. Those are not
widly differe
On 6/11/24 07:34, Christoph Hellwig wrote:
On Fri, Jun 07, 2024 at 02:45:55PM +0100, Pavel Begunkov wrote:
On 6/5/24 09:24, Christoph Hellwig wrote:
On Mon, Jun 03, 2024 at 03:52:32PM +0100, Pavel Begunkov wrote:
The question for Christoph is what exactly is the objection here? Why we
would no
On 6/12/24 6:06 AM, Jason Gunthorpe wrote:
> On Tue, Jun 11, 2024 at 11:09:15AM -0700, Mina Almasry wrote:
>
>> Just curious: in Pavel's effort, io_uring - which is not a device - is
>> trying to share memory with the page_pool, which is also not a device.
>> And Pavel is being asked to wrap the m
On Tue, Jun 11, 2024 at 11:09:15AM -0700, Mina Almasry wrote:
> Just curious: in Pavel's effort, io_uring - which is not a device - is
> trying to share memory with the page_pool, which is also not a device.
> And Pavel is being asked to wrap the memory in a dmabuf. Is dmabuf
> going to be the ker
On Mon, Jun 10, 2024 at 3:15 PM Jason Gunthorpe wrote:
>
> On Mon, Jun 10, 2024 at 08:20:08PM +0100, Pavel Begunkov wrote:
> > On 6/10/24 16:16, David Ahern wrote:
>
> > > > There is no reason you shouldn't be able to use your fast io_uring
> > > > completion and lifecycle flow with DMABUF backed
On Mon, Jun 10, 2024 at 11:26 PM Christoph Hellwig wrote:
>
> On Mon, Jun 10, 2024 at 09:16:43AM -0600, David Ahern wrote:
> >
> > exactly. io_uring, page_pool, dmabuf - all kernel building blocks for
> > solutions. This why I was pushing for Mina's set not to be using the
> > name `devmem` - it i
Am 11.06.24 um 08:25 schrieb Christoph Hellwig:
On Mon, Jun 10, 2024 at 02:38:18PM +0200, Christian König wrote:
Well there is the fundamental problem that you can't use io_uring to
implement the semantics necessary for a dma_fence.
What is the exact problem there?
It's an intentional design
On Mon, Jun 10, 2024 at 08:20:08PM +0100, Pavel Begunkov wrote:
> On 6/10/24 16:16, David Ahern wrote:
> > > There is no reason you shouldn't be able to use your fast io_uring
> > > completion and lifecycle flow with DMABUF backed memory. Those are not
> > > widly different things and there is goo
On 6/10/24 16:41, Mina Almasry wrote:
On Mon, Jun 10, 2024 at 5:38 AM Christian König
wrote:
Am 10.06.24 um 14:16 schrieb Jason Gunthorpe:
On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
On 6/10/24 01:37, David Wei wrote:
On 2024-06-07 17:52, Jason Gunthorpe wrote:
IMHO it
On 6/10/24 16:16, David Ahern wrote:
On 6/10/24 6:16 AM, Jason Gunthorpe wrote:
On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
On 6/10/24 01:37, David Wei wrote:
On 2024-06-07 17:52, Jason Gunthorpe wrote:
IMHO it seems to compose poorly if you can only use the io_uring
lifec
On Mon, Jun 10, 2024 at 02:38:18PM +0200, Christian König wrote:
> Am 10.06.24 um 14:16 schrieb Jason Gunthorpe:
> > On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
> > > On 6/10/24 01:37, David Wei wrote:
> > > > On 2024-06-07 17:52, Jason Gunthorpe wrote:
> > > > > IMHO it seems t
On Mon, Jun 10, 2024 at 5:38 AM Christian König
wrote:
>
> Am 10.06.24 um 14:16 schrieb Jason Gunthorpe:
> > On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
> >> On 6/10/24 01:37, David Wei wrote:
> >>> On 2024-06-07 17:52, Jason Gunthorpe wrote:
> IMHO it seems to compose poo
On 6/10/24 6:16 AM, Jason Gunthorpe wrote:
> On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
>> On 6/10/24 01:37, David Wei wrote:
>>> On 2024-06-07 17:52, Jason Gunthorpe wrote:
IMHO it seems to compose poorly if you can only use the io_uring
lifecycle model with io_uring
Am 10.06.24 um 14:16 schrieb Jason Gunthorpe:
On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
On 6/10/24 01:37, David Wei wrote:
On 2024-06-07 17:52, Jason Gunthorpe wrote:
IMHO it seems to compose poorly if you can only use the io_uring
lifecycle model with io_uring registered
On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
> On 6/10/24 01:37, David Wei wrote:
> > On 2024-06-07 17:52, Jason Gunthorpe wrote:
> > > IMHO it seems to compose poorly if you can only use the io_uring
> > > lifecycle model with io_uring registered memory, and not with DMABUF
> >
On 6/7/24 17:59, Mina Almasry wrote:
On Fri, Jun 7, 2024 at 8:47 AM Pavel Begunkov wrote:
On 6/7/24 16:42, Pavel Begunkov wrote:
On 6/7/24 15:27, David Ahern wrote:
On 6/7/24 7:42 AM, Pavel Begunkov wrote:
I haven't seen any arguments against from the (net) maintainers so
far. Nor I see any
On 6/10/24 01:37, David Wei wrote:
On 2024-06-07 17:52, Jason Gunthorpe wrote:
IMHO it seems to compose poorly if you can only use the io_uring
lifecycle model with io_uring registered memory, and not with DMABUF
memory registered through Mina's mechanism.
By this, do you mean io_uring must be
On 2024-06-07 17:52, Jason Gunthorpe wrote:
> IMHO it seems to compose poorly if you can only use the io_uring
> lifecycle model with io_uring registered memory, and not with DMABUF
> memory registered through Mina's mechanism.
By this, do you mean io_uring must be exclusively used to use this
fea
On 2024-06-07 17:27, David Ahern wrote:
> I also do not understand why the ifq cache and overloading xdp functions
> have stuck around; I always thought both were added by Jonathan to
> simplify kernel ports during early POC days.
Setting up an Rx queue for ZC w/ a different pp will be done proper
On Fri, Jun 7, 2024 at 8:47 AM Pavel Begunkov wrote:
>
> On 6/7/24 16:42, Pavel Begunkov wrote:
> > On 6/7/24 15:27, David Ahern wrote:
> >> On 6/7/24 7:42 AM, Pavel Begunkov wrote:
> >>> I haven't seen any arguments against from the (net) maintainers so
> >>> far. Nor I see any objection against
On 6/7/24 16:42, Pavel Begunkov wrote:
On 6/7/24 15:27, David Ahern wrote:
On 6/7/24 7:42 AM, Pavel Begunkov wrote:
I haven't seen any arguments against from the (net) maintainers so
far. Nor I see any objection against callbacks from them (considering
that either option adds an if).
I have s
On 6/7/24 15:27, David Ahern wrote:
On 6/7/24 7:42 AM, Pavel Begunkov wrote:
I haven't seen any arguments against from the (net) maintainers so
far. Nor I see any objection against callbacks from them (considering
that either option adds an if).
I have said before I do not understand why the d
On Fri, Jun 07, 2024 at 08:27:29AM -0600, David Ahern wrote:
> On 6/7/24 7:42 AM, Pavel Begunkov wrote:
> > I haven't seen any arguments against from the (net) maintainers so
> > far. Nor I see any objection against callbacks from them (considering
> > that either option adds an if).
>
> I have sa
On 6/7/24 7:42 AM, Pavel Begunkov wrote:
> I haven't seen any arguments against from the (net) maintainers so
> far. Nor I see any objection against callbacks from them (considering
> that either option adds an if).
I have said before I do not understand why the dmabuf paradigm is not
sufficient f
On 6/5/24 09:24, Christoph Hellwig wrote:
On Mon, Jun 03, 2024 at 03:52:32PM +0100, Pavel Begunkov wrote:
The question for Christoph is what exactly is the objection here? Why we
would not be using well defined ops when we know there will be more
users?
The point is that there should be no mor
On 6/3/24 16:43, Mina Almasry wrote:
On Mon, Jun 3, 2024 at 7:52 AM Pavel Begunkov wrote:
On 6/3/24 15:17, Mina Almasry wrote:
On Fri, May 31, 2024 at 10:35 PM Christoph Hellwig wrote:
On Thu, May 30, 2024 at 08:16:01PM +, Mina Almasry wrote:
I'm unsure if the discussion has been reso
On Mon, Jun 3, 2024 at 7:52 AM Pavel Begunkov wrote:
>
> On 6/3/24 15:17, Mina Almasry wrote:
> > On Fri, May 31, 2024 at 10:35 PM Christoph Hellwig
> > wrote:
> >>
> >> On Thu, May 30, 2024 at 08:16:01PM +, Mina Almasry wrote:
> >>> I'm unsure if the discussion has been resolved yet. Sendin
On 6/3/24 15:17, Mina Almasry wrote:
On Fri, May 31, 2024 at 10:35 PM Christoph Hellwig wrote:
On Thu, May 30, 2024 at 08:16:01PM +, Mina Almasry wrote:
I'm unsure if the discussion has been resolved yet. Sending the series
anyway to get reviews/feedback on the (unrelated) rest of the ser
On Fri, May 31, 2024 at 10:35 PM Christoph Hellwig wrote:
>
> On Thu, May 30, 2024 at 08:16:01PM +, Mina Almasry wrote:
> > I'm unsure if the discussion has been resolved yet. Sending the series
> > anyway to get reviews/feedback on the (unrelated) rest of the series.
>
> As far as I'm concern
From: Jakub Kicinski
The page providers which try to reuse the same pages will
need to hold onto the ref, even if page gets released from
the pool - as in releasing the page from the pp just transfers
the "ownership" reference from pp to the provider, and provider
will wait for other references t
31 matches
Mail list logo
