[dpdk-dev] [PATCH v4 07/12] net/failsafe: support flow API
Stephen Hemminger
stephen at networkplumber.org
Thu Jun 1 20:02:22 CEST 2017
On Thu, 1 Jun 2017 16:28:13 +0200
Gaëtan Rivet <gaetan.rivet at 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.rivet at 6wind.com> wrote:
> >
> > > Signed-off-by: Gaetan Rivet <gaetan.rivet at 6wind.com>
> > > Acked-by: Olga Shern <olgas at 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.
More information about the dev
mailing list