DPDK patches and discussions
 help / color / mirror / Atom feed
From: Patrick Fu <patrick.fu@intel.com>
To: dev@dpdk.org
Cc: thomas@monjalon.net, ferruh.yigit@intel.com,
	maxime.coquelin@redhat.com, bruce.richardson@intel.com,
	mm6021@att.com, zhihong.wang@intel.com, liang-min.wang@intel.com,
	konstantin.ananyev@intel.com, timothy.miskell@intel.com,
	cunming.liang@intel.com, patrick.fu@intel.com
Subject: [dpdk-dev] [PATCH v1 0/3] lib: introduce traffic mirroring lib
Date: Wed,  9 Sep 2020 08:22:44 +0800	[thread overview]
Message-ID: <20200909002247.864844-1-patrick.fu@intel.com> (raw)

Network Test Access Point (TAP) is the network monitoring service
commonly adotpted in SDN-based network infrastructures. When VMs are
inter-connected over virtual switches, TAP requires vSwitch to mirror
out network traffics from specific workload VM ports to the TAP
device/VM ports. Classical mirroring impmentations in vSwitch make an
extra copy of the source packets, which results in significant degradation
in the throughput levels vSwitch could normally archieve. Therefore, we
propose a new set of APIs to support high-throughput packet mirroring
through hardware offloading.

The proposal is consisted of three major parts:
 - Mirror registration APIs
 - Mirror offload/customization callbacks
 - Shared mirror data path

In this patch set, mirroring happens between a pair of ethdev ports (one for
the source port and the other for the mirror port), which is configurable
on a per-port per-direction basis. i.e. applications invoke the mirroring
API to register source ports and traffic directions (tx or rx). The
registration API will then attach the mirror data path to the source port
as a standard ethdev tx or rx callback. If any custom mirror offload
functions are specified by applications, the offload function will be
executed within the mirror data path.

The mirror data path intercepts the packets flowing over the registered
source ports and, rather than doing extra packets copy operations, simply
transmits packets to the destination (mirror) port with an incremented
mbuf reference count. In this way, an identical copy of the packet data is
transmitted to both the mirror port and the original traffic destination.

In addition, with the proposed APIs we can implement even more complicated
mirrorings scenarios. Two examples include flow based mirroring and MAC
address matching, both of which have common usage within the industry.

Our prior studies demonstrate that this methedology is capble of doubling
the mirroring performance as compared to the default OVS port mirroring
performance (refer to the paper in IEEE xplore for further details:
https://ieeexplore.ieee.org/document/9110293)
An OVS implementation was also suggested to the OVS community for review
and comments (refer to the following OVS RFC patch:
https://patchwork.ozlabs.org/project/openvswitch/patch/
1595596858-78846-2-git-send-email-emma.finn@intel.com/)

We are considering implementing the mirroring APIs as a standalone library
in DPDK, but it's also reasonble to place it inside ethdev layer or within
the vhost-pmd considering the potential usage scenarios.

Patrick Fu (3):
  lib/mirror: introduce traffic mirror API
  lib/mirror: add port based mirroring
  lib/mirror: add flow based mirroring

 config/common_base                       |   5 +
 lib/Makefile                             |   2 +
 lib/librte_mirror/Makefile               |  20 +
 lib/librte_mirror/meson.build            |   6 +
 lib/librte_mirror/rte_mirror.c           | 461 +++++++++++++++++++++++
 lib/librte_mirror/rte_mirror.h           | 111 ++++++
 lib/librte_mirror/rte_mirror_version.map |   7 +
 lib/meson.build                          |   2 +-
 8 files changed, 613 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_mirror/Makefile
 create mode 100644 lib/librte_mirror/meson.build
 create mode 100644 lib/librte_mirror/rte_mirror.c
 create mode 100644 lib/librte_mirror/rte_mirror.h
 create mode 100644 lib/librte_mirror/rte_mirror_version.map

-- 
2.18.4


             reply	other threads:[~2020-09-09  0:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09  0:22 Patrick Fu [this message]
2020-09-09  0:22 ` [dpdk-dev] [PATCH v1 1/3] lib/mirror: introduce traffic mirror API Patrick Fu
2020-09-09  1:09   ` Wang, Haiyue
2020-09-09  6:02     ` Fu, Patrick
2020-09-21 15:26   ` MEHAN, MUNISH
2020-09-09  0:22 ` [dpdk-dev] [PATCH v1 2/3] lib/mirror: add port based mirroring Patrick Fu
2020-09-09  0:22 ` [dpdk-dev] [PATCH v1 3/3] lib/mirror: add flow " Patrick Fu
2020-09-22  7:40 ` [dpdk-dev] [PATCH v1 0/3] lib: introduce traffic mirroring lib Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200909002247.864844-1-patrick.fu@intel.com \
    --to=patrick.fu@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=cunming.liang@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=liang-min.wang@intel.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mm6021@att.com \
    --cc=thomas@monjalon.net \
    --cc=timothy.miskell@intel.com \
    --cc=zhihong.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).