On Sat, 3 Dec 2016 11:48:22 -0800
John Fastabend wrote:
> On 16-12-03 08:19 AM, Willem de Bruijn wrote:
> > On Fri, Dec 2, 2016 at 12:22 PM, Jesper Dangaard Brouer
> > wrote:
> >>
> >> On Thu, 1 Dec 2016 10:11:08 +0100 Florian Westphal
On 16-12-03 08:19 AM, Willem de Bruijn wrote:
> On Fri, Dec 2, 2016 at 12:22 PM, Jesper Dangaard Brouer
> wrote:
>>
>> On Thu, 1 Dec 2016 10:11:08 +0100 Florian Westphal wrote:
>>
>>> In light of DPDKs existence it make a lot more sense to me to provide
>>> a).
On Fri, Dec 2, 2016 at 12:22 PM, Jesper Dangaard Brouer
wrote:
>
> On Thu, 1 Dec 2016 10:11:08 +0100 Florian Westphal wrote:
>
>> In light of DPDKs existence it make a lot more sense to me to provide
>> a). a faster mmap based interface (possibly AF_PACKET
On Fri, Dec 2, 2016 at 11:56 AM, Stephen Hemminger
wrote:
> On Fri, 2 Dec 2016 19:12:00 +0100
> Hannes Frederic Sowa wrote:
>
>> On 02.12.2016 17:59, Tom Herbert wrote:
>> > On Fri, Dec 2, 2016 at 3:54 AM, Hannes Frederic Sowa
>> >
On Fri, 2 Dec 2016 19:12:00 +0100
Hannes Frederic Sowa wrote:
> On 02.12.2016 17:59, Tom Herbert wrote:
> > On Fri, Dec 2, 2016 at 3:54 AM, Hannes Frederic Sowa
> > wrote:
> >> On 02.12.2016 11:24, Jesper Dangaard Brouer wrote:
> >>>
On 02.12.2016 17:59, Tom Herbert wrote:
> On Fri, Dec 2, 2016 at 3:54 AM, Hannes Frederic Sowa
> wrote:
>> On 02.12.2016 11:24, Jesper Dangaard Brouer wrote:
>>> On Thu, 1 Dec 2016 13:51:32 -0800
>>> Tom Herbert wrote:
>>>
>> The technical
On Thu, 1 Dec 2016 10:11:08 +0100 Florian Westphal wrote:
> In light of DPDKs existence it make a lot more sense to me to provide
> a). a faster mmap based interface (possibly AF_PACKET based) that allows
> to map nic directly into userspace, detaching tx/rx queue from kernel.
>
On Fri, Dec 2, 2016 at 3:54 AM, Hannes Frederic Sowa
wrote:
> On 02.12.2016 11:24, Jesper Dangaard Brouer wrote:
>> On Thu, 1 Dec 2016 13:51:32 -0800
>> Tom Herbert wrote:
>>
> The technical plenary at last IETF on Seoul a couple of weeks ago
On 02.12.2016 11:24, Jesper Dangaard Brouer wrote:
> On Thu, 1 Dec 2016 13:51:32 -0800
> Tom Herbert wrote:
>
The technical plenary at last IETF on Seoul a couple of weeks ago was
exclusively focussed on DDOS in light of the recent attack against
Dyn. There
On Thu, 1 Dec 2016 13:51:32 -0800
Tom Herbert wrote:
> >> The technical plenary at last IETF on Seoul a couple of weeks ago was
> >> exclusively focussed on DDOS in light of the recent attack against
> >> Dyn. There were speakers form Cloudflare and Dyn. The Cloudflare
> >>
On Thu, Dec 1, 2016 at 1:27 PM, Hannes Frederic Sowa
wrote:
> On 01.12.2016 22:12, Tom Herbert wrote:
>> On Thu, Dec 1, 2016 at 12:44 PM, Hannes Frederic Sowa
>> wrote:
>>> Hello,
>>>
>>> this is a good conversation and I simply want to
On 01.12.2016 22:12, Tom Herbert wrote:
> On Thu, Dec 1, 2016 at 12:44 PM, Hannes Frederic Sowa
> wrote:
>> Hello,
>>
>> this is a good conversation and I simply want to bring my worries
>> across. I don't have good solutions for the problems XDP tries to solve
>> but
On Thu, Dec 1, 2016 at 12:44 PM, Hannes Frederic Sowa
wrote:
> Hello,
>
> this is a good conversation and I simply want to bring my worries
> across. I don't have good solutions for the problems XDP tries to solve
> but I fear we could get caught up in maintenance
Hello,
this is a good conversation and I simply want to bring my worries
across. I don't have good solutions for the problems XDP tries to solve
but I fear we could get caught up in maintenance problems in the long
term given the ideas floating around on how to evolve XDP currently.
On
On Thu, Dec 1, 2016 at 10:01 AM, Tom Herbert wrote:
>
>
> On Thu, Dec 1, 2016 at 1:11 AM, Florian Westphal wrote:
>>
>> [ As already mentioned in my reply to Tom, here is
>> the xdp flamebait/critique ]
>>
>> Lots of XDP related patches started to appear on
On 01.12.2016 17:19, David Miller wrote:
> Saying that ntuple filters can handle the early drop use case doesn't
> take into consideration the nature of the tables (hundreds of
> thousands of "evil" IP addresses), whether hardware can actually
> handle that (it can't), and whether simple IP
David Miller wrote:
> Saying that ntuple filters can handle the early drop use case doesn't
> take into consideration the nature of the tables (hundreds of
> thousands of "evil" IP addresses),
Thats not what I said.
But Ok, message received. I rest my case.
On 12/01/16 at 04:52pm, Hannes Frederic Sowa wrote:
> First of all, this is a rant targeted at XDP and not at eBPF as a whole.
> XDP manipulates packets at free will and thus all security guarantees
> are off as well as in any user space solution.
>
> Secondly user space provides policy, acl,
From: Thomas Graf
Date: Thu, 1 Dec 2016 15:58:34 +0100
> The benefits of XDP for this use case are extremely obvious in combination
> with local applications which need to be protected. ntuple filters won't
> cut it. They are limited and subject to a certain rate at which they
>
Thomas Graf wrote:
> On 12/01/16 at 10:11am, Florian Westphal wrote:
> > Aside from this, XDP, like DPDK, is a kernel bypass.
> > You might say 'Its just stack bypass, not a kernel bypass!'.
> > But what does that mean exactly? That packets can still be passed
> > onward to normal
Hi,
On 01.12.2016 15:58, Thomas Graf wrote:
> On 12/01/16 at 10:11am, Florian Westphal wrote:
>> Aside from this, XDP, like DPDK, is a kernel bypass.
>> You might say 'Its just stack bypass, not a kernel bypass!'.
>> But what does that mean exactly? That packets can still be passed
>> onward to
On 12/01/16 at 10:11am, Florian Westphal wrote:
> Aside from this, XDP, like DPDK, is a kernel bypass.
> You might say 'Its just stack bypass, not a kernel bypass!'.
> But what does that mean exactly? That packets can still be passed
> onward to normal stack?
> Bypass solutions like netmap can
On 01.12.2016 10:11, Florian Westphal wrote:
> [ As already mentioned in my reply to Tom, here is
> the xdp flamebait/critique ]
>
> Lots of XDP related patches started to appear on netdev.
> I'd prefer if it would stop...
I discussed this with Florian and helped with the text. I want to
mention
[ As already mentioned in my reply to Tom, here is
the xdp flamebait/critique ]
Lots of XDP related patches started to appear on netdev.
I'd prefer if it would stop...
To me XDP combines all disadvantages of stack bypass solutions like dpdk
with the disadvantages of kernel programming with a
24 matches
Mail list logo