Network driver behaviour when loosing link

Network driver behaviour when loosing link

[Michael Renzmann]

Hi all.

I'm playing with a network driver and came across one thing I'd like to 
ask something about.

Let's assume a driver detects a link status change (for example, the 
link is dropped). I would have expected that the driver should signal 
the change via netif_carrier_on/_off (if used at all) and tell the 
kernel to stop/resume sending packets to the driver (via 
netif_wake_queue/netif_stop_queue).

When checking several drivers I found some that call 
netif_[wake|stop]_queue (e100, e1000), while others don't (natsemi, tg3).

Hence the question: what is the recommended behaviour in such a case? Is 
it ok to call netif_[stop|wake]_queue? How about adjusting the 
IFF_RUNNING flag accordingly? Is there any documentation available on 
this topic?

Thanks in advance.

Bye, Mike

Re: Network driver behaviour when loosing link

[Tommy Christensen]

Michael Renzmann wrote:
> Hi all.
> 
> I'm playing with a network driver and came across one thing I'd like to 
> ask something about.
> 
> Let's assume a driver detects a link status change (for example, the 
> link is dropped). I would have expected that the driver should signal 
> the change via netif_carrier_on/_off (if used at all) and tell the 
> kernel to stop/resume sending packets to the driver (via 
> netif_wake_queue/netif_stop_queue).
> 
> When checking several drivers I found some that call 
> netif_[wake|stop]_queue (e100, e1000), while others don't (natsemi, tg3).
> 
> Hence the question: what is the recommended behaviour in such a case? Is 

netif_carrier_on/off should certainly be used.

The use of netif_stop_queue depends on your HW:

  A) If your NIC continues taking packets from the ring buffer while link
     is down, then just let it do so.  No need to call netif_stop_queue.
     Since recently, the stack will seize sending packets to your driver
     anyway.  NB: this doesn't happen instantly, but typically within 1 sec.
     after calling netif_carrier_off.

  B) If your NIC stops DMA'ing packets when link is down, you have two
     options:
     1) Check netif_carrier_ok in your hard_start_xmit function.
     2) Call netif_stop_queue when link is lost.
     In both cases you have to flush the NIC's TX ring buffer, in order not
     to hold up resources (and not to send out stale packets when link is
     restored).

> it ok to call netif_[stop|wake]_queue? How about adjusting the 

The queue state is assumed stable when holding dev->xmit_lock, so you can
only call netif_stop_queue/wake_queue when this lock is held.  However,
this requirement doesn't seem do be followed everywhere.  And then there
is the LLTX drivers...

> IFF_RUNNING flag accordingly? Is there any documentation available on 
> this topic?

Drivers shouldn't touch IFF_RUNNING.  It is maintained by the stack.

Documentation?  I haven't really seen any myself, except for the usual:
source code, and mailing-list discussions.  Any pointers are welcome'd.

-Tommy