On Thu, 15 Dec 2016, Jesper Dangaard Brouer wrote:
> > It sounds like Christoph's RDMA approach might be the way to go.
>
> I'm getting more and more fond of Christoph's RDMA approach. I do
> think we will end-up with something close to that approach. I just
> wanted to get review on my idea fir
On Thu, Dec 15, 2016 at 12:28 AM, Jesper Dangaard Brouer
wrote:
> On Wed, 14 Dec 2016 14:45:00 -0800
> Alexander Duyck wrote:
>
>> On Wed, Dec 14, 2016 at 1:29 PM, Jesper Dangaard Brouer
>> wrote:
>> > On Wed, 14 Dec 2016 08:45:08 -0800
>> > Alexander Duyck wrote:
>> >
>> >> I agree. This is a
On Wed, 14 Dec 2016 14:45:00 -0800
Alexander Duyck wrote:
> On Wed, Dec 14, 2016 at 1:29 PM, Jesper Dangaard Brouer
> wrote:
> > On Wed, 14 Dec 2016 08:45:08 -0800
> > Alexander Duyck wrote:
> >
> >> I agree. This is a no-go from the performance perspective as well.
> >> At a minimum you wou
On Wed, Dec 14, 2016 at 1:29 PM, Jesper Dangaard Brouer
wrote:
> On Wed, 14 Dec 2016 08:45:08 -0800
> Alexander Duyck wrote:
>
>> I agree. This is a no-go from the performance perspective as well.
>> At a minimum you would have to be zeroing out the page between uses to
>> avoid leaking data, an
On Wed, 14 Dec 2016 08:45:08 -0800
Alexander Duyck wrote:
> I agree. This is a no-go from the performance perspective as well.
> At a minimum you would have to be zeroing out the page between uses to
> avoid leaking data, and that assumes that the program we are sending
> the pages to is slightl
On Wed, 14 Dec 2016, Hannes Frederic Sowa wrote:
> Wouldn't changing of the pages cause expensive TLB flushes?
Yes so you would only want that feature if its realized at the page
table level for debugging issues.
Once you have memory registered with the hardware device then also the
device could
On Wed, 14 Dec 2016 08:32:10 -0800
John Fastabend wrote:
> On 16-12-14 01:39 AM, Jesper Dangaard Brouer wrote:
> > On Tue, 13 Dec 2016 12:08:21 -0800
> > John Fastabend wrote:
> >
> >> On 16-12-13 11:53 AM, David Miller wrote:
> >>> From: John Fastabend
> >>> Date: Tue, 13 Dec 2016 09:43:5
On 14.12.2016 20:43, Christoph Lameter wrote:
> On Wed, 14 Dec 2016, David Laight wrote:
>
>> If the kernel is doing ANY validation on the frames it must copy the
>> data to memory the application cannot modify before doing the validation.
>> Otherwise the application could change the data afterwa
On Wed, 14 Dec 2016, David Laight wrote:
> If the kernel is doing ANY validation on the frames it must copy the
> data to memory the application cannot modify before doing the validation.
> Otherwise the application could change the data afterwards.
The application is not allowed to change the da
From: Christoph Lameter
> Sent: 14 December 2016 17:00
> On Tue, 13 Dec 2016, Hannes Frederic Sowa wrote:
>
> > > Interesting. So you even imagine sockets registering memory regions
> > > with the NIC. If we had a proper NIC HW filter API across the drivers,
> > > to register the steering rule (
On Wed, Dec 14, 2016 at 8:32 AM, John Fastabend
wrote:
> On 16-12-14 01:39 AM, Jesper Dangaard Brouer wrote:
>> On Tue, 13 Dec 2016 12:08:21 -0800
>> John Fastabend wrote:
>>
>>> On 16-12-13 11:53 AM, David Miller wrote:
From: John Fastabend
Date: Tue, 13 Dec 2016 09:43:59 -0800
>
On Tue, 13 Dec 2016, Hannes Frederic Sowa wrote:
> > Interesting. So you even imagine sockets registering memory regions
> > with the NIC. If we had a proper NIC HW filter API across the drivers,
> > to register the steering rule (like ibv_create_flow), this would be
> > doable, but we don't (DP
On 16-12-14 01:39 AM, Jesper Dangaard Brouer wrote:
> On Tue, 13 Dec 2016 12:08:21 -0800
> John Fastabend wrote:
>
>> On 16-12-13 11:53 AM, David Miller wrote:
>>> From: John Fastabend
>>> Date: Tue, 13 Dec 2016 09:43:59 -0800
>>>
What does "zero-copy send packet-pages to the application
On Tue, 13 Dec 2016 12:08:21 -0800
John Fastabend wrote:
> On 16-12-13 11:53 AM, David Miller wrote:
> > From: John Fastabend
> > Date: Tue, 13 Dec 2016 09:43:59 -0800
> >
> >> What does "zero-copy send packet-pages to the application/socket that
> >> requested this" mean? At the moment on x8
On 16-12-13 11:53 AM, David Miller wrote:
> From: John Fastabend
> Date: Tue, 13 Dec 2016 09:43:59 -0800
>
>> What does "zero-copy send packet-pages to the application/socket that
>> requested this" mean? At the moment on x86 page-flipping appears to be
>> more expensive than memcpy (I can post s
From: John Fastabend
Date: Tue, 13 Dec 2016 09:43:59 -0800
> What does "zero-copy send packet-pages to the application/socket that
> requested this" mean? At the moment on x86 page-flipping appears to be
> more expensive than memcpy (I can post some data shortly) and shared
> memory was proposed
On 13.12.2016 17:10, Jesper Dangaard Brouer wrote:
>> What is bad about RDMA is that it is a separate kernel subsystem.
>> What I would like to see is a deeper integration with the network
>> stack so that memory regions can be registred with a network socket
>> and work requests then can be submit
On 16-12-13 08:10 AM, Jesper Dangaard Brouer wrote:
>
> On Mon, 12 Dec 2016 12:06:59 -0600 (CST) Christoph Lameter
> wrote:
>> On Mon, 12 Dec 2016, Jesper Dangaard Brouer wrote:
>>
>>> Hmmm. If you can rely on hardware setup to give you steering and
>>> dedicated access to the RX rings. In thos
On Tue, 13 Dec 2016, Jesper Dangaard Brouer wrote:
> This is the early demux problem. With the push-mode of registering
> memory, you need hardware steering support, for zero-copy support, as
> the software step happens after DMA engine have written into the memory.
Right. But we could fall back
On Mon, 12 Dec 2016 12:06:59 -0600 (CST) Christoph Lameter
wrote:
> On Mon, 12 Dec 2016, Jesper Dangaard Brouer wrote:
>
> > Hmmm. If you can rely on hardware setup to give you steering and
> > dedicated access to the RX rings. In those cases, I guess, the "push"
> > model could be a more dire
On Mon, Dec 12, 2016 at 06:49:03AM -0800, John Fastabend wrote:
> On 16-12-12 06:14 AM, Mike Rapoport wrote:
> >>
> > We were not considered using XDP yet, so we've decided to limit the initial
> > implementation to macvtap because we can ensure correspondence between a
> > NIC queue and virtual NI
On Mon, Dec 12, 2016 at 04:10:26PM +0100, Jesper Dangaard Brouer wrote:
> On Mon, 12 Dec 2016 16:14:33 +0200
> Mike Rapoport wrote:
> >
> > They are copied :-)
> > Presuming we are dealing only with vhost backend, the received skb
> > eventually gets converted to IOVs, which in turn are copied to
On Mon, 12 Dec 2016, Jesper Dangaard Brouer wrote:
> Hmmm. If you can rely on hardware setup to give you steering and
> dedicated access to the RX rings. In those cases, I guess, the "push"
> model could be a more direct API approach.
If the hardware does not support steering then one should be
On Mon, 12 Dec 2016 06:49:03 -0800
John Fastabend wrote:
> On 16-12-12 06:14 AM, Mike Rapoport wrote:
> > On Mon, Dec 12, 2016 at 10:40:42AM +0100, Jesper Dangaard Brouer wrote:
> >>
> >> On Mon, 12 Dec 2016 10:38:13 +0200 Mike Rapoport
> >> wrote:
> >>
> >>> Hello Jesper,
> >>>
> >>> On Mo
On Mon, 12 Dec 2016 16:14:33 +0200
Mike Rapoport wrote:
> On Mon, Dec 12, 2016 at 10:40:42AM +0100, Jesper Dangaard Brouer wrote:
> >
> > On Mon, 12 Dec 2016 10:38:13 +0200 Mike Rapoport
> > wrote:
> >
> > > Hello Jesper,
> > >
> > > On Mon, Dec 05, 2016 at 03:31:32PM +0100, Jesper Dangaar
On 16-12-12 06:14 AM, Mike Rapoport wrote:
> On Mon, Dec 12, 2016 at 10:40:42AM +0100, Jesper Dangaard Brouer wrote:
>>
>> On Mon, 12 Dec 2016 10:38:13 +0200 Mike Rapoport
>> wrote:
>>
>>> Hello Jesper,
>>>
>>> On Mon, Dec 05, 2016 at 03:31:32PM +0100, Jesper Dangaard Brouer wrote:
Hi all,
>
On Mon, Dec 12, 2016 at 10:40:42AM +0100, Jesper Dangaard Brouer wrote:
>
> On Mon, 12 Dec 2016 10:38:13 +0200 Mike Rapoport
> wrote:
>
> > Hello Jesper,
> >
> > On Mon, Dec 05, 2016 at 03:31:32PM +0100, Jesper Dangaard Brouer wrote:
> > > Hi all,
> > >
> > > This is my design for how to safe
On Mon, 12 Dec 2016 10:38:13 +0200 Mike Rapoport
wrote:
> Hello Jesper,
>
> On Mon, Dec 05, 2016 at 03:31:32PM +0100, Jesper Dangaard Brouer wrote:
> > Hi all,
> >
> > This is my design for how to safely handle RX zero-copy in the network
> > stack, by using page_pool[1] and modifying NIC dri
Hello Jesper,
On Mon, Dec 05, 2016 at 03:31:32PM +0100, Jesper Dangaard Brouer wrote:
> Hi all,
>
> This is my design for how to safely handle RX zero-copy in the network
> stack, by using page_pool[1] and modifying NIC drivers. Safely means
> not leaking kernel info in pages mapped to userspace
Hi all,
This is my design for how to safely handle RX zero-copy in the network
stack, by using page_pool[1] and modifying NIC drivers. Safely means
not leaking kernel info in pages mapped to userspace and resilience
so a malicious userspace app cannot crash the kernel.
It is only a design, and t
30 matches
Mail list logo
