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
