Re: [dpdk-dev] [PATCH 00/12] introduce fail-safe PMD

["Gaëtan Rivet" <gaetan.rivet@6wind.com>]

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