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.f...@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.w...@intel.com> > Signed-off-by: Patrick Fu <patrick...@intel.com> > Signed-off-by: Timothy Miskell <timothy.misk...@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/
