On Thu, 1 Jun 2017 16:28:13 +0200 Gaëtan Rivet <gaetan.ri...@6wind.com> wrote:
> 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. > The synthetic path can't do flow direction in netvsc (and via tap). Therefore this whole flow direction part is uninteresting for the use case of Hyper-V/Azure.
