From: Robert Olsson <[EMAIL PROTECTED]>
Date: Thu, 20 Dec 2007 10:52:17 +0100
> Yes but the reason was not to wait for all pending polls to
> complete so a server/router could be rebooted even under high-
> load and DOS. We've experienced some nasty problems with this.
I know, see the rest of
David Miller writes:
> > Is the netif_running() check even required?
>
> No, it is not.
>
> When a device is brought down, one of the first things
> that happens is that we wait for all pending NAPI polls
> to complete, then block any new polls from starting.
Hello!
Yes but the reaso
2007/12/13, Andrew Gallatin <[EMAIL PROTECTED]>:
>
> If the netif_running() check is indeed required to make a device break
> out of napi polling and respond to an ifconfig down, then I think the
> netif_running() check should be moved up into net_rx_action() to avoid
> potential for driver complex
David Miller wrote, On 12/13/2007 11:34 PM:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 23:28:41 +0100
>
>> ...I'm afraid I can't understand: I mean doing the same but without
>> passing this info with 'work == weight': if driver sends this info,
>> why it can't instead c
From: Jarek Poplawski <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 23:28:41 +0100
> ...I'm afraid I can't understand: I mean doing the same but without
> passing this info with 'work == weight': if driver sends this info,
> why it can't instead call something like napi_continue() with
> this list_mo
David Miller wrote, On 12/13/2007 09:37 PM:
...
> For example, if we export the list handling widget into the ->poll()
> routines, god help the person who wants to change how the poll list is
> managed in net_rx_action() :-/
...I'm afraid I can't understand: I mean doing the same but without
pass
Stephen Hemminger wrote, On 12/13/2007 09:41 PM:
> David Miller wrote:
>> From: Jarek Poplawski <[EMAIL PROTECTED]>
>> Date: Thu, 13 Dec 2007 21:16:12 +0100
>>
>>
>>> I see in a nearby thread you would prefer to save some work to drivers
>>> (like this netif_running() check), but I think this a
David Miller wrote:
From: Jarek Poplawski <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 21:16:12 +0100
I see in a nearby thread you would prefer to save some work to drivers
(like this netif_running() check), but I think this all is at the cost
of flexibility, and there will probably appear new
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 11:35:07 -0800
> How about allowing a return value of -1 from napi_poll and letting
> device check itself.
It doesn't avoid the code duplication in the ->poll() fast paths.
I don't care, on the other hand, if crap accumulates in
From: Jarek Poplawski <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 21:16:12 +0100
> I see in a nearby thread you would prefer to save some work to drivers
> (like this netif_running() check), but I think this all is at the cost
> of flexibility, and there will probably appear new problems, when a
>
David Miller wrote, On 12/13/2007 02:50 PM:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 14:49:53 +0100
>
>> As a matter of fact, since it's "unlikely()" in net_rx_action() anyway,
>> I wonder what is the main reason or gain of leaving such a tricky
>> exception, instead o
David Miller wrote:
From: Andrew Gallatin <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 14:02:25 -0500
Or perhaps we should just leave things as is.
We should probably add a "disabling" state bit to the
napi struct flags, this will be set by napi_disable()
before it loops trying to set t
Stephen Hemminger wrote:
On Thu, 13 Dec 2007 06:19:38 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
From: Andrew Gallatin <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 09:13:54 -0500
If the netif_running() check is indeed required to make a device break
out of napi polling and respond to a
From: Andrew Gallatin <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 14:02:25 -0500
> Or perhaps we should just leave things as is.
We should probably add a "disabling" state bit to the
napi struct flags, this will be set by napi_disable()
before it loops trying to set the sched bit.
net_rx_action()
On Thu, 13 Dec 2007 06:19:38 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Gallatin <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 09:13:54 -0500
>
> > If the netif_running() check is indeed required to make a device break
> > out of napi polling and respond to an ifconfig down
David Miller wrote:
> From: Andrew Gallatin <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 09:13:54 -0500
>
>> If the netif_running() check is indeed required to make a device break
>> out of napi polling and respond to an ifconfig down, then I think the
>> netif_running() check should be moved up i
From: Andrew Gallatin <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 09:13:54 -0500
> If the netif_running() check is indeed required to make a device break
> out of napi polling and respond to an ifconfig down, then I think the
> netif_running() check should be moved up into net_rx_action() to avoid
Joonwoo Park wrote:
> 2007/12/13, Kok, Auke <[EMAIL PROTECTED]>:
>> David Miller wrote:
>>> From: Andrew Gallatin <[EMAIL PROTECTED]>
>>> Date: Wed, 12 Dec 2007 12:29:23 -0500
>>>
Is the netif_running() check even required?
>>> No, it is not.
>>>
>>> When a device is brought down, one of the
On Thu, Dec 13, 2007 at 05:50:13AM -0800, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 14:49:53 +0100
>
> > As a matter of fact, since it's "unlikely()" in net_rx_action() anyway,
> > I wonder what is the main reason or gain of leaving such a tricky
> >
From: Jarek Poplawski <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 14:49:53 +0100
> As a matter of fact, since it's "unlikely()" in net_rx_action() anyway,
> I wonder what is the main reason or gain of leaving such a tricky
> exception, instead of letting drivers to always decide which is the
> best
On 12-12-2007 19:41, Kok, Auke wrote:
> David Miller wrote:
>> From: Andrew Gallatin <[EMAIL PROTECTED]>
>> Date: Wed, 12 Dec 2007 12:29:23 -0500
>>
>>> Is the netif_running() check even required?
>> No, it is not.
>>
>> When a device is brought down, one of the first things
>> that happens is that
2007/12/13, Kok, Auke <[EMAIL PROTECTED]>:
> David Miller wrote:
> > From: Andrew Gallatin <[EMAIL PROTECTED]>
> > Date: Wed, 12 Dec 2007 12:29:23 -0500
> >
> >> Is the netif_running() check even required?
> >
> > No, it is not.
> >
> > When a device is brought down, one of the first things
> > tha
David Miller wrote:
> From: Andrew Gallatin <[EMAIL PROTECTED]>
> Date: Wed, 12 Dec 2007 12:29:23 -0500
>
>> Is the netif_running() check even required?
>
> No, it is not.
>
> When a device is brought down, one of the first things
> that happens is that we wait for all pending NAPI polls
> to co
David Miller wrote:
From: Andrew Gallatin <[EMAIL PROTECTED]>
Date: Wed, 12 Dec 2007 12:29:23 -0500
Is the netif_running() check even required?
No, it is not.
When a device is brought down, one of the first things
that happens is that we wait for all pending NAPI polls
to complete, then bloc
From: Andrew Gallatin <[EMAIL PROTECTED]>
Date: Wed, 12 Dec 2007 12:29:23 -0500
> Is the netif_running() check even required?
No, it is not.
When a device is brought down, one of the first things
that happens is that we wait for all pending NAPI polls
to complete, then block any new polls from s
[I apologize for loosing threading, I'm replying from the archives]
> The problem is that the driver is doing a NAPI completion and
> re-enabling chip interrupts with work_done == weight, and that is
> illegal.
The only time at least myri10ge will do this is due to
the !netif_running(netdev) che
From: "Joonwoo Park" <[EMAIL PROTECTED]>
Date: Wed, 12 Dec 2007 15:05:26 +0900
> Could you explain how it fix the problem?
> IMHO I think your patch cannot solve the problem.
> The drivers can call netif_rx_complete and net_rx_action can do
> list_move_tail also.
Stephen is confused about what th
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 11 Dec 2007 21:46:34 -0800
> Isn't this a better fix for all drivers, rather than peppering every
> driver with the special case. This is how the logic worked up until
> 2.6.24.
Stephen this is not the problem.
The problem is that the driver
2007/12/12, Stephen Hemminger <[EMAIL PROTECTED]>:
> Isn't this a better fix for all drivers, rather than peppering every
> driver with the special case. This is how the logic worked up until
> 2.6.24.
>
>
> --- a/net/core/dev.c2007-12-11 12:16:20.0 -0800
> +++ b/net/core/dev.c2007-
29 matches
Mail list logo
