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 trie
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.
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 this code path. Basicall
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 | NAPIF_STATE_
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 subject to the race for NIC using some kind of edge trigger
> > > i
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 interru
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 provided by the NIC, and my probe was added
> in tc
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 = READ_ONCE(n->state);
> > +
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, the
> following can happen.
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 handler can grab
>> it.
>>
>> Problem is that if an
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 confident it was not
a sende
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, &napi->state);
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
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 NAPI_STATE_SCHED bit
> while IRQ
14 matches
Mail list logo
