DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: patrick.fu@intel.com
Cc: dev@dpdk.org, ferruh.yigit@intel.com, maxime.coquelin@redhat.com,
	bruce.richardson@intel.com, zhihong.wang@intel.com,
	liang-min.wang@intel.com, konstantin.ananyev@intel.com,
	timothy.miskell@intel.com, cunming.liang@intel.com,
	arybchenko@solarflare.com, Jiawei Wang <jiaweiw@mellanox.com>,
Subject: Re: [dpdk-dev] [RFC] lib: introduce traffic mirroring API
Date: Thu, 30 Jul 2020 08:32:52 +0200
Message-ID: <9050775.XvCxKblxuy@thomas> (raw)
In-Reply-To: <20200730032332.3742259-1-patrick.fu@intel.com>

30/07/2020 05:23, Patrick Fu:
> 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 proposal, 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. 
> Mirror registration API proto-types are defined as follows:
> int rte_mirror_register(uint16_t src_port,
> 	struct rte_mirror_param *param);
> int rte_mirror_unregister(uint16_t src_port);
> struct rte_mirror_param contains all of the parameters the mirror data
> path will use, e.g. the mirror port number, the source traffic direction
> to be mirrored, the custom mirroring offload function pointer, the
> application context, etc. Notablely, applications should passdown a
> spinlock through this structure, which is used to synchronize the packet
> data access between application and the mirror data path.
> 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.
> Signed-off-by: Liang-min Wang <liang-min.wang@intel.com>
> Signed-off-by: Patrick Fu <patrick.fu@intel.com>
> Signed-off-by: Timothy Miskell <timothy.miskell@intel.com>

I assume you consider deprecating rte_eth_mirror_rule_set()

Please consider reviewing this implementation in rte_flow:

  reply	other threads:[~2020-07-30  6:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30  3:23 Patrick Fu
2020-07-30  6:32 ` Thomas Monjalon [this message]
2020-07-31  2:34   ` Fu, Patrick
2020-07-31  9:31     ` Thomas Monjalon
2020-07-31 11:41       ` Fu, Patrick

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:

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

  git send-email \
    --in-reply-to=9050775.XvCxKblxuy@thomas \
    --to=thomas@monjalon.net \
    --cc=arybchenko@solarflare.com \
    --cc=bruce.richardson@intel.com \
    --cc=cunming.liang@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jiaweiw@mellanox.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=liang-min.wang@intel.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=orika@mellanox.com \
    --cc=patrick.fu@intel.com \
    --cc=timothy.miskell@intel.com \
    --cc=zhihong.wang@intel.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git