This commit creates a new heartbeat mode for LACP. This mode
treats LACP as a protocol simply for monitoring link status. It
strips out most of the sanity checks built into the protocol.
Addition of this mode makes "lacp-force-aggregatable" and
"lacp-strict" options obsolete so they are removed.
Users will the ability to manually set aggregation keys on a
per-slave basis in order to use some of the more advanced LACP
features. Most notably, LACP controlled active-backup bonding
requires fine grained aggregation key configuration.
In some extremely advanced situations, one may want to force
non-bondable slaves to advertise themselves as bondable. This
patch adds that capability.
Also includes some minor code cleanup.
The receive rate for a LACP packets is simply 3 times the
transmission rate. It doesn't make sense to maintain separate
macros for these values especially since future patches will allow
arbitrary transmission rates.
When LACP negotiations are unsuccessful, OVS falls back to standard
balance-slb bonding. In some cases, users may want to require
successful LACP negotiations for any slaves to be enabled at all.
This patch implements a new "strict" mode which disables all slaves
when LACP negotiations are unsuccessful.
The enabled flag in the LACP module was only used to set the
Collecting and Distributing flags in the LACP protocol. It was
intended to be set by the bonding code to mimic its enabled flag.
The spec is relatively vague on the precise meaning of these flags,
and most implementations do something completely different with
them. For these reasons, it seems acceptable to remove the enabled
flag for the sake of simplicity. A slave is now Collecting and
Distributing if it is attached, or LACP couldn't be negotiated.
There's no reason that I can see to maintain this information in struct
port and struct iface. It's redundant, since the lacp implementation
maintains the same information.
Only the first 6 bytes (ETH_ADDR_LEN) of the 'sys_id' argument are used,
but the prototype declared it as an array of 8 bytes. This has no effect
on the generated code--the declared size of an array parameter is
irrelevant--but it is misleading.
Also, add 'const' since the array is not modified.
