On Wed, May 31, 2017 at 08:21:39AM -0700, Stephen Hemminger wrote: > On Mon, 29 May 2017 15:42:19 +0200 > Gaetan Rivet <gaetan.ri...@6wind.com> wrote: > > > Signed-off-by: Gaetan Rivet <gaetan.ri...@6wind.com> > > Acked-by: Olga Shern <ol...@mellanox.com> > > --- > > 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
