On Fri, Mar 03, 2017 at 04:14:20PM +0000, Bruce Richardson wrote:
On Fri, Mar 03, 2017 at 04:40:22PM +0100, Gaetan Rivet wrote:
This PMD intercepts and manages Ethernet device removal events issued by
slave PMDs and re-initializes them transparently when brought back so that
existing applications do not need to be modified to benefit from true
hot-plugging support.
The stacked PMD approach shares many similarities with the bonding PMD but
with a different purpose. While bonding provides the ability to group
several links into a single logical device for enhanced throughput and
supports fail-over at link level, this one manages the sudden disappearance
of the underlying device; it guarantees applications face a valid device in
working order at all times.
Each fail-safe instance is configured to run atop one or several
devices, with one defined as the preferred device. Hot-plug events are
handled on all of them, and Tx is always directed to the preferred device
if present or to the next available failover device (Rx is always performed
on all devices for simplicity).
Moreover, the configured slaves (preferred or failover) do not need to be
present at initialization time and may appear later.
Slaves configuration is continuously synchronized with that of the virtual
device, which exposes their common set of capabilities to the application.
Failure to apply the current configuration state to a slave for any reason
simply reschedules its initialization.
This series depends on the series
[PATCH 0/4] clarify eth_dev state management
[PATCH 0/5] add device removal event
Hi,
Hi Bruce,
this looks an interesting PMD, and I like the wrapper approach. However,
why duplicate the functionality of the bonding device in another device
driver? Is it not possible to have this driver wrap individual devices
and then have the bonding driver use those wrapped devices to present an
omni-present device? It seems strange to have support for grouping
devices together in two different drivers - one should leverage the
other.
Yes there appears to be a certain amount of overlap between these two
PMDs from the above description. Actually we've considered modifying
bonding at first but found it to be fundamentally incompatible:
- By design, with bonding, applications are aware of slave PMDs and can
use them directly (even if they shouldn't, depending on the
aggregation mode). If they were supported, hot-plug events would have
to be managed by the application as well.
- With fail-safe, slaves are provided as PMD parameters and are fully owned
by the parent instance, which takes care of their entire initialization
and provides transparent support for hot-plug events.
Their purposes also differ:
- Bonding implements various modes of operation for link aggregation (round
robin, active backup, LACP...) in the same fashion as the Linux bond
driver.
- Fail-safe handles hot-plug events so applications do not have to.
To answer your second question, both are stackable: the fail-safe design
aims at being the most transparent possible, meaning that it should make
no difference to applications using it, whether within a bond or not.
Alternatively, should this be merged into the bonding driver or replace
it?
Applications (or users) that need their combined functionality benefit
from greater flexibility this way, so I think having them both in the
tree makes sense.
Regards,
/Bruce
Regards
--
Gaëtan Rivet
6WIND
