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

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

On Wed, May 17, 2017 at 01:50:40PM +0100, Ferruh Yigit wrote:
>On 3/20/2017 3:00 PM, Thomas Monjalon wrote:
>> There have been some discussions on this new PMD and it will be
>> discussed today in the techboard meeting.
>>
>> I would like to expose my view and summarize the solutions I have heard.
>> First it is important to remind that everyone agrees on the need for
>> this feature, i.e. masking the hotplug events by maintaining an ethdev
>> object even without real underlying device.
>>
>> 1/
>> The proposal from Gaetan is to add a failsafe driver with 2 features:
>> 	* masking underlying device
>> 	* limited and small failover code to switch from a device
>> 	  to another one, with the same centralized configuration
>> The latter feature makes think to the bonding driver, but it could be
>> kept limited without any intent of implementing real bonding features.
>>
>> 2/
>> If we really want to merge failsafe and bonding features, we could
>> create a new bonding driver with centralized configuration.
>> The legacy bonding driver let each slave to be configured separately.
>> It is a different model and we should not mix them.
>> If one is better, it could be deprecated later.
>>
>> 3/
>> It can be tried to implement the failsafe feature into the bonding
>> driver, as Neil suggests.
>> However, I am not sure it would work very well or would be easy to use.
>>
>> 4/
>> We can implement only the failsafe feature as a PMD and use it to wrap
>> the slaves of the bonding driver.
>> So the order of link would be
>> 	bonding -> failsafe -> real device
>> In this model, failsafe can have only one slave and do not implement
>> the fail-over feature.
>>
>
>Tech board decided [1] to "reconsider" the PMD for this release (17.08).
>So, lets start it J
>
>I think it is good idea to continue on top of above summary, is there a
>plan to how to proceed?
>

The fail-safe proposal has not evolved from the techboard point of view.
The salient point is still choosing between those 4 possible integrations.

To give a quick overview of its current state:

I have started working on a v3 to be integrated to v17.08. The work
however was exceedingly complicated due to deep-rooted dependencies in
the PCI implementation within the EAL, which has evolved in v17.05 and
will evolve during this release.

The current rte_bus rework from Jan Blunck and myself will greatly
simplify the sub-EAL layer that was used in the fail-safe. I am thus
waiting on Jan Blunck series on attach / detach, to propose mine in
turn for rte_devargs, move the PCI bus where it belongs and, finally,
rebase the fail-safe upon it.

The form this work is taking however is still the same as previously,
thus currently aiming at solutions 1 or 2.

>Thanks,
>ferruh
>
>[1]
>http://dpdk.org/ml/archives/dev/2017-March/061009.html

-- 
Gaëtan Rivet
6WIND