From: David Miller
> Sent: 16 November 2015 20:32
> From: "Jason A. Donenfeld"
> Date: Mon, 16 Nov 2015 20:52:28 +0100
>
> > This works fine with, say, iperf3 in TCP mode. The AVX performance
> > is great. However, when using iperf3 in UDP mode, irq_fpu_usable()
> > is mostly false! I added a
From: David Miller
> Sent: 16 November 2015 20:32
> From: "Jason A. Donenfeld"
> Date: Mon, 16 Nov 2015 20:52:28 +0100
>
> > This works fine with, say, iperf3 in TCP mode. The AVX performance
> > is great. However, when using iperf3 in UDP mode, irq_fpu_usable()
> > is mostly
On Tue, Nov 17, 2015 at 12:57 AM, Jason A. Donenfeld wrote:
> 2. irq_fpu_usable() is FALSE for UDP! Since in_interrupt() is always
> true in ndo_start_xmit, this means that in this case, both
> interrupted_user_mode() and interrupted_kernel_fpu_idle() are false!
> Investigating further, will
Hi Hannes,
Thanks for your response.
On Mon, Nov 16, 2015 at 11:27 PM, Hannes Frederic Sowa
wrote:
> Use the irqsoff tracer to find the problematic functions which disable
> interrupts and try to work around it in case of UDP. This could benefit
> the whole stack.
I didn't know about the
Hi Jason,
On Mon, Nov 16, 2015, at 21:58, Jason A. Donenfeld wrote:
> Hi David,
>
> On Mon, Nov 16, 2015 at 9:32 PM, David Miller
> wrote:
> > Network device driver transmit executes with software interrupts
> > disabled.
> >
> > Therefore on x86, you cannot use the FPU.
>
> That is extremely
On Mon, Nov 16, 2015 at 10:33 PM, David Miller wrote:
> Someone already did a Linux implemenation of exactly that two decades
> ago, we rejected that design and did what we did.
It's not exactly IPSec though, so don't worry. It's a totally new
thing that combines a lot of different recent ideas,
From: "Jason A. Donenfeld"
Date: Mon, 16 Nov 2015 22:28:52 +0100
> I'm making a simpler replacement for IPSec that operates as an
> device driver on the interface level
Someone already did a Linux implemenation of exactly that two decades
ago, we rejected that design and did what we did.
--
To
On Mon, Nov 16, 2015 at 10:17 PM, David Miller wrote:
>
> Not without a complete redesign of the x86 fpu save/restore mechanism.
Urg, okay. I still wonder why irq_fpu_usable() is true when using TCP but not
when using UDP... Any ideas on this?
> The driver is the wrong place to do software
From: "Jason A. Donenfeld"
Date: Mon, 16 Nov 2015 21:58:49 +0100
> That is extremely problematic for me. Is there a way to make this
> not so?
Not without a complete redesign of the x86 fpu save/restore mechanism.
The driver is the wrong place to do software cryptographic transforms
anyways.
Hi David,
On Mon, Nov 16, 2015 at 9:32 PM, David Miller wrote:
> Network device driver transmit executes with software interrupts
> disabled.
>
> Therefore on x86, you cannot use the FPU.
That is extremely problematic for me. Is there a way to make this not
so? A driver flag that would allow
From: "Jason A. Donenfeld"
Date: Mon, 16 Nov 2015 20:52:28 +0100
> This works fine with, say, iperf3 in TCP mode. The AVX performance
> is great. However, when using iperf3 in UDP mode, irq_fpu_usable()
> is mostly false! I added a dump_stack() call to see why, except
> nothing looks strange;
From: "Jason A. Donenfeld"
Date: Mon, 16 Nov 2015 20:52:28 +0100
> This works fine with, say, iperf3 in TCP mode. The AVX performance
> is great. However, when using iperf3 in UDP mode, irq_fpu_usable()
> is mostly false! I added a dump_stack() call to see why, except
> nothing
On Mon, Nov 16, 2015 at 10:17 PM, David Miller wrote:
>
> Not without a complete redesign of the x86 fpu save/restore mechanism.
Urg, okay. I still wonder why irq_fpu_usable() is true when using TCP but not
when using UDP... Any ideas on this?
> The driver is the wrong
On Mon, Nov 16, 2015 at 10:33 PM, David Miller wrote:
> Someone already did a Linux implemenation of exactly that two decades
> ago, we rejected that design and did what we did.
It's not exactly IPSec though, so don't worry. It's a totally new
thing that combines a lot of
Hi Jason,
On Mon, Nov 16, 2015, at 21:58, Jason A. Donenfeld wrote:
> Hi David,
>
> On Mon, Nov 16, 2015 at 9:32 PM, David Miller
> wrote:
> > Network device driver transmit executes with software interrupts
> > disabled.
> >
> > Therefore on x86, you cannot use the FPU.
>
From: "Jason A. Donenfeld"
Date: Mon, 16 Nov 2015 22:28:52 +0100
> I'm making a simpler replacement for IPSec that operates as an
> device driver on the interface level
Someone already did a Linux implemenation of exactly that two decades
ago, we rejected that design and did
From: "Jason A. Donenfeld"
Date: Mon, 16 Nov 2015 21:58:49 +0100
> That is extremely problematic for me. Is there a way to make this
> not so?
Not without a complete redesign of the x86 fpu save/restore mechanism.
The driver is the wrong place to do software cryptographic
Hi David,
On Mon, Nov 16, 2015 at 9:32 PM, David Miller wrote:
> Network device driver transmit executes with software interrupts
> disabled.
>
> Therefore on x86, you cannot use the FPU.
That is extremely problematic for me. Is there a way to make this not
so? A driver
On Tue, Nov 17, 2015 at 12:57 AM, Jason A. Donenfeld wrote:
> 2. irq_fpu_usable() is FALSE for UDP! Since in_interrupt() is always
> true in ndo_start_xmit, this means that in this case, both
> interrupted_user_mode() and interrupted_kernel_fpu_idle() are false!
> Investigating
Hi Hannes,
Thanks for your response.
On Mon, Nov 16, 2015 at 11:27 PM, Hannes Frederic Sowa
wrote:
> Use the irqsoff tracer to find the problematic functions which disable
> interrupts and try to work around it in case of UDP. This could benefit
> the whole stack.
I
20 matches
Mail list logo