netdev - bonding netdev events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0804241727070.15579@zuben.voltaire.com>
Date:	Thu, 24 Apr 2008 18:07:10 +0300 (IDT)
From:	Or Gerlitz <ogerlitz@...taire.com>
To:	Jay Vosburgh <fubar@...ibm.com>
cc:	Sean Hefty <sean.hefty@...el.com>, netdev@...r.kernel.org
Subject: bonding netdev events

Hi Jay,

I'd like to hear your opinion on adding bonding related netdev events to be delivered
through the netdevice notifier chain mechanism of include/linux/notifier.h

The need I am dealing with arises from a situation where bonding under active-backup
mode does a "fail-back" to the primary slave device and this should be noted by an
entity outside the bonding driver.

The context is high-availability for drivers such as rNFS and iSER which use the rdma
communication manager (rdma_cm, include/rdma/{ib_addr.h, rdma_cm.h}. The address resolution
service of the rdma cm is based on IP semantics and uses ARP and the device associated with the
resulted neighbour to resolve the RDMA devices/addresses (eg IB GIDs) to use for the connection.
When this is combined with bonding (eg bond0 enslaves ib0 and ib1), the rdma connection is
established through the device associated with the active slave. When some failure occurs, bonding
does fail-over and in parallel the hw rdma connection gets broken. So when the app attempts to
reconnect the rdma cm address resolution (ARP) goes through the new slave and we are done.

Under some occasions the primary option (explained in Documentation/networking/bonding.txt
for those who are not familiar with it) should be applied also to rdma connections. That is, if
possible, the user want the connection to be established over a primary link, meaning that if bonding
does "fail back" to the primary slave, same should go for the rdma connection. Currently, bonding
does this failback, but since the "secondary" link is perfectly fine the rdma connection stays on it.

A quite simple way I was thinking off, is have the rdma cm register to get netdev events, and
have bonding announce the failback through event, say it delivers NETDEV_BONDING_FAILBACK_PRIMARY
where the rdma cm can now act on it.

Or
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html