Cover Comment List
List cover comments
GET /api/covers/42779/comments/?format=api
[ { "id": 84252, "web_url": "http://patches.dpdk.org/comment/84252/", "msgid": "<3685021.sWt9K18E1B@xps>", "list_archive_url": "https://inbox.dpdk.org/dev/3685021.sWt9K18E1B@xps", "date": "2018-07-26T16:57:06", "subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "submitter": { "id": 685, "url": "http://patches.dpdk.org/api/people/685/?format=api", "name": "Thomas Monjalon", "email": "thomas@monjalon.net" }, "content": "> Anoob Joseph (12):\n> examples/l2fwd: move macro definitions to common header\n> examples/l2fwd: move structure definitions to common header\n> examples/l2fwd: move globally accessed vars to common header\n> examples/l2fwd: move dataplane code to new file\n> examples/l2fwd: remove unused header includes\n> examples/l2fwd: move drain buffers to new function\n> examples/l2fwd: optimize check for master core\n> examples/l2fwd: move periodic tasks to new function\n> examples/l2fwd: skip timer updates for non master cores\n> examples/l2fwd: move pkt send code to a new function\n> examples/l2fwd: use fprint instead of printf for usage print\n> examples/l2fwd: improvements to the usage print\n\nMaintainers of this app look to be against adding complexity.\n\nIn order to get this series accepted, we need more discussions\nwith more people involved.\nSo it will miss 18.08.\n\nIt can be discussed in a more global discussion about examples maintenance.\nIf discussion does not happen, you can request it to the technical board.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id DDF843238;\n\tThu, 26 Jul 2018 18:57:13 +0200 (CEST)", "from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com\n\t[66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 02BE8288C\n\tfor <dev@dpdk.org>; Thu, 26 Jul 2018 18:57:12 +0200 (CEST)", "from compute1.internal (compute1.nyi.internal [10.202.2.41])\n\tby mailout.nyi.internal (Postfix) with ESMTP id 75D3A21D6F;\n\tThu, 26 Jul 2018 12:57:12 -0400 (EDT)", "from mailfrontend1 ([10.202.2.162])\n\tby compute1.internal (MEProxy); Thu, 26 Jul 2018 12:57:12 -0400", "from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id 391FBE4AB8;\n\tThu, 26 Jul 2018 12:57:11 -0400 (EDT)" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=\n\tcc:content-transfer-encoding:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc; s=mesmtp; bh=9MwZe1vmG98dsof613cDdIF9I9\n\tbL8k7w4vmq+Lg/3h4=; b=eVWYOp+XAhVjcI8SgdzRkb7Xqqxf/J1V9Eah9roEcu\n\tGNHRHw6S2ri9vb06Z4yl7t3z9ReYd2xPfYdfw9t/VxGKw6EyzZOYCu6aYLTVKIZz\n\tDMyhHa2BwTaMPe2EfNxsew1tNemuXt7akfsavad4nXGvKlsKYKwNPlR/0dr47qPn\n\t0=", "v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-transfer-encoding:content-type\n\t:date:from:in-reply-to:message-id:mime-version:references\n\t:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9MwZe1\n\tvmG98dsof613cDdIF9I9bL8k7w4vmq+Lg/3h4=; b=KlpZHkBFF9v5IeSqCoftsV\n\tbSEm21EErH9YwCXmU7La+KAHB2VSTdYUMqR/ZcbXIfYGU8x0h+K7AJW/QTwpZUWM\n\tn3Gpb9IN3ArR4P3AnrJkgpOIuUBYqVPhurHT/8SPRFL7j3JaKDvbM7xTZSYeUD7O\n\tKdhunQenw3W8732a6dyH/UcKY75p2t154uSaEpAzmgC/Exf0IPVCvhuhKqLWCwRG\n\tThbEFeoYpzLjwATPiOi8/TYyfqroR2UotGvZqwuujePwf9Arv/Ym46RVXwNnbz+K\n\tVukPTlC0CIZ6a+hHpGd+Q8d5oim+fNTOwoPCS1UVzOunJy+Pq6vR9UOQf4RYka0g\n\t==" ], "X-ME-Proxy": "<xmx:aP1ZW6dHfesvIXYPmnMoqgjP8NgfelZsIVB6D0yTdo1D5jbCU8jPpQ>\n\t<xmx:aP1ZW6kKFgV3dPZn3eumI0xJPQwOH5bMBVpj8a0OllCqttvRV7wK3A>\n\t<xmx:aP1ZW3yBstYZDfiAYwNXgbyz0pl3ock_SF237gjQi6ykZ95AMC6T7g>\n\t<xmx:aP1ZW1wpFBaLRYcunOIZNgrUe2s5NkjzildY_NPcrq26Fb_nDw7PDA>\n\t<xmx:aP1ZW_VOeAXw4p7P7taFUDeFyuGKup3PGVosCkMtSW9Qay0ST751lA>\n\t<xmx:aP1ZW6zFfN9L88CcubX-SJEPmIL56hfKyJDIKsaoBAL44YBouVrCoQ>", "X-ME-Sender": "<xms:aP1ZW_EsWLlBG6WCFsxk9QOx2T3dzO8RvBf9FFLRjqLhy2dGzzguiQ>", "From": "Thomas Monjalon <thomas@monjalon.net>", "To": "Anoob Joseph <anoob.joseph@caviumnetworks.com>", "Cc": "dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>,\n\tPablo de Lara <pablo.de.lara.guarch@intel.com>,\n\tJerin Jacob <jerin.jacob@caviumnetworks.com>,\n\tNarayana Prasad <narayanaprasad.athreya@caviumnetworks.com>", "Date": "Thu, 26 Jul 2018 18:57:06 +0200", "Message-ID": "<3685021.sWt9K18E1B@xps>", "In-Reply-To": "<1531289248-20025-1-git-send-email-anoob.joseph@caviumnetworks.com>", "References": "<1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<1531289248-20025-1-git-send-email-anoob.joseph@caviumnetworks.com>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "7Bit", "Content-Type": "text/plain; charset=\"us-ascii\"", "Subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 84378, "web_url": "http://patches.dpdk.org/comment/84378/", "msgid": "<e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com>", "list_archive_url": "https://inbox.dpdk.org/dev/e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com", "date": "2018-08-01T06:59:50", "subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "submitter": { "id": 893, "url": "http://patches.dpdk.org/api/people/893/?format=api", "name": "Anoob Joseph", "email": "anoob.joseph@caviumnetworks.com" }, "content": "Hi Thomas,\n\nOn 26-07-2018 22:27, Thomas Monjalon wrote:\n> External Email\n>\n>> Anoob Joseph (12):\n>> examples/l2fwd: move macro definitions to common header\n>> examples/l2fwd: move structure definitions to common header\n>> examples/l2fwd: move globally accessed vars to common header\n>> examples/l2fwd: move dataplane code to new file\n>> examples/l2fwd: remove unused header includes\n>> examples/l2fwd: move drain buffers to new function\n>> examples/l2fwd: optimize check for master core\n>> examples/l2fwd: move periodic tasks to new function\n>> examples/l2fwd: skip timer updates for non master cores\n>> examples/l2fwd: move pkt send code to a new function\n>> examples/l2fwd: use fprint instead of printf for usage print\n>> examples/l2fwd: improvements to the usage print\n> Maintainers of this app look to be against adding complexity.\n>\n> In order to get this series accepted, we need more discussions\n> with more people involved.\n> So it will miss 18.08.\n>\n> It can be discussed in a more global discussion about examples maintenance.\n> If discussion does not happen, you can request it to the technical board.\n>\nEvent dev framework and various adapters enable multiple packet handling \nschemes, as opposed to the traditional polling on queues. But these \nfeatures are not integrated into any established example application. \nThere are specific example applications for event dev etc, which can be \nused to analyze an event device or a particular eventdev adapter, but \nthere is no standard application which can be used to compare the real \nworld performance for a system when it's using event device for packet \nhandling and when it's done via polling on queues.\n\nThe following patch submitted by Sunil was looking to address this issue \nwith l3fwd,\nhttps://mails.dpdk.org/archives/dev/2018-March/093131.html\n\nBruce & Jerin reviewed the patch and suggested the addition of helper \nfunctions to abstract the event mode additions in applications,\nhttps://mails.dpdk.org/archives/dev/2018-April/096879.html\n\nThis effort of adding helper functions for eventmode was taken up \nfollowing the above suggestion. The idea is to add eventmode without \ntouching the existing code path. All the eventmode specific additions \nwould go into library so that these need not be repeated for every \napplication. And since there is no change in the existing code path, \nperformance for any vendor should not have any impact with the additions.\n\nThe scope of this effort has increased since the submission, as now we \nhave Tx adapter as well. Sunil & Konstantin had clarified their \nconcerns, and gave green flag to this approach.\nhttps://mails.dpdk.org/archives/dev/2018-June/105730.html\nhttps://mails.dpdk.org/archives/dev/2018-July/106453.html\n\nI guess Bruce was opening this question to the community. For compute \nintense applications like ipsec-secgw, eventmode might be the right \napproach in the first place. Such complex applications would need a \nscheduler to perform dynamic load balancing. Addition of eventmode in \nl2fwd was to float around the idea which can then be scaled for more \ncomplex applications.\n\nIf maintainers doesn't have any objection to this, I'm fine with adding \nthis in the next release.\n\nThanks,\nAnoob", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 65B2358C4;\n\tWed, 1 Aug 2018 09:01:08 +0200 (CEST)", "from NAM03-CO1-obe.outbound.protection.outlook.com\n\t(mail-co1nam03on0045.outbound.protection.outlook.com [104.47.40.45])\n\tby dpdk.org (Postfix) with ESMTP id C78045689\n\tfor <dev@dpdk.org>; Wed, 1 Aug 2018 09:01:06 +0200 (CEST)", "from [IPv6:2405:204:d400:8dee:817b:e263:61d9:47e]\n\t(2405:204:d400:8dee:817b:e263:61d9:47e) by\n\tSN6PR07MB4911.namprd07.prod.outlook.com (2603:10b6:805:3c::29) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1017.15; Wed, 1 Aug 2018 06:59:37 +0000" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=u1117l5ypnj76JDoWqj/JjIuLuSx9ahSeLG4+WMtmmM=;\n\tb=RKg+eF0qXXduBulYDsOk34LPOa0CeOREhVXTHHK7K6P61jhE/2KfpU+f08VnaXGTjSLTrylHADMeManpUKXbzWIlbZ6iqnpV5A1q6zGzT+sF/jA8WdpQ5NmFJgjKZRP+YQCchwnBlbn8ZMdhRPkQlaY2gpRw1LB3HnEsqa2xtZQ=", "Authentication-Results": "spf=none (sender IP is )\n\tsmtp.mailfrom=Anoob.Joseph@cavium.com; ", "To": "Thomas Monjalon <thomas@monjalon.net>", "Cc": "dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>,\n\tPablo de Lara <pablo.de.lara.guarch@intel.com>,\n\tJerin Jacob <jerin.jacob@caviumnetworks.com>,\n\tNarayana Prasad <narayanaprasad.athreya@caviumnetworks.com>,\n\tHemant Agrawal <hemant.agrawal@nxp.com>,\n\t\"Ananyev, Konstantin\" <konstantin.ananyev@intel.com>,\n\tSunil Kumar Kori <sunil.kori@nxp.com>, Nikhil Rao <nikhil.rao@intel.com>", "References": "<1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<1531289248-20025-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<3685021.sWt9K18E1B@xps>", "From": "\"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com>", "Message-ID": "<e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com>", "Date": "Wed, 1 Aug 2018 12:29:50 +0530", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.9.1", "MIME-Version": "1.0", "In-Reply-To": "<3685021.sWt9K18E1B@xps>", "Content-Type": "text/plain; charset=utf-8; format=flowed", "Content-Transfer-Encoding": "7bit", "Content-Language": "en-US", "X-Originating-IP": "[2405:204:d400:8dee:817b:e263:61d9:47e]", "X-ClientProxiedBy": "BMXPR01CA0021.INDPRD01.PROD.OUTLOOK.COM\n\t(2603:1096:b00:d::31) To SN6PR07MB4911.namprd07.prod.outlook.com\n\t(2603:10b6:805:3c::29)", "X-MS-PublicTrafficType": "Email", "X-MS-Office365-Filtering-Correlation-Id": "f7bdcda3-c4ae-4131-ca9c-08d5f77c5cb4", "X-Microsoft-Antispam": "BCL:0; PCL:0;\n\tRULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020);\n\tSRVR:SN6PR07MB4911; ", "X-Microsoft-Exchange-Diagnostics": [ "1; SN6PR07MB4911;\n\t3:TeZLVHH42nLhR6jNpYsMjoC+mlgoiY6Hqz06UFF88IhO+27LLoYB/Tl76jQ6U+uHHCPNOG/Vy6zpeV/yTfnbvuFOWlxTD/L4UdrGHbQcYq/yzC0nQKVf7zL/rF+wyd/h5ul4k+jBZOkU33scIVAp4ryStAV5jM6PNydKOJDkzDUhYrDgkeWrrKnycvMiGXh9RMDcKATNhg3t/VVSgL8QLahSYD1mALBt+4UNuRd0XZrZ3+f4NKdwGYb6sW8MXVT6;\n\t25:vjj/gU2un78l7Y8qnNblZucDbYKA9uhtJnwSzpcNnPFT1Po1uA92PMkH6Dul2LPMkAw5s3tAAraQXrcv+zITE6SLeuSg1YYqTN+Q7+DKOSPzib+Obx6uV4sKzLcmqtVLWa4a7MuZpcae0dzMYmVETFuQeCSzc8fFTy4ZtaQHkUUEsA2lDHAGiV00MakOYpdPNCDWRAgPs40/CQaGSozo3rbe22dkCfIoK/SvaVYsZePz9u5sWPlNRoldcyTzTL7dm+68oFI/joDUqODKO4VM+Nix06FTtKls9rmSxDpoexou0NSiKojfnY8yasgMYjpX+IYGktT3OrNjv+EeyAMJvw==;\n\t31:O4qlQxIkYAGE74PAGRFYNoaEwgjm6rUgXDniOZ5US4gasivS0kwuqT3N4ZhYV5zXc6NndSKvx9I6Uu5xdxIVC2AalhBIj3UoJK3WTQlRYXT5rQEKUoRlf5S6mIP1f7TXz/tSnQV/2y2a5MsQWM0itehkbig6QaRx1PoD9PxiTlBHf8QFiZth/K9EKrivnSmLVJXssMGo+clqGc/8h218/IqcypEJieE0Bx+M7WSHJKs=", "1; SN6PR07MB4911;\n\t20:jeS3XoQPI2hRlIILUaYQKhcIuDObOcVJcGlLckHNoAwZmdvhWRj6K7kCZ+VEXCmVwCYEAJwXGtoJD6tPFnyIDVYSCREactrmn6XWLMpQZQRlFHQPjoTFx4oq/DSSZ7I7DTem29DKStp7rAWi4CV8p0E86k0vVCMr17PVBqkmqp/ix9lmZ5sFJ+oN8/ANBVSPmDxQZVxU/2Aj4h+kAWXUHzKuJiYvZTXQmB3tHJO6aVwMK/Lw9vqKC9qrxf7btFjthQBOluusRuJaz5PjqwB47Q0hq07yeWUIwUrbo7yFw1M2/M1ZugSklB5M/PBANuSUWNP7Uk0WIn/BmZR3uQiMOQEKJmujUHsQiMnq4udOC/+Na13u2WxBk5lTI/8Hto3/n2BYnlICqib8pEa34a4L230K8yJ43R/g3AwnsHw3KWCQTW/WYQParbpvqqr26IXJf8vNWE6k1fYTUuxq8KI4MUsz5ZOk74LPKBEi8BxCaZAW/QAdJtpqh/C1Jkx3e/PoKyBAgjVkOiAWCffrPhZe4qHtHQwKTVwKiGnoCp5WTBkxbSkSuCDy353qJnEYwoPhGkQXP17t72vdGUylEQi5Rugykq+31YPrhDpaXJ+aIsM=;\n\t4:Ad9xibdNT9pRJ2/xiUcCYOgrqJUT+uxbaVSE3vbbLM4q2FrGy667lUp+EMtIJX72gBbXIaiNM70rpIoM5pdNbK7RopB5U9NJzCqTKlNQRz4cpG2U2ZKcD3Iq/RkA2pmWZfW3ZI9RQNVHw47aICjfYi/oAwrecRhEL18f7+YSwtnGldJs1kHEp7V8pql/I9aZJNk9AFfdktt/O4ITSMI2w9z0AUnNLwxCwGlbcj9tNCE2VNPculMS8IN61INhd/iMTB0Jk2u4Eu6RCoHH2rgNU/D3lt1SXd6TNWOIt5bYo8PFkXRQ+XJdY7cUss+nn0Ey", "=?utf-8?q?1=3BSN6PR07MB4911=3B23=3ADBpb?=\n\t=?utf-8?q?bY7XVMTDJLXWlzI7mR7ni4eQawT2gF4CG3NRSEsZnnMbhKxdmWzbTgGa?=\n\t=?utf-8?q?ViaRwjOFphij9kW+DIm7WExdfp0fcU6s9/DpHx8dDlZEWjr/qpx0gm/K?=\n\t=?utf-8?q?12vN02pqFIhQT+5g+0D4QI61Qgn++uRhMBcoCNEdhLZ+uyT5pIhPm9uk?=\n\t=?utf-8?q?xqVQ6y85Wk/zSLBFfrNdF8h92ijADPGdZky5z+Kisl6it88Q3tzSjtuy?=\n\t=?utf-8?q?Az8TG4N7yZjVigh+PmO8WCxIdH4bSye5EWDyGkiwXQ0UMSuICx9Huu2X?=\n\t=?utf-8?q?6uRrVCweEJrItInV6DT0tvZs7LNOFIVDTIIAcjgfp/mO4ukGWWmg3sAo?=\n\t=?utf-8?q?52LFW3tpt/8x1SzNc8mBZOa6n80XgAWRDfj84M9J5U/fiNUWiRNGC+kc?=\n\t=?utf-8?q?BCwlPI4hqlKPTSy2jgq4Kky0jMtpnpmcQMCxHk/J6kGfaiFoeeLK3izU?=\n\t=?utf-8?q?C9wtM+aXj2M6RZIRd2uqcyTotrb3cVMDxxydGvvl688Dq5dAmpCsSebu?=\n\t=?utf-8?q?lRMwTEI9U6lnUscEHfNh30tx7I8oi/D1b55FIQZCmRamk8MyY3E3ZqI8?=\n\t=?utf-8?q?jdl+1gzQrcl3ReI6XMlvAVWRmPZ5PhfWCbCpFi3HQkk9tG2uvwkfscJ7?=\n\t=?utf-8?q?kVYtIe5lQeYCPGgI9kEGXxo8+6Vwzd6m2CHX4kyEEx5kNYPGg0Xomrp9?=\n\t=?utf-8?q?7aJLD/gSK1+SwjPMnmA8/RQkyEcJObTZbT+L8I6kVJT5az4vmwXgxJn9?=\n\t=?utf-8?q?4RrGy9i5rVjBGecEDWIzFuD0pzq6acEWEZBlmKupZwoiIytKMl7lxLzp?=\n\t=?utf-8?q?hizdszjaxmu0JHKggXavOL50LeFwZIXfNQ2JAtiy4a5GE22cPT4TCHSs?=\n\t=?utf-8?q?jI9fCYdzgD4EJZSW49G2d5fW/JgqGRFXDr1Olp9lJyqFtWlLZA9pNXvm?=\n\t=?utf-8?q?iJQIJ1Q3Uiz7sNZocqNkxjk1YE+/OaHMYr5zrNlGDfSOIB1dZJt5oKZr?=\n\t=?utf-8?q?ZRPCazjDtgP6oVy85eDnfM9xZE1QrZVhmXNJmW5CA+O3ComlXO4nshFx?=\n\t=?utf-8?q?hpzYqwrXH5sMuJmxgIAUZcnEBt+i7dHsJVAh5peGqidzVfw5+bmdfpKa?=\n\t=?utf-8?q?vzXrsYSU48JrsXGUs4qcrMJnz2KGG2j8ue/6L96Uw6g7HB+j4S8ky9Fg?=\n\t=?utf-8?q?+mOd5W2WWThmzgE3udNMvVZZ+G3CcyuFijcsPj98Wq0ATzTzsv0siJi9?=\n\t=?utf-8?q?ctlJ0iyvKuruJ/5Jyz3vGPYZhBbIBLTjVkGj9w4+08fxrcXf8UmmmZn7?=\n\t=?utf-8?q?s7kEXP7XSDMWGgxtPSpoCCbA4+FGP9o6ay4u2PuwwxuIrusU5cXwiwKe?=\n\t=?utf-8?q?HiqJ66jKvM8n3GngDQQbBqR7sgogBJRYfzI/ZyCMA+euQObqqCRrsFNU?=\n\t=?utf-8?q?AlCIxGEKJBRoV0OkjWIKW8cZRBRvq9lPp4NpeY1pc6BpQZouzTtmoFz/?=\n\t=?utf-8?q?81iIHWz6p5Lv4r46x7MSNFglmwl3H1dWSrHtp+HRDyevmqrdvF4GA9q0?=\n\t=?utf-8?q?QLc/77zfNc+MxS4SJ+9q8wfbuiVWXDqwQg=3D=3D?=", "1; SN6PR07MB4911;\n\t6:vg6+7nPlgruv13gMqepB1FA6cmEvW6QTnvkadYg+arQGaqjnxB54uMG9HoK80zmgEEJQ6iZCvVm0zvMN7zX0rhmQmCHujBnQaCRW9u7+SK3FJibmLBV+5sUEerCwQ/6HC6P3lOlYqTqeHabysQONYUh9OFTl9Fh/shz1ESxb/eTnqjICuXh/xqJqZE72LvwpA+So7Ool0jQR9NC3pO3UCv7W4jVTlXG1tJJj5U828+PHeObbVrTsmzF3UVTE3VPt2dzGPC4Fe15c81Ff+y3dO3MbuFg75WoYtJjRF+rqBaBLsVpYYBjuyKqr4n0gTORymWSi3kmV1FvwsZV9Yn359mwRfs5gAUqIGDZcmGoDwjZaJLFxJKTA5XUIPbS5+VkhjKygRx5MQC/i6E0dP10sa70KTrhRXiepSX6+LOL8ylXXzWPQuTXKh/HjmhKamX3Ic8OmjIAGfAVe6leFBdTXxA==;\n\t5:OxkdD+ciqEoCNCTqqTWCFEFo5pH3z6N4ze74IEpqcQ/SpPrqG8jwvul86qg8EYvQ+DE3XUWqwQXPzLxipSoyWJHZR+VtPkV/udPBLFefeMAHl9ssq2yCvVP6Z1C1o/NXJtzpNwEguOa1JFssN3Yg4Y2VcFXQSj64X1gDS/FS6v0=;\n\t7:/FjHSWkurByKOP2d4LudS/e56eTVBdYr6CObvxiQUM3mZV303DQ/oWUiXYyJVUJOzs6xUCorScuMSFzuHQ6xNjw7k+NM9v3z3eEl4m4ub9LmlprDtSBDLN/4IxJ+RHNNlgHufSZFj5FFFpLKbh6B6ZyaUZ+FfKrCvRerpwwOlwNDk5JgHxtVdMDBKnB4SIhpBNPVpAAugW7KxHM0ofgiAB/wXzqQHZo8gvj5rTsLrsj6wkvgYwQR1hBRkmgxXa/7" ], "X-MS-TrafficTypeDiagnostic": "SN6PR07MB4911:", "X-Microsoft-Antispam-PRVS": "<SN6PR07MB4911DCABF4F579D640BFBE96F82D0@SN6PR07MB4911.namprd07.prod.outlook.com>", "X-Exchange-Antispam-Report-Test": "UriScan:(278428928389397);", "X-MS-Exchange-SenderADCheck": "1", "X-Exchange-Antispam-Report-CFA-Test": "BCL:0; PCL:0;\n\tRULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(3231311)(944501410)(52105095)(10201501046)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016);\n\tSRVR:SN6PR07MB4911; BCL:0; PCL:0; RULEID:; SRVR:SN6PR07MB4911; ", "X-Forefront-PRVS": "0751474A44", "X-Forefront-Antispam-Report": "SFV:NSPM;\n\tSFS:(10009020)(136003)(39860400002)(346002)(376002)(396003)(366004)(189003)(52164004)(199004)(486006)(186003)(53546011)(64126003)(54906003)(14444005)(97736004)(476003)(446003)(58126008)(386003)(229853002)(67846002)(5660300001)(65826007)(23676004)(52396003)(46003)(52146003)(42882007)(76176011)(53936002)(11346002)(316002)(2616005)(2486003)(6486002)(52116002)(6306002)(16526019)(106356001)(3260700006)(25786009)(31696002)(50466002)(8676002)(81166006)(68736007)(105586002)(6246003)(305945005)(31686004)(7736002)(6916009)(4326008)(65956001)(47776003)(36756003)(478600001)(6666003)(65806001)(81156014)(6116002)(230700001)(1706002)(72206003)(8936002)(966005)(2906002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR07MB4911;\n\tH:[IPv6:2405:204:d400:8dee:817b:e263:61d9:47e]; FPR:; SPF:None;\n\tLANG:en; PTR:InfoNoRecords; MX:1; A:1; ", "Received-SPF": "None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)", "X-Microsoft-Antispam-Message-Info": "DGZMWi+SycizfrXFSK2KiSlk0wU0FhWQWGQqql2fVIuYmcjnzlP63r4w5fNT36T0VN5eRrLYz5CZxMVm4hBJbBHTWMoUGGOJNTLKCtJkJZ74tjar41CCCQyec61oJMUb4xCMF1lHH7Xl93eYIzuu4xJLz3zIOt9hFSNvR6E2nE9HWLvL1LrD0z0MDoOokxy/Gla5KzJO3b1lGTYtSOna+AuaKe4gpbMMrALfzTfpAAMmY70PSqqOuvGT2nkQOj8l5+md0pe8JWz2C+TKiMfEmTzzQinjK8i/aPI+HURBOooTebifz4WcFZRuZkaDa+W3XiC8omP2/eTuljM9m3IaCTQHkFVwt/NWXXOkf2MNr64=", "SpamDiagnosticOutput": "1:99", "SpamDiagnosticMetadata": "NSPM", "X-OriginatorOrg": "caviumnetworks.com", "X-MS-Exchange-CrossTenant-OriginalArrivalTime": "01 Aug 2018 06:59:37.7868\n\t(UTC)", "X-MS-Exchange-CrossTenant-Network-Message-Id": "f7bdcda3-c4ae-4131-ca9c-08d5f77c5cb4", "X-MS-Exchange-CrossTenant-FromEntityHeader": "Hosted", "X-MS-Exchange-CrossTenant-Id": "711e4ccf-2e9b-4bcf-a551-4094005b6194", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "SN6PR07MB4911", "Subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 84432, "web_url": "http://patches.dpdk.org/comment/84432/", "msgid": "<20180801095414.7bc34b30@xeon-e3>", "list_archive_url": "https://inbox.dpdk.org/dev/20180801095414.7bc34b30@xeon-e3", "date": "2018-08-01T16:54:14", "subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "submitter": { "id": 27, "url": "http://patches.dpdk.org/api/people/27/?format=api", "name": "Stephen Hemminger", "email": "stephen@networkplumber.org" }, "content": "On Wed, 1 Aug 2018 12:29:50 +0530\n\"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com> wrote:\n\n> Hi Thomas,\n> \n> On 26-07-2018 22:27, Thomas Monjalon wrote:\n> > External Email\n> > \n> >> Anoob Joseph (12):\n> >> examples/l2fwd: move macro definitions to common header\n> >> examples/l2fwd: move structure definitions to common header\n> >> examples/l2fwd: move globally accessed vars to common header\n> >> examples/l2fwd: move dataplane code to new file\n> >> examples/l2fwd: remove unused header includes\n> >> examples/l2fwd: move drain buffers to new function\n> >> examples/l2fwd: optimize check for master core\n> >> examples/l2fwd: move periodic tasks to new function\n> >> examples/l2fwd: skip timer updates for non master cores\n> >> examples/l2fwd: move pkt send code to a new function\n> >> examples/l2fwd: use fprint instead of printf for usage print\n> >> examples/l2fwd: improvements to the usage print \n> > Maintainers of this app look to be against adding complexity.\n> >\n> > In order to get this series accepted, we need more discussions\n> > with more people involved.\n> > So it will miss 18.08.\n> >\n> > It can be discussed in a more global discussion about examples maintenance.\n> > If discussion does not happen, you can request it to the technical board.\n> > \n> Event dev framework and various adapters enable multiple packet handling \n> schemes, as opposed to the traditional polling on queues. But these \n> features are not integrated into any established example application. \n> There are specific example applications for event dev etc, which can be \n> used to analyze an event device or a particular eventdev adapter, but \n> there is no standard application which can be used to compare the real \n> world performance for a system when it's using event device for packet \n> handling and when it's done via polling on queues.\n> \n> The following patch submitted by Sunil was looking to address this issue \n> with l3fwd,\n> https://mails.dpdk.org/archives/dev/2018-March/093131.html\n> \n> Bruce & Jerin reviewed the patch and suggested the addition of helper \n> functions to abstract the event mode additions in applications,\n> https://mails.dpdk.org/archives/dev/2018-April/096879.html\n> \n> This effort of adding helper functions for eventmode was taken up \n> following the above suggestion. The idea is to add eventmode without \n> touching the existing code path. All the eventmode specific additions \n> would go into library so that these need not be repeated for every \n> application. And since there is no change in the existing code path, \n> performance for any vendor should not have any impact with the additions.\n> \n> The scope of this effort has increased since the submission, as now we \n> have Tx adapter as well. Sunil & Konstantin had clarified their \n> concerns, and gave green flag to this approach.\n> https://mails.dpdk.org/archives/dev/2018-June/105730.html\n> https://mails.dpdk.org/archives/dev/2018-July/106453.html\n> \n> I guess Bruce was opening this question to the community. For compute \n> intense applications like ipsec-secgw, eventmode might be the right \n> approach in the first place. Such complex applications would need a \n> scheduler to perform dynamic load balancing. Addition of eventmode in \n> l2fwd was to float around the idea which can then be scaled for more \n> complex applications.\n> \n> If maintainers doesn't have any objection to this, I'm fine with adding \n> this in the next release.\n> \n> Thanks,\n> Anoob\n\nIt is important that DPDK has good examples of how to use existing\nframeworks and libraries. These applications are what most customers\nbuild their applications from and they provide basis for testing.\n\nThe DPDK needs to continue to support multiple usage models. This\nis one of its strong points. I would rather leave existing l2fwd\nand l3fwd alone and instead make new examples that use the frameworks.\nIf nothing else haveing l2fwd and l2fwd-eventdev would allow for\nperformance comparisons.\n\nAs the number of examples increases, probably also need to have\na roadmap or decision chart to explain the advangage/disadvantage\nof each architecture.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 1A9A81B149;\n\tWed, 1 Aug 2018 18:54:19 +0200 (CEST)", "from mail-pl0-f41.google.com (mail-pl0-f41.google.com\n\t[209.85.160.41]) by dpdk.org (Postfix) with ESMTP id BD5BC1B067\n\tfor <dev@dpdk.org>; Wed, 1 Aug 2018 18:54:17 +0200 (CEST)", "by mail-pl0-f41.google.com with SMTP id u11-v6so3536500plq.5\n\tfor <dev@dpdk.org>; Wed, 01 Aug 2018 09:54:17 -0700 (PDT)", "from xeon-e3 (204-195-22-127.wavecable.com. [204.195.22.127])\n\tby smtp.gmail.com with ESMTPSA id\n\ts14-v6sm46439632pfj.105.2018.08.01.09.54.16\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tWed, 01 Aug 2018 09:54:16 -0700 (PDT)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=networkplumber-org.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:in-reply-to:references\n\t:mime-version:content-transfer-encoding;\n\tbh=fX9LdCgScgWk/9QA8n3rlm9GcDckaufv3aDnPR/S1+0=;\n\tb=NpKrkUrtikDW1uZDJT547cFmjrdO2JfEyfkxoZIH42Xyf1CtnPrEAyJWesyjoIHMez\n\tzDyVNBSbTCfV4fzKh/5YnWXhAxPg/HhqlVuNfKs37G3rYu+MLTtCBhOaS2WUWK5L2+Pv\n\tG5xort9UrAxtmvtJ7jvfMJSekZtza5iiqn7Fdx4z5kiwmMGQBSxuT2HXOOa5Ze3R+793\n\tqe5+pDhML3B4/VIHCCrzoRHdVI7vZC0COR8eiOMbHGbkGQoqzO6NmRZei0Dt6NjbLp9n\n\twX4cIXwbGEoH3GPosF8zXAgP6I6kQ3iumJmjdUBh2wFguezsS9BrURWaNeaQFoPImdd/\n\t+6NQ==", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=fX9LdCgScgWk/9QA8n3rlm9GcDckaufv3aDnPR/S1+0=;\n\tb=bmifIae6B+RfloaLJlEQngUjvT5k49Keuexoxi2IFISJDWhdmB6UMDqUi065OTUYrA\n\t135HImd3dXSe+GHJWidT0KhdiLAsw8438GE1moESPrjrR9gCIGvWHJDeMdcb9GSlDyhN\n\tiyBqHhgX2UsAkFfW433EJL9qmIJfpyvIJyFFZXPXVYBwB4Oeyz6+C1j43IyR2AgwAfU0\n\ttE26pwtu0qfzl+M+cMp9HuQXKKTuW7jMpLK0TCSTUdXv9trpxkWAO5O7ZivzNOJKEBE/\n\t461dHBVdbeQEMv9kNS7ZlaWdP8jhFRCet5N/u2/BtlZOKiUe98+U/nXAf+rb+NCT5sGX\n\tcRXQ==", "X-Gm-Message-State": "AOUpUlGWCGYyY5g54qw8mkqVjPZKIBwxgtxquQ0T8RIgIc2MmzIlRRnR\n\tfwzXi5l3B0EvJaaVtqfBapw7rA==", "X-Google-Smtp-Source": "AAOMgpfCRKHGE7XOZkxkoWfig0a8LdOY6t9QcyKCEBEKH1yR9/qqYNAmz7//fWMOsp2u6wN2eCbSdQ==", "X-Received": "by 2002:a17:902:9a06:: with SMTP id\n\tv6-v6mr12736359plp.316.1533142456813; \n\tWed, 01 Aug 2018 09:54:16 -0700 (PDT)", "Date": "Wed, 1 Aug 2018 09:54:14 -0700", "From": "Stephen Hemminger <stephen@networkplumber.org>", "To": "\"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com>", "Cc": "Thomas Monjalon <thomas@monjalon.net>, dev@dpdk.org, Bruce Richardson\n\t<bruce.richardson@intel.com>, Pablo de Lara\n\t<pablo.de.lara.guarch@intel.com>, Jerin Jacob\n\t<jerin.jacob@caviumnetworks.com>, Narayana Prasad\n\t<narayanaprasad.athreya@caviumnetworks.com>, Hemant Agrawal\n\t<hemant.agrawal@nxp.com>, \"Ananyev, Konstantin\"\n\t<konstantin.ananyev@intel.com>, Sunil Kumar Kori <sunil.kori@nxp.com>,\n\tNikhil Rao <nikhil.rao@intel.com>", "Message-ID": "<20180801095414.7bc34b30@xeon-e3>", "In-Reply-To": "<e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com>", "References": "<1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<1531289248-20025-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<3685021.sWt9K18E1B@xps>\n\t<e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=US-ASCII", "Content-Transfer-Encoding": "7bit", "Subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 84433, "web_url": "http://patches.dpdk.org/comment/84433/", "msgid": "<20180801172628.GA471@jerin>", "list_archive_url": "https://inbox.dpdk.org/dev/20180801172628.GA471@jerin", "date": "2018-08-01T17:26:30", "subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "submitter": { "id": 305, "url": "http://patches.dpdk.org/api/people/305/?format=api", "name": "Jerin Jacob", "email": "jerin.jacob@caviumnetworks.com" }, "content": "-----Original Message-----\n> Date: Wed, 1 Aug 2018 09:54:14 -0700\n> From: Stephen Hemminger <stephen@networkplumber.org>\n> To: \"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com>\n> Cc: Thomas Monjalon <thomas@monjalon.net>, dev@dpdk.org, Bruce Richardson\n> <bruce.richardson@intel.com>, Pablo de Lara\n> <pablo.de.lara.guarch@intel.com>, Jerin Jacob\n> <jerin.jacob@caviumnetworks.com>, Narayana Prasad\n> <narayanaprasad.athreya@caviumnetworks.com>, Hemant Agrawal\n> <hemant.agrawal@nxp.com>, \"Ananyev, Konstantin\"\n> <konstantin.ananyev@intel.com>, Sunil Kumar Kori <sunil.kori@nxp.com>,\n> Nikhil Rao <nikhil.rao@intel.com>\n> Subject: Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n> additions\n> \n> \n> On Wed, 1 Aug 2018 12:29:50 +0530\n> \"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com> wrote:\n> \n> > Hi Thomas,\n> >\n> > On 26-07-2018 22:27, Thomas Monjalon wrote:\n> > > External Email\n> > >\n> > >> Anoob Joseph (12):\n> > >> examples/l2fwd: move macro definitions to common header\n> > >> examples/l2fwd: move structure definitions to common header\n> > >> examples/l2fwd: move globally accessed vars to common header\n> > >> examples/l2fwd: move dataplane code to new file\n> > >> examples/l2fwd: remove unused header includes\n> > >> examples/l2fwd: move drain buffers to new function\n> > >> examples/l2fwd: optimize check for master core\n> > >> examples/l2fwd: move periodic tasks to new function\n> > >> examples/l2fwd: skip timer updates for non master cores\n> > >> examples/l2fwd: move pkt send code to a new function\n> > >> examples/l2fwd: use fprint instead of printf for usage print\n> > >> examples/l2fwd: improvements to the usage print\n> > > Maintainers of this app look to be against adding complexity.\n> > >\n> > > In order to get this series accepted, we need more discussions\n> > > with more people involved.\n> > > So it will miss 18.08.\n> > >\n> > > It can be discussed in a more global discussion about examples maintenance.\n> > > If discussion does not happen, you can request it to the technical board.\n> > >\n> > Event dev framework and various adapters enable multiple packet handling\n> > schemes, as opposed to the traditional polling on queues. But these\n> > features are not integrated into any established example application.\n> > There are specific example applications for event dev etc, which can be\n> > used to analyze an event device or a particular eventdev adapter, but\n> > there is no standard application which can be used to compare the real\n> > world performance for a system when it's using event device for packet\n> > handling and when it's done via polling on queues.\n> >\n> > The following patch submitted by Sunil was looking to address this issue\n> > with l3fwd,\n> > https://mails.dpdk.org/archives/dev/2018-March/093131.html\n> >\n> > Bruce & Jerin reviewed the patch and suggested the addition of helper\n> > functions to abstract the event mode additions in applications,\n> > https://mails.dpdk.org/archives/dev/2018-April/096879.html\n> >\n> > This effort of adding helper functions for eventmode was taken up\n> > following the above suggestion. The idea is to add eventmode without\n> > touching the existing code path. All the eventmode specific additions\n> > would go into library so that these need not be repeated for every\n> > application. And since there is no change in the existing code path,\n> > performance for any vendor should not have any impact with the additions.\n> >\n> > The scope of this effort has increased since the submission, as now we\n> > have Tx adapter as well. Sunil & Konstantin had clarified their\n> > concerns, and gave green flag to this approach.\n> > https://mails.dpdk.org/archives/dev/2018-June/105730.html\n> > https://mails.dpdk.org/archives/dev/2018-July/106453.html\n> >\n> > I guess Bruce was opening this question to the community. For compute\n> > intense applications like ipsec-secgw, eventmode might be the right\n> > approach in the first place. Such complex applications would need a\n> > scheduler to perform dynamic load balancing. Addition of eventmode in\n> > l2fwd was to float around the idea which can then be scaled for more\n> > complex applications.\n> >\n> > If maintainers doesn't have any objection to this, I'm fine with adding\n> > this in the next release.\n> >\n> > Thanks,\n> > Anoob\n> \n> It is important that DPDK has good examples of how to use existing\n> frameworks and libraries. These applications are what most customers\n> build their applications from and they provide basis for testing.\n> \n> The DPDK needs to continue to support multiple usage models. This\n> is one of its strong points. I would rather leave existing l2fwd\n> and l3fwd alone and instead make new examples that use the frameworks.\n> If nothing else haveing l2fwd and l2fwd-eventdev would allow for\n> performance comparisons.\n\nUnlike other applications example, there wont be any change in packet\nprocessing functions in eventdev vs poll mode case. Only worker\nschematics will change and that can be moved to separated files.\nsomething like worker_poll.c and worker_event.c and both of them\nuse common packet processing functions using mbuf.\n\nThe only disadvantage of having separate application would be packet\nprocessing code duplication. Which is non trivial for l3fwd, IPSec\napplication IMO.\n\n# Are we fine with code duplication in example application like l3fwd and\nIPSec?\n# if yes, Are we fine with keeping l2fwd _as is_ to reduce the \ncomplexity and l2fwd-eventdev supports both modes wherever possible?\n\n> \n> As the number of examples increases, probably also need to have\n> a roadmap or decision chart to explain the advangage/disadvantage\n> of each architecture.\n>", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 190A31B1ED;\n\tWed, 1 Aug 2018 19:26:57 +0200 (CEST)", "from NAM01-SN1-obe.outbound.protection.outlook.com\n\t(mail-sn1nam01on0047.outbound.protection.outlook.com [104.47.32.47])\n\tby dpdk.org (Postfix) with ESMTP id 63B5E1B1CC\n\tfor <dev@dpdk.org>; Wed, 1 Aug 2018 19:26:55 +0200 (CEST)", "from jerin (106.201.44.195) by\n\tBYAPR07MB4998.namprd07.prod.outlook.com (2603:10b6:a03:5b::23) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1017.15; Wed, 1 Aug 2018 17:26:46 +0000" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=Ll8SEwP4eQG79nUKxzyz7aoCs+rWsFjO8/PMO+YsKdg=;\n\tb=Zl/I8yFAwE4ZSbOQy8Rs95FZ3kshZo2SYdsXoAzI6SLdTRukMJurcEWGBN13oBd7IHbEQ36SX1C6gCeP5+to81Q+DMXNubxC06wRdTx04fhlr/va2xHCe3Hsuw9uM+0WLHFsP51X/Uw4135jtjv3EB+5AwcwErJE6OjWohNVjXo=", "Authentication-Results": "spf=none (sender IP is )\n\tsmtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; ", "Date": "Wed, 1 Aug 2018 22:56:30 +0530", "From": "Jerin Jacob <jerin.jacob@caviumnetworks.com>", "To": "Stephen Hemminger <stephen@networkplumber.org>", "Cc": "\"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com>,\n\tThomas Monjalon <thomas@monjalon.net>, dev@dpdk.org,\n\tBruce Richardson <bruce.richardson@intel.com>,\n\tPablo de Lara <pablo.de.lara.guarch@intel.com>,\n\tNarayana Prasad <narayanaprasad.athreya@caviumnetworks.com>,\n\tHemant Agrawal <hemant.agrawal@nxp.com>,\n\t\"Ananyev, Konstantin\" <konstantin.ananyev@intel.com>,\n\tSunil Kumar Kori <sunil.kori@nxp.com>, Nikhil Rao <nikhil.rao@intel.com>", "Message-ID": "<20180801172628.GA471@jerin>", "References": "<1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<1531289248-20025-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<3685021.sWt9K18E1B@xps>\n\t<e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com>\n\t<20180801095414.7bc34b30@xeon-e3>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<20180801095414.7bc34b30@xeon-e3>", "User-Agent": "Mutt/1.10.1 (2018-07-13)", "X-Originating-IP": "[106.201.44.195]", "X-ClientProxiedBy": "PN1PR0101CA0064.INDPRD01.PROD.OUTLOOK.COM\n\t(2603:1096:c00:d::26) To BYAPR07MB4998.namprd07.prod.outlook.com\n\t(2603:10b6:a03:5b::23)", "X-MS-PublicTrafficType": "Email", "X-MS-Office365-Filtering-Correlation-Id": "254eabcc-8ef5-4a99-f4eb-08d5f7d3f89c", "X-Microsoft-Antispam": "BCL:0; PCL:0;\n\tRULEID:(7020095)(4652040)(8989117)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020);\n\tSRVR:BYAPR07MB4998; ", "X-Microsoft-Exchange-Diagnostics": [ "1; BYAPR07MB4998;\n\t3:7i0m35qDLw4HAOqH5i4acVXeC+Vq/IAKzA4EJm/PXBxA5wRlySHR3RQkHBN6zyWaBPncig1OlI6N6/SiDcvUOw7E9EXUTcPM67umx1a34s5B/cqa95VBopW2ACYZoOpU7qnN1d+NEraVkyKzHf1zMTRlJhE8NamSbS+8Ez6bYnm+8Y9OO8W2Vfn4t64FNZqbGiBmcqh/aYLKPWuhNgT81oN8EzqjXtpphJzsYheV6meMwKAyzrL2YEyFkImJDbF9;\n\t25:3qsrfLk8xPksHEMBgFT2CoCLOT2kvkuQ3anEkmzpkkvkgN2b34zpPC57IiVpjIjMSZfbO3eyoIXFuS7yFGQ1sNhdjTpom+PYS+ZeXn/6YosknHLZaB3xTFDjhx/pM5D3zD/ps5uZVt1Cl6l9MGYIClSRecaA+Q/Hmq9/RlHvf9fTeWH4M4dCRrAsVaxUi/DsXVlbikLK1rWciwaJOEj6cc+2OfZC6goM6HkB+khqJFMh64q+kblRjawWzhjAZ6aYgp8g2frPiJV0Jty6iLAUHn3tz0+/djU51bh8bBM4k/vGtLUVI0G1yVGnzsv/siKRC41x5c8SyHpYNLwf/C8GHw==;\n\t31:+w6ws3hI4aj8lp8M3/UlYHF2jqymM2BbgFzuPvhHnUMdNh3EGjFnpZI0zHxDzEnZulLNP7U/lGqu7QrF8SnEzvZh4eSo6SABn/XISC1V6XepCQUoYpQsZiXCb+WPzvPU+g5yuHX5Uzxbmr89L9rURtg9NGXrR0wqJbu3Rh+iBjWNGxB7YPMqsOZUSQV0XyQV9L5/xQvICdLdIEaM/MCZDn8UpgDvZs+WgQyIBxTv6yE=", "1; BYAPR07MB4998;\n\t20:QSfOfMzMYxZ5BYVr9Jbg3tdDhWY+dLZUw09QAzQcUnSaKb1zOZcI8ufo8cxvuKWHXi/bsNBnAqqLy9/6ABhQpMlovID456+DbVZ9Gl5eCwRc7YfQT9jktQF9TfSZ7cuvpLU0ZkL7rO7i1tghHFH6NNL+YcZlS81MVqQAFUuPgSPA6JzZZdJq8DEb3aGskADyw97gRdf2zGyuJx4iedt2aCtucatJTHa2pnh21dM+7Qsac/7yEsFv+gGJUMY5rJ+2pM18S50gEqlSJeaofrw+FTTpBa3YpIZWz1793LfTsLm0WHWvNTSGMZi/E3Y2qfR6cQWJEYC/lpHvqJ9HeP9lNd4iyUtrVC2QCUYOpXsjQln3IyRWH1EnGMYj7oCDFHdWB9Bkp+16JayIV0f+HcQI2M+88vU1iw1MEyqD/81b1TZlUdl8GxTdVS99hZ+swXH9q6xTkZCt3GEY+LeCP+TqkTASCVTgsKunuk1Qg0/7UlS5FDbYhQCtQfGFuf5F9Ue9V5sNxNc20QlgwoyJqWAcMzeh/OsSCRh8+6dZYqnT0vdBYWt5A3LduLAHzAOZERL8PRx5aaIQll/nP99HXqMoDvZrPoDYhqbeyaQ+n0Y7JgM=", "1; BYAPR07MB4998;\n\t4:8UDjYuyr4VE5DwPfqmEH6isQNiWzKsEfBOl7wpXDMkQSJ3ju8EDNisyIIJlU+5QYJAY9rBTs2RAQIW5nBCR3o/3PE+sRzy7L+D0UrpzyZ92W5schRYMHkMsdDZsVm0m9S+FFJp/f3EgdKDdoH+2rfnOgin4iiB8reEK0mccu6enASgeesG+j6HwwHEaNv7uYEzQtDngSPUPyXpSw91QMuRtucNQL6nHT8SaPklmIew2discgWvmpCjpghYWGiwIXvcnBdc8jdmuAGSDC1BnzFPspIFJtYEhG3DiQdOaZrpV8NPAYq99S3GMTy6OyMvzQR9Te4zPAgRjIm0PIYJW/hsBxxsWKRTtgpev/rvYlV74wRJHhKBBy97QrJWSxfO8k", "=?us-ascii?Q?1; BYAPR07MB4998;\n\t23:KAzlmArie2B+no57DfhRlHKPtVyq4XKyQcNyisBuo?=\n\tO42xnUh6Zia0K5UCx+xM0UgDFvUzvpiUCO+y47gYTHMOOzohTMtg3wlQN1FVguzoSMfkw4SIyu/1V/ZYnbDsyqvrkewVWqZ5jq40d2BqL1OOzlfPW1V1F0dXzW/MZhHVsekPHbC31MSGNwnQr5/c9vLU9/l5TGbcXZyzwJHjtX/lPX6eZGTRcwhfMc0GOI8uSyIno2sPLNaCZZqfKli5duRO2YJG4vxZUFq/fjwwIHttSHwpPqGeMdN2zwRoYmtfjEIY8YfQB5sNsKCxIeFSYFYalMllD2pqxdMtDRWELk0mHCYIJSj7PnBsE0PCX3A8E3lHvuOIybKb4ETSn5bkHBLq4cYEd87STMapK1PPRVjhKLMM32fEeFX67Lvh8tXdaW3lJDSkkrkze9I/y0Dow+LxknBLShy2hCWYt72R0VaLAbvWby1iV6eEBavljcfleaABUbbf1LjnaTwSoHE7tMIVxS+5awn3NcRea/fonL2acAAoq86VcjpIHLdsMIa5EUOPYiNpybdCUG9agTrOhjWZ6RjBi6SrhC0hbxG32tJYxbfvbVe5HA24mC+KS1Wv3+pfC4SiQ46dowu7lxY14IhAyQpkVHzxHmLt8R/UBK6NZtgy42dWevgpIjE/DlM2C4SYEwe2rqOlUrMKwfquawpCBqrd5Wuo30sNLegPv9dgbn94Ug26uj5tvEbAs5aQF1f+x0L8p332Z1FwelHRWRn17mDngCjUD549kkKhIYhFf4G/yj0xIcpeZZ3qKMy9n5PY8Ek9mdwkpikv79tOLXhCb8ZOBbohjegXLPBA/DyBskZMNRXCiQOaN/286ZQxrp9cHEku3KDYGQbi+TwWcdUiCr2BGFne+D8+Bu+76P1vixNQi1wKeRKpc6HXaxiZjCW/qKoCr2wXm0cV7o8GclVwm8TMy1tDqXRbsGhP1T4NJPDRoUOJzfGKw19ScwcKSdXpo2kEvUKeFwTMgLFNJUEu3++GdwNjYVpsZc2vxPOpX1aQN6/SkooF45AN6C6/ltzVRlDCBeTlHLeQR68z2j7mWABSVvDXh4d+fcy7NlCT77WHxiduAJL39bllh+DzwqZFd9lMRajOcV90rxrQx/gSD7t/ZtPG3nz5p/S1hAuskPQsGt/vD56BRQd0bhuRgi43MP3Dys8ZC8qTA17dwUu3iBkjWXFkUqwq4KhwYlL+5BHTcaU/BH+MmWsZYjHMTPSaxC0uh4Jo1II8QoAIes/9P1CHV8j91x8znK5g3SwMaWpEUU5z9YtTDmokiERNpQdEbVzSpZwzz8GF/OgcVx1yN6IerHwQEijeMzkTK5+Ds4a0Vk6xqg7N1+y/WAohUsdIwM+LZg8uAcFyON1SdHWXSrwIfcPn7K/bsCQZhdK3w2/Q5fbpY8VInNkbWHS6dQhigucJKD4lOhtrAQwnv1jiVFzLn7w+JllGgHSxOezOY+Tm5RnY/wmfyQWHKd8/2M=", "1; BYAPR07MB4998;\n\t6:RIrfZ3yt1WilZ0BRWGd1zrP10XzEDm0Cn02NLwOl8OQFsffmi23hW9vpTeULSkjZxsa9SkyQHp8daV8UIdHZwwLWRje6I6Wr4TBfdr3oMNalty8Ygeqm3qDBPECEsls2hvn9Y6uMuZ80HTlbhY/3U5qTpSthppBuWta2I1J7xUb7NbbiWvIEsyarnUu7mUmqStoPLeXvK9LX//++LnQAIGOVkycmjhrbVPxYKK2GWncDKmixp5KFA8Wb6bcPrABho7SriZ4i/8jbDuQkWyFdjQswECyiGRy+z99Agrs28uD6b4OxzaMbIvDG4FvLXcVx5OJj5QkVoZNuEjHObKuTAynEkKyXuQlOp14DVmjj+7wW6GB1dN5MzHAKd6FPcbGwXEH5wEcHhMv+s3kashxoLCUmZYZUdfB9k6mVeLg95DLU7Z9NtRstUSia44OLsgZ3SQOR/3DRwOxSuwRLYmFZXg==;\n\t5:qz37v7eiELf3mjRgB1QTuDaNZHZSGMMC4aqFpk4IAjtjZQn88VMY5PhYMkFmDreVkM+kyiO0wG8YQwcnSQhRQH0afD+TZG0d9hS1gfzyetAjMd6yI+AGO0tBf0yKFB0BbWP9iwH1H7cm2NNaDcjfdC4lP1TqCrAtGldA41VksII=;\n\t7:/OsaQkC/MkFqsqAIKwr4nBmrQ4W0cJ+Uu7TGledtJ9PPees4P+EFdJAgYGLCS7ThLf85GlgFK2wBKmIiGpuwLcCbABlcgd3f/WZbb8h0K73SNru3kO6gycTX06IV6OXO8JsB89fpLxgescLrA6LUYi7R3RZX7bfm3pEgo1mVGrnP22AvwTpf8+LngYR40prO/zXGKSHzaH60ladTbVBrN4qn8XHjMIS9Hg7570dJHeXwomHRGQ2/84iZKAVoX0sE" ], "X-MS-TrafficTypeDiagnostic": "BYAPR07MB4998:", "X-Microsoft-Antispam-PRVS": "<BYAPR07MB499804AD3607B7A504344C85E32D0@BYAPR07MB4998.namprd07.prod.outlook.com>", "X-Exchange-Antispam-Report-Test": "UriScan:(278428928389397)(185117386973197)(228905959029699); ", "X-MS-Exchange-SenderADCheck": "1", "X-Exchange-Antispam-Report-CFA-Test": "BCL:0; PCL:0;\n\tRULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(10201501046)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016);\n\tSRVR:BYAPR07MB4998; BCL:0; PCL:0; RULEID:; SRVR:BYAPR07MB4998; ", "X-Forefront-PRVS": "0751474A44", "X-Forefront-Antispam-Report": "SFV:NSPM;\n\tSFS:(10009020)(376002)(136003)(39850400004)(396003)(346002)(366004)(52164004)(189003)(199004)(13464003)(16526019)(966005)(26005)(446003)(14444005)(476003)(9686003)(6306002)(55016002)(72206003)(8676002)(81156014)(33896004)(386003)(53546011)(6246003)(33656002)(55236004)(44832011)(5009440100003)(956004)(11346002)(50466002)(76176011)(486006)(53936002)(81166006)(186003)(58126008)(42882007)(54906003)(47776003)(7736002)(97736004)(6496006)(68736007)(316002)(4326008)(52116002)(305945005)(2906002)(25786009)(106356001)(478600001)(229853002)(1076002)(66066001)(5660300001)(23726003)(105586002)(6666003)(33716001)(16586007)(6916009)(93886005)(6116002)(8936002)(3846002)(18370500001);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR07MB4998; H:jerin; FPR:; SPF:None;\n\tLANG:en; PTR:InfoNoRecords; MX:1; A:1; ", "Received-SPF": "None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)", "X-Microsoft-Antispam-Message-Info": "9bSrT6sjEwELLwN4gnFa+leYeu4AxGvWwTea07w3M2JAoLKh9GwSAJ606uD33ev5V/kV5iLLmsWJFrVtZxIqERz25n34KdPbnnSr5zVA7bDYw18uTjn1QqyvkZLrL0un8y0zvO9M7nRNdM4vm1CNwiz6yjo9QjLZFPXCXpKyLz1BYaxHEKijm6PI/ruMIyqGYpcjdRoelvPwVRlTaeMNgxzHf6Qmn1ut47JkuiAXBhop8AmfUnHCXF/XxRbZNjnW6CPkHEDj67SfAPEpvv85DDvsS9sG8DGnkntquA4sGgDvBpi0khrB5Vyk5S3DJVu5HZlYFrJJc/7+UegoRRGkjHuDVXtFmmjuP2gZHrYoVqo=", "SpamDiagnosticOutput": "1:99", "SpamDiagnosticMetadata": "NSPM", "X-OriginatorOrg": "caviumnetworks.com", "X-MS-Exchange-CrossTenant-OriginalArrivalTime": "01 Aug 2018 17:26:46.5198\n\t(UTC)", "X-MS-Exchange-CrossTenant-Network-Message-Id": "254eabcc-8ef5-4a99-f4eb-08d5f7d3f89c", "X-MS-Exchange-CrossTenant-FromEntityHeader": "Hosted", "X-MS-Exchange-CrossTenant-Id": "711e4ccf-2e9b-4bcf-a551-4094005b6194", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR07MB4998", "Subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 84459, "web_url": "http://patches.dpdk.org/comment/84459/", "msgid": "<2601191342CEEE43887BDE71AB977258E6D4D959@IRSMSX102.ger.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/2601191342CEEE43887BDE71AB977258E6D4D959@IRSMSX102.ger.corp.intel.com", "date": "2018-08-02T08:19:53", "subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "submitter": { "id": 33, "url": "http://patches.dpdk.org/api/people/33/?format=api", "name": "Ananyev, Konstantin", "email": "konstantin.ananyev@intel.com" }, "content": "Hi everyone,\n\n> > > >\n> > > > In order to get this series accepted, we need more discussions\n> > > > with more people involved.\n> > > > So it will miss 18.08.\n> > > >\n> > > > It can be discussed in a more global discussion about examples maintenance.\n> > > > If discussion does not happen, you can request it to the technical board.\n> > > >\n> > > Event dev framework and various adapters enable multiple packet handling\n> > > schemes, as opposed to the traditional polling on queues. But these\n> > > features are not integrated into any established example application.\n> > > There are specific example applications for event dev etc, which can be\n> > > used to analyze an event device or a particular eventdev adapter, but\n> > > there is no standard application which can be used to compare the real\n> > > world performance for a system when it's using event device for packet\n> > > handling and when it's done via polling on queues.\n> > >\n> > > The following patch submitted by Sunil was looking to address this issue\n> > > with l3fwd,\n> > > https://mails.dpdk.org/archives/dev/2018-March/093131.html\n> > >\n> > > Bruce & Jerin reviewed the patch and suggested the addition of helper\n> > > functions to abstract the event mode additions in applications,\n> > > https://mails.dpdk.org/archives/dev/2018-April/096879.html\n> > >\n> > > This effort of adding helper functions for eventmode was taken up\n> > > following the above suggestion. The idea is to add eventmode without\n> > > touching the existing code path. All the eventmode specific additions\n> > > would go into library so that these need not be repeated for every\n> > > application. And since there is no change in the existing code path,\n> > > performance for any vendor should not have any impact with the additions.\n> > >\n> > > The scope of this effort has increased since the submission, as now we\n> > > have Tx adapter as well. Sunil & Konstantin had clarified their\n> > > concerns, and gave green flag to this approach.\n> > > https://mails.dpdk.org/archives/dev/2018-June/105730.html\n> > > https://mails.dpdk.org/archives/dev/2018-July/106453.html\n> > >\n> > > I guess Bruce was opening this question to the community. For compute\n> > > intense applications like ipsec-secgw, eventmode might be the right\n> > > approach in the first place. Such complex applications would need a\n> > > scheduler to perform dynamic load balancing. Addition of eventmode in\n> > > l2fwd was to float around the idea which can then be scaled for more\n> > > complex applications.\n> > >\n> > > If maintainers doesn't have any objection to this, I'm fine with adding\n> > > this in the next release.\n> > >\n> > > Thanks,\n> > > Anoob\n> >\n> > It is important that DPDK has good examples of how to use existing\n> > frameworks and libraries. These applications are what most customers\n> > build their applications from and they provide basis for testing.\n> >\n> > The DPDK needs to continue to support multiple usage models. This\n> > is one of its strong points. I would rather leave existing l2fwd\n> > and l3fwd alone and instead make new examples that use the frameworks.\n> > If nothing else haveing l2fwd and l2fwd-eventdev would allow for\n> > performance comparisons.\n> \n> Unlike other applications example, there wont be any change in packet\n> processing functions in eventdev vs poll mode case. Only worker\n> schematics will change and that can be moved to separated files.\n> something like worker_poll.c and worker_event.c and both of them\n> use common packet processing functions using mbuf.\n> \n> The only disadvantage of having separate application would be packet\n> processing code duplication. Which is non trivial for l3fwd, IPSec\n> application IMO.\n\nPersonally I am ok with original design suggestion: \nkeep packet processing code common, that would be used by both poll and event modes. \nWe could just have a command-line parameter in which mode the app will run.\nAnother alternative - generate two binaries l2fwd-poll, l2fwd-event (or so).\nKonstantin\n> \n> # Are we fine with code duplication in example application like l3fwd and\n> IPSec?\n> # if yes, Are we fine with keeping l2fwd _as is_ to reduce the\n> complexity and l2fwd-eventdev supports both modes wherever possible?\n> \n> >\n> > As the number of examples increases, probably also need to have\n> > a roadmap or decision chart to explain the advangage/disadvantage\n> > of each architecture.\n> >", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id DCB2D1B450;\n\tThu, 2 Aug 2018 10:19:57 +0200 (CEST)", "from mga12.intel.com (mga12.intel.com [192.55.52.136])\n\tby dpdk.org (Postfix) with ESMTP id C77C21B44B\n\tfor <dev@dpdk.org>; Thu, 2 Aug 2018 10:19:56 +0200 (CEST)", "from fmsmga001.fm.intel.com ([10.253.24.23])\n\tby fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t02 Aug 2018 01:19:55 -0700", "from irsmsx105.ger.corp.intel.com ([163.33.3.28])\n\tby fmsmga001.fm.intel.com with ESMTP; 02 Aug 2018 01:19:54 -0700", "from irsmsx102.ger.corp.intel.com ([169.254.2.110]) by\n\tirsmsx105.ger.corp.intel.com ([169.254.7.195]) with mapi id\n\t14.03.0319.002; Thu, 2 Aug 2018 09:19:53 +0100" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.51,434,1526367600\"; d=\"scan'208\";a=\"77650941\"", "From": "\"Ananyev, Konstantin\" <konstantin.ananyev@intel.com>", "To": "Jerin Jacob <jerin.jacob@caviumnetworks.com>, Stephen Hemminger\n\t<stephen@networkplumber.org>", "CC": "\"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com>, Thomas Monjalon\n\t<thomas@monjalon.net>, \"dev@dpdk.org\" <dev@dpdk.org>, \"Richardson, Bruce\"\n\t<bruce.richardson@intel.com>, \"De Lara Guarch, Pablo\"\n\t<pablo.de.lara.guarch@intel.com>, Narayana Prasad\n\t<narayanaprasad.athreya@caviumnetworks.com>, Hemant Agrawal\n\t<hemant.agrawal@nxp.com>, Sunil Kumar Kori <sunil.kori@nxp.com>, \"Rao,\n\tNikhil\" <nikhil.rao@intel.com>", "Thread-Topic": "[dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "Thread-Index": "AQHUKWVEpfA3xxjs9ka3kRVIAeujS6SrDP8AgAAJBACAAQjiQA==", "Date": "Thu, 2 Aug 2018 08:19:53 +0000", "Message-ID": "<2601191342CEEE43887BDE71AB977258E6D4D959@IRSMSX102.ger.corp.intel.com>", "References": "<1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<1531289248-20025-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<3685021.sWt9K18E1B@xps>\n\t<e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com>\n\t<20180801095414.7bc34b30@xeon-e3> <20180801172628.GA471@jerin>", "In-Reply-To": "<20180801172628.GA471@jerin>", "Accept-Language": "en-IE, en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-titus-metadata-40": "eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTEwNmFkYmYtYTRhZS00NzY3LThkYWYtYTc2ZDkyMjYwMTNlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiS04zRmRTUzRhUFl3UzYyVTRQcTVmRW1QQWwwbzMzUmJNMzQ3M00zakpvRm5hNlwvU3hZMjhuVGM4XC8zeVBxSmpUIn0=", "x-ctpclassification": "CTP_NT", "dlp-product": "dlpe-windows", "dlp-version": "11.0.400.15", "dlp-reaction": "no-action", "x-originating-ip": "[163.33.239.180]", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "Subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 84705, "web_url": "http://patches.dpdk.org/comment/84705/", "msgid": "<fd4dd899-00b2-b7e3-6acc-29af0571ce2f@caviumnetworks.com>", "list_archive_url": "https://inbox.dpdk.org/dev/fd4dd899-00b2-b7e3-6acc-29af0571ce2f@caviumnetworks.com", "date": "2018-08-13T07:22:19", "subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "submitter": { "id": 893, "url": "http://patches.dpdk.org/api/people/893/?format=api", "name": "Anoob Joseph", "email": "anoob.joseph@caviumnetworks.com" }, "content": "Hi Bruce, Pablo,\n\nIf there are no more issues about the approach, can you review the \npatches and give the feedback?\n\nPlease do note that this series doesn't add any event mode specific \ncode. That will come as a different patch series after incorporating \nJerin's comments.\n\nThanks,\nAnoob\nOn 02-08-2018 13:49, Ananyev, Konstantin wrote:\n> External Email\n>\n> Hi everyone,\n>\n>>>>> In order to get this series accepted, we need more discussions\n>>>>> with more people involved.\n>>>>> So it will miss 18.08.\n>>>>>\n>>>>> It can be discussed in a more global discussion about examples maintenance.\n>>>>> If discussion does not happen, you can request it to the technical board.\n>>>>>\n>>>> Event dev framework and various adapters enable multiple packet handling\n>>>> schemes, as opposed to the traditional polling on queues. But these\n>>>> features are not integrated into any established example application.\n>>>> There are specific example applications for event dev etc, which can be\n>>>> used to analyze an event device or a particular eventdev adapter, but\n>>>> there is no standard application which can be used to compare the real\n>>>> world performance for a system when it's using event device for packet\n>>>> handling and when it's done via polling on queues.\n>>>>\n>>>> The following patch submitted by Sunil was looking to address this issue\n>>>> with l3fwd,\n>>>> https://mails.dpdk.org/archives/dev/2018-March/093131.html\n>>>>\n>>>> Bruce & Jerin reviewed the patch and suggested the addition of helper\n>>>> functions to abstract the event mode additions in applications,\n>>>> https://mails.dpdk.org/archives/dev/2018-April/096879.html\n>>>>\n>>>> This effort of adding helper functions for eventmode was taken up\n>>>> following the above suggestion. The idea is to add eventmode without\n>>>> touching the existing code path. All the eventmode specific additions\n>>>> would go into library so that these need not be repeated for every\n>>>> application. And since there is no change in the existing code path,\n>>>> performance for any vendor should not have any impact with the additions.\n>>>>\n>>>> The scope of this effort has increased since the submission, as now we\n>>>> have Tx adapter as well. Sunil & Konstantin had clarified their\n>>>> concerns, and gave green flag to this approach.\n>>>> https://mails.dpdk.org/archives/dev/2018-June/105730.html\n>>>> https://mails.dpdk.org/archives/dev/2018-July/106453.html\n>>>>\n>>>> I guess Bruce was opening this question to the community. For compute\n>>>> intense applications like ipsec-secgw, eventmode might be the right\n>>>> approach in the first place. Such complex applications would need a\n>>>> scheduler to perform dynamic load balancing. Addition of eventmode in\n>>>> l2fwd was to float around the idea which can then be scaled for more\n>>>> complex applications.\n>>>>\n>>>> If maintainers doesn't have any objection to this, I'm fine with adding\n>>>> this in the next release.\n>>>>\n>>>> Thanks,\n>>>> Anoob\n>>> It is important that DPDK has good examples of how to use existing\n>>> frameworks and libraries. These applications are what most customers\n>>> build their applications from and they provide basis for testing.\n>>>\n>>> The DPDK needs to continue to support multiple usage models. This\n>>> is one of its strong points. I would rather leave existing l2fwd\n>>> and l3fwd alone and instead make new examples that use the frameworks.\n>>> If nothing else haveing l2fwd and l2fwd-eventdev would allow for\n>>> performance comparisons.\n>> Unlike other applications example, there wont be any change in packet\n>> processing functions in eventdev vs poll mode case. Only worker\n>> schematics will change and that can be moved to separated files.\n>> something like worker_poll.c and worker_event.c and both of them\n>> use common packet processing functions using mbuf.\n>>\n>> The only disadvantage of having separate application would be packet\n>> processing code duplication. Which is non trivial for l3fwd, IPSec\n>> application IMO.\n> Personally I am ok with original design suggestion:\n> keep packet processing code common, that would be used by both poll and event modes.\n> We could just have a command-line parameter in which mode the app will run.\n> Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so).\n> Konstantin\n>> # Are we fine with code duplication in example application like l3fwd and\n>> IPSec?\n>> # if yes, Are we fine with keeping l2fwd _as is_ to reduce the\n>> complexity and l2fwd-eventdev supports both modes wherever possible?\n>>\n>>> As the number of examples increases, probably also need to have\n>>> a roadmap or decision chart to explain the advangage/disadvantage\n>>> of each architecture.\n>>>", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 5050D37A2;\n\tMon, 13 Aug 2018 09:22:08 +0200 (CEST)", "from NAM02-SN1-obe.outbound.protection.outlook.com\n\t(mail-sn1nam02on0065.outbound.protection.outlook.com [104.47.36.65])\n\tby dpdk.org (Postfix) with ESMTP id 7AA4B2B83\n\tfor <dev@dpdk.org>; Mon, 13 Aug 2018 09:22:06 +0200 (CEST)", "from [10.88.100.222] (115.113.156.2) by\n\tBYAPR07MB4902.namprd07.prod.outlook.com (2603:10b6:a02:ef::25) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1038.19; Mon, 13 Aug 2018 07:21:58 +0000" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=y6wnaolOfWvaP2unOp9BBgDoJUFgWR8vfkJO/HMD8Hs=;\n\tb=PwBShjv3nDDX9GFS/viUV8O7Bggzi87An8mC6gGjmQlKh7P9baLMTX/CVL4T27yStsPH+39yHmCeZGhTtUdmRIkWJRG/bBWFi3Po4bN56Tcp5qfBqGV4+ewuKAgeU86dYgJJatoNEPOh3W+MAwvHucXxIgTk8By/R3y7asxA3YM=", "Authentication-Results": "spf=none (sender IP is )\n\tsmtp.mailfrom=Anoob.Joseph@cavium.com; ", "To": "Thomas Monjalon <thomas@monjalon.net>,\n\t\"Richardson, Bruce\" <bruce.richardson@intel.com>,\n\t\"De Lara Guarch, Pablo\" <pablo.de.lara.guarch@intel.com>", "Cc": "\"Ananyev, Konstantin\" <konstantin.ananyev@intel.com>,\n\tJerin Jacob <jerin.jacob@caviumnetworks.com>,\n\tStephen Hemminger <stephen@networkplumber.org>, \"dev@dpdk.org\"\n\t<dev@dpdk.org>,\n\tNarayana Prasad <narayanaprasad.athreya@caviumnetworks.com>, \n\tHemant Agrawal <hemant.agrawal@nxp.com>,\n\tSunil Kumar Kori <sunil.kori@nxp.com>, \"Rao,\n\tNikhil\" <nikhil.rao@intel.com>", "References": "<1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<1531289248-20025-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<3685021.sWt9K18E1B@xps>\n\t<e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com>\n\t<20180801095414.7bc34b30@xeon-e3> <20180801172628.GA471@jerin>\n\t<2601191342CEEE43887BDE71AB977258E6D4D959@IRSMSX102.ger.corp.intel.com>", "From": "\"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com>", "Message-ID": "<fd4dd899-00b2-b7e3-6acc-29af0571ce2f@caviumnetworks.com>", "Date": "Mon, 13 Aug 2018 12:52:19 +0530", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.9.1", "MIME-Version": "1.0", "In-Reply-To": "<2601191342CEEE43887BDE71AB977258E6D4D959@IRSMSX102.ger.corp.intel.com>", "Content-Type": "text/plain; charset=utf-8; format=flowed", "Content-Transfer-Encoding": "7bit", "Content-Language": "en-US", "X-Originating-IP": "[115.113.156.2]", "X-ClientProxiedBy": "PN1PR0101CA0050.INDPRD01.PROD.OUTLOOK.COM\n\t(2603:1096:c00:d::12) To BYAPR07MB4902.namprd07.prod.outlook.com\n\t(2603:10b6:a02:ef::25)", "X-MS-PublicTrafficType": "Email", "X-MS-Office365-Filtering-Correlation-Id": "9401f5ad-64c2-4a5e-322a-08d600ed7715", "X-Microsoft-Antispam": "BCL:0; PCL:0;\n\tRULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020);\n\tSRVR:BYAPR07MB4902; ", "X-Microsoft-Exchange-Diagnostics": [ "1; BYAPR07MB4902;\n\t3:uR7OS6MYvy+MI+juWlfXEuEcVXWZBRzHrYNmEt2qg94PF1lKK/A7jXGGHV2jfnUhzk6CMTxVU8qHghhKN/ROZ36BV1whA2MQAxUhHTko0KJbPuhTRHEl9VfEg6LcbAQsTfwQ171hNHTvXmH4jSLf/prSd83rUw5tsR8VeaEx6Y5B+799ScLQFxWU0ZNfO8ItAflZCpANX1L+vYxCzWClI5R9+2OUXnZzIc8W2LfSBynOFBwTJkJOv9Y2PTsbQLBt;\n\t25:mTK2S20uIx5OUVuLsMNP0ZEtefXGiWGDgAiZ50wfikWbN73wjyALBXMwQaUxkdhiKcGlOtJ53bEe+m6phXUa7QLXSmrAMAs2Sngs7N2XbZ/X6bBUlKsw/dhDF4kLT4+lGZbDzLF0Jmb6mR2+z+Hve+MNWTRtTs1MZfO02EAOCEomkyExIyaBpQ/wv2sksfwZerf5zlq/6xd/8G7fJqulJM09IzNkqWM6Op5izzHO6/g4Q2NdC1HhzgQF8zAHCmls0sFPj4sDvNVhgPrSNaTXyttJpS0Nf/Hb7Jh+wcdRGdYE8HornbW1o5Zy22QzGX50Xp1H2iRLTJBdiCmGbaxJNQ==;\n\t31:RY8aTbUyKMD39O+FliDLtSWdTbrSnQPfDjkei/OBB2xxHz+GkcTO5qJgm6keZQFIUrf1NNzvfkL892t1izik5zg3w74cFI+SbUyRc6kS61sW8mrRvnext+9v5BPEeXgl9JI1R6qyvgOvj/HuYZesPlguB+nNTiu2KEQZGJfjN/7id2+0W0j5VqLpz0c2zOzm5XoDDlGA7l3ZcYT8S33kvnxQrweJtD3oWknOjkI9dnc=", "1; BYAPR07MB4902;\n\t20:Gd863yWzpkoqVcmv4nf7kOWwOQgdA6d7hlq7oIcuDOw+RU4hz0eUrCInAU2nvvxmuBDmmV/zBRHJXeeEZTDbKqrdQYv5DlKngeEzP0tDOETOJFlbXIuqE3jZ8biUWclmEuxXcOdfdyeKw0W7t70uFvlAaK2i0IpO12Srtp+yZTfdx/wlBx05/nee1tN6btvfuEmKnXoch9aPqZb5HWfeAES109pCahA7koXIyiZ9ZySO25IlsGbYVFTYqIM6NJ6gmDAIV2q4iLp0cGl8yxdlzWigZOISAWz5Sg8zwUrn6DZPvfnlkhfpRCFE7y2Y1yPxxFQu3ZJKWQNxpoXw8ejTg5H+Si9o703eso8mVCnfU3hw8jDT68RgMosne28ee+O879M9flZCE73mnRSTgRUBtfhS96bUEGukAHwNIMA2ZPZsEm0/D3Cz3ETvRWYAoSjHq3I9Lyhl90pQcO6GxizJSTOSpBbva0ju1NioNQwbF49jpaq4rU39o505vVCejM75kKy+GY8xlXaZBvOKkzTgltDfxmYFwEcEapUHjXMfxJyAL/eRmF/HX9p5tQHiJSmVJ53nb2e+Yr93bgXNeTFxF9Ic3sktiL+T6dDDKbCeQTc=;\n\t4:snPqfRlGGaaxhdjmo5KO/DX7TkNVJ39aGAqJaRdM2z5wKuzhebnNlsdVgfPBXboX5KA7JNPigVzkdPTG8acrTc+DhYGAetOqtxsv/ey5C222i6RCeAC6Qs8f5jc/WmYZlpZlXxKEkeG0Hzsd1vbgjwK6BVvdpk0y+OqoV3iU6uHYYOVW+A4q8QLgbyJwbMfz8GtCgOMTzrC6rg8U8UaJ9ftsQT23Csn1Ni3Wwtc3d5g//8NTVWJ7dTMpMLb8VW3hisKiXprapAaJwLO7Hv/69iCBz8wCR0h+0Zd1HBJg6nOcDGYnI5wG9/Q93b8G0me0", "=?utf-8?q?1=3BBYAPR07MB4902=3B23=3AGxLn?=\n\t=?utf-8?q?fpB8tVPjTE/YNhr8VkHFmeo1rxkwDsJSdg7snkzCFSE5UFOR0FhTFtyh?=\n\t=?utf-8?q?h+o7zp9TO/8sTRDLC0GKV/JbcGLPBwLkP89CmqZif8T3wb3ptIT4EP9Y?=\n\t=?utf-8?q?CrqDJm82lzJWC0ck/EDqO8vcDkqM4e0ksQtSPWH463fIlm33nQJTb9wL?=\n\t=?utf-8?q?UxnOq0EzfbaYiFnoB4HMgRKyHj8XugUxQjy4dJDbcL6yn9MtS0EpUroD?=\n\t=?utf-8?q?2BSg7gP9AUJ+STrB1/JeRPzcoMn6HPUG5301IAzqWrTzARcK21hFjuuO?=\n\t=?utf-8?q?fXadbsHHuw/0e4YXKBp2VWDdHWY3kkC9F0SonhHsBoNDPBdCukEnY2J0?=\n\t=?utf-8?q?0RMvvqDruBWPEEYhUTY4ED8Fpm465Vep2pNHj+kzK0hrBeuvkEb9/zYl?=\n\t=?utf-8?q?cDHNPAMroa2/q0Zt35KMG6FYToYY05Rq0xRCQeR3eTd50JhqKSpOBAcn?=\n\t=?utf-8?q?DLXWl2JSinUzludRm6WYmQToHiyf6PV2Mo6nORZrwiYuTMFrdzK27TIC?=\n\t=?utf-8?q?z1DNlln4Ags/ISasTXkMVsAB6Le3qVcRu9pH0dYNbHcZJfospjuhIG2i?=\n\t=?utf-8?q?pn01k7vaTLqJoz4KCsV4fxa9AOGveaT6TFC/+6pBGIcJgI8AM70b+Io1?=\n\t=?utf-8?q?K8x9zKUd2VTFlh1ncSKfUvdPUzaTU3+MrGWgNIYUzJFoXoXi/d2KnZS7?=\n\t=?utf-8?q?94qlrXg4XQAX5L8AYVhAZJXPe8bTHZa9UAz3rV4rhogFS27rmR61EJK7?=\n\t=?utf-8?q?teUgODqV0B9T5Cq8MX9m5FsuTGsD8uQABKKO02yDfCzKDuhhunSLghgu?=\n\t=?utf-8?q?Qmp9c2r78MB9bcXf9WNk1WVzMf4ZeoFUoZYhlF5vqilq3ghoXVQL1Vyx?=\n\t=?utf-8?q?vqoSFYTx67Vtr6mBq30l5ExtGpm2+ICx3eiFYd/ioCm01x6i6gJF6PQg?=\n\t=?utf-8?q?jrr3OgfV2uYFkCenw0CJkeSBBaNaudP0DknhgWHd6PCgb+dQvxF1Gj55?=\n\t=?utf-8?q?tLbElTs3QW43+Rq21giDJIH47z1Rpy+phyNDaS2zFmmeqOJuADyQ2YIq?=\n\t=?utf-8?q?bS17P6tICOXSNF3m7jmMcN8Ro/ZLcWvuh+9pBqdDhiXW4jCq0trcBws4?=\n\t=?utf-8?q?7ouCbL8WfNk2HOWxfhPpDgYooiWFBwyfT1TIegpZ6aqCHUFiERDyOdY4?=\n\t=?utf-8?q?75lbZFqKJ5hGnOoEmD4YzUXn83TrsRwxYzbYtP1+cMMD247RLpMyW2rx?=\n\t=?utf-8?q?+NsQv2cZlYop9rEZaWAqvqcguQWFJWLHKcTdS3zjKmR0L2j9Dgi7Pag4?=\n\t=?utf-8?q?Xsp1x8N2t5QDNpFzK9/VSNLoklmRHHtNGd2Ok4EiMg7CcMhOV9TzIjtM?=\n\t=?utf-8?q?MXu4atxVS9vW2bWleojQTQnke+PYsE2S0CMy7W8vJ7+d1r5J2mH+teyM?=\n\t=?utf-8?q?NBQXd1spOsB4HyU41tzOzgTug09KTpdTVnyNocBmRzHQHRQ2bjLTPABJ?=\n\t=?utf-8?q?nhTPqC0qIRXsuXdIWJXkTEFM2jlGHJlkdrJky0/u3wqfY8eY19jtDxwA?=\n\t=?utf-8?q?kVzURtwsp8jbTS60Hq9chnK86tJ13PClHxG19iW5+I9gvHK7Snu5W19Q?=\n\t=?utf-8?q?Vhrd4I/CIYmLMgDqW4FA7igHe53MD1Axr/v3lul1/IvsmsVWjmWWIqzJ?=\n\t=?utf-8?q?0Tys5E/BV5mfYCrAkNUOvgNl3fZpIBRmazrrRHZtmex6GWL08OvbyA6W?=\n\t=?utf-8?q?CgmrRxCAXbfmWAU=3D?=", "1; BYAPR07MB4902;\n\t6:nVZsAMnqTFIHTw+nIStQAQWIqG0dHC+El1eiPffrGNx3yFj6Vj26zKarhJQRL/2qhuuVbyoY06cAz7/hfsrtgbMD0721n6aj8VbA2WpPlt63EuWeUCt6I2XEQnqADyjW5jMlWoPMqshkw6JhoI0BA/4wgJGLzu8SeYbcApcCXVCbmeSSsi+qlh+r3Vi9y6jm2wdNBNxByar2KCBvdo+YD0dPM27vtVvYmBmDfnNu1gepiIRZKYEvdULUFfp97+uqK/kihqiBtDIzIvROQ1SPIF4tdUZbWTz1EKodyKn4avZ9LlXkco4b+iBXGRXx9fYLekedS1PT2lryjF49U6HoQgmjyUGRNe0TMjk5NLsVFMze5IUVPuxtNQhkBxWNU2Z3PLnuvvcL7civB8J5JRKgDaua5eWt8vH/5aPih+tHhVpuhzmuOLk74yUyBOjDC7ebnPxyGpxFKRtr3/8u7i9KYg==;\n\t5:LSk7cbXeOzDaLEA0Ky8Ny4rkv33GAY2J2qs8Gd4FGdqz6I4xTM2KplUUoPXgIm6/aRM/uAylxG/tKvfLYwLnz/xg++Ckf+zLZFaFW5glfDYH5fTzdSsvS0/wsR3O+j4NJoN1vjlLsHgOQ2my5Gq2yj0N/lqQ0A08B80+OBkeIY0=;\n\t7:7uaAVDpeoMaXS5hT0tu9M+h9NwT24PrZe6BRJBnMWbtqa64QXVqbzkZnGmAKKftyBzb8DP3k2YjqK55k//h+ZvG49l2GqvjJZDx+SSCuKFLIQt5xC85H+N51lMvt4A61/OdTiWYMTucDvumrfa5WpT99Qf3/m33NzGVV0Cg+FbgUYEGmIn+qmARsWErN+nMiK5F1jAczHU5bafb/8dnlRF8yP9fLt2YoOROdU6TsuBmqidAdhmYeDVH1BrfNzJM4" ], "X-MS-TrafficTypeDiagnostic": "BYAPR07MB4902:", "X-Microsoft-Antispam-PRVS": "<BYAPR07MB4902C46EC859B5131B7E4A95F8390@BYAPR07MB4902.namprd07.prod.outlook.com>", "X-Exchange-Antispam-Report-Test": "UriScan:(278428928389397);", "X-MS-Exchange-SenderADCheck": "1", "X-Exchange-Antispam-Report-CFA-Test": "BCL:0; PCL:0;\n\tRULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016);\n\tSRVR:BYAPR07MB4902; BCL:0; PCL:0; RULEID:; SRVR:BYAPR07MB4902; ", "X-Forefront-PRVS": "07630F72AD", "X-Forefront-Antispam-Report": "SFV:NSPM;\n\tSFS:(10009020)(6049001)(376002)(346002)(136003)(366004)(39850400004)(396003)(52164004)(189003)(199004)(53754006)(6116002)(3846002)(446003)(230700001)(966005)(478600001)(11346002)(105586002)(72206003)(50466002)(8936002)(106356001)(7736002)(93886005)(305945005)(8676002)(68736007)(476003)(81166006)(2616005)(956004)(31686004)(81156014)(67846002)(229853002)(36756003)(2486003)(6486002)(97736004)(25786009)(64126003)(3260700006)(4326008)(47776003)(65806001)(6306002)(6246003)(54906003)(65956001)(66066001)(42882007)(26005)(53546011)(6666003)(23676004)(16526019)(76176011)(58126008)(31696002)(55236004)(5660300001)(14444005)(65826007)(2906002)(316002)(186003)(386003)(52146003)(53936002)(52116002)(77096007)(110136005)(486006)(16576012);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR07MB4902; H:[10.88.100.222]; FPR:;\n\tSPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; ", "Received-SPF": "None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)", "X-Microsoft-Antispam-Message-Info": "dj4kHtnjp53amMVL0ra21RYmm+Gmf0VgyhsiB81rhoSIbJ8UiDslGGH90H+O3ZNDtAczpHoL0RZOL15jTjNx06/tJFEecI38TjNaxRfwvlZkUe504ZCk/o2tCWBbdCNP3CQeJ9iaYaBa2dHaX4IyAfrPD+sxq6nJegjK9jA9m1UDtE0anlZC3JYfUrHg8qQb0YXdQLMdaXsQKlXTGMQCiJIwiFSwwnlKWycpTMdwdJOoIzrgQb9DXQwSrBkdmk2NJGrYbrg0GrfOkG8+It2dKd3MwYpZLS5YRu9iqkibdRruBy+TIq7yNw9DBbxE4KJqwDlVlJSfCzcTDak2LToT2sEPq/lG4ympnScvLJ+rNH0=", "SpamDiagnosticOutput": "1:99", "SpamDiagnosticMetadata": "NSPM", "X-OriginatorOrg": "caviumnetworks.com", "X-MS-Exchange-CrossTenant-OriginalArrivalTime": "13 Aug 2018 07:21:58.8849\n\t(UTC)", "X-MS-Exchange-CrossTenant-Network-Message-Id": "9401f5ad-64c2-4a5e-322a-08d600ed7715", "X-MS-Exchange-CrossTenant-FromEntityHeader": "Hosted", "X-MS-Exchange-CrossTenant-Id": "711e4ccf-2e9b-4bcf-a551-4094005b6194", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR07MB4902", "Subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 84710, "web_url": "http://patches.dpdk.org/comment/84710/", "msgid": "<20180813092705.GA11396@bricha3-MOBL.ger.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/20180813092705.GA11396@bricha3-MOBL.ger.corp.intel.com", "date": "2018-08-13T09:27:05", "subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "submitter": { "id": 20, "url": "http://patches.dpdk.org/api/people/20/?format=api", "name": "Bruce Richardson", "email": "bruce.richardson@intel.com" }, "content": "On Mon, Aug 13, 2018 at 12:52:19PM +0530, Joseph, Anoob wrote:\n> Hi Bruce, Pablo,\n> \n> If there are no more issues about the approach, can you review the patches\n> and give the feedback?\n> \n> Please do note that this series doesn't add any event mode specific code.\n> That will come as a different patch series after incorporating Jerin's\n> comments.\n> \n> Thanks,\n> Anoob\n\nMy main concern is with l2fwd, rather than l3fwd, which is already fairly\ncomplicated. I could see l3fwd being updated to allow an eventmode without\ntoo many problems.\n\nWith l2fwd, the only issue I have is with the volume of code involved.\nl2fwd is currently a very simple application which fits in a single file.\nWith these updates it's no longer such a simple, approachable app, rather\nit becomes one which takes a bit of studying a switching between files to\nfully understand. The data path is only a very small part of the app, so by\nadding an event-based path to the same app we have very little code saving.\nTherefore, I think having a separate l2fwd-eventdev would be better for\nthis case. Two simpler to understand apps is better than one more\ncomplicated on IMHO.\n\nMy 2c.\n\n/Bruce\n\n> On 02-08-2018 13:49, Ananyev, Konstantin wrote:\n> > External Email\n> > \n> > Hi everyone,\n> > \n> > > > > > In order to get this series accepted, we need more discussions\n> > > > > > with more people involved.\n> > > > > > So it will miss 18.08.\n> > > > > > \n> > > > > > It can be discussed in a more global discussion about examples maintenance.\n> > > > > > If discussion does not happen, you can request it to the technical board.\n> > > > > > \n> > > > > Event dev framework and various adapters enable multiple packet handling\n> > > > > schemes, as opposed to the traditional polling on queues. But these\n> > > > > features are not integrated into any established example application.\n> > > > > There are specific example applications for event dev etc, which can be\n> > > > > used to analyze an event device or a particular eventdev adapter, but\n> > > > > there is no standard application which can be used to compare the real\n> > > > > world performance for a system when it's using event device for packet\n> > > > > handling and when it's done via polling on queues.\n> > > > > \n> > > > > The following patch submitted by Sunil was looking to address this issue\n> > > > > with l3fwd,\n> > > > > https://mails.dpdk.org/archives/dev/2018-March/093131.html\n> > > > > \n> > > > > Bruce & Jerin reviewed the patch and suggested the addition of helper\n> > > > > functions to abstract the event mode additions in applications,\n> > > > > https://mails.dpdk.org/archives/dev/2018-April/096879.html\n> > > > > \n> > > > > This effort of adding helper functions for eventmode was taken up\n> > > > > following the above suggestion. The idea is to add eventmode without\n> > > > > touching the existing code path. All the eventmode specific additions\n> > > > > would go into library so that these need not be repeated for every\n> > > > > application. And since there is no change in the existing code path,\n> > > > > performance for any vendor should not have any impact with the additions.\n> > > > > \n> > > > > The scope of this effort has increased since the submission, as now we\n> > > > > have Tx adapter as well. Sunil & Konstantin had clarified their\n> > > > > concerns, and gave green flag to this approach.\n> > > > > https://mails.dpdk.org/archives/dev/2018-June/105730.html\n> > > > > https://mails.dpdk.org/archives/dev/2018-July/106453.html\n> > > > > \n> > > > > I guess Bruce was opening this question to the community. For compute\n> > > > > intense applications like ipsec-secgw, eventmode might be the right\n> > > > > approach in the first place. Such complex applications would need a\n> > > > > scheduler to perform dynamic load balancing. Addition of eventmode in\n> > > > > l2fwd was to float around the idea which can then be scaled for more\n> > > > > complex applications.\n> > > > > \n> > > > > If maintainers doesn't have any objection to this, I'm fine with adding\n> > > > > this in the next release.\n> > > > > \n> > > > > Thanks,\n> > > > > Anoob\n> > > > It is important that DPDK has good examples of how to use existing\n> > > > frameworks and libraries. These applications are what most customers\n> > > > build their applications from and they provide basis for testing.\n> > > > \n> > > > The DPDK needs to continue to support multiple usage models. This\n> > > > is one of its strong points. I would rather leave existing l2fwd\n> > > > and l3fwd alone and instead make new examples that use the frameworks.\n> > > > If nothing else haveing l2fwd and l2fwd-eventdev would allow for\n> > > > performance comparisons.\n> > > Unlike other applications example, there wont be any change in packet\n> > > processing functions in eventdev vs poll mode case. Only worker\n> > > schematics will change and that can be moved to separated files.\n> > > something like worker_poll.c and worker_event.c and both of them\n> > > use common packet processing functions using mbuf.\n> > > \n> > > The only disadvantage of having separate application would be packet\n> > > processing code duplication. Which is non trivial for l3fwd, IPSec\n> > > application IMO.\n> > Personally I am ok with original design suggestion:\n> > keep packet processing code common, that would be used by both poll and event modes.\n> > We could just have a command-line parameter in which mode the app will run.\n> > Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so).\n> > Konstantin\n> > > # Are we fine with code duplication in example application like l3fwd and\n> > > IPSec?\n> > > # if yes, Are we fine with keeping l2fwd _as is_ to reduce the\n> > > complexity and l2fwd-eventdev supports both modes wherever possible?\n> > > \n> > > > As the number of examples increases, probably also need to have\n> > > > a roadmap or decision chart to explain the advangage/disadvantage\n> > > > of each architecture.\n> > > > \n>", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 476A137A2;\n\tMon, 13 Aug 2018 11:27:13 +0200 (CEST)", "from mga06.intel.com (mga06.intel.com [134.134.136.31])\n\tby dpdk.org (Postfix) with ESMTP id CA8BC2661\n\tfor <dev@dpdk.org>; Mon, 13 Aug 2018 11:27:11 +0200 (CEST)", "from orsmga007.jf.intel.com ([10.7.209.58])\n\tby orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t13 Aug 2018 02:27:10 -0700", "from bricha3-mobl.ger.corp.intel.com ([10.237.221.107])\n\tby orsmga007.jf.intel.com with SMTP; 13 Aug 2018 02:27:07 -0700", "by (sSMTP sendmail emulation); Mon, 13 Aug 2018 10:27:06 +0100" ], "X-Amp-Result": "UNSCANNABLE", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.53,232,1531810800\"; d=\"scan'208\";a=\"64484631\"", "Date": "Mon, 13 Aug 2018 10:27:05 +0100", "From": "Bruce Richardson <bruce.richardson@intel.com>", "To": "\"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com>", "Cc": "Thomas Monjalon <thomas@monjalon.net>,\n\t\"De Lara Guarch, Pablo\" <pablo.de.lara.guarch@intel.com>,\n\t\"Ananyev, Konstantin\" <konstantin.ananyev@intel.com>,\n\tJerin Jacob <jerin.jacob@caviumnetworks.com>,\n\tStephen Hemminger <stephen@networkplumber.org>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>,\n\tNarayana Prasad <narayanaprasad.athreya@caviumnetworks.com>,\n\tHemant Agrawal <hemant.agrawal@nxp.com>,\n\tSunil Kumar Kori <sunil.kori@nxp.com>, \"Rao,\n\tNikhil\" <nikhil.rao@intel.com>", "Message-ID": "<20180813092705.GA11396@bricha3-MOBL.ger.corp.intel.com>", "References": "<1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<1531289248-20025-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<3685021.sWt9K18E1B@xps>\n\t<e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com>\n\t<20180801095414.7bc34b30@xeon-e3> <20180801172628.GA471@jerin>\n\t<2601191342CEEE43887BDE71AB977258E6D4D959@IRSMSX102.ger.corp.intel.com>\n\t<fd4dd899-00b2-b7e3-6acc-29af0571ce2f@caviumnetworks.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<fd4dd899-00b2-b7e3-6acc-29af0571ce2f@caviumnetworks.com>", "Organization": "Intel Research and Development Ireland Ltd.", "User-Agent": "Mutt/1.10.1 (2018-07-13)", "Subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 84724, "web_url": "http://patches.dpdk.org/comment/84724/", "msgid": "<0c162ae7-ebf7-38fe-ea0b-2d18769ddb7d@caviumnetworks.com>", "list_archive_url": "https://inbox.dpdk.org/dev/0c162ae7-ebf7-38fe-ea0b-2d18769ddb7d@caviumnetworks.com", "date": "2018-08-13T15:59:01", "subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "submitter": { "id": 893, "url": "http://patches.dpdk.org/api/people/893/?format=api", "name": "Anoob Joseph", "email": "anoob.joseph@caviumnetworks.com" }, "content": "Hi Bruce,\n\nThe reason why l2fwd was chosen was to allow everyone to chip in their \nideas while preparing the framework.\nThis framework would be extended to other applications, hence needed \nenough inputs before expanding to complex applications. If your \nsuggestion is to make l3fwd event driven first, I'll start looking in \nthat direction.\n\nAs for l2fwd, I'm fine with moving event-mode additions to a new app. \nBut with the present approach, the app would run in both event mode and \npoll mode.\n\nYour thoughts on renaming the existing app to l2fwd-poll and the \nproposed app as l2fwd?\n\nThanks,\nAnoob\nOn 13-08-2018 14:57, Bruce Richardson wrote:\n> External Email\n>\n> On Mon, Aug 13, 2018 at 12:52:19PM +0530, Joseph, Anoob wrote:\n>> Hi Bruce, Pablo,\n>>\n>> If there are no more issues about the approach, can you review the patches\n>> and give the feedback?\n>>\n>> Please do note that this series doesn't add any event mode specific code.\n>> That will come as a different patch series after incorporating Jerin's\n>> comments.\n>>\n>> Thanks,\n>> Anoob\n> My main concern is with l2fwd, rather than l3fwd, which is already fairly\n> complicated. I could see l3fwd being updated to allow an eventmode without\n> too many problems.\n>\n> With l2fwd, the only issue I have is with the volume of code involved.\n> l2fwd is currently a very simple application which fits in a single file.\n> With these updates it's no longer such a simple, approachable app, rather\n> it becomes one which takes a bit of studying a switching between files to\n> fully understand. The data path is only a very small part of the app, so by\n> adding an event-based path to the same app we have very little code saving.\n> Therefore, I think having a separate l2fwd-eventdev would be better for\n> this case. Two simpler to understand apps is better than one more\n> complicated on IMHO.\n>\n> My 2c.\n>\n> /Bruce\n>\n>> On 02-08-2018 13:49, Ananyev, Konstantin wrote:\n>>> External Email\n>>>\n>>> Hi everyone,\n>>>\n>>>>>>> In order to get this series accepted, we need more discussions\n>>>>>>> with more people involved.\n>>>>>>> So it will miss 18.08.\n>>>>>>>\n>>>>>>> It can be discussed in a more global discussion about examples maintenance.\n>>>>>>> If discussion does not happen, you can request it to the technical board.\n>>>>>>>\n>>>>>> Event dev framework and various adapters enable multiple packet handling\n>>>>>> schemes, as opposed to the traditional polling on queues. But these\n>>>>>> features are not integrated into any established example application.\n>>>>>> There are specific example applications for event dev etc, which can be\n>>>>>> used to analyze an event device or a particular eventdev adapter, but\n>>>>>> there is no standard application which can be used to compare the real\n>>>>>> world performance for a system when it's using event device for packet\n>>>>>> handling and when it's done via polling on queues.\n>>>>>>\n>>>>>> The following patch submitted by Sunil was looking to address this issue\n>>>>>> with l3fwd,\n>>>>>> https://mails.dpdk.org/archives/dev/2018-March/093131.html\n>>>>>>\n>>>>>> Bruce & Jerin reviewed the patch and suggested the addition of helper\n>>>>>> functions to abstract the event mode additions in applications,\n>>>>>> https://mails.dpdk.org/archives/dev/2018-April/096879.html\n>>>>>>\n>>>>>> This effort of adding helper functions for eventmode was taken up\n>>>>>> following the above suggestion. The idea is to add eventmode without\n>>>>>> touching the existing code path. All the eventmode specific additions\n>>>>>> would go into library so that these need not be repeated for every\n>>>>>> application. And since there is no change in the existing code path,\n>>>>>> performance for any vendor should not have any impact with the additions.\n>>>>>>\n>>>>>> The scope of this effort has increased since the submission, as now we\n>>>>>> have Tx adapter as well. Sunil & Konstantin had clarified their\n>>>>>> concerns, and gave green flag to this approach.\n>>>>>> https://mails.dpdk.org/archives/dev/2018-June/105730.html\n>>>>>> https://mails.dpdk.org/archives/dev/2018-July/106453.html\n>>>>>>\n>>>>>> I guess Bruce was opening this question to the community. For compute\n>>>>>> intense applications like ipsec-secgw, eventmode might be the right\n>>>>>> approach in the first place. Such complex applications would need a\n>>>>>> scheduler to perform dynamic load balancing. Addition of eventmode in\n>>>>>> l2fwd was to float around the idea which can then be scaled for more\n>>>>>> complex applications.\n>>>>>>\n>>>>>> If maintainers doesn't have any objection to this, I'm fine with adding\n>>>>>> this in the next release.\n>>>>>>\n>>>>>> Thanks,\n>>>>>> Anoob\n>>>>> It is important that DPDK has good examples of how to use existing\n>>>>> frameworks and libraries. These applications are what most customers\n>>>>> build their applications from and they provide basis for testing.\n>>>>>\n>>>>> The DPDK needs to continue to support multiple usage models. This\n>>>>> is one of its strong points. I would rather leave existing l2fwd\n>>>>> and l3fwd alone and instead make new examples that use the frameworks.\n>>>>> If nothing else haveing l2fwd and l2fwd-eventdev would allow for\n>>>>> performance comparisons.\n>>>> Unlike other applications example, there wont be any change in packet\n>>>> processing functions in eventdev vs poll mode case. Only worker\n>>>> schematics will change and that can be moved to separated files.\n>>>> something like worker_poll.c and worker_event.c and both of them\n>>>> use common packet processing functions using mbuf.\n>>>>\n>>>> The only disadvantage of having separate application would be packet\n>>>> processing code duplication. Which is non trivial for l3fwd, IPSec\n>>>> application IMO.\n>>> Personally I am ok with original design suggestion:\n>>> keep packet processing code common, that would be used by both poll and event modes.\n>>> We could just have a command-line parameter in which mode the app will run.\n>>> Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so).\n>>> Konstantin\n>>>> # Are we fine with code duplication in example application like l3fwd and\n>>>> IPSec?\n>>>> # if yes, Are we fine with keeping l2fwd _as is_ to reduce the\n>>>> complexity and l2fwd-eventdev supports both modes wherever possible?\n>>>>\n>>>>> As the number of examples increases, probably also need to have\n>>>>> a roadmap or decision chart to explain the advangage/disadvantage\n>>>>> of each architecture.\n>>>>>", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id A5E1510A3;\n\tMon, 13 Aug 2018 17:58:49 +0200 (CEST)", "from NAM04-CO1-obe.outbound.protection.outlook.com\n\t(mail-eopbgr690057.outbound.protection.outlook.com [40.107.69.57])\n\tby dpdk.org (Postfix) with ESMTP id 5E40BFEB\n\tfor <dev@dpdk.org>; Mon, 13 Aug 2018 17:58:47 +0200 (CEST)", "from [10.88.100.222] (115.113.156.2) by\n\tBN7PR07MB4899.namprd07.prod.outlook.com (2603:10b6:406:ef::28) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1038.22; Mon, 13 Aug 2018 15:58:40 +0000" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=T9jM8aezygzWTqDFD3qZSSWLLoYq0M8oYc6Dcrv/we0=;\n\tb=oPBDie05W3Oc6jaDN9PhRSL2a3i7q3MMr66ZgRviX+6AqnCkT9SizBjOqzBxUZoohKONeWmy76+5I5YrpDbPhfkbxSUPFPS7lycPZZFK2hMGx9vrpS9Sq7p1p0PIvDHai1wV7wiKS01PYC+CRl0q4Be3UA/xCy74Sc+iLxAyjxo=", "Authentication-Results": "spf=none (sender IP is )\n\tsmtp.mailfrom=Anoob.Joseph@cavium.com; ", "To": "Bruce Richardson <bruce.richardson@intel.com>", "Cc": "Thomas Monjalon <thomas@monjalon.net>,\n\t\"De Lara Guarch, Pablo\" <pablo.de.lara.guarch@intel.com>,\n\t\"Ananyev, Konstantin\" <konstantin.ananyev@intel.com>,\n\tJerin Jacob <jerin.jacob@caviumnetworks.com>,\n\tStephen Hemminger <stephen@networkplumber.org>, \"dev@dpdk.org\"\n\t<dev@dpdk.org>,\n\tNarayana Prasad <narayanaprasad.athreya@caviumnetworks.com>, \n\tHemant Agrawal <hemant.agrawal@nxp.com>,\n\tSunil Kumar Kori <sunil.kori@nxp.com>, \"Rao,\n\tNikhil\" <nikhil.rao@intel.com>", "References": "<1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<1531289248-20025-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<3685021.sWt9K18E1B@xps>\n\t<e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com>\n\t<20180801095414.7bc34b30@xeon-e3> <20180801172628.GA471@jerin>\n\t<2601191342CEEE43887BDE71AB977258E6D4D959@IRSMSX102.ger.corp.intel.com>\n\t<fd4dd899-00b2-b7e3-6acc-29af0571ce2f@caviumnetworks.com>\n\t<20180813092705.GA11396@bricha3-MOBL.ger.corp.intel.com>", "From": "\"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com>", "Message-ID": "<0c162ae7-ebf7-38fe-ea0b-2d18769ddb7d@caviumnetworks.com>", "Date": "Mon, 13 Aug 2018 21:29:01 +0530", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.9.1", "MIME-Version": "1.0", "In-Reply-To": "<20180813092705.GA11396@bricha3-MOBL.ger.corp.intel.com>", "Content-Type": "text/plain; charset=utf-8; format=flowed", "Content-Transfer-Encoding": "7bit", "Content-Language": "en-US", "X-Originating-IP": "[115.113.156.2]", "X-ClientProxiedBy": "MAXPR0101CA0068.INDPRD01.PROD.OUTLOOK.COM\n\t(2603:1096:a00:e::30) To BN7PR07MB4899.namprd07.prod.outlook.com\n\t(2603:10b6:406:ef::28)", "X-MS-PublicTrafficType": "Email", "X-MS-Office365-Filtering-Correlation-Id": "451ace57-fe1d-4f71-5e75-08d60135a559", "X-Microsoft-Antispam": "BCL:0; PCL:0;\n\tRULEID:(7020095)(4652040)(8989117)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020);\n\tSRVR:BN7PR07MB4899; ", "X-Microsoft-Exchange-Diagnostics": [ "1; BN7PR07MB4899;\n\t3:ZcFyiwCQ9y4gZ+B6PKvqUS8uQJSK9gWy5wRZ+9UC+YmtD7p4F6hIIq0XPWOYUT72BJ/DWZ5m1/oSYfhQxpW7QwycwrG/QI89muR5SbtxaATCKXokruLZJ1DQ6rhFRxK0rcjF5VgLhxuzFtqlNngfi7d5Y5fjRilVe52u+ZSC0/2E0cBozojhZQI54HqKn+gwv/g86lJuesXDDaGwiGxVZ0NbnmkOTNsoZwKtfhsSBVub6ySItzk0AVoe37yPVTfz;\n\t25:G5TpuSujra83RnUQ6XKmZpYzHp1MTjEc2ymCtaWYfJam7SD5cJh/lUEDcnrsxNumbmajcOw6GqCAh9Xx2qOiw4UXVeo7YEggr/VRj53ZfCkA8MhHbVz1AeJUqeGPrNdReXyFdqbR3FhJN2KZK6M7GRTazWPW2oxay97T3O18eNXhyUHmaZlpNO4RuGjxA2oSUCxgDgpYCVCZuFwtEpfKyArPcGr0EAmUkEwfM/drSLg32qfw3p26a1HfxHii0eazW74qMeDN8ZiuazIp6S8Ah67MAS96UfIl9Ssqf0P9kL3PWzI7ke/o6bXa7IJU17Araq+dMRxifHLM4H70QbVaJw==;\n\t31:U91bKeFCEgGS88hrHQywOcLpbEpVIdu+CmseyVnStLSjitlIXgpZwHulbEZQQdiMiNS7X2QQjBXVGOCDy4XzqnJafJ3kmcstz7rDmL+s9NZYEgMqwDJpuc1BgqmzVKy7IOAmO5lk+7CceyJm9V/2nIqfrofgTt5I5sTdu6QYA8Tc0NXhOmRDrttvhs4egGM07ULbvK/L8Lmw3XD6D6WdwMxt3XhiE0JGlVq1Up/8dNw=", "1; BN7PR07MB4899;\n\t20:84iTPmYPG+nc/3ToWDx3pZk5Z1phwg1T8pRmdNUJNuHWO/3emPIbtWjiiy1qpa7JmW+RNXSGqWcr2/u78GP05E5P+inb95Zju2zVwxUrGOCgrEyWFv0x45u9ECajlFIilHQNYMYRs9Mowp8geirfnpLi2r0HUS8cgzRZin8dkT2oM0Z1/GH9bw3jTs4us/Iu1OXYiBbNn+19GQezmpl7r7uxsojZZetKBmu+zqGNJ90UF6CCdWozsdvZCB26zD80tjWbvYNItR6CTUl8pZpDBeeqmvnpH2JNnFoNydgXsSRHcNynkY9pZAoDLlG18CtxaA71sDoprV+DAcJZSuESFTuIKVVMFfrNvqXZmjomHE/D2f27SOCquGLUaXqV6QTc7Z/v+StHlsXnT+yA2t08AenOK3Tz24UeSjbmRPFPLXYp4ZIXTAk1gKLfer5Dp2ONSFsIoAJP5TGE4pKJaeTFQCmzfI9yk81KM/P4tz1HBzFJPPqi+U4G26ImY5/8TJLRZv/RHexLyguFhRV/2mFAMqixVGPPrqAX9SozsUsNVn0Ib9i1kSk+5Xaw2liDB76DzwY6C3teDLR8HotFXa8YrL+DR4hKfFtYwcmaBqCmW9A=;\n\t4:AVBDWrSQTJfEoYlwU2ObJFpVnhoSLjHdzGQrJJSiHNEEwMyUu0PqEnntgYrB5Wmwfu8v+SYMpUYg7+c0tSY35PzQ2Zin70PXUW8iH2022wUZRC9d67Z+8QiujgVlV0yY9978UmQF/wE57ICnVLLQwvNIK8x/IN0iX/Hqzxr0xm5Jtf2p+8LWM/6kudQNwgZgJzJXFnEbMEtBCyoTvuZAuJ/lRuuf+ZmMwVH97p6N/A68oKWiPCOin6RwGVFGCLDn4JQMpRXTPf2n3cgmi7DwlIxQ4mUrJ3CLvF/YNbbWABB56EMXqVKSO5AKfnRjh+Cc", "=?utf-8?q?1=3BBN7PR07MB4899=3B23=3A/4JL?=\n\t=?utf-8?q?3uYFadwmU9Hp7jVMGYS83En6ofOH2F9hPBGq370GjTeVkFV1iknwDC37?=\n\t=?utf-8?q?5GG0MtMun7mW7OoCB4WeKv7/227/0HTjGMQpk4qLw8m1Ozno1ZM5A8Ag?=\n\t=?utf-8?q?Uvt4Z2GFDaDSe554npC7DUMKWOD5T1egcJ52pK3TdipmJduiNC27PIM6?=\n\t=?utf-8?q?yf1oZDWPtyuT1OSzSL4gKecjIcc4S01yS0vaVNc+H8/pSkK3Vvt0uRwg?=\n\t=?utf-8?q?xnyizN9khblbkOA77CdMD94vO/FOEgPaGF+Ro52xtf/tssDurD9R0ueS?=\n\t=?utf-8?q?O9JFUdUh20/ufLP9VRUOyxoxh1a+H1g7vvPeHGdhhl+uDtkjkc8V0GA/?=\n\t=?utf-8?q?zsMPO9F0gMIbCuv9tbPJq1DF1oLwwXsHzSS6RNfkajpxNjeUB8Bs9CF7?=\n\t=?utf-8?q?OeR19N/6er8YSOS7xAyfSL9i+xMFhu6JAXkzjD/iQoGhBBwGcpAtr6Pv?=\n\t=?utf-8?q?hOxAQ5b9IM4x6sSTLifZ4fTfisL5EKmpf/7vHCmvpLWsDrz3spjNsWD3?=\n\t=?utf-8?q?0XW4WNeFA5ortjhouqhx80jR7ag2pBrXMnx4AoUuT5tLSz7SNgzJ9bcy?=\n\t=?utf-8?q?Rig5M213oM7riViD0dk/Xnv9PnwePcz7+8SGrjQ4BRsURVMoCLxR1FYN?=\n\t=?utf-8?q?wxbOi2ZQtJs9eQ9gL+q2wipLJaj96OuddYCdAeuCS16ZCt/aPiKEhxmU?=\n\t=?utf-8?q?/TKIuqg34SkDvZQUaRqXtgWOobo/jgl5MtF4EzY3PZiwRXQioMgBETQG?=\n\t=?utf-8?q?UvylKht5wECruo1ZnWW88DhPjpx1HrUP65jp9ODo3ed2qkhXRCuSEFNO?=\n\t=?utf-8?q?8y+UeD4zIY4OGIkUzmb26tYZs7qVQHts+PD4K4qNfFNLMwD4WrQgTu/Q?=\n\t=?utf-8?q?BxXtr7yjEzfy2HviycIpMXySqm3WHLuylzil3CiEKTy42Y41YHN98eE6?=\n\t=?utf-8?q?6OdDsbCUjin56o1TBITnBlr/FvIKSfrNt9gSdXSYQy+LprMaJWnbvvgG?=\n\t=?utf-8?q?1xlqxibkjwW33vgPsiQo+QCcIx68f3/cjYyTNQ4m5Os4DTWu/eT0Y/DD?=\n\t=?utf-8?q?M6qdiJjPED73wkYPc1Lys45kJufz28hrZr7sWXKULjw/4jbIwr8d61tp?=\n\t=?utf-8?q?Njp+IczHw9kQ5hlVqdDbvcL3Uk9DAbtwOg3EZowd8511DdaIM2L1GdN2?=\n\t=?utf-8?q?RuPyYYJIxIaFJnaKWDSW0uF1pfNW1I2nK5Ug4M7BWLjK+jtVrBrIRGpJ?=\n\t=?utf-8?q?+aBKe8v65+NlnwVfesANr/YseTuHt5uBi5rOlOwASJV62QPUpKNGeYRT?=\n\t=?utf-8?q?WNpqT8tJjvqcKguqBJ+9mh8imRKSf7JmcKW5kTvjfx6ofyRCGoeIYF6n?=\n\t=?utf-8?q?IOcHuU/H1lISby1eXijkpgcX4CQuC/JzznTdTkXHMWd7xX8/cqeVsHc6?=\n\t=?utf-8?q?gocJnrSTqCfj6e4Waowj1UfTKKhiaAcFDtg39Wr5mFzTsa4ApKpxV9jY?=\n\t=?utf-8?q?1fFIiudGpgwXRXJSaXknlfht5wv3mcmXKWVD4IWAq1wIsAaHS/CVv4R0?=\n\t=?utf-8?q?lBi4NNfnVWD6I7D7T0fLMKZRqS986z2iS4J/GZxPmopPyobP0hsZtUeF?=\n\t=?utf-8?q?5BdFmTdywOjByJrihnATounk7z1nHGiRR5DJh07f/e9L3TDUOsKEQKPu?=\n\t=?utf-8?q?RKChnNR2SWHSUJqEj2AiTv7KbeiOtsOy0YhzsfBHPFtLSX/eqbJWcHc+?=\n\t=?utf-8?q?vTYm7b1vrTNjgqKGFGT0XDjfxGwqOvrx2KJpjimPcYFJf6Ltiz748hj6?=\n\t=?utf-8?q?jRkZz/OPndn6uhUYTGtTfMQgGYo+n1vHD2SvBIzL3N8Q?=", "1; BN7PR07MB4899;\n\t6:xKd/xsRKxsZzfW37YFJUuN1ufqARjNmAzZA9aaS7uVFMp8BMGvHKoKyC+KCAvLqwduxXSoO6nL63dCrdt2RHmZfLtYFnTf9an85lkeZp9n0i8/TQ3E1cbHWkPoTc3yxdrF27I/ivp/YKkiXkCiWt/opRV0i/mrTq1CAwsZjlmRvvPF5nAG/IUXqP6HnGdBE9W9Hsp7DhBdQlI6ZyoLSH7SuVzmqMeI6Acy2OPLsz9BGoOGAv/Gu1bYxP0G+imoqoYkkG7mFTggtiN/0pB1uhdg+17d678/X2RfiWs2Dvp05q6Bqfr5KmcKU0XanzP5AMpITAHz1lXnRPTIy1qamgfB83fenbhskKUGiSt6eat0d/tFz6aPZyT/TpslET4iOtuwDsiQ/TBvY6jysa9mcinDxzBcHwo4WzbQ02z68HNQCzCQ2704Zij3p73oIZJG2A30QV6u8eNqgC+79jYVF63w==;\n\t5:Js/qO7Ntghv8hGgMtoUojd6Ak6X1OViJxCn6lEnrJe5fjqqYo4zoiIO+gSh8vZ0Bt2LKpHTA8eHUQh+6q7wLxiIrI4FsSDXf7qM2zhqNvENUlEiyI9OvTzaQULsNi0ZMnjQ2sbTHNL+qwNw9X/uaxM8otEtLRjBN+aXb+iIWQf0=;\n\t7:Vo0oTPU8V7IrxTKI/cVd1HpHrqKkesZjxK5nRYSgwJZQGKsaFGIvcVxqyKA4xGf+wM6y0X/9dwLnT3iWo4kjJNgP4SoQUDx6Mx/uoW4wIg1CnpATNy+tQb68t0SQ55k3RZ7j+J+64ccoVZrHbawKqPcvALo4znII4vSDCJvf3tFSHdzr0hV9+JvX1BJOt1VKIovSwYN9EDjj7AHDoXC/gFMNj+jI6SERiAKg4QFAQ6b5kXyE2KuX2wB9ZjTWGwlj" ], "X-MS-TrafficTypeDiagnostic": "BN7PR07MB4899:", "X-Microsoft-Antispam-PRVS": "<BN7PR07MB4899E6AE1518CC0FADA835D3F8390@BN7PR07MB4899.namprd07.prod.outlook.com>", "X-Exchange-Antispam-Report-Test": "UriScan:(278428928389397);", "X-MS-Exchange-SenderADCheck": "1", "X-Exchange-Antispam-Report-CFA-Test": "BCL:0; PCL:0;\n\tRULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016);\n\tSRVR:BN7PR07MB4899; BCL:0; PCL:0; RULEID:; SRVR:BN7PR07MB4899; ", "X-Forefront-PRVS": "07630F72AD", "X-Forefront-Antispam-Report": "SFV:NSPM;\n\tSFS:(10009020)(979002)(6049001)(39860400002)(136003)(396003)(376002)(346002)(366004)(189003)(52164004)(199004)(53754006)(6666003)(478600001)(31686004)(966005)(65826007)(8676002)(72206003)(81166006)(105586002)(81156014)(106356001)(64126003)(8936002)(50466002)(3260700006)(2906002)(5660300001)(25786009)(23676004)(3846002)(6916009)(67846002)(6116002)(230700001)(68736007)(97736004)(6486002)(54906003)(65956001)(16576012)(66066001)(47776003)(386003)(31696002)(58126008)(36756003)(446003)(6306002)(486006)(77096007)(16526019)(11346002)(6246003)(76176011)(52146003)(55236004)(14444005)(305945005)(2616005)(4326008)(26005)(186003)(956004)(229853002)(7736002)(2486003)(476003)(52116002)(316002)(53546011)(53936002)(42882007)(65806001)(93886005)(969003)(989001)(999001)(1009001)(1019001);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR07MB4899; H:[10.88.100.222]; FPR:;\n\tSPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; ", "Received-SPF": "None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)", "X-Microsoft-Antispam-Message-Info": "fEGN33vN9pJGMKNxYTcO96EPVKsdbCrYTuYBATOSg+uBF9hWbnGoVLFKnWNaRM6PrkxU1m6kUQt6+czYvVoXRwDeNEx0FYYMdZiWvaieOGIGEA9L7btXrDBYfmPF6vs0udugjljX3r7sWxM/IgfxEfjkbDJWatrcs58mwwF8AGl6Acdbcgwq2lXU4l0IshuIZIALLZyBW9NY99J55N9XnGbGA7FHcBZ+OEVbkuqGlbJlLamCN/2QN0yqCzlmNcsYlEHcSoz2P/PyhB8wJtTsMiMgm+iB+21mk2cWbm9dKvr6pwhAoUB5JDrz4Wgqd/D6S2CEU0ZpgSNRszWMGjVlSR1qZVeU5vfX3UJ6rcWGXnY=", "SpamDiagnosticOutput": "1:99", "SpamDiagnosticMetadata": "NSPM", "X-OriginatorOrg": "caviumnetworks.com", "X-MS-Exchange-CrossTenant-OriginalArrivalTime": "13 Aug 2018 15:58:40.2160\n\t(UTC)", "X-MS-Exchange-CrossTenant-Network-Message-Id": "451ace57-fe1d-4f71-5e75-08d60135a559", "X-MS-Exchange-CrossTenant-FromEntityHeader": "Hosted", "X-MS-Exchange-CrossTenant-Id": "711e4ccf-2e9b-4bcf-a551-4094005b6194", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BN7PR07MB4899", "Subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 84736, "web_url": "http://patches.dpdk.org/comment/84736/", "msgid": "<20180814103313.GA12412@bricha3-MOBL.ger.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/20180814103313.GA12412@bricha3-MOBL.ger.corp.intel.com", "date": "2018-08-14T10:33:13", "subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "submitter": { "id": 20, "url": "http://patches.dpdk.org/api/people/20/?format=api", "name": "Bruce Richardson", "email": "bruce.richardson@intel.com" }, "content": "On Mon, Aug 13, 2018 at 09:29:01PM +0530, Joseph, Anoob wrote:\n> Hi Bruce,\n> \n> The reason why l2fwd was chosen was to allow everyone to chip in their ideas\n> while preparing the framework.\n> This framework would be extended to other applications, hence needed enough\n> inputs before expanding to complex applications. If your suggestion is to\n> make l3fwd event driven first, I'll start looking in that direction.\n\nSeems good to me, if others don't have an issue with it.\n\n> \n> As for l2fwd, I'm fine with moving event-mode additions to a new app. But\n> with the present approach, the app would run in both event mode and poll\n> mode.\n> \n> Your thoughts on renaming the existing app to l2fwd-poll and the proposed\n> app as l2fwd?\n> \n> Thanks,\n> Anoob\n\nI'm not sure about the name \"poll\", I think \"ethdev\" and \"eventdev\" should be\nthe suffixes, if we want to move in that direction.\nHowever, my preference would be to leave l2fwd as-is, and to have a comment\nat the top of the source file, and note in the documentation along the\nlines of:\n\n\"This example demonstrates basic l2 forwarding using ethdev primitives. To\nsee the same use-case implemented using event-based primitives, see the\n'l2fwd-eventdev' example\".\n\nAs I said before, my main concern is to keep the basic examples short and\nreadable.\n\n/Bruce\n\n> On 13-08-2018 14:57, Bruce Richardson wrote:\n> > External Email\n> > \n> > On Mon, Aug 13, 2018 at 12:52:19PM +0530, Joseph, Anoob wrote:\n> > > Hi Bruce, Pablo,\n> > > \n> > > If there are no more issues about the approach, can you review the patches\n> > > and give the feedback?\n> > > \n> > > Please do note that this series doesn't add any event mode specific code.\n> > > That will come as a different patch series after incorporating Jerin's\n> > > comments.\n> > > \n> > > Thanks,\n> > > Anoob\n> > My main concern is with l2fwd, rather than l3fwd, which is already fairly\n> > complicated. I could see l3fwd being updated to allow an eventmode without\n> > too many problems.\n> > \n> > With l2fwd, the only issue I have is with the volume of code involved.\n> > l2fwd is currently a very simple application which fits in a single file.\n> > With these updates it's no longer such a simple, approachable app, rather\n> > it becomes one which takes a bit of studying a switching between files to\n> > fully understand. The data path is only a very small part of the app, so by\n> > adding an event-based path to the same app we have very little code saving.\n> > Therefore, I think having a separate l2fwd-eventdev would be better for\n> > this case. Two simpler to understand apps is better than one more\n> > complicated on IMHO.\n> > \n> > My 2c.\n> > \n> > /Bruce\n> > \n> > > On 02-08-2018 13:49, Ananyev, Konstantin wrote:\n> > > > External Email\n> > > > \n> > > > Hi everyone,\n> > > > \n> > > > > > > > In order to get this series accepted, we need more discussions\n> > > > > > > > with more people involved.\n> > > > > > > > So it will miss 18.08.\n> > > > > > > > \n> > > > > > > > It can be discussed in a more global discussion about examples maintenance.\n> > > > > > > > If discussion does not happen, you can request it to the technical board.\n> > > > > > > > \n> > > > > > > Event dev framework and various adapters enable multiple packet handling\n> > > > > > > schemes, as opposed to the traditional polling on queues. But these\n> > > > > > > features are not integrated into any established example application.\n> > > > > > > There are specific example applications for event dev etc, which can be\n> > > > > > > used to analyze an event device or a particular eventdev adapter, but\n> > > > > > > there is no standard application which can be used to compare the real\n> > > > > > > world performance for a system when it's using event device for packet\n> > > > > > > handling and when it's done via polling on queues.\n> > > > > > > \n> > > > > > > The following patch submitted by Sunil was looking to address this issue\n> > > > > > > with l3fwd,\n> > > > > > > https://mails.dpdk.org/archives/dev/2018-March/093131.html\n> > > > > > > \n> > > > > > > Bruce & Jerin reviewed the patch and suggested the addition of helper\n> > > > > > > functions to abstract the event mode additions in applications,\n> > > > > > > https://mails.dpdk.org/archives/dev/2018-April/096879.html\n> > > > > > > \n> > > > > > > This effort of adding helper functions for eventmode was taken up\n> > > > > > > following the above suggestion. The idea is to add eventmode without\n> > > > > > > touching the existing code path. All the eventmode specific additions\n> > > > > > > would go into library so that these need not be repeated for every\n> > > > > > > application. And since there is no change in the existing code path,\n> > > > > > > performance for any vendor should not have any impact with the additions.\n> > > > > > > \n> > > > > > > The scope of this effort has increased since the submission, as now we\n> > > > > > > have Tx adapter as well. Sunil & Konstantin had clarified their\n> > > > > > > concerns, and gave green flag to this approach.\n> > > > > > > https://mails.dpdk.org/archives/dev/2018-June/105730.html\n> > > > > > > https://mails.dpdk.org/archives/dev/2018-July/106453.html\n> > > > > > > \n> > > > > > > I guess Bruce was opening this question to the community. For compute\n> > > > > > > intense applications like ipsec-secgw, eventmode might be the right\n> > > > > > > approach in the first place. Such complex applications would need a\n> > > > > > > scheduler to perform dynamic load balancing. Addition of eventmode in\n> > > > > > > l2fwd was to float around the idea which can then be scaled for more\n> > > > > > > complex applications.\n> > > > > > > \n> > > > > > > If maintainers doesn't have any objection to this, I'm fine with adding\n> > > > > > > this in the next release.\n> > > > > > > \n> > > > > > > Thanks,\n> > > > > > > Anoob\n> > > > > > It is important that DPDK has good examples of how to use existing\n> > > > > > frameworks and libraries. These applications are what most customers\n> > > > > > build their applications from and they provide basis for testing.\n> > > > > > \n> > > > > > The DPDK needs to continue to support multiple usage models. This\n> > > > > > is one of its strong points. I would rather leave existing l2fwd\n> > > > > > and l3fwd alone and instead make new examples that use the frameworks.\n> > > > > > If nothing else haveing l2fwd and l2fwd-eventdev would allow for\n> > > > > > performance comparisons.\n> > > > > Unlike other applications example, there wont be any change in packet\n> > > > > processing functions in eventdev vs poll mode case. Only worker\n> > > > > schematics will change and that can be moved to separated files.\n> > > > > something like worker_poll.c and worker_event.c and both of them\n> > > > > use common packet processing functions using mbuf.\n> > > > > \n> > > > > The only disadvantage of having separate application would be packet\n> > > > > processing code duplication. Which is non trivial for l3fwd, IPSec\n> > > > > application IMO.\n> > > > Personally I am ok with original design suggestion:\n> > > > keep packet processing code common, that would be used by both poll and event modes.\n> > > > We could just have a command-line parameter in which mode the app will run.\n> > > > Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so).\n> > > > Konstantin\n> > > > > # Are we fine with code duplication in example application like l3fwd and\n> > > > > IPSec?\n> > > > > # if yes, Are we fine with keeping l2fwd _as is_ to reduce the\n> > > > > complexity and l2fwd-eventdev supports both modes wherever possible?\n> > > > > \n> > > > > > As the number of examples increases, probably also need to have\n> > > > > > a roadmap or decision chart to explain the advangage/disadvantage\n> > > > > > of each architecture.\n> > > > > > \n>", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 250FF4C93;\n\tTue, 14 Aug 2018 12:33:22 +0200 (CEST)", "from mga06.intel.com (mga06.intel.com [134.134.136.31])\n\tby dpdk.org (Postfix) with ESMTP id A7B324C8D\n\tfor <dev@dpdk.org>; Tue, 14 Aug 2018 12:33:19 +0200 (CEST)", "from fmsmga001.fm.intel.com ([10.253.24.23])\n\tby orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t14 Aug 2018 03:33:18 -0700", "from bricha3-mobl.ger.corp.intel.com ([10.237.221.107])\n\tby fmsmga001.fm.intel.com with SMTP; 14 Aug 2018 03:33:15 -0700", "by (sSMTP sendmail emulation); Tue, 14 Aug 2018 11:33:14 +0100" ], "X-Amp-Result": "UNSCANNABLE", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.53,237,1531810800\"; d=\"scan'208\";a=\"81206813\"", "Date": "Tue, 14 Aug 2018 11:33:13 +0100", "From": "Bruce Richardson <bruce.richardson@intel.com>", "To": "\"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com>", "Cc": "Thomas Monjalon <thomas@monjalon.net>,\n\t\"De Lara Guarch, Pablo\" <pablo.de.lara.guarch@intel.com>,\n\t\"Ananyev, Konstantin\" <konstantin.ananyev@intel.com>,\n\tJerin Jacob <jerin.jacob@caviumnetworks.com>,\n\tStephen Hemminger <stephen@networkplumber.org>,\n\t\"dev@dpdk.org\" <dev@dpdk.org>,\n\tNarayana Prasad <narayanaprasad.athreya@caviumnetworks.com>,\n\tHemant Agrawal <hemant.agrawal@nxp.com>,\n\tSunil Kumar Kori <sunil.kori@nxp.com>, \"Rao,\n\tNikhil\" <nikhil.rao@intel.com>", "Message-ID": "<20180814103313.GA12412@bricha3-MOBL.ger.corp.intel.com>", "References": "<1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<1531289248-20025-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<3685021.sWt9K18E1B@xps>\n\t<e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com>\n\t<20180801095414.7bc34b30@xeon-e3> <20180801172628.GA471@jerin>\n\t<2601191342CEEE43887BDE71AB977258E6D4D959@IRSMSX102.ger.corp.intel.com>\n\t<fd4dd899-00b2-b7e3-6acc-29af0571ce2f@caviumnetworks.com>\n\t<20180813092705.GA11396@bricha3-MOBL.ger.corp.intel.com>\n\t<0c162ae7-ebf7-38fe-ea0b-2d18769ddb7d@caviumnetworks.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=us-ascii", "Content-Disposition": "inline", "In-Reply-To": "<0c162ae7-ebf7-38fe-ea0b-2d18769ddb7d@caviumnetworks.com>", "Organization": "Intel Research and Development Ireland Ltd.", "User-Agent": "Mutt/1.10.1 (2018-07-13)", "Subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 84787, "web_url": "http://patches.dpdk.org/comment/84787/", "msgid": "<7f529e8f-a61f-3950-265e-8923efc61743@caviumnetworks.com>", "list_archive_url": "https://inbox.dpdk.org/dev/7f529e8f-a61f-3950-265e-8923efc61743@caviumnetworks.com", "date": "2018-08-18T09:58:13", "subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "submitter": { "id": 893, "url": "http://patches.dpdk.org/api/people/893/?format=api", "name": "Anoob Joseph", "email": "anoob.joseph@caviumnetworks.com" }, "content": "Hi Bruce,\n\nOn 14-08-2018 16:03, Bruce Richardson wrote:\n> External Email\n>\n> On Mon, Aug 13, 2018 at 09:29:01PM +0530, Joseph, Anoob wrote:\n>> Hi Bruce,\n>>\n>> The reason why l2fwd was chosen was to allow everyone to chip in their ideas\n>> while preparing the framework.\n>> This framework would be extended to other applications, hence needed enough\n>> inputs before expanding to complex applications. If your suggestion is to\n>> make l3fwd event driven first, I'll start looking in that direction.\n> Seems good to me, if others don't have an issue with it.\n>\n>> As for l2fwd, I'm fine with moving event-mode additions to a new app. But\n>> with the present approach, the app would run in both event mode and poll\n>> mode.\n>>\n>> Your thoughts on renaming the existing app to l2fwd-poll and the proposed\n>> app as l2fwd?\n>>\n>> Thanks,\n>> Anoob\n> I'm not sure about the name \"poll\", I think \"ethdev\" and \"eventdev\" should be\n> the suffixes, if we want to move in that direction.\nWith new adapters, like crypto adapter, event device will be able to \nhandle multiple devices at the same time. It will be able to abstract \nnot just eth device but other devices too (crypto for example). For apps \nlike ipsec-secgw, crypto also would be abstracted with event-device. So \nwhat should be the ideal naming convention taking into account all that? \nUsing \"eth\"& \"event\" won't fit in for such cases.\n\nPresently, mode was defined by the way packets were submitted to & \nreceived from the device. With poll mode, device(eth, crypto etc) would \nget packets directly from the core & the core would then poll for \ncompletion. In case of event-mode, event device handles this scheduling. \nEvent device would submit (to all devices) and receive packets (from all \ndevices). Core need not poll on the device, in that case. Hence the \nnaming...\n\nYour thoughts?\n\nAnoob\n> However, my preference would be to leave l2fwd as-is, and to have a comment\n> at the top of the source file, and note in the documentation along the\n> lines of:\n>\n> \"This example demonstrates basic l2 forwarding using ethdev primitives. To\n> see the same use-case implemented using event-based primitives, see the\n> 'l2fwd-eventdev' example\".\n>\n> As I said before, my main concern is to keep the basic examples short and\n> readable.\n>\n> /Bruce\n>\n>> On 13-08-2018 14:57, Bruce Richardson wrote:\n>>> External Email\n>>>\n>>> On Mon, Aug 13, 2018 at 12:52:19PM +0530, Joseph, Anoob wrote:\n>>>> Hi Bruce, Pablo,\n>>>>\n>>>> If there are no more issues about the approach, can you review the patches\n>>>> and give the feedback?\n>>>>\n>>>> Please do note that this series doesn't add any event mode specific code.\n>>>> That will come as a different patch series after incorporating Jerin's\n>>>> comments.\n>>>>\n>>>> Thanks,\n>>>> Anoob\n>>> My main concern is with l2fwd, rather than l3fwd, which is already fairly\n>>> complicated. I could see l3fwd being updated to allow an eventmode without\n>>> too many problems.\n>>>\n>>> With l2fwd, the only issue I have is with the volume of code involved.\n>>> l2fwd is currently a very simple application which fits in a single file.\n>>> With these updates it's no longer such a simple, approachable app, rather\n>>> it becomes one which takes a bit of studying a switching between files to\n>>> fully understand. The data path is only a very small part of the app, so by\n>>> adding an event-based path to the same app we have very little code saving.\n>>> Therefore, I think having a separate l2fwd-eventdev would be better for\n>>> this case. Two simpler to understand apps is better than one more\n>>> complicated on IMHO.\n>>>\n>>> My 2c.\n>>>\n>>> /Bruce\n>>>\n>>>> On 02-08-2018 13:49, Ananyev, Konstantin wrote:\n>>>>> External Email\n>>>>>\n>>>>> Hi everyone,\n>>>>>\n>>>>>>>>> In order to get this series accepted, we need more discussions\n>>>>>>>>> with more people involved.\n>>>>>>>>> So it will miss 18.08.\n>>>>>>>>>\n>>>>>>>>> It can be discussed in a more global discussion about examples maintenance.\n>>>>>>>>> If discussion does not happen, you can request it to the technical board.\n>>>>>>>>>\n>>>>>>>> Event dev framework and various adapters enable multiple packet handling\n>>>>>>>> schemes, as opposed to the traditional polling on queues. But these\n>>>>>>>> features are not integrated into any established example application.\n>>>>>>>> There are specific example applications for event dev etc, which can be\n>>>>>>>> used to analyze an event device or a particular eventdev adapter, but\n>>>>>>>> there is no standard application which can be used to compare the real\n>>>>>>>> world performance for a system when it's using event device for packet\n>>>>>>>> handling and when it's done via polling on queues.\n>>>>>>>>\n>>>>>>>> The following patch submitted by Sunil was looking to address this issue\n>>>>>>>> with l3fwd,\n>>>>>>>> https://mails.dpdk.org/archives/dev/2018-March/093131.html\n>>>>>>>>\n>>>>>>>> Bruce & Jerin reviewed the patch and suggested the addition of helper\n>>>>>>>> functions to abstract the event mode additions in applications,\n>>>>>>>> https://mails.dpdk.org/archives/dev/2018-April/096879.html\n>>>>>>>>\n>>>>>>>> This effort of adding helper functions for eventmode was taken up\n>>>>>>>> following the above suggestion. The idea is to add eventmode without\n>>>>>>>> touching the existing code path. All the eventmode specific additions\n>>>>>>>> would go into library so that these need not be repeated for every\n>>>>>>>> application. And since there is no change in the existing code path,\n>>>>>>>> performance for any vendor should not have any impact with the additions.\n>>>>>>>>\n>>>>>>>> The scope of this effort has increased since the submission, as now we\n>>>>>>>> have Tx adapter as well. Sunil & Konstantin had clarified their\n>>>>>>>> concerns, and gave green flag to this approach.\n>>>>>>>> https://mails.dpdk.org/archives/dev/2018-June/105730.html\n>>>>>>>> https://mails.dpdk.org/archives/dev/2018-July/106453.html\n>>>>>>>>\n>>>>>>>> I guess Bruce was opening this question to the community. For compute\n>>>>>>>> intense applications like ipsec-secgw, eventmode might be the right\n>>>>>>>> approach in the first place. Such complex applications would need a\n>>>>>>>> scheduler to perform dynamic load balancing. Addition of eventmode in\n>>>>>>>> l2fwd was to float around the idea which can then be scaled for more\n>>>>>>>> complex applications.\n>>>>>>>>\n>>>>>>>> If maintainers doesn't have any objection to this, I'm fine with adding\n>>>>>>>> this in the next release.\n>>>>>>>>\n>>>>>>>> Thanks,\n>>>>>>>> Anoob\n>>>>>>> It is important that DPDK has good examples of how to use existing\n>>>>>>> frameworks and libraries. These applications are what most customers\n>>>>>>> build their applications from and they provide basis for testing.\n>>>>>>>\n>>>>>>> The DPDK needs to continue to support multiple usage models. This\n>>>>>>> is one of its strong points. I would rather leave existing l2fwd\n>>>>>>> and l3fwd alone and instead make new examples that use the frameworks.\n>>>>>>> If nothing else haveing l2fwd and l2fwd-eventdev would allow for\n>>>>>>> performance comparisons.\n>>>>>> Unlike other applications example, there wont be any change in packet\n>>>>>> processing functions in eventdev vs poll mode case. Only worker\n>>>>>> schematics will change and that can be moved to separated files.\n>>>>>> something like worker_poll.c and worker_event.c and both of them\n>>>>>> use common packet processing functions using mbuf.\n>>>>>>\n>>>>>> The only disadvantage of having separate application would be packet\n>>>>>> processing code duplication. Which is non trivial for l3fwd, IPSec\n>>>>>> application IMO.\n>>>>> Personally I am ok with original design suggestion:\n>>>>> keep packet processing code common, that would be used by both poll and event modes.\n>>>>> We could just have a command-line parameter in which mode the app will run.\n>>>>> Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so).\n>>>>> Konstantin\n>>>>>> # Are we fine with code duplication in example application like l3fwd and\n>>>>>> IPSec?\n>>>>>> # if yes, Are we fine with keeping l2fwd _as is_ to reduce the\n>>>>>> complexity and l2fwd-eventdev supports both modes wherever possible?\n>>>>>>\n>>>>>>> As the number of examples increases, probably also need to have\n>>>>>>> a roadmap or decision chart to explain the advangage/disadvantage\n>>>>>>> of each architecture.\n>>>>>>>", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id B827929AC;\n\tSat, 18 Aug 2018 11:57:58 +0200 (CEST)", "from NAM01-BN3-obe.outbound.protection.outlook.com\n\t(mail-bn3nam01on0084.outbound.protection.outlook.com [104.47.33.84])\n\tby dpdk.org (Postfix) with ESMTP id BF255235\n\tfor <dev@dpdk.org>; Sat, 18 Aug 2018 11:57:56 +0200 (CEST)", "from [IPv6:2405:204:d304:3387:7872:4c88:2493:98ac]\n\t(2405:204:d304:3387:7872:4c88:2493:98ac) by\n\tSN6PR07MB4910.namprd07.prod.outlook.com (2603:10b6:805:39::16) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1038.25; Sat, 18 Aug 2018 09:57:47 +0000" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=Dr5p7ltdoJawPVmFyjpaG6Kzo90zrWcsVgFlYZcfLdc=;\n\tb=DMjHIsOxp5rwxXcqH+iNeqrepAsCQ6xqCi1f5VrcoXjRrWBqzNDUlaO1LcuufN8EbvtgMzjwDAO80hh/2e1ka4NpuG8oR0M8X8TAJv/2VSJaws8xZwXUQpUB40pFjc3xma+QRbulI2Up9rKFzxUU6hOZOpOcWNykBRHiwHmbLkc=", "Authentication-Results": "spf=none (sender IP is )\n\tsmtp.mailfrom=Anoob.Joseph@cavium.com; ", "To": "Bruce Richardson <bruce.richardson@intel.com>", "Cc": "Thomas Monjalon <thomas@monjalon.net>,\n\t\"De Lara Guarch, Pablo\" <pablo.de.lara.guarch@intel.com>,\n\t\"Ananyev, Konstantin\" <konstantin.ananyev@intel.com>,\n\tJerin Jacob <jerin.jacob@caviumnetworks.com>,\n\tStephen Hemminger <stephen@networkplumber.org>, \"dev@dpdk.org\"\n\t<dev@dpdk.org>,\n\tNarayana Prasad <narayanaprasad.athreya@caviumnetworks.com>, \n\tHemant Agrawal <hemant.agrawal@nxp.com>,\n\tSunil Kumar Kori <sunil.kori@nxp.com>, \"Rao,\n\tNikhil\" <nikhil.rao@intel.com>", "References": "<1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<1531289248-20025-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<3685021.sWt9K18E1B@xps>\n\t<e1777177-1aef-2558-8221-a76631dcf932@caviumnetworks.com>\n\t<20180801095414.7bc34b30@xeon-e3> <20180801172628.GA471@jerin>\n\t<2601191342CEEE43887BDE71AB977258E6D4D959@IRSMSX102.ger.corp.intel.com>\n\t<fd4dd899-00b2-b7e3-6acc-29af0571ce2f@caviumnetworks.com>\n\t<20180813092705.GA11396@bricha3-MOBL.ger.corp.intel.com>\n\t<0c162ae7-ebf7-38fe-ea0b-2d18769ddb7d@caviumnetworks.com>\n\t<20180814103313.GA12412@bricha3-MOBL.ger.corp.intel.com>", "From": "\"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com>", "Message-ID": "<7f529e8f-a61f-3950-265e-8923efc61743@caviumnetworks.com>", "Date": "Sat, 18 Aug 2018 15:28:13 +0530", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.9.1", "MIME-Version": "1.0", "In-Reply-To": "<20180814103313.GA12412@bricha3-MOBL.ger.corp.intel.com>", "Content-Type": "text/plain; charset=utf-8; format=flowed", "Content-Transfer-Encoding": "7bit", "Content-Language": "en-US", "X-Originating-IP": "[2405:204:d304:3387:7872:4c88:2493:98ac]", "X-ClientProxiedBy": "BMXPR01CA0029.INDPRD01.PROD.OUTLOOK.COM\n\t(2603:1096:b00:c::15) To SN6PR07MB4910.namprd07.prod.outlook.com\n\t(2603:10b6:805:39::16)", "X-MS-PublicTrafficType": "Email", "X-MS-Office365-Filtering-Correlation-Id": "ac850534-7d84-4f68-6673-08d604f11129", "X-Microsoft-Antispam": "BCL:0; PCL:0;\n\tRULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020);\n\tSRVR:SN6PR07MB4910; ", "X-Microsoft-Exchange-Diagnostics": [ "1; SN6PR07MB4910;\n\t3:Ic7qnhMqcPRuOo9KMNdl29MY9EifkB3wp7Fnue68oR2E5EJldH/6JGNxJnlIUCB/+ARP6ClkrY0V4uzcSFH7b9fH4vSfk6IKkdJUVJnhjh4+3FFQjijZHIE+K2eSV6PeE4mfxequkjS4wqlgINFmenp7LTgZGAGGMefI7UIm/W5fd1scl41Bl7+eVNj8MVxF5Hf+gdgPdGTaoOon3FN+cZgE211hrRpNJ6l2ACiojjIhUAM4buDAeB+Tdem5gbW7;\n\t25:fcZ0gzLWejbKboITz6j0TAs+yCmmCAZhySZr0R4cV4/JxxJcitmPOslumYMDo7dk+CxPdofSq/WuC7hjidRfscuLrxKKUJpDs+Xv1f2WriRYk6B9KbLuUYL8AP0HgkPA474C81w0osv3pB74L5HEGSvQ2ZUQAcbSW5NtSH3lcoPrXh3W3eOk8CF86tK6Z6MGrxY68C1moSB17AJp9Uk0xHzDoeqRQeZKmbOLFK2o5pFPfO+YE8kjwKad2RlU1F9EtfIBRWZDZjPa5y604vtb0Vf2MUB0XQ4CcLAFHJNN1XImsIgzvCt8X6M98CNf/mVNRyifU0ZIsMvCxUs8H/WECw==;\n\t31:dFyri3EmShHUqkpwX8VxSVRh42SP6HSIJG7kgctmBfNOVtP1PI+mTYFBFxq+tF9fZNerMRcjX6GV7MlkQXWHYgj/cGQG2HC9jn3RnwxUEC4z/xuoz/9DHi4Qxb0Iug4qyKAS+SOxTYTahRaGTsD5fi/vuyxINpl5vOT5m9+4zqYPl5wpA1a0k6aA41FBNTOoco+riujw7Ry7qzZy6PS2ciqwblw2u7IhDLvWQlKtcqI=", "1; SN6PR07MB4910;\n\t20:Wk1cpAjRJu84HCsv+R1n9JZ9i3LJ6E7/d4yq/A3hRqwq+KW3zUoTdgsc1PsCqSSoqkikVj/wBf8wioqj4lMC3rntwaMEOparRIRVJalDUdZztt7YhuQhchl3TfApLtOCV0H0Ys7T0aYnhYeNFOKqnouhFIQkKYZVOJFr8ADvR9hpMr+rTyozlRic1Sk/8kwG+Kd1IYCtoqRgaku/TKYYj76vc9NmJAvJAd5UW50cie9lpANXrWJD+EOkivYYbQyuBiu3H46izqHuNNoiVjO4UaWbvedkC44vEfcXMB02hpUXx339rIKDl7Io1ov2N1H2pKx1cdj31BnvXjtxTMUdYsgpyfH53POgB8p6X5rLVHEVDjPnSviMx/Vfm0Y+VDx2ev4ZkZgQf4BfYDB73hWn/wYn1oUhpNKh1UlqBcBZYP5nMa7yp9T7hlFaVkdWjueF68vmtEQvZ9mRIXE1fCHkjI+Ubb4SWOccTfUppg3mOQCXqJSf6lFb1PkM5IPKwa56B4/WlthfbcxBJsdp2n1r5G1uKyL42TVAiDhUSfI4tebWad7zQqumoYQBu18SIeKUxWOChI6aQzrcYGu44ZyuPBBQyI/GmBdj1ZDyyYjj0Ic=;\n\t4:3ujUkqJrIc/JjBzNvktGBCDpapRCIsBM6TCHVsT0G7c0aybh3bT1A/SUHDBQquU4x5Tb6LVXefTmo4fVKBPJDBhbPmtXit3H3QsLt4ymFq/O2QQ8kKDDCPby4oJMNxY8JaZVrCfbYaU24u1RdgMsdMPsrYCYyOL0x9bJjW0AVeP1LAPdWqPVAorT8g8ZedOBg1qlTkgtzG4m7Z3cNpaPfSHLzxR6v5IyFCa8Aw3m9xNxhK+XDHPZ67rLZjhakz0A6sc2Rex+11RduXTycHgeBkWsvd3gKraZw7QZiHq/zaZY3DfY9WFGBiKj7rbGu2y3", "=?utf-8?q?1=3BSN6PR07MB4910=3B23=3Aacid?=\n\t=?utf-8?q?uVZHEWhxrTbnabWVG14xIs0uiJ1ZFD3nB43nYMMT+Gw9/cyR+XzrQQrv?=\n\t=?utf-8?q?Ai9etDWtzelNHvnoCR9TGN7nZpEKV2qO4K6h3li0oULvNBHOvcf1ufQX?=\n\t=?utf-8?q?TgC7Ygf0hazOE1Jm9wyOvomXBQYMCjYOchOk3xWATIqWsKUAvjyLoCSD?=\n\t=?utf-8?q?LGzWXn0WoIgbE/AL2SoBuCKkG1m1SHFm8q5HVsfywcxLvH/V+9x7rv7c?=\n\t=?utf-8?q?a+tujS1leJ4wHBD8/CaZF7/TEIqAltzECt38ZcJ5DGbTH5hKE4p3j2rp?=\n\t=?utf-8?q?Zfb7v6l33H+/BuV6N1955bsHNMCaAyP0Y8z9Ps5OSUxT5MIARP9gGpb2?=\n\t=?utf-8?q?qUSOELKodn2ERYwyA7aP51nEY79CbBCSVXlH5zT/J2wtic00YJsMD+ko?=\n\t=?utf-8?q?WLsTEtpj3tLhdqloT3dm0z5ACkKzfKllc/7j4QhfMWfeIrGEzsYK+nE8?=\n\t=?utf-8?q?PFYLryhIynRXIdln/Yb2Y+dLxyG/V99+5ft7vYJbxGrEYTmUiyXZN37Y?=\n\t=?utf-8?q?g3YuzOJdR1kZtYuV5Ce53POYu/7LBkRES6nekdyahMfjInVq7KKomnpY?=\n\t=?utf-8?q?+p9sJz90v+05XQ/gpYQ5D4Hocjbdp7WVzWQK8jL3m60pQ+NMlFRROST2?=\n\t=?utf-8?q?KLqviqwAd1acjfRzjA1T3YBQqOQAIhzqjf54lswAJJlXvIiVAkdqeDgE?=\n\t=?utf-8?q?IUiLtF/eJbqpSZ1Ph+PFT+pQHKjk+kmxaaaorpc4Qpj/N4nngBAKPwvY?=\n\t=?utf-8?q?E7GLSeOQLA4pv2qvFZ7JUrvroIQKlhH4cp9k8dbMiYhTYc+i3ppLvEuE?=\n\t=?utf-8?q?KsJ5bXi5AmPE4Xaf+BChLRYdN3vQXuGVQvwlTk6rY/6IkGY2C4j6rXml?=\n\t=?utf-8?q?nlv6xA0HxmGSsOFkJO/y/AtE5z8LD4KotUX6FO+ZhdFkr1UaIFplkYYE?=\n\t=?utf-8?q?lw1GWt3DqY+vneKqcnW6lp8FJuRsz33xcMjiMKIOhqVi79aj5mgs/Bfn?=\n\t=?utf-8?q?PiKuelOFFRaZsjhfStMMAjn+eDDPaAOcBH/hPM20ne0NyFyEVloSowEa?=\n\t=?utf-8?q?e1A9+TBtVZrhqF9wjbzB0TeAC4RkV6taHAGHIyQljOH9HcsPA7jjZFWY?=\n\t=?utf-8?q?onTor1IYpFQfufr24dkDRpU9RuHkN9J2tCI4GHNIPBP4RUXn7XxtgfKo?=\n\t=?utf-8?q?8UzhtTBZ5BJnlrPC7BxugN+N1fWwr25be1rZ8DjjxNKTSJyzIYr6g/e5?=\n\t=?utf-8?q?I4DMtG/ZYbNjsUSb7KZogf8lrtzyflqB66kWjr7+pEEXg15GkEBuhl2o?=\n\t=?utf-8?q?abEJZwkbnOC5ddwGC8ojxw5Tz8OpwgIwQGvNnhx75Do1U+VTge3m4uh3?=\n\t=?utf-8?q?2Z2PSr0/J2snf5Rik1i59oizG6kM3p7ha87Wi9l74YmA3hKzNXj0brZf?=\n\t=?utf-8?q?52DDyv+UO5rP3dNevxxKoapUGzCp9q0ri6x/Th7aKALzaNiM4Z16Wu00?=\n\t=?utf-8?q?oywSoZUO1yMgGMcbv0U0uVpGdxJMZd9OSN7n0j3SKqkqBJ6AUlHaufAw?=\n\t=?utf-8?q?Z1xx9XFVtujBS4PhuZkPyMSX3HIUfL4Tygd6yzQ8jtNObvtASJhpsbVm?=\n\t=?utf-8?q?bi0FWec8C/VaV0I70xWB?=", "1; SN6PR07MB4910;\n\t6:3zTn2M5O3y2f8xCZ1glhmYr/D7P8h4lKr3rnRb12o/ewtxmUuxSVxJtB79L67epQyqSC5d7IcHPG+JQvTgRi0FqMzG4IT2+RFBHYgt7T+yXJXB8fdELgIjQPo0tOZDem8ZTlv21DJwJfyyYs6rZDvD2bqgPiKChYy1SJy2WhqujTgijc4k9Aodh5iKjoo8IsyVhHm7uLBlFI0VizBjolhcwOFDiNTdK2TESCu8DTf84/bXEJdYJ/LyvVxtKLzj8Ubb/vI1esw8r2Ydcewc2Yon7VIAyUUHj/8TeIfq8VB4vihrIbitdnz21gYySJvp9oY1AEv4c31Q353JViuVsY86EWMGuPw2cGpp0PsId3lCNig9ujI4rZlTACgjzAfi1xoGg/SV9/JYgPZpg7tUWMMikVymqL5i46mcEaJh/ut2hzkuVhTdrUBbgqIiHR7NudSSSzo9/jsHvx3MVrE0H2Ow==;\n\t5:SUeOheBJVBmPZyn2PFXo/tzzXFQot5pGnQRcyt6vHKRwjOEHf5tCE1bnGxsbKW6eIVorhndD1Sjwv1fvYT6FwU7fIPVJp5Co9GvWoG8JGqs7YmWTNHDRhW0L9HfGXiB3TLCghagV+5atlcHMk4O2zt2wGaVl63eIMuJY4pLIGRw=;\n\t7:WE136/1nvnBHS3PmYY5GlXO4Ptb6pd/2ZnGhaNtne6yG0/rFTmsRdewAp0gkimlHIwLyOyVnsfsdS5oNSnRkN4vBheGw6NtvGmoNYcUBBtij8esReyJbNiLJ3JbjPqxK9wmlc498WmPq94HN5RKtWeCaSr3jcMhJkg3ybamkrqb0qXSh9YKjJzcyqlpcioKxIMFyu8HsOMogbpg3jIJ+/kOiVJTlawm0ZG6GxFm0VKZY7m+IRR98f5zTnnGDgXom" ], "X-MS-TrafficTypeDiagnostic": "SN6PR07MB4910:", "X-Microsoft-Antispam-PRVS": "<SN6PR07MB4910D301D0CFCAD332DF5E64F83C0@SN6PR07MB4910.namprd07.prod.outlook.com>", "X-Exchange-Antispam-Report-Test": "UriScan:(278428928389397);", "X-MS-Exchange-SenderADCheck": "1", "X-Exchange-Antispam-Report-CFA-Test": "BCL:0; PCL:0;\n\tRULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(3002001)(10201501046)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699016);\n\tSRVR:SN6PR07MB4910; BCL:0; PCL:0; RULEID:; SRVR:SN6PR07MB4910; ", "X-Forefront-PRVS": "076804FE30", "X-Forefront-Antispam-Report": "SFV:NSPM;\n\tSFS:(10009020)(136003)(366004)(396003)(346002)(376002)(39850400004)(53754006)(52164004)(189003)(199004)(50466002)(64126003)(7736002)(105586002)(305945005)(97736004)(81156014)(8676002)(81166006)(25786009)(3260700006)(6486002)(8936002)(106356001)(229853002)(966005)(316002)(58126008)(478600001)(68736007)(54906003)(72206003)(53936002)(6246003)(31686004)(4326008)(6306002)(14444005)(76176011)(446003)(16526019)(186003)(2906002)(93886005)(476003)(47776003)(11346002)(65956001)(486006)(6116002)(31696002)(52116002)(67846002)(2486003)(52146003)(52396003)(23676004)(65806001)(230700001)(6666003)(46003)(1706002)(6916009)(42882007)(36756003)(65826007)(5660300001)(53546011)(386003)(2616005);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR07MB4910;\n\tH:[IPv6:2405:204:d304:3387:7872:4c88:2493:98ac]; FPR:; SPF:None;\n\tLANG:en; PTR:InfoNoRecords; MX:1; A:1; ", "Received-SPF": "None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)", "X-Microsoft-Antispam-Message-Info": "utLgpv9GsrFtHK+3kxzSIxkuuOBbZH/+YbuydbRVBPKufmwVMdnsyM2VJaan8X3b25/Tbv4X7OR0xBddPUnr94S0aqdioQeEmi4dDgS3Ut/iGIbm4EvcuuaBMzIdCk+NPhhCdaKN/ffJq+UOn6W80MwoFZTB967p0Rfd99aauKTetGDC4puVDvP09NH5zYp+C0I9BZRx2o2LrHYala2IAGgcwYjCFlFKhiCEk1veG0SzJJT+vDf3vI83s24cqxQTOsjYMcEvXztzRDjx4St1zOk46CfSStPaN+L3M9ktgBH/322qn/L5JvyN1424JqEqJ8nmVuK48Oh9cBcHN8KnwwKeChRB5aMRMWbTZ+3PI6A=", "SpamDiagnosticOutput": "1:99", "SpamDiagnosticMetadata": "NSPM", "X-OriginatorOrg": "caviumnetworks.com", "X-MS-Exchange-CrossTenant-OriginalArrivalTime": "18 Aug 2018 09:57:47.8089\n\t(UTC)", "X-MS-Exchange-CrossTenant-Network-Message-Id": "ac850534-7d84-4f68-6673-08d604f11129", "X-MS-Exchange-CrossTenant-FromEntityHeader": "Hosted", "X-MS-Exchange-CrossTenant-Id": "711e4ccf-2e9b-4bcf-a551-4094005b6194", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "SN6PR07MB4910", "Subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 88344, "web_url": "http://patches.dpdk.org/comment/88344/", "msgid": "<4007247.pNfAseMmkf@xps>", "list_archive_url": "https://inbox.dpdk.org/dev/4007247.pNfAseMmkf@xps", "date": "2018-10-29T02:22:24", "subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "submitter": { "id": 685, "url": "http://patches.dpdk.org/api/people/685/?format=api", "name": "Thomas Monjalon", "email": "thomas@monjalon.net" }, "content": "18/08/2018 11:58, Joseph, Anoob:\n> Hi Bruce,\n> \n> On 14-08-2018 16:03, Bruce Richardson wrote:\n> > On Mon, Aug 13, 2018 at 09:29:01PM +0530, Joseph, Anoob wrote:\n> >> Hi Bruce,\n> >>\n> >> The reason why l2fwd was chosen was to allow everyone to chip in their ideas\n> >> while preparing the framework.\n> >> This framework would be extended to other applications, hence needed enough\n> >> inputs before expanding to complex applications. If your suggestion is to\n> >> make l3fwd event driven first, I'll start looking in that direction.\n> > Seems good to me, if others don't have an issue with it.\n> >\n> >> As for l2fwd, I'm fine with moving event-mode additions to a new app. But\n> >> with the present approach, the app would run in both event mode and poll\n> >> mode.\n> >>\n> >> Your thoughts on renaming the existing app to l2fwd-poll and the proposed\n> >> app as l2fwd?\n> >>\n> >> Thanks,\n> >> Anoob\n> > I'm not sure about the name \"poll\", I think \"ethdev\" and \"eventdev\" should be\n> > the suffixes, if we want to move in that direction.\n> With new adapters, like crypto adapter, event device will be able to \n> handle multiple devices at the same time. It will be able to abstract \n> not just eth device but other devices too (crypto for example). For apps \n> like ipsec-secgw, crypto also would be abstracted with event-device. So \n> what should be the ideal naming convention taking into account all that? \n> Using \"eth\"& \"event\" won't fit in for such cases.\n> \n> Presently, mode was defined by the way packets were submitted to & \n> received from the device. With poll mode, device(eth, crypto etc) would \n> get packets directly from the core & the core would then poll for \n> completion. In case of event-mode, event device handles this scheduling. \n> Event device would submit (to all devices) and receive packets (from all \n> devices). Core need not poll on the device, in that case. Hence the \n> naming...\n> \n> Your thoughts?\n\nI think it is OK to have event mode in examples, in general.\nThe only concern of Bruce was to keep l2fwd example simple.\nSo for l2fwd, and only for this one, you can create a new example\ncalled l2fwd-event.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id A9A1BB62;\n\tMon, 29 Oct 2018 03:22:22 +0100 (CET)", "from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com\n\t[66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 0032E160\n\tfor <dev@dpdk.org>; Mon, 29 Oct 2018 03:22:20 +0100 (CET)", "from compute1.internal (compute1.nyi.internal [10.202.2.41])\n\tby mailout.nyi.internal (Postfix) with ESMTP id 8929721BA5;\n\tSun, 28 Oct 2018 22:22:20 -0400 (EDT)", "from mailfrontend2 ([10.202.2.163])\n\tby compute1.internal (MEProxy); Sun, 28 Oct 2018 22:22:20 -0400", "from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id 83756102A0;\n\tSun, 28 Oct 2018 22:22:18 -0400 (EDT)" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=\n\tfrom:to:cc:subject:date:message-id:in-reply-to:references\n\t:mime-version:content-transfer-encoding:content-type; s=mesmtp;\n\tbh=OM1DPN2Pb9bA+0DrP78qJx+Z6gCb9lSvpqE+AJBgi64=; b=Bsl7EfG1OyB2\n\tWFdGKDBoWNvQr0SA8RixbTQCYPvQ2M64QRh//haZdXC5ENuhhLpqtlDq07Bisuoj\n\twnHIQzWyO2aMuk0JsgklQl3UKBTr5FmxSFSggjPOxmXpGiWzOnwyrJWonmfB9wzZ\n\tC/p75mMzaQyxPAu/3LgPtN4khLY7TUY=", "v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-transfer-encoding:content-type\n\t:date:from:in-reply-to:message-id:mime-version:references\n\t:subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender\n\t:x-sasl-enc; s=fm1; bh=OM1DPN2Pb9bA+0DrP78qJx+Z6gCb9lSvpqE+AJBgi\n\t64=; b=wZmDL92so4i3BSjvvrCGSbkR08uyG58MwKLMuyGHDpz95Ljmb4Hx2+amt\n\tFz/E1WwJV2VkBeyTFl+nPD144AqgefnMH3uVgzDrysGuC/qD85vljyCWu7FAxwkp\n\t7poyjjiTW6fHDIH97tDYX2wbId97KosibTflOPQ4krJvrwS9kSdue99mfD7v4kAs\n\t5OXTUCfhVYWJ/RHu1qqltXVjH5Yg2QbjSMuphOCQvmnIWTl4YIN0Xm3SKL9K8xvd\n\t1gFAiGxBTVFAs32ZKRistkrhDdaiBNCbIuC2LZPeESd7tOcOHZW8DwHxmiSRyKqH\n\ttCg0NNQGpOuoogFhtQWXkr72Z/08Q==" ], "X-ME-Sender": "<xms:227WW7sDpNWUiOBj0KFIjMFIADCf2Q8a815Q7fT2M8RTV3CSSfbROg>", "X-ME-Proxy": "<xmx:227WW1tPl92sh2rCDsY1y2nzwDfo5gAScJegM9BPz1bCztdNE320mw>\n\t<xmx:227WW20U-mGgvSDr0a7FtAAKjz4kQKVtG2PtBuOL_hVGhuhnsPQekw>\n\t<xmx:227WWzDmh2FWv28VU_K11autkZMKS8XfbqJZD1y5mZBMS98gPjAFJQ>\n\t<xmx:227WWwwsy4tp4HNqTwXnkp5O4mnP3pOTesHfsOJvrlWiF2GoxJr0NA>\n\t<xmx:227WWzQILOj8YXuP2LiLzij1_dPfODYKJ1Bbd0jBubo69pIxFONSZw>\n\t<xmx:3G7WWyshQ7ePktNWe61i6CYMMWOil9h-fzrJF19MXPN9y36G9uwrDw>", "From": "Thomas Monjalon <thomas@monjalon.net>", "To": "\"Joseph, Anoob\" <Anoob.Joseph@caviumnetworks.com>", "Cc": "dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>,\n\t\"De Lara Guarch, Pablo\" <pablo.de.lara.guarch@intel.com>, \"Ananyev,\n\tKonstantin\" <konstantin.ananyev@intel.com>,\n\tJerin Jacob <jerin.jacob@caviumnetworks.com>,\n\tStephen Hemminger <stephen@networkplumber.org>,\n\tNarayana Prasad <narayanaprasad.athreya@caviumnetworks.com>,\n\tHemant Agrawal <hemant.agrawal@nxp.com>,\n\tSunil Kumar Kori <sunil.kori@nxp.com>, \n\t\"Rao, Nikhil\" <nikhil.rao@intel.com>", "Date": "Mon, 29 Oct 2018 03:22:24 +0100", "Message-ID": "<4007247.pNfAseMmkf@xps>", "In-Reply-To": "<7f529e8f-a61f-3950-265e-8923efc61743@caviumnetworks.com>", "References": "<1528976946-14396-1-git-send-email-anoob.joseph@caviumnetworks.com>\n\t<20180814103313.GA12412@bricha3-MOBL.ger.corp.intel.com>\n\t<7f529e8f-a61f-3950-265e-8923efc61743@caviumnetworks.com>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "7Bit", "Content-Type": "text/plain; charset=\"us-ascii\"", "Subject": "Re: [dpdk-dev] [PATCH v2 00/12] preparing l2fwd for eventmode\n\tadditions", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null } ]