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
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. M
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 s
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
> >> lo
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
> > buffe
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 thes
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 proof-of-concept
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 supp
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 sta
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
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 pro
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 proof-of
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
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 in
14 matches
Mail list logo
