On Wed, May 31, 2017 at 08:21:39AM -0700, Stephen Hemminger wrote:

On Mon, 29 May 2017 15:42:19 +0200
Gaetan Rivet [off-list ref] wrote:

quoted

Signed-off-by: Gaetan Rivet <redacted>
Acked-by: Olga Shern <redacted>
---
 doc/guides/nics/features/failsafe.ini   |   1 +
 drivers/net/failsafe/Makefile           |   1 +
 drivers/net/failsafe/failsafe.c         |   1 +
 drivers/net/failsafe/failsafe_eal.c     |   1 +
 drivers/net/failsafe/failsafe_ether.c   |  70 +++++++++++
 drivers/net/failsafe/failsafe_flow.c    | 216 ++++++++++++++++++++++++++++++++
 drivers/net/failsafe/failsafe_ops.c     |  29 +++++
 drivers/net/failsafe/failsafe_private.h |  18 +++
 8 files changed, 337 insertions(+)
 create mode 100644 drivers/net/failsafe/failsafe_flow.c

How does this interact with typical case of VF and dumb virtual device?
The VF has flow API but dumb virtual device does not.

The fail-safe requires capabilities to be the same on all its slave. If
a capability must be supported on the VF, then is should be as well on
the synthetic path.

But the TAP PMD that can be used to capture traffic from a synthetic
path supports rte_flow in the same capacity as other NICs.

How does this work with late binding plugin? If VF arrives later is
the flow table reprogrammed to the VF?

The fail-safe stores an internal representation of rte_flows. These are
replayed in the same order upon plugin, so the flow table is
reprogrammed in the same way to the VF.

-- 
Gaëtan Rivet
6WIND