netdev
[Top] [All Lists]

Re: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis

To: Bogdan Costescu <bogdan.costescu@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis
From: jamal <hadi@xxxxxxxxxx>
Date: Fri, 1 Jun 2001 10:14:08 -0400 (EDT)
Cc: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>, Pete Zaitcev <zaitcev@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, <netdev@xxxxxxxxxxx>
In-reply-to: <Pine.LNX.4.33.0106011521440.18082-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Jeff, Thanks for copying netdev. Wish more people would do that.

On Fri, 1 Jun 2001, Bogdan Costescu wrote:

> On Fri, 1 Jun 2001, Jeff Garzik wrote:
>
> > The loss and regain of link status should be proactively signalled to
> > userspace using netlink or something similar.
>
> [ For the general discussion ]
> I fully agree, but I just wanted to give an example of legit use from
> user space of _current_ values from hardware.
>
> >  Currently we have
> > netif_carrier_{on,off,ok} but it is only passively checked.
> > netif_carrier_{on,off} should probably schedule_task() to fire off a
> > netlink message...
>
> [ Link status details ]
> Just that not all NICs have hardware support (and/or not all drivers use
> these facilities) for link status change notification using interrupts.
> Right now, most drivers _poll_ for media status and based on the poll
> rate, netif_carrier routines are (or should be) called. We can't make the
> poll rate very small for the general case, as MII access is time
> consuming (same discussion was some months ago when the bonding driver
> was updated). However, for users who know that they need this info to be
> more accurate (at the expense of CPU time), polling through ioctl's is the
> only solution.

Not really.

One idea i have been toying with is to maintain hysteris or threshold of
some form in dev_watchdog;
example: if watchdog timer expires threshold times, you declare the link
dead and send netif_carrier_off netlink message.
On recovery, you send  netif_carrier_on

Assumption:
If the tx path is blocked, more than likely the link is down.

cheers,
jamal


<Prev in Thread] Current Thread [Next in Thread>