|
Hi Stefan,
Sorry for delay :/ too much meeting...
>nice to hear that my patch makes sense to more than just me, especially
>as I already started to have a look at VRRPd to add support for
>operative state detection. But I'd be quite happy with just downloading
>a version that has the new functionality as soon as you've finished ;-)
yes :) ... Currently have done the MII regs BMSR probe embended into a
thread that reflect informations from kernel to userspace. So I have an
interface monitoring thread that is sync with kernel info (IFF_UP|DOWN,
IFF_RUNNING, MII_BMSR&0x0004)
I have favorized netlink fetch for IFF_UP|DOWN|RUNNING because I think in
the future it is the right place for fetching those information <=> It
would be nice if IFF_RUNNING would take care of NIC status (remote fault,
jabber detect, link established, ...)
Right now I will review the VRRP data structure to be more generic and
clean :) pointing to the global interface monitoring structure.
>For VRRP polling the interface seems to be an acceptable solution as the
>daemon has to wake up once every second anyway. Whenever you query the
>interface state in 2.2, either via ioctl(SIOCGIFFLAGS, ...) or netlink
>socket, the original IFF_RUNNING flag is returned. So for drivers that
>support it, an operative state is available by polling - BUT: Playing
>with dev->flags without proper locking invites race conditions, and this
>is what drivers in 2.2 do.
I agree, for polling, this is my current devel design. Currently daemon
fetch flags from netlink (i_flags).
>>From the user mode view, it's the same in 2.4. Different to 2.2,
>
>IFF_RUNNING in the kernel dev->flags is meaningless and replaced
>by a bit in dev->state that can be handled atomically. This bit is sent
>as IFF_RUNNING to user mode and works for drivers that support it.
>Actually, most drivers ignore the operative state, and some ported from
>2.2 still fiddle with IFF_RUNNING in the kernel structure - obviously
>quite useless in 2.4.
>
>Now what my patch does is sending netlink messages whenever the
>NO_CARRIER bit in dev->state changes und reusing the in kernel
>IFF_RUNNING flag to keep the state when the interface was queried last
>time by the thread. It should not interfere with any process querying
>the interface from user mode, but it may interact with drivers that
>change IFF_RUNNING directly. Anyway, it's those drivers that I consider
>broken ;-)
I have first tested directly with netlink monitoring netlink link carrier
counter. But maintening coherence on a counter value is not scalable.
Direct driver polling for media stats is more robust IMHO.
>On the long run, I hope that more drivers start supporting that
>functionality now as the interface is available and software starts
>using it.
Agreed :)
>For VRRPd, IMHO the best solution would be that the behaviour can be
>selected between no state detection and the two alternatives (IFF_UP &
>IFF_RUNNING) or MII registers values that you've already mentioned in
>another mail. That's the best we can have now - even though it will mean
>"no state detection" for most cards.
Yes, I have started with the design :
1. During VRRP framework bootstrap : initialize interface structure
(ifindex, mac, flags, setted, ...)
2. Register a monitoring thread (HB thread) polling every secs informations
from kernel/drivers to maintains coherence.
3. The monitoring thread fetch flags from netlink IFF_UP & IFF_RUNNING and
if possible probe BMSR from MII regs.
4. This interface structure (a reflection structure from kernel) is then
used from all the keepalived framework (VRRP & Healthcheck) => VRRP: For
state transition to FAULT_STATE & Healthcheck: performing checks if IP
address is registered on the director.
I hope I will finish this quick :) can not give currently a fixed release
date :/
Best regards & thanks for your inputs,
Alexandre
|
