From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id F34ECA052B for ; Fri, 31 Jul 2020 01:55:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 39E962BB8; Fri, 31 Jul 2020 01:55:21 +0200 (CEST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80111.outbound.protection.outlook.com [40.107.8.111]) by dpdk.org (Postfix) with ESMTP id EED411C00D for ; Tue, 21 Jul 2020 09:01:25 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GydEa9VtuX2juJKaH3Cb5g1aFY12h3RQi/XyhLY0PaBBf6CNnKlQqFDGcG8AGNK/yG84RWqPOhIe39E+grR4yAJ/FZKCQxlBOkZRghG9RiTbtd8CBw3wG8PclbMfZOFuvsm0xTMVqztv0LlvYb2n9mU2k92vkYbv5IgxOY1QoxIbOlMFHDI6IV+4JsoTsOS2JrkyngbX1Ve0Xv04lCsWZAkR30qPHK0kuPbNZa/7iQZDhC6WCnDOspL7xbYEl+okyT6cuaXJPr+FPVB6wBNiXx3D3DoSvlZKvru4niIwtvOotzlTsfkiqKQbTG4Bww4UDiQT7arhm0G3Dy+iMAcesA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qC6t8RUE0PtcblewEfbJdCTWJRwWz0cyXn7twtOvZU0=; b=S8ImaSpDwoD2WCRVgluXggb/8Nm/AGKLnrEwCakGU0xZYtTsiDc/uQC8Lx4Pl99kyrORIDf9c4HZlVF3JJrtczTqsjHBJW5A6OYBzrmX+yzi62ikvJ+dfPXoZdNyh8wUPww//Jag9PxxKAyf6evs668zZleyyngIe0UoI4lhWA2GbDMOZd22AFyVc2oyvqu/kR6Oyp6AavuXqw1e6PSVRP8L7XoFvttRaviGJnuzDPNm7Jc/DThoNbxd/B2Ds3OfAWLnIHCfYbErIndRJ8Xdl1CragoZfOe3EsAtBha2VUR6OmnVnA5uBFEgjZq2wFc1W5NZ483TJyAFeWTVM2Ueag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=emutex.com; dmarc=pass action=none header.from=emutex.com; dkim=pass header.d=emutex.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emutex.onmicrosoft.com; s=selector2-emutex-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qC6t8RUE0PtcblewEfbJdCTWJRwWz0cyXn7twtOvZU0=; b=l7Y3qEkOO/HM/X91aGZYgLbDckVDUMDgkmAYown86ykv5K+T4nhc5oJX3AFSlNPSvfbM0bfBHWF79KIJvviv8a5qJQhgx0Nt8rL+OIDaAiLA4lDhKVdUiX8VvBCu9HY5FCAf6QDOyQ9X7qyCb6QWNycFZN+ZOfUTGg6HVbegVBY= Authentication-Results: tatacommunications.com; dkim=none (message not signed) header.d=none; tatacommunications.com; dmarc=none action=none header.from=emutex.com; Received: from DB6P190MB0552.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:34::14) by DB6P190MB0374.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:33::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.17; Tue, 21 Jul 2020 07:01:24 +0000 Received: from DB6P190MB0552.EURP190.PROD.OUTLOOK.COM ([fe80::71ad:f6fd:3c3f:d637]) by DB6P190MB0552.EURP190.PROD.OUTLOOK.COM ([fe80::71ad:f6fd:3c3f:d637%3]) with mapi id 15.20.3195.026; Tue, 21 Jul 2020 07:01:24 +0000 To: users@dpdk.org References: <20200720080852.4db7f0ae@hermes.lan> From: Pierre Cc: prashanth.fernando@tatacommunications.com Message-ID: <4b4368f1-871d-fa49-0049-b0210161b055@emutex.com> Date: Tue, 21 Jul 2020 08:01:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <20200720080852.4db7f0ae@hermes.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ClientProxiedBy: MRXP264CA0041.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:14::29) To DB6P190MB0552.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:34::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (79.95.87.24) by MRXP264CA0041.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:14::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.18 via Frontend Transport; Tue, 21 Jul 2020 07:01:23 +0000 X-Originating-IP: [79.95.87.24] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 652a780a-7df3-44ff-07ac-08d82d43e167 X-MS-TrafficTypeDiagnostic: DB6P190MB0374: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5797; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1oNPoS3ylULG/UsxrtnAL9exsfW1vP1PEJmqREpXv6Msux6RKH26aQkUVR21zMLBsMZDkT9H+JJJCOTTm2qJKRiiSs2m/yMxYrUJgFz1XdjPChPQ/DZy2JoAvAVLrZQ+MCK6LPaXwRCalMvVvR/hrrXMQvnKw2iHggijssOp/7fRKWQiLeY8k5s2+z9hzXubKK5rOvlET4pk1IknPVFzOEiPecpr09W2Bnj5u+QrfhEpO4F4bq48AesDEHKwDAdDpqf2tr1/+lN89uVl9bgTd3sjdWpza/b6t9jqJZu4rgjDS/0tySTPrPNZVyxjX5YnX74ZGQPD57+5aD1BWwaQKA4vGJBAXfuP5Hl3Dk/DJ5xYUybhjPkfu+OTENTJl0g2P6+KzmVJxmWkvKYmGIkuLbLf/a2YZ6DMD2/+mEu3Kd8yi8RmdItz+xeW8K6jEeVJIDzLixd79rqRJ7LxpgjSZQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6P190MB0552.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(346002)(376002)(366004)(39830400003)(136003)(396003)(52116002)(5660300002)(186003)(8936002)(8676002)(508600001)(31686004)(36756003)(53546011)(26005)(16576012)(4326008)(16526019)(316002)(31696002)(86362001)(6916009)(2906002)(66556008)(66476007)(66946007)(15974865002)(6486002)(83380400001)(2616005)(956004)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: K7rAvH0i/VsJYEfmyseUGflnAmVQTCjgUGCAYEiuS43DCbLxXI0qd+cXaDUHjJomb86C3ifEJmWb2LBj3y+JpF5ZX8RkfNL4acWHXYtPsolSyiLecHosKIEOG0n7vSCi3+JAOxBl112qh887Yb0YqLvIsKbN1hDuPlN6k/imeLwOATznoTp94Fv488sZ/z17FBmSSdmnGxZfqubFFi3OB9A4Vc/fu2CNjVxVPBM/Bsnsi+Dgh/XWLMX6f7OzOZKv39YlPUsRVxvMVpdReETJqoIjUPy/JW8DvqFPHZXdQNkEtIEzjwUUJlq5tunFTEjZtS6oXeMU00ftAxfacPqF9NqBfvlZGK35yykM6/8TO4j9BW4xpkyTX+128rmvFfy9E/IRaP2pNjek/ATKCgFSN+Xq6jEYQ0DMn/lngHGbco/MBnYLMkrWcg8qsZH1puQh2p7/K4zXwQEGs1fM7Haiu9ufIe1yk18PnZzR78IHzJY= X-OriginatorOrg: emutex.com X-MS-Exchange-CrossTenant-Network-Message-Id: 652a780a-7df3-44ff-07ac-08d82d43e167 X-MS-Exchange-CrossTenant-AuthSource: DB6P190MB0552.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jul 2020 07:01:24.2528 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84cc844b-5c53-4da1-99da-34ef4089ea8e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vWc6C4I+RJU9nj+buAlCS1JDVitT+XhI7glnA6DxQfvAbn5feJb1b4t+AcJGHv0NvhNa8YE2/SjUyaYHla1j6CQG7FuuoysnbZxrUXvlrLs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0374 X-Mailman-Approved-At: Fri, 31 Jul 2020 01:55:19 +0200 Subject: Re: [dpdk-users] Run To Completion Vs Pipeline X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" HI In a run-to-completion simple model on a single core,    - you have full control of the execution order and packet transmission order, typically being strictly the same than reception order.   - simple model to make it easy to debug and learn DPDK code.   - simple model to get deterministic latencies.   - will not scale easily, because the bottleneck is the whole sw. In a simple pipeline model,   - execution order get less deterministic .     If the problems to solve are stateless (no dependency between packets), that might be ok,     extreme scalability is easy to achieve.   - you need queues between pipelined components. You have to handle overflows and bottlenecks,     and decisions to throttle and drop traffic is yours.    - you might wish to use priority queues, i.e. much more complex design with its own drawbacks      and failure cases , and debugging uncertainties. Latencies get hairy to analyse. There are all intermediates between these extremes , e.g. pipelining across multiple  run-to-completion stateful subsystems - stateful TCP reordering and reassembly, - IP reordering and reassembly, IPSec , fragmentations  between networks with different mtus - UDP reassembly before regex - IGMP packets and multicast packets - ...... all the networking fun .....  - and you have to design your subsystem to best fit workloads vs. processing power of each core. you could switch dynamically from one model to the other one depending on traffic rates - at low traffic rate, get the best use of a single core and save the maximum of power on the system   this would favour a run-to-completion model at run time. - at high traffic rate, wake up multiple cores    this would favour a piplining model at run time. On 20/07/2020 16:08, Stephen Hemminger wrote: > On Mon, 20 Jul 2020 05:03:55 +0000 > Prashanth Fernando wrote: > >> Hi, >> >> I'm wondering why DPDK proposes 2 different models. >> Is there any situation that fits one model but not another? >> >> I am looking to build an application with a firewall, regex, LPM, rate-limiters etc ... >> I am wondering which approach would be a best fit for my usecase. >> >> >> Thanks, >> Prashanth >> > There are two different factors here. > First, how many cores do you have to burn. The run to completion model uses > less cores (and has less latency). But other models are better if some set > of packets require longer to process (VPN, Crypto, ...) in that case you > want to push packets to other core. -- Emutex Limited, Roselawn House, National Technology Park, Limerick, V94 6R68, Ireland. Phone: +353 (0)61 514496 Ext# 814, Web: www.emutex.com.