From patchwork Sun Dec 8 12:30:35 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Anoob Joseph X-Patchwork-Id: 63641 Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0AC5AA04F1; Sun, 8 Dec 2019 13:31:14 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 42EC31BE3D; Sun, 8 Dec 2019 13:31:14 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 621141BDFD for ; Sun, 8 Dec 2019 13:31:12 +0100 (CET) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB8CVBOO021889; Sun, 8 Dec 2019 04:31:11 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : mime-version : content-type : content-transfer-encoding; s=pfpt0818; bh=l6gzsfAMoNtcodeUFB9/+lRVb44PuoFyEybGZq3/fTk=; b=avuxPf21n4PADPEY8i5Auu+V4sW7UUeK87kpd53bcRy362JW3xNXVyQVj0e9yjJ876ZL kpX31Bvs52MIJiPGtDBuYihEXg9DQIuu5Lc3/QbYulnNvpocLhqTdzvl7YgbHlMKPNSD nPEdvTnMuU3sXI+/s4SRAvZsBVJeaikBzOd3k8akIJAdaPHLg2WOWKDRDLjhE8adjfzc doDYnnmLVEcbyOV/JqOhQA47qGnTzjf0mZV3lHUDpyeBI0/EiPKVJswELTNotgFhKaHJ qK/0whu5MwZETunLyBHGN1EibZZ9UGOvVCI6qq3B4PPr0R7H6tMzT2dFD3rmtVBwkYKs Sw== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2wrbawjm42-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 08 Dec 2019 04:31:11 -0800 Received: from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 8 Dec 2019 04:31:10 -0800 Received: from maili.marvell.com (10.93.176.43) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server id 15.0.1367.3 via Frontend Transport; Sun, 8 Dec 2019 04:31:10 -0800 Received: from ajoseph83.caveonetworks.com.com (unknown [10.29.45.60]) by maili.marvell.com (Postfix) with ESMTP id EB5D33F703F; Sun, 8 Dec 2019 04:31:05 -0800 (PST) From: Anoob Joseph To: Akhil Goyal , Radu Nicolau , Thomas Monjalon CC: Anoob Joseph , Jerin Jacob , Narayana Prasad , Ankur Dwivedi , Archana Muniganti , Tejasree Kondoj , Vamsi Attunuru , "Lukasz Bartosik" , Konstantin Ananyev , Date: Sun, 8 Dec 2019 18:00:35 +0530 Message-ID: <1575808249-31135-1-git-send-email-anoobj@marvell.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-08_03:2019-12-05,2019-12-08 signatures=0 Subject: [dpdk-dev] [PATCH 00/14] add eventmode to ipsec-secgw X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" This series introduces event-mode additions to ipsec-secgw. This effort is based on the proposed changes for l2fwd-event and the additions in l3fwd for event support. With this series, ipsec-secgw would be able to run in eventmode. The worker thread (executing loop) would be receiving events and would be submitting it back to the eventdev after the processing. This way, multicore scaling and h/w assisted scheduling is achieved by making use of the eventdev capabilities. Since the underlying event device would be having varying capabilities, the worker thread could be drafted differently to maximize performance. This series introduces usage of multiple worker threads, among which the one to be used will be determined by the operating conditions and the underlying device capabilities. For example, if an event device - eth device pair has Tx internal port, then application can do tx_adapter_enqueue() instead of regular event_enqueue(). So a thread making an assumption that the device pair has internal port will not be the right solution for another pair. The infrastructure added with these patches aims to help application to have multiple worker threads, there by extracting maximum performance from every device without affecting existing paths/use cases. The eventmode configuration is predefined. All packets reaching one eth port will hit one event queue. All event queues will be mapped to all event ports. So all cores will be able to receive traffic from all ports. When schedule_type is set as RTE_SCHED_TYPE_ORDERED/ATOMIC, event device will ensure the ordering. Ordering would be lost when tried in PARALLEL. Following command line options are introduced, --transfer-mode: to choose between poll mode & event mode --schedule-type: to specify the scheduling type (RTE_SCHED_TYPE_ORDERED/ RTE_SCHED_TYPE_ATOMIC/ RTE_SCHED_TYPE_PARALLEL) --process-dir: outbound/inbound --process-mode: app mode /driver mode The two s/w config options added to ipsec-secgw can be used in benchmarking h/w performance, 1. process-dir : states whether the direction is outbound/inbound. This option aims to avoid an unnecessary check of determining whether inbound/outbound processing need to be done on the packet. For each option a different light weight worker thread would be executed. 2. process-mode: states whether the application has to run in driver mode or app mode. Driver-mode: This mode will have bare minimum changes in the application to support ipsec. There woudn't be any lookup etc done in the application. And for inline-protocol use case, the thread would resemble l2fwd as the ipsec processing would be done entirely in the h/w. This mode can be used to benchmark the raw performance of the h/w. All the application side steps (like lookup) can be redone based on the requirement of the end user. Hence the need for a mode which would report the raw performance. App-mode: This mode will have all the features currently implemented with ipsec-secgw (non librte_ipsec mode). All the lookups etc would follow the existing methods and would report numbers that can be compared against regular ipsec-secgw benchmark numbers. Example commands to execute ipsec-secgw in various modes on OCTEONTX2 platform, #Inbound driver mode ./ipsec-secgw -w 0002:02:00.0,nb_ipsec_in_sa=128 -w 0002:03:00.0,nb_ipsec_in_sa=128 -w 0002:04:00.0,nb_ipsec_in_sa=128 -w 0002:07:00.0,nb_ipsec_in_sa=128 -w 0002:0e:00.0 -w 0002:10:00.1 --log-level=8 -c 0x7 – -P -p 0xf --config "(0,0,0),(1,0,0),(2,0,0),(3,0,0)" -f dpdk_internal/100g_4.3.cfg --transfer-mode 1 --schedule-type 2 --process-mode app --process-dir in #Inbound app mode ./ipsec-secgw -w 0002:02:00.0,nb_ipsec_in_sa=128 -w 0002:03:00.0,nb_ipsec_in_sa=128 -w 0002:04:00.0,nb_ipsec_in_sa=128 -w 0002:07:00.0,nb_ipsec_in_sa=128 -w 0002:0e:00.0 -w 0002:10:00.1 --log-level=8 -c 0x3f – -P -p 0xf --config "(0,0,0),(1,0,0),(2,0,0),(3,0,0)" -f dpdk_internal/100g_4.3.cfg --transfer-mode 1 --schedule-type 2 --process-mode drv --process-dir in #Outbound driver mode ./ipsec-secgw -w 0002:02:00.0 -w 0002:03:00.0 -w 0002:04:00.0 -w 0002:07:00.0 -w 0002:0e:00.0 -w 0002:10:00.1 --log-level=8 -c 0x1f – -P -p 0xf --config "(0,0,0),(1,0,0),(2,0,0),(3,0,0)" -f a-aes-gcm-new.cfg --transfer-mode 1 --schedule-type 2 --process-mode app --process-dir out #Outbound app mode ./ipsec-secgw -w 0002:02:00.0 -w 0002:03:00.0 -w 0002:04:00.0 -w 0002:07:00.0 -w 0002:0e:00.0 -w 0002:10:00.1 --log-level=8 -c 0x7f – -P -p 0xf --config "(0,0,0),(1,0,0),(2,0,0),(3,0,0)" -f a-aes-gcm-new.cfg --transfer-mode 1 --schedule-type 2 --process-mode drv --process-dir out This series doesn't introduce any library change. And the decision to add eventmode additions in ipsec-secgw was approved by the Tech Board. This series adds non burst tx internal port workers only. It provides infrastructure for non internal port workers, however does not define any. Also, only inline ipsec mode is supported by the worker threads added. Following are planned features, 1. Add burst mode workers. 2. Add non internal port workers. 3. Verify support for Rx core (the support is added but lack of h/w to verify). 4. Add lookaside protocol support. Following are features that Marvell won't be attempting. 1. Inline crypto support. 2. Lookaside crypto support. For the features that Marvell won't be attempting, new workers can be introduced by the respective stake holders. This series is tested on Marvell OCTEONTX2. Ankur Dwivedi (3): examples/ipsec-secgw: add default rte_flow for inline Rx examples/ipsec-secgw: add driver outbound worker examples/ipsec-secgw: add app outbound worker Anoob Joseph (5): examples/ipsec-secgw: add framework for eventmode helper examples/ipsec-secgw: add eventdev port-lcore link examples/ipsec-secgw: add Rx adapter support examples/ipsec-secgw: add Tx adapter support examples/ipsec-secgw: add routines to display config Lukasz Bartosik (6): examples/ipsec-secgw: add routines to launch workers examples/ipsec-secgw: add support for internal ports examples/ipsec-secgw: add eventmode to ipsec-secgw examples/ipsec-secgw: add app inbound worker examples/ipsec-secgw: add app processing code examples/ipsec-secgw: add cmd line option for bufs examples/ipsec-secgw/Makefile | 2 + examples/ipsec-secgw/event_helper.c | 1742 +++++++++++++++++++++++++++++++++++ examples/ipsec-secgw/event_helper.h | 324 +++++++ examples/ipsec-secgw/ipsec-secgw.c | 533 +++++++++-- examples/ipsec-secgw/ipsec-secgw.h | 81 ++ examples/ipsec-secgw/ipsec.c | 17 + examples/ipsec-secgw/ipsec.h | 36 +- examples/ipsec-secgw/ipsec_worker.c | 766 +++++++++++++++ examples/ipsec-secgw/ipsec_worker.h | 39 + examples/ipsec-secgw/meson.build | 4 +- examples/ipsec-secgw/sa.c | 11 - 11 files changed, 3446 insertions(+), 109 deletions(-) create mode 100644 examples/ipsec-secgw/event_helper.c create mode 100644 examples/ipsec-secgw/event_helper.h create mode 100644 examples/ipsec-secgw/ipsec-secgw.h create mode 100644 examples/ipsec-secgw/ipsec_worker.c create mode 100644 examples/ipsec-secgw/ipsec_worker.h