RE: [PATCH v2 net] net: solve a NAPI race

2017-03-02 Thread David Laight
From: Eric Dumazet > Sent: 01 March 2017 17:33 > On Wed, 2017-03-01 at 08:14 -0800, Alexander Duyck wrote: > > > What build flags are you using? With -Os or -O2 I have seen it > > convert the /b * c into a single shift. > > > > > Because b & c are unsigned in our case. > > I presume David

Re: [PATCH v2 net] net: solve a NAPI race

2017-03-01 Thread Eric Dumazet
On Wed, 2017-03-01 at 08:14 -0800, Alexander Duyck wrote: > What build flags are you using? With -Os or -O2 I have seen it > convert the /b * c into a single shift. > Because b & c are unsigned in our case. I presume David tried signed integers, this is why gcc does that.

Re: [PATCH v2 net] net: solve a NAPI race

2017-03-01 Thread Alexander Duyck
On Wed, Mar 1, 2017 at 2:41 AM, David Laight wrote: > From: Alexander Duyck >> Sent: 28 February 2017 17:20 > ... >> You might want to consider just using a combination AND, divide, >> multiply, and OR to avoid having to have any conditional branches >> being added due to

RE: [PATCH v2 net] net: solve a NAPI race

2017-03-01 Thread David Laight
From: Alexander Duyck > Sent: 28 February 2017 17:20 ... > You might want to consider just using a combination AND, divide, > multiply, and OR to avoid having to have any conditional branches > being added due to this code path. Basically the logic would look > like: > new = val |

Re: [PATCH v2 net] net: solve a NAPI race

2017-02-28 Thread Stephen Hemminger
On Wed, 1 Mar 2017 01:22:40 +0100 Francois Romieu wrote: > David Miller : > > From: Eric Dumazet > > Date: Mon, 27 Feb 2017 08:44:14 -0800 > > > > > Any point doing a napi_schedule() not from device hard irq handler > > > is

Re: [PATCH v2 net] net: solve a NAPI race

2017-02-28 Thread Francois Romieu
David Miller : > From: Eric Dumazet > Date: Mon, 27 Feb 2017 08:44:14 -0800 > > > Any point doing a napi_schedule() not from device hard irq handler > > is subject to the race for NIC using some kind of edge trigger > > interrupts. > > > > Since we

Re: [PATCH v2 net] net: solve a NAPI race

2017-02-28 Thread Alexander Duyck
On Mon, Feb 27, 2017 at 6:21 AM, Eric Dumazet wrote: > From: Eric Dumazet > > While playing with mlx4 hardware timestamping of RX packets, I found > that some packets were received by TCP stack with a ~200 ms delay... > > Since the timestamp was

Re: [PATCH v2 net] net: solve a NAPI race

2017-02-28 Thread Eric Dumazet
On Tue, 2017-02-28 at 09:20 -0800, Alexander Duyck wrote: > On Mon, Feb 27, 2017 at 6:21 AM, Eric Dumazet wrote: > > +bool napi_schedule_prep(struct napi_struct *n) > > +{ > > + unsigned long val, new; > > + > > + do { > > + val =

Re: [PATCH v2 net] net: solve a NAPI race

2017-02-27 Thread David Miller
From: Eric Dumazet Date: Mon, 27 Feb 2017 08:44:14 -0800 > Any point doing a napi_schedule() not from device hard irq handler > is subject to the race for NIC using some kind of edge trigger > interrupts. > > Since we do not provide a ndo to disable device interrupts,

Re: [PATCH v2 net] net: solve a NAPI race

2017-02-27 Thread Alexander Duyck
On Mon, Feb 27, 2017 at 8:19 AM, David Miller wrote: > From: Eric Dumazet > Date: Mon, 27 Feb 2017 06:21:38 -0800 > >> A NAPI driver normally arms the IRQ after the napi_complete_done(), >> after NAPI_STATE_SCHED is cleared, so that the hard irq

[PATCH v2 net] net: solve a NAPI race

2017-02-27 Thread Eric Dumazet
From: Eric Dumazet While playing with mlx4 hardware timestamping of RX packets, I found that some packets were received by TCP stack with a ~200 ms delay... Since the timestamp was provided by the NIC, and my probe was added in tcp_v4_rcv() while in BH handler, I was

Re: [PATCH v2 net] net: solve a NAPI race

2017-02-27 Thread Eric Dumazet
On Mon, 2017-02-27 at 08:44 -0800, Eric Dumazet wrote: > // busy polling or napi_watchdog() BTW, we also can add to the beginning of busy_poll_stop() : clear_bit(NAPI_STATE_MISSED, >state);

Re: [PATCH v2 net] net: solve a NAPI race

2017-02-27 Thread Eric Dumazet
On Mon, 2017-02-27 at 11:19 -0500, David Miller wrote: > Various rules were meant to protect these sequences, and make sure > nothing like this race could happen. > > Can you show the specific sequence that fails? > > One of the basic protections is that the device IRQ is not re-enabled > until

Re: [PATCH v2 net] net: solve a NAPI race

2017-02-27 Thread David Miller
From: Eric Dumazet Date: Mon, 27 Feb 2017 06:21:38 -0800 > A NAPI driver normally arms the IRQ after the napi_complete_done(), > after NAPI_STATE_SCHED is cleared, so that the hard irq handler can grab > it. > > Problem is that if another point in the stack grabs