From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8C9F9A034E; Tue, 1 Feb 2022 18:50:27 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 26FA840698; Tue, 1 Feb 2022 18:50:27 +0100 (CET) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2067.outbound.protection.outlook.com [40.107.236.67]) by mails.dpdk.org (Postfix) with ESMTP id 3E5E140691 for ; Tue, 1 Feb 2022 18:50:26 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ccaf8ZMo1C/lDs0wnOWisDTarTjyvO1EW0g43ToLt+YsdTAY2ttM2xTrZnYDeAVNCxc5wjhN9Df2mGqNDveLFWAj8RkjbUslVUVZJALKuuhtWLqObP1a4oLspaf/my1HurqqdFJhQAKDu0XP/4uIDrtvd3JtbCXhdr0Ys1oKnuPXaODsphLNNdyJTJm32v+YiFsWWUgYunZTCvdAXWEOKJegVrNjnsVfb7piwBajcJnYVxA71yWUWgnAiFpFI8c3HhSKpZkC7YeQNEPk0bJO+ig9VviD6vZsaIlY6i25S/0SWPyo6QD9xOQrM9EQ3wFOqss3JBVpcWSco8pBYwerRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Q+CRf7rVB0z8OhyiilR1LT2cXto8mpG2APdi0Fm5KxY=; b=AQJXskaPH+P6Vs4+otCn42XWZFDduL9sLtlRz06QLBSO4+mivnIrvI9kiP+4mjS86aOeRLpjUEfH82jViFR5VTBMZaoj2cFCKCoBo7AghafgQdtSeI5ZZFWAlnejFMS/w5JvA+GWGIukbt9etQhdTcj2By1qHl/FuVe92FLdMA24hlGu107hpXIAvkrw48DvRQRB3N2UJ4T/T9Qoh8xQquqPW19f/GZwJm6IE1+JqCVSz07hpwx0Wunty5h98o5auj3FC8y/CRxEUjmmGuGD6NbVPcLODGmJwr/1paqVF738rS5M76+0CJ8tmElDkKCkcIo1usNc2rM3quLKzuTvCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q+CRf7rVB0z8OhyiilR1LT2cXto8mpG2APdi0Fm5KxY=; b=kC6/WLt+VtMrjNnZiK98h9B371nQRiSfdsR0qUAMMyveazdXEU/JRGylT57KPjkMtGbmwDQAaQ/pZzOEQQ7CDo7QnIKVh6OldZk2PnUpjVyfqULUsOEds7T37H+GpLxOHhMNuLzpQQtNbZQaoxWaxJnTlsKUngaim0PUcJp1KIOCEJ77lthBGn/rgGOhIRv+8m5SGKbCekXSL0MYBNTZuRJGiDzYxD85Vh6eRM+Pr8beReZ9dy24Ao0vzp0fkZgin9Ib+eIc4uYn2ZccNfzPth/qXW4YcsHwMkvImJbPwIgkOtreaqQ+/uClghR2oL5W5yyB42+Db1dY8OAZdSY5FQ== Received: from CH2PR12MB4280.namprd12.prod.outlook.com (2603:10b6:610:ac::11) by MW2PR12MB2426.namprd12.prod.outlook.com (2603:10b6:907:10::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.15; Tue, 1 Feb 2022 17:50:22 +0000 Received: from MW2PR12MB4666.namprd12.prod.outlook.com (2603:10b6:302:13::22) by CH2PR12MB4280.namprd12.prod.outlook.com (2603:10b6:610:ac::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Tue, 1 Feb 2022 17:50:18 +0000 Received: from MW2PR12MB4666.namprd12.prod.outlook.com ([fe80::1869:1984:7899:8cbb]) by MW2PR12MB4666.namprd12.prod.outlook.com ([fe80::1869:1984:7899:8cbb%4]) with mapi id 15.20.4930.022; Tue, 1 Feb 2022 17:50:18 +0000 From: Ori Kam To: Ivan Malov , Alexander Kozyrev CC: Ajit Khaparde , dpdk-dev , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Andrew Rybchenko , Ferruh Yigit , "mohammad.abdul.awal@intel.com" , Qi Zhang , Jerin Jacob Subject: RE: [PATCH v2 03/10] ethdev: bring in async queue-based flow rules Thread-Topic: [PATCH v2 03/10] ethdev: bring in async queue-based flow rules Thread-Index: AQHYEX6Om1uLjSZF1UGgrQkfZJQ24Kx0wTQAgADoCYCAAcUMAIAGcQ+AgAEZdcA= Date: Tue, 1 Feb 2022 17:50:18 +0000 Message-ID: References: <2fb135e6-f492-bb8-1554-4df1f089fc79@oktetlabs.ru> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 790e7c73-ff1f-495a-7f2a-08d9e5ab4f71 x-ms-traffictypediagnostic: CH2PR12MB4280:EE_|MW2PR12MB2426:EE_ x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: txgvgEi30qGMtDD2S0Zt+wKMU52x36eBFD4XOgA0iHP6D0hhViNj4mtAIG54XihsMT76ll0yhXesYVTEknKj6ZWlIctgShE8Gz9SydKBxSem9nj/r5spiTFoBVF/aYncA45QJGLB+pNEyrz2olVnEA6HbxEevqQaTJdX6OQXA5RAvgC5lu0sNirqbJC9aZzTjgUEOECcT4JGpMiozxIUZSsAVmbrrMUGOS9QgQfMk42qnXfjwVGqbnXgiPNblEq6k9zUkRmgaTfeytaW3qq7uBN0v/U+WADIOCPVSKidBwBwI7dEXMjN6dmLfxZo3r0sphDGwgNEKn7hG+w/tYbF5fv17fbLCKcyiiUP1tt/LNMIRu8PcwNiFTNuoBvwEM/9wrcwwTsuzxrRsJbZj/I7EM50zSbApxNz9Xu2mIWUW8FLUoTj4w9U0CqH/qI+STiFifTqFj83yMC8RKA978NuvmtqJxPIKbIAGHec9KNeJeq8ZGiF8ABKfESeDwu3vQl5ZKAIYmAoIiHK0fu7ZUbnR1cES8V6t1LZusObEYaDog9albAai0QZtJT4TxVy7N+xVAbpHGV/dawihhM6E4yshc3duj7Cfb5AUxUS3BQH/0KQsDqZNIdhMhez/uph5YVhvC0iSJgZEaKQj7wDbK+q64hEC+ujLDBTPZOpQhSm2L/jvq7gj7SvRb31rlyVcVpqPr/mImDDPolWa5qTsoMLOg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4280.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(4326008)(8936002)(26005)(8676002)(83380400001)(64756008)(110136005)(508600001)(6636002)(54906003)(55016003)(86362001)(33656002)(186003)(66446008)(66556008)(66476007)(66946007)(76116006)(71200400001)(38070700005)(52536014)(5660300002)(38100700002)(53546011)(9686003)(316002)(6506007)(7696005)(2906002)(30864003)(122000001)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?EiZNugL2TgCXSDkV6A4WdbHW0j0MJPzphUKOft0vXUCMIePPj/XpX1DxDA8y?= =?us-ascii?Q?EZB8WDh+wcm1UBUMqPiIRufBwe5lnORZvTgs24eI8YgiIwztRrqKOms3mKx4?= =?us-ascii?Q?cONQbDnI/pdchjv+VarwPqcylyPUB+9IwgGmCRG+ALa5a88ror+B/x8BXgwP?= =?us-ascii?Q?T0SXoeLFaaD4Bd2T1pGWl1dOBLkg0g4SM2ahO9JljvY3w2GSFfzvEh9TS33q?= =?us-ascii?Q?2iESVuAXwSrG+lmTMBNjMkUzWgazoSjtpcbc68+cl8oSet4oJoO8GWtbVTnQ?= =?us-ascii?Q?swX9kr+uMJpKtt2PFJlmxUyRiVXUHDmIIy9VvlYzwSDeFAt4aE+gdDV00H/Q?= =?us-ascii?Q?Y9Pv6PGqQZf3CGmJ9NKP1BG2ZrMiwwbmVGHc1uxS4S0HC4Q2IecrGYUIB56J?= =?us-ascii?Q?bFOJC49S60AaA+Dp1sQALzxeOz+x/JWHQ4RmvOP+9HMp6P3ffVJmIE0X2M2u?= =?us-ascii?Q?l9nsHH45duZsz6SGny5If0SLl5QMF/mSCHc6e9K5JzNxu5vMnAn326XQzO2M?= =?us-ascii?Q?M43w2ue0uJ7eBryawkvF9O3+UrGPTWpJAIC7GWWnZcfTZaYYFqhu7YssDTNf?= =?us-ascii?Q?aRqjrJ07HDBUmYz+5Y3FZ/r03K2q2bw97PhsDEbBhQVluYw2+CPryQF0kC6J?= =?us-ascii?Q?5L6NGfb4QGuWHUoX/h92DZFh0G7XCo2etsaIp6Ub0Aa/r8CKDAeQdHzeWE7t?= =?us-ascii?Q?YCzULgWJjiDrEmeTq2TkAq5Cw5Kj1nuVvEVBKNlBCZWTqeP0gaUmq520k0ve?= =?us-ascii?Q?VUZ6Uryr8blw0i+DjAXQJnSZSDz1Wftti2X/sM6WWBDEzkVUPnZfpmvmic3m?= =?us-ascii?Q?M7d7XNCnHMOkq2+Zus8nwdMj1E9RP3S8afyHduE5oROhA25lfZrZBaMqN7a7?= =?us-ascii?Q?o7rUT5eoZBpI5URi2PilL6nY46PqZe2Lw3GW7UG3C1zhYDCgEhxcNV6pRYkp?= =?us-ascii?Q?oQ5Fv/tBqikpoqzA6nKF6wfr7Argq/dMm7Y3x1kxU1UWHBl/iChos0+r3A40?= =?us-ascii?Q?69nGCh9ZYtrK4EEHvz+Kio9+MlwMfhMSHOJAUSSZ4KiQGnt4OsgbAhv+FSTX?= =?us-ascii?Q?9ad3ZnQ4RJRkQM9529oBhzcLMPaT6VWV+/x0ReyxqnouS5RYtVcvMBI5h7O/?= =?us-ascii?Q?1lDY5OezPd7wpm0azhqtQo+gin3oZRlOdEZL+1419Fc0JSLa270DsewFvKSZ?= =?us-ascii?Q?tqSIz2Yj7+63BOhnrJdQl/UhFsMzMnqQE7BN1gg/RFBy8xaQCGFhNtxdxf8s?= =?us-ascii?Q?2TCuS3wdf7uKlDtttQn2VX2iIRqyTi5RlZqpesOxJ4wUmLbeYKqydcg/X/3B?= =?us-ascii?Q?5XefrbxkcpPB57RYj4KesbC9K1sMKSuWTnmVaswA2abqdy8bcS4sKhy9EX0t?= =?us-ascii?Q?VMbICK5A5cZIUYi7Zjkl4jJWMAactvjhK5tncMPa3ppPG/3puyYT86Tw7DB+?= =?us-ascii?Q?IAnzULkz43h5tep1uSM49SPRaAvulWod1oU55BOTzMjC/iCsMKhTNYJEUa2b?= =?us-ascii?Q?XgIvzQfX07MqP2U7nsit2d4bMnwO8yGzwW85QKGD3TFAEXWltK8drf7Lqnaz?= =?us-ascii?Q?T/4gg96TBMFEVIIrBfGCb2sAjcGXPq9WNOxC3hesPURvDjm3odSu+7HFMzuS?= =?us-ascii?Q?Vtv57tLrdlpIY/a4+J6bGG0=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR12MB4666.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 790e7c73-ff1f-495a-7f2a-08d9e5ab4f71 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2022 17:50:18.3548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nkyDPy+gGmC4IfrEwW3StcP8uXx0KEkwSW/zAIDs0ajZ2TFXZplXH4InZBuGrlwLHUjxY0c7XVnZccawdEGv+w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR12MB2426 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi=20 > -----Original Message----- > From: Ivan Malov > Sent: Tuesday, February 1, 2022 2:18 AM > Subject: RE: [PATCH v2 03/10] ethdev: bring in async queue-based flow rul= es >=20 > Hi all, >=20 > On Thu, 27 Jan 2022, Alexander Kozyrev wrote: >=20 > > On Wednesday, January 26, 2022 13:54 Ajit Khaparde wrote: > >> > >> On Tue, Jan 25, 2022 at 9:03 PM Alexander Kozyrev > >> wrote: > >>> > >>> On Monday, January 24, 2022 19:00 Ivan Malov > >> wrote: > >>>> This series is very helpful as it draws attention to > >>>> the problem of making flow API efficient. That said, > >>>> there is much room for improvement, especially in > >>>> what comes to keeping things clear and concise. > >>>> > >>>> In example, the following APIs > >>>> > >>>> - rte_flow_q_flow_create() > >>>> - rte_flow_q_flow_destroy() > >>>> - rte_flow_q_action_handle_create() > >>>> - rte_flow_q_action_handle_destroy() > >>>> - rte_flow_q_action_handle_update() > >>>> > >>>> should probably be transformed into a unified one > >>>> > >>>> int > >>>> rte_flow_q_submit_task(uint16_t port_id, > >>>> uint32_t queue_id, > >>>> const struct rte_flow_q_ops_attr *q_ops_attr= , > >>>> enum rte_flow_q_task_type task_type, > >>>> const void *task_data, > >>>> rte_flow_q_task_cookie_t cookie, > >>>> struct rte_flow_error *error); > >>>> > >>>> with a handful of corresponding enum defines and data structures > >>>> for these 5 operations. > >>> We were thinking about the unified function for all queue operations. >=20 > Good. >=20 > >>> But it has too many drawbacks in our opinion: >=20 > Is that so? >=20 > >>> 1. Different operation return different results and unneeded paramete= rs. > >>> q_flow_create gives a flow handle, q_action_handle returns indirect a= ction > >> handle. > >>> destroy functions return the status. All these cases needs to be hand= led > >> differently. >=20 > Yes, all of these are to be handled differently, but this does not mean > that one cannot think of a unified handle format. The application can > remember which cookie corresponds to which operation type after all. >=20 I agree with with Alexander, merging all of those functions to one will res= ult in extra parameters which will be unsued. Basic programing apporch is that functions should do one thing, it is easier to document / use / test and will run faster. > >>> Also, the unified function is bloated with various parameters not nee= ded > >> for all operations. >=20 > That is far-fetched. >=20 Just thinking about extra parameter to return the handle only in case of create flow. Also in future I guess we will want to add modify rule and indirect actions I assume that in both case dedicated functions will be much better for example for the indirect use the same names we are using now only adding q in the name and extra queue parameter. > Non-unified set of APIs is also bloated. Takes long to read. Many > duplicating comments. When one has added a new API for a different > type of task, they will have to duplicate many lines one more time. >=20 > In the case of unified API, one has to add a new enum type (one line), > specific (and thus concise) description for it, and the corresponding > structure for the task data. That's it. The rest is up to the PMDs. >=20 > Also, it should be possible to make the task data IN-OUT, to return > its task-specific handle (to address your above concern). >=20 > >>> Both of these point results in hard to understand API and messy > >> documentation with > >>> various structures on how to use it in every particular case. >=20 I disagree with you I think that having unused and misleading parameters is much more messy from user view point. > The documentation for the method is always the same. Precise and concise. > The task data structures will have their own descriptions, yes. But that > does not make the documentation messy. Or am I missing something? >=20 > >>> 2. Performance consideration. > >>> We aimed the new API with the insertion/deletion rate in mind. >=20 > Good. >=20 > >>> Adding if conditions to distinguish between requested operation will = cause > >> some degradation. >=20 > Some degradation.. - how serious would it be? What's for the "if" > conditions, well, I believe the compiler is smart enough to deal > with them efficiently. After all, the suggested approach is > a fixed set of operation (task) types. One can have a > static array of task-specific methods in the PMD. > And only one condition to check the value bounds. >=20 yes from our testing just an if will result in degradation. Even just the indirect ref to the PMD function results in degradation. I guess if you try to add an if in the datapath (rx_burst/tx_burst) you wil= l=20 Need to explain the reason. > >>> It is preferred to have separate small functions that do one job and = make it > >> efficient. >=20 > A noble idea. >=20 Noble idea is good so lets do it small functions. > >> Interfaces are still the same. >=20 > That is the major point of confusion. The application developer has to > be super-careful to tell the queue version of "flow_create" from the > regular one. The two set of APIs are indeed counterparts, and that's > might be ambiguous. Whilst in the unified approach, readers will > understand that this new API is just a task-submitter for > the asynchronous type of operation. >=20 > > Glad I made it clearer. Ivan, what do you think about these considerati= ons? >=20 > Well, I'm not pushing anyone to abandon the existing approach and switch > to the unified API design. But the above points might not be that > difficult to address. This deserves more discussions. >=20 > Any other opinions? >=20 I vote for the suggested API lets try and see. > > > >>> > >>>> By the way, shouldn't this variety of operation types cover such > >>>> from the tunnel offload model? Getting PMD's opaque "tunnel > >>>> match" items and "tunnel set" actions - things like that. > >>> Don't quite get the idea. Could you please elaborate more on this? >=20 > rte_flow_tunnel_decap_set(), rte_flow_tunnel_action_decap_release(); > rte_flow_tunnel_match(), rte_flow_tunnel_item_release(). >=20 > >>> > >>>> Also, I suggest that the attribute "drain" > >>>> be replaced by "postpone" (invert the meaning). > >>>> rte_flow_q_drain() should then be renamed to > >>>> rte_flow_q_push_postponed(). > >>>> > >>>> The rationale behind my suggestion is that "drain" tricks readers in= to > >>>> thinking that the enqueued operations are going to be completely > >> purged, > >>>> whilst the true intention of the API is to "push" them to the hardwa= re. > >>> I don't have a strong opinion on this naming, if you think "postpone"= is > >> better. > >>> Or we can name it as "doorbell" to signal a NIC about some work to be > >> done > >>> and "rte_flow_q_doorbell" to do this explicitly after a few operation= s. > >>> >=20 > By the sound of it, "push" is just a shorter term for "doorbell". >=20 I don't think the name should be doorbell, since it may not just be doorbel= l for example PMD may organize the rules in a better way. > >>>> rte_flow_q_dequeue() also needs to be revisited. The name suggests > >> that > >>>> some "tasks" be cancelled, whereas in reality this API implies "poll= " > >>>> semantics. So why not name it "rte_flow_q_poll"? > >>> The polling implies an active busy-waiting of the result. Which is no= t the > >> case here. >=20 > That is far-fetched. Polling implies some periodic invocations, > that is correct. But it's up to the application whether to > make this a tight loop or not. Or am I missing something? >=20 I like the dequeue since it also tells the developer that this is how he=20 remove rules from the queue. > >>> What we do is only getting results for already processed operations, = hence > >> "dequeue" as opposite to "queue". > >>> What do you think? Or we can have push for drain and pull for dequeue= as > >> an alternative. >=20 > Pull is not that informative. The commonly-used term is "poll". > But let's hear some other opinions. Maybe someone has their > way with naming. >=20 > >>> > >>>> I believe this function should return an array of completions, just > >>>> like it does in the current version, but provide a "cookie" (can be > >>>> represented by a uintptr_t value) for each completion entry. > >>>> > >>>> The rationale behind choosing "cookie" over "user_data" is clarity. > >>>> Term "user_data" sounds like "flow action conf" or "counter data", > >>>> whilst in reality it likely stands for something normally called > >>>> a cookie. Please correct me if I've got that wrong. > >>> I haven't heard about cookies in context not related to web browsing. > >>> I think that user data is more than a simple cookie, it can contain > >>> anything that application wants to associate with this flow rule, i.e= . > >>> connection ID, timestamp, anything. It is more general term here. >=20 > OK. Seems like I overestimated clarity of the term "cookie". >=20 > >>> > >>>> Well, the short of it: submit_task(), push_postponed() and poll(). > >>>> Having a unified "submit_task()" API should allow to reduce the > >>>> amount of comment duplication. > >>> I'm afraid it won't reduce the amount of comments needed anyway. >=20 > It will reduce the amount of generic (now just repeating) comments. > That's it. Task-specific comments will stay, and that is fine. >=20 Like above API should be as direct as possible. > >>> Instead of 5 descriptions of purpose-specific function we will end up= with > >>> a huge blob of text trying to explain how to use a single function wi= th > >>> 5 different input structures and 3 different output types. That is re= ally > >> messy. >=20 > Is that so? It shouldn't be like that. It should say about enqueuing a > task, whilst task-specific comments belong in the corresponding enum > or structure definitions. Definitely not a single huge comment. >=20 > >>> > >>>> In what comes to RST commentary, please consider a bullet-formatted > >>>> description for improved readability: > >>>> > >>>> - Flow rule management is done via special flow management queues > >>>> - The queue operations are asynchronous and not thread-safe > >>>> - The operations can thus be invoked by the app's datapath > >>>> - The queue count is configured at initialisation stage > >>>> - Available operation types: submit_task, push_postponed and poll > >>>> - Polling provides completions for submitted tasks > >>>> - The completions can be reordered withing a queue > >>>> - Polling must be done on time to avoid overflows > >>> Agree, it does seem nicer and cleaner, will adopt this style in v3. >=20 > Very well. >=20 > >>> > >>>> Please note that the above review notes are just a quick primer, > >>>> nothing more. I may be mistaken with regard to some aspects. > >>>> > >>>> I humbly request that we agree on the API sketch and naming > >>>> before going to the next review cycle. > >>>> > >>>> Thank you. > >>> Thanks for your suggestions, let's see if we can find a common round = here. > > >=20 > Alright. >=20 > -- > Ivan M Best, Ori