From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0080.outbound.protection.outlook.com [104.47.32.80]) by dpdk.org (Postfix) with ESMTP id 7385D5934 for ; Fri, 14 Oct 2016 11:26:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oZBCq7zBDhm+5FmvsBk4a3+/OyUS46XK3UAyOAcyZXM=; b=M+I1cHUz6vJewKguEqGJpGKoaoxd42OCetsZFng/gHSnvma6coDUOgbBLIGThL1bIRQ2OlO6eA898BLn8VOw6+xxe3jhWy08kFvhVjVD2quvBviM6Yzx8IodINc9VZMVfiMxVdnrXwA1JP/CGdlBaTGJe+mmZvT3Dp8A+RmaMB4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (111.93.218.67) by BN3PR0701MB1719.namprd07.prod.outlook.com (10.163.39.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.12; Fri, 14 Oct 2016 09:26:28 +0000 Date: Fri, 14 Oct 2016 14:56:09 +0530 From: Jerin Jacob To: Bill Fischofer CC: , , , , Hemant Agrawal , Message-ID: <20161014092607.GA16828@localhost.localdomain> References: <20161005072451.GA2358@localhost.localdomain> <1476214216-31982-1-git-send-email-jerin.jacob@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.2 (2016-07-01) X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: MAXPR01CA0036.INDPRD01.PROD.OUTLOOK.COM (10.164.146.136) To BN3PR0701MB1719.namprd07.prod.outlook.com (10.163.39.18) X-MS-Office365-Filtering-Correlation-Id: 7a30fe2c-d088-4257-275a-08d3f4142eb3 X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1719; 2:IMFObHo+UldJuDbIqLrWkLMTWP4bfFhzl3n2Vv00F2X/D1pSKb5pvNKauRVszaich+YzRxagovEl+8mQK+zHcakqa7EtCqFzuW59fWXyX09kaOZ177F8naqpfHvqDgcwkYpkpWQWPx6bif+9hb9ey7J02d6Gry1MuN3ZQBdmWJ0TrYlV9qsA59wm2Z1jTVeX7NF8m6kGt29FRQR0scOkMQ==; 3:uIk31N4yFKFgmQ98iqhvphxAa1WFXhcQqo84/CahclTPWoFEL80aMvRE8iZGoI6x5L1UO+vHHm/x+8+hGJ2UnrT7uSL5JDjjVyxOmGccqlRgmJVQc3OhjF6EckRBAeA8V7CfwBqf3bISD7xqZZ1+FA==; 25:M9f2y7+/fMlnoT3xuXIQOpwZtzPZoC0nRUwFZbl4o2P77WP5Al28UvjqRNXOWr2QOznkBD3BZwPfOaG2ZamGSxXWQeR0YuVOdzRP9Nk3HUSTREZmVQQMoRMmos57016EnJKCgEcezal4dNqXID5bI7oZG707zm8ovaT72H1xs9F0qBm4KE6K79k9aG+zyN0/TX5qABU+US3wutGXMT+W5i9GWLJhpuKhYKaEsG2xY2fZ/RUOMmQDOQBV5ox1A++9d54NMHDYMCmpE2rW0NhWiRfpKL6eaRTuE4RferVUeMTIkWC18z3pLP8W+HiOE6oy9dSjNxivtoSZj7vjTlba0qcGyriSRCkqTrWoITNycpXVsO9C5CD60J32OKLq6uZKz2OibYcTBqdGgAjoMwy3yM0AZKWYCcTODeDNzv++q/Y2dIr51ZKkIVL4kjZw9bGD X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0701MB1719; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1719; 31:CX/XpWjHNQAm57vIEO8UivvMcP+jC8669u53imS64gDiAKy/UM7p9QDdQTDjaK4fEOsmvGdv9G0mOAd2pYKejqTswRgM6BZtQ+Hck/r4c5UmD8SZRfY3x/1ye92PW0epGcgDI7XpSkG4EqYH7R03w5VPWDQQYori/1G7h442iUedf58wHd2UWe+9+Lvi+P45Js2GZqJIsJruov48XDKfEgsvqrjBrvgsuHu7aK8RWSdlLZGnVoSW81NWstbfTy+I; 20:UmkB2sdkb5XvOMcFJYRogf8fN21uETHpl3a1ymCy4oT0/AF6R8j208d4brArTuwJQ+gBIiSMAByn46b1uoFGTNgZpbjQ1hPPvV+hqU5C4lcs1K/U9e8MK/JPdkbxhKVLzZrifXUNP36LLl41OKEzQo/i72pB3tmZSnT0q4u/8BOJVNbEAAiFDCRwcRDJrgif5ttPMH7jCTJSEejqc+6F2gZlr8eLV0riv/XnJSi5x5eQ03eAMemYV37+NihEIYt6odFWxB2W18aG98rgQ9ReBvx0uJISzR2yNRlGe3CFBBUwnAvUXg15O6KAik0uEf4xw7caMceJtW5QrdZGOq2BaHvrVG5Q/TtLfxLdGh5o1yy4fgBUm1riaBlBCC5lsB56WmyCnK/salIB3c5uyGzyS4maBeMbfwSu+sOp/fVASM6ZHTBI62qc4QkaQg8OvuDTRKQqnUE8GwNumPW1wMw4zWgpgN+TCuDunUL8YtRG4fGTmdGnopwIJgZOP1++5OMq3n5IsO/LWcoj8kNWFQyh+XriVrg9hgI6oSDOvixv4bl3XBejSXjia/1WLuMloX0Esxn5Ah8njIAB6G8AaOppN2Ss8gQu59BsdTpQtQ31arY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0701MB1719; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0701MB1719; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1719; 4:zSLL3jVdqhTBVlKb+EGRiZKfOq3nzelskfrthUmC8rEOTtNEH1K9f/8BHb/ltRdV5CZ3750CI6q56u7+wrJiC0zSAUQMfcUww+UqJdR9KPd1lwv9tYTvWmRNsMRxpdthdQa0spv12FMliONim6DE5KaiiEt0cn44b7LLXS6sU7gt00mfis+sSyq5uwGZGStxFI0YgNxI4+GOcp8iO8IRZaG9zZ2JDV544aOhLhoxDohBnz8NvFMaLU8kdgnyLivSgmhvAfPNhD5fImiJY/t2du5Hsblrmrwmv78MYEjxJh4CT/U60YhD9mnwF9fEsyDHivlBRNDJ6kF38+/y01NRS4IoPWVs67I+H8BlSRE9SWlqiG+78Dd30L7zNCI/wZoZ8tjT18hS3clDrSbMRxyNOQ== X-Forefront-PRVS: 0095BCF226 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6069001)(6009001)(7916002)(199003)(24454002)(51914003)(189002)(586003)(3846002)(6116002)(9686002)(2870700001)(2950100002)(68736007)(8666005)(42186005)(33656002)(1076002)(189998001)(6916009)(42882006)(97736004)(23676002)(6666003)(50466002)(5009440100003)(19580395003)(47776003)(92566002)(77096005)(101416001)(4001350100001)(83506001)(66066001)(110136003)(61506002)(5660300001)(8676002)(81166006)(106356001)(2906002)(105586002)(81156014)(4326007)(50986999)(54356999)(305945005)(76176999)(7846002)(7736002)(7099028)(18370500001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0701MB1719; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA3MDFNQjE3MTk7MjM6aDBGVE1OYTdONGxEZ002cXdmOXg5M2ZW?= =?utf-8?B?cnFoSmxRM1hNRGdYV2J6WnJWWEhlYWRUQmo3dTkvVnRaODNwTFdqTmdCVEJi?= =?utf-8?B?UjRrLzJWalI2VVpCUFBlVmVGa0xZZ1FVQUhNdGtlVHhqK2ZaRmprR1JQbTdn?= =?utf-8?B?Y2NLd1ZvYjNmUDVXdm0xMnQxWUxtejg5cmFMMUE0cXc4K0E4bzJCb24wTWQ1?= =?utf-8?B?OHhEdCtFc3hRL1BhSGRjS3NSbDRjV2wwOFBlcmtMbnV5MGlzZERPeXlSaXpr?= =?utf-8?B?ZmdlMXVhcXl4YUFDNElhU2FpS2hEcFNZdWdxMnNOTjZDazIyTWZmSURqLzVN?= =?utf-8?B?KzkyYlc0UE93N3lqMk1NUHdXNDJmTDRCSmxVNlFJdHhjdmNjaC9oa09mMGJz?= =?utf-8?B?M2tOcm1MMTF4WS9RUkxOV2RNQkVkbkU3Qkh3Z3ordU1BeDVXQmtJSDRPWmJu?= =?utf-8?B?eG1xQldCaitLcXNlNjczNGZ3N1lmQ3BzTWtXUUltamh3em1pUGgwY0JBdDIw?= =?utf-8?B?YUlUYlFwNnNUN2x3ako5V1JVSGZpM3hxVkJNRy9PQ1hkOGJrMFZqampVelF0?= =?utf-8?B?N0tZUUtsWDBpQTNaOWU2NW5oNHc0NTNwdFFIcEM2QWNDc3RNbWJCZXlTb0NH?= =?utf-8?B?SGU1VEVJYmJTM0VndTBGUGlOcUg0L3ZkSm9oYmt6WWJ5ZnZTY1dXQVBXMWY3?= =?utf-8?B?aWswQnhmZElPTzRLc2dhZzdkNko5S3A1T0pGT2NxcFdHR3RCV2N1QmRDTnZn?= =?utf-8?B?bXU2VHFnMmFjS25CNkxLSUhoN3MyUXVQRnI1OHIrMy84M1pTRzhXNURBRVdB?= =?utf-8?B?MWNGWmIrY3dieG1ZR2dTbDVRK1lULzF0cXJrUEpsRGpnTWp5bzhRRTVqZ1hm?= =?utf-8?B?aXBNSTlTSkVqYS84VnJVMTdYOUVHbGtmL01ndG9Vb0hjWGtUS3NGaENITWNx?= =?utf-8?B?WnlZbWNkU0JJdFkyNHkrZldXRW9IaWQ2NlpEZUtRdWpzZFpucCt1Q2Rlek5u?= =?utf-8?B?TzNYTlk3b3hMUEkzckd6cUVUMDZJUVhDbXc0ZnQxUytUME8wNzdYbjVCNGkx?= =?utf-8?B?bHhwMVJzVm82YWVmdEtXd2t5SzJzTjB0Yk9FMjhwQ0tUVTB1dlBCVnhQOEFm?= =?utf-8?B?SWc5MnFscEdyNGxIZ0NySzZ1bEx5a2U4ZWtkUWdmcnRFcDE4dW8wL1RTenpO?= =?utf-8?B?eTdZVXRyYWZNTFJ4aGp3eENGNGl4SXJHSlBwTTBoYzh5U0tGbnFEaGpmcHU3?= =?utf-8?B?czZnaVowWklVdnkrMVVEdXB2KytiNVl4d0p5L00xd0xlNzZnYTJQZ1FUcHdD?= =?utf-8?B?dG03Y0xvWFcvdVYxQjRmbjhKc2lCeTJJUlg4ZGZad3RSamlTelRxdFl1UDdX?= =?utf-8?B?MnRaUVExU1NkMk9oVEdZTnE2U0xyYlFUOGZuUEJxSkc5QjNVNUlLcXFiVkFE?= =?utf-8?B?UE9JTXZaRld5MDVTT3dVV0R1SjZKeGNZbnJPcnBvUDZlS1BLQVZRR2pabWZz?= =?utf-8?B?ODlBZFEvZlNPZlErT09mcDZjSExCK3pXRlNTcm9qUGZkWTVFMTR3MiszRlFv?= =?utf-8?B?bTRQVVorM0xsRmZnQW9KendTMGdhNzV1cDRBVUFoMnRvNU1SUnlyT0pQeGpX?= =?utf-8?B?ZFNDVEhBRXltcGd0Vk1PQzg0WkZodDlZMHA2Smh6SW1vbDlkajNHZWJUUmly?= =?utf-8?B?L0R2MUs0VDdQajZ5VEVVcHJzaDhyNlMxNXhVQ2F2eENsaDEzOUVBY2pMc2Ri?= =?utf-8?B?NzVQTTkxR0tOSk5qTkZIU1ZIaVFLQ2RFMEw5RlhMaUQyOWFNNEJMcC9zVk1w?= =?utf-8?Q?dbnyDUlAgEnliGi?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1719; 6:IR8GWEBqCWAyJG0GtuFGLXpEdIGffSckPE9aFimFqqq7Na97T0BfrIxb8PhmZN7bOmNzn59FtSdA3lAy3g3RCp6WFQeWlYpOYRJcySKm8j5rrqLJIo/BgBtK1U+S+iUngOzdZmGwiDU3rSEhaT8w49uLu7SXb7YW65VciOvdesjk0UOgnr48pW6CZqsNxTaD+nyzxB6WOlKRNOLhI6z/1z/1rbotO31L0ETB6SSW2YZjdFWRxmnJDhpr+vkN0M14MZBWbKcjCwo4BY5s7joP854XBO1EE0OpIotjSszEoQe7M9D1usnpZVZbqITvnLTs; 5:lBtLSnLePDjT0yVQklgu1V2hUQbdkg5f7n7lpX3suTFnNwJfpzBnlYTeYZQwzvrTC7kgliKyUrvhnXMkkh/E2nyYXOHxX9t5U2pIPFmgtLo4z1DD8zIGffRfkBbLa0o/XhhqOLt/QrHw93OicdnFQQ==; 24:a3WLmJtV+drhWOGIgPmh7Y8B0vxZdgRh0EggMT4493/Y0DOE2roMk8i/9YIrGSwmZwPyNo4rLwVZ4ai3JBEOYClLYwrIl4R8iYPCdZ6qn7U=; 7:k/fEADdC9TuM9MHxMhpUFrxRqSH4A2oGc7bNtEamN6gmWHSG0oeeGgFdIEY5HU8C+82GsQTFgkmjg3dTx0QBr8Ne0YFXQzoUTr96mfAQkNblroXUpt4ljlVPQC4k8dDaJzV76FXAYWcDUmy/pA4ovokmlHUvmZNFRv70ebEVuWoqg0/PLEx32iROpwC1S1ELz+vi02t+psFzJFRUzS6OZm7iP4OgS66+C5XiluqVH3t4XAb+Si5ige+HbWuM1uNV+SIUegNdl6mCRH+oXIGKKd2/r2a7UTI1Z9xjfFd1XlZqJNszQXpUj7mQelMStVuesJqEJ1vbPK8G3x2u7spNw/23grwYwQ0xkC7TsXAS340= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2016 09:26:28.5058 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0701MB1719 Subject: Re: [dpdk-dev] [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 09:26:48 -0000 On Thu, Oct 13, 2016 at 11:14:38PM -0500, Bill Fischofer wrote: > Hi Jerin, Hi Bill, Thanks for the review. [snip] > > + * If the device init operation is successful, the correspondence between > > + * the device identifier assigned to the new device and its associated > > + * *rte_event_dev* structure is effectively registered. > > + * Otherwise, both the *rte_event_dev* structure and the device > > identifier are > > + * freed. > > + * > > + * The functions exported by the application Event API to setup a device > > + * designated by its device identifier must be invoked in the following > > order: > > + * - rte_event_dev_configure() > > + * - rte_event_queue_setup() > > + * - rte_event_port_setup() > > + * - rte_event_port_link() > > + * - rte_event_dev_start() > > + * > > + * Then, the application can invoke, in any order, the functions > > + * exported by the Event API to schedule events, dequeue events, enqueue > > events, > > + * change event queue(s) to event port [un]link establishment and so on. > > + * > > + * Application may use rte_event_[queue/port]_default_conf_get() to get > > the > > + * default configuration to set up an event queue or event port by > > + * overriding few default values. > > + * > > + * If the application wants to change the configuration (i.e. call > > + * rte_event_dev_configure(), rte_event_queue_setup(), or > > + * rte_event_port_setup()), it must call rte_event_dev_stop() first to > > stop the > > + * device and then do the reconfiguration before calling > > rte_event_dev_start() > > + * again. The schedule, enqueue and dequeue functions should not be > > invoked > > + * when the device is stopped. > > > > Given this requirement, the question is what happens to events that are "in > flight" at the time rte_event_dev_stop() is called? Is stop an asynchronous > operation that quiesces the event _dev and allows in-flight events to drain > from queues/ports prior to fully stopping, or is some sort of separate > explicit quiesce mechanism required? If stop is synchronous and simply > halts the event_dev, then how is an application to know if subsequent > configure/setup calls would leave these pending events with no place to > stand? > >>From an application API perspective rte_event_dev_stop() is a synchronous function. If the stop has been called for re-configuring the number of queues, ports etc of the device, then "in flight" entry preservation will be implementation defined. else "in flight" entries will be preserved. [snip] > > +extern int > > +rte_event_dev_socket_id(uint8_t dev_id); > > + > > +/* Event device capability bitmap flags */ > > +#define RTE_EVENT_DEV_CAP_QUEUE_QOS (1 << 0) > > +/**< Event scheduling prioritization is based on the priority associated > > with > > + * each event queue. > > + * > > + * \see rte_event_queue_setup(), RTE_EVENT_QUEUE_PRIORITY_NORMAL > > + */ > > +#define RTE_EVENT_DEV_CAP_EVENT_QOS (1 << 1) > > +/**< Event scheduling prioritization is based on the priority associated > > with > > + * each event. Priority of each event is supplied in *rte_event* > > structure > > + * on each enqueue operation. > > + * > > + * \see rte_event_enqueue() > > + */ > > + > > +/** > > + * Event device information > > + */ > > +struct rte_event_dev_info { > > + const char *driver_name; /**< Event driver name */ > > + struct rte_pci_device *pci_dev; /**< PCI information */ > > + uint32_t min_dequeue_wait_ns; > > + /**< Minimum supported global dequeue wait delay(ns) by this > > device */ > > + uint32_t max_dequeue_wait_ns; > > + /**< Maximum supported global dequeue wait delay(ns) by this > > device */ > > + uint32_t dequeue_wait_ns; > > > > Am I reading this correctly that there is no way to support an indefinite > waiting capability? Or is this just saying that if a timed wait is > performed there are min/max limits for the wait duration? Application can wait indefinite if required. see RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT configuration option. Trivial application may not need different wait values on each dequeue.This is a performance optimization opportunity for implementation. > > > > + /**< Configured global dequeue wait delay(ns) for this device */ > > + uint8_t max_event_queues; > > + /**< Maximum event_queues supported by this device */ > > + uint32_t max_event_queue_flows; > > + /**< Maximum supported flows in an event queue by this device*/ > > + uint8_t max_event_queue_priority_levels; > > + /**< Maximum number of event queue priority levels by this device. > > + * Valid when the device has RTE_EVENT_DEV_CAP_QUEUE_QOS capability > > + */ > > + uint8_t nb_event_queues; > > + /**< Configured number of event queues for this device */ > > > > Is 256 a sufficient number of queues? While various SoCs may have limits, > why impose such a small limit architecturally? Each event queue potentially can support millions of flows.That way, 256 may not be a small limit.The reason to choose queue_id as 8bit to hold all the attribute of "struct rte_event" in 128bit. So that SIMD optimization is possible in the implementation. > > + /**< The maximum number of active flows this queue can track at any > > + * given time. The value must be in the range of > > + * [1 - max_event_queue_flows)] which previously supplied > > + * to rte_event_dev_configure(). > > + */ > > + uint32_t nb_atomic_order_sequences; > > + /**< The maximum number of outstanding events waiting to be > > (egress-) > > + * reordered by this queue. In other words, the number of entries > > in > > + * this queue’s reorder buffer.The value must be in the range of > > + * [1 - max_event_queue_flows)] which previously supplied > > + * to rte_event_dev_configure(). > > > > What happens if this limit is exceeded? While atomic limits are bounded by > the number of lcores, the same cannot be said for ordered queues. > Presumably the queue would refuse further dequeues once this limit is > reached until pending reorders are resolved to permit continued processing? > If so that should be stated explicitly. OK. I will update details. > > > > + * > > + * > > + * The device start step is the last one and consists of setting the event > > + * queues to start accepting the events and schedules to event ports. > > + * > > + * On success, all basic functions exported by the API (event enqueue, > > + * event dequeue and so on) can be invoked. > > + * > > + * @param dev_id > > + * Event device identifier > > + * @return > > + * - 0: Success, device started. > > + * - <0: Error code of the driver device start function. > > + */ > > +extern int > > +rte_event_dev_start(uint8_t dev_id); > > + > > +/** > > + * Stop an event device. The device can be restarted with a call to > > + * rte_event_dev_start() > > + * > > + * @param dev_id > > + * Event device identifier. > > + */ > > +extern void > > +rte_event_dev_stop(uint8_t dev_id); > > > > Having this be a void function implies this function cannot fail. Is that > assumption always correct? Yes. Subsequent rte_event_dev_start() can return error if the implementation really have some critical issues on starting the device. > > > > + > > +/** > > + * Close an event device. The device cannot be restarted! > > + * > > + * @param dev_id > > + * Event device identifier > > + * > > + * @return > > + * - 0 on successfully closing device > > + * - <0 on failure to close device > > + */ > > +extern int