Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-23 Thread David Wei
On 17/08/2023 15:18, Mina Almasry wrote: > On Thu, Aug 17, 2023 at 11:04 AM Pavel Begunkov > wrote: >> >> On 8/14/23 02:12, David Ahern wrote: >>> On 8/9/23 7:57 PM, Mina Almasry wrote: Changes in RFC v2: -- >> ... ** Test Setup Kernel: net-next with this

Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-23 Thread David Ahern
On 8/23/23 3:52 PM, David Wei wrote: > I'm also preparing a submission for NetDev conf. I wonder if you and others at > Google plan to present there as well? If so, then we may want to coordinate > our > submissions and talks (if accepted). personally, I see them as related but separate topics.

Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-18 Thread Pavel Begunkov
On 8/14/23 02:12, David Ahern wrote: On 8/9/23 7:57 PM, Mina Almasry wrote: Changes in RFC v2: -- ... ** Test Setup Kernel: net-next with this RFC and memory provider API cherry-picked locally. Hardware: Google Cloud A3 VMs. NIC: GVE with header split & RSS & flow steering

Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-17 Thread Mina Almasry
On Thu, Aug 17, 2023 at 11:04 AM Pavel Begunkov wrote: > > On 8/14/23 02:12, David Ahern wrote: > > On 8/9/23 7:57 PM, Mina Almasry wrote: > >> Changes in RFC v2: > >> -- > ... > >> ** Test Setup > >> > >> Kernel: net-next with this RFC and memory provider API cherry-picked > >>

Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-16 Thread Willem de Bruijn
On Tue, Aug 15, 2023 at 9:38 AM David Laight wrote: > > From: Mina Almasry > > Sent: 10 August 2023 02:58 > ... > > * TL;DR: > > > > Device memory TCP (devmem TCP) is a proposal for transferring data to and/or > > from device memory efficiently, without bouncing the data to a host memory > >

RE: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-15 Thread David Laight
From: Mina Almasry > Sent: 10 August 2023 02:58 ... > * TL;DR: > > Device memory TCP (devmem TCP) is a proposal for transferring data to and/or > from device memory efficiently, without bouncing the data to a host memory > buffer. Doesn't that really require peer-to-peer PCIe transfers? IIRC

Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-13 Thread Mina Almasry
On Sun, Aug 13, 2023 at 6:12 PM David Ahern wrote: > > On 8/9/23 7:57 PM, Mina Almasry wrote: > > Changes in RFC v2: > > -- > > > > The sticking point in RFC v1[1] was the dma-buf pages approach we used to > > deliver the device memory to the TCP stack. RFC v2 is a

Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-13 Thread David Ahern
On 8/9/23 7:57 PM, Mina Almasry wrote: > Changes in RFC v2: > -- > > The sticking point in RFC v1[1] was the dma-buf pages approach we used to > deliver the device memory to the TCP stack. RFC v2 is a proof-of-concept > that attempts to resolve this by implementing scatterlist

Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-11 Thread Christian König
Am 10.08.23 um 20:44 schrieb Mina Almasry: On Thu, Aug 10, 2023 at 3:29 AM Christian König wrote: Am 10.08.23 um 03:57 schrieb Mina Almasry: Changes in RFC v2: -- The sticking point in RFC v1[1] was the dma-buf pages approach we used to deliver the device memory to the TCP

Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-10 Thread Mina Almasry
On Thu, Aug 10, 2023 at 11:58 AM Jason Gunthorpe wrote: > > On Thu, Aug 10, 2023 at 11:44:53AM -0700, Mina Almasry wrote: > > > Someone will correct me if I'm wrong but I'm not sure netlink itself > > will do (sufficient) access control. However I meant for the netlink > > API to bind dma-bufs to

Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-10 Thread Jason Gunthorpe
On Thu, Aug 10, 2023 at 11:44:53AM -0700, Mina Almasry wrote: > Someone will correct me if I'm wrong but I'm not sure netlink itself > will do (sufficient) access control. However I meant for the netlink > API to bind dma-bufs to be a CAP_NET_ADMIN API, and I forgot to add > this check in this

Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-10 Thread Mina Almasry
On Thu, Aug 10, 2023 at 3:29 AM Christian König wrote: > > Am 10.08.23 um 03:57 schrieb Mina Almasry: > > Changes in RFC v2: > > -- > > > > The sticking point in RFC v1[1] was the dma-buf pages approach we used to > > deliver the device memory to the TCP stack. RFC v2 is a

Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-10 Thread Jason Gunthorpe
On Thu, Aug 10, 2023 at 12:29:08PM +0200, Christian König wrote: > Am 10.08.23 um 03:57 schrieb Mina Almasry: > > Changes in RFC v2: > > -- > > > > The sticking point in RFC v1[1] was the dma-buf pages approach we used to > > deliver the device memory to the TCP stack. RFC v2 is a

Re: [RFC PATCH v2 00/11] Device Memory TCP

2023-08-10 Thread Christian König
Am 10.08.23 um 03:57 schrieb Mina Almasry: Changes in RFC v2: -- The sticking point in RFC v1[1] was the dma-buf pages approach we used to deliver the device memory to the TCP stack. RFC v2 is a proof-of-concept that attempts to resolve this by implementing scatterlist support

[RFC PATCH v2 00/11] Device Memory TCP

2023-08-09 Thread Mina Almasry
Changes in RFC v2: -- The sticking point in RFC v1[1] was the dma-buf pages approach we used to deliver the device memory to the TCP stack. RFC v2 is a proof-of-concept that attempts to resolve this by implementing scatterlist support in the networking stack, such that we can