Re: [dpdk-dev] [RFC] lib: introduce traffic mirroring API

[Thomas Monjalon <thomas@monjalon.net>]

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()
http://doc.dpdk.org/api/rte__ethdev_8h.html#a1c88c5e86f0358981443600f05069091

Please consider reviewing this implementation in rte_flow:
	https://patches.dpdk.org/patch/73279/