From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0082.outbound.protection.outlook.com [104.47.33.82]) by dpdk.org (Postfix) with ESMTP id 4ED10370 for ; Tue, 29 Nov 2016 05:03:21 +0100 (CET) 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=YqPFJQUalruYm72i6k7Qvw6dX+EsQw0s1ypp6FuAo20=; b=iqV8sj7Y6fQuXLwYEnjpDDOaLIo7dwp8wcQFE5tLcVUZsAomN6H+DtwS3UBQUVjD6S0/TRFcK7NnqbUEI/grSxQhDs2FzPq7Qt9MozQ9xxfj6wrdJebGg1uXrszJbMooUFoBkm8MhG+YunfKHsP8G6quoGVdRm/CA4KxvZUpWR8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from svelivela-lt.caveonetworks.com (50.233.148.156) by BLUPR0701MB1713.namprd07.prod.outlook.com (10.163.85.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Tue, 29 Nov 2016 04:01:47 +0000 Date: Tue, 29 Nov 2016 09:31:42 +0530 From: Jerin Jacob To: Bruce Richardson CC: Thomas Monjalon , , , , Message-ID: <20161129040141.GA11674@svelivela-lt.caveonetworks.com> References: <1479447902-3700-1-git-send-email-jerin.jacob@caviumnetworks.com> <3691745.y1f1NvKTEv@xps13> <20161124015912.GA13508@svelivela-lt.caveonetworks.com> <1883454.103LptOkIX@xps13> <20161125002334.GA21048@svelivela-lt.caveonetworks.com> <20161125110053.GA149796@bricha3-MOBL3.ger.corp.intel.com> <20161126025454.GA13886@svelivela-lt.caveonetworks.com> <20161128091610.GB168972@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20161128091610.GB168972@bricha3-MOBL3.ger.corp.intel.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Originating-IP: [50.233.148.156] X-ClientProxiedBy: CY1PR12CA0041.namprd12.prod.outlook.com (10.160.137.51) To BLUPR0701MB1713.namprd07.prod.outlook.com (10.163.85.14) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1713; 2:r7/OCDpjQmWlH0Y5v3mFx4Ob9JXh4A6FjLszasbYFd4LZQ05RxFUq2EjQcXgYfNcXgm93cg64iDu1zU+o4fNsqxQbMuc72whxWVW6hZTEoC2jV+blGpNVCxUiyPzuXHpwGbnEsg2IFFoMiHHhk5trYHV+oOCd/e2p4fTI1Z8gv0=; 3:fTR5Sd6mgZBBRV3MxrvJBrw2naEla5pY+UzlPvqmJyOPfoaRifpKj3yUswjnzTcJxuPjB17El1KqBkuMV60BR8woukN0ddaMTqKzL/1Cosgs0p1dpmK5sLBmlpjhVSOo2Qli7Bnz8x0SN7mEPDDHxNEj0jw6MGcAgxnikJsgqLI=; 25:rwebVY5GdOe456yfFVPixjxE2kIGrgM3YkViaKRDWTY4lbNMqIEWPOM2GMajRt6HJGvJkBGovM+6Y+0CU3LHBI9kBwsA9LZH50IP+TzKKzx2tTMtLJAmUyziU0EOxRAD4DT0d1SwftbTbjVXBGH4nEpQ/xvH0+aaUcqof+2/pb8WBLVcisXInwM6kSGik0gBWT+xYbs9jOfS+Whw4QLsM4pcAM1iXXQwH+oqv1YnBJmKyEMIOMdnSDmoHLHsOQlKW/gzhvxc5OFtf5X+l9F2Wh6FsTYVFIsdpSnD9pUFfhgHN7zapo0kNeUKbcDPZ59fcHm9TDT61ZGv/1dTyg5p2jQZfJu60ws+W2pJePREIPmTNWEEf8j7Jsdp0lI4gsbu7gvhWXY3STRAVo3mY97qviyhjlOeR1NP056b1pBIu8SlK/3R2gq5VGHisp0GAYkwrz/LqrJ9y147pp+3/ge6zQ== X-MS-Office365-Filtering-Correlation-Id: 6195ac8c-35b3-4dab-d090-08d4180c713b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BLUPR0701MB1713; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1713; 31:go/CsNNnYbaLpmFlz2t+blgRdUDcmjssGcu7kex8KlVQlzlgdYPvXXc2lNgNolOZ79OcdRR9QShGGouOKa0HpPda/84q+H3izuaNvZ/oUPPkGR2DNOj6OwAy9F0LIgksC2O5QJ+2CTEubBN0RPY53SIK9miJGSSzhbCXrbhvp9G1u2SgvAm7aPezfSyQebSghOyJ8TgqT10VmXMO/8Td07km7hL4/R2fEnrNflBU8tj9OLfRNUbWz0tg3gnvrHM7grnfjQvkXCndieIxjKM37fnAsFqUIz0XoiCqwZotrk8=; 20:3+NxM1at4sQCkjsEV6QuCooNyshOh8qf5nL3LBRe4ThICyPlR/hJyBSRsirkeqGnQpkQQA5GgsBTO/FwNtZLtz06uPq67X7diDHDNkUKZutk1nmfX4yZ/0Qo4dmDUr7+Bw3FseXBXQmm9P5hunRCMNnWK55frVxa+0pT1fECS3P9KOO8joQp6D7faA81dChzimnHVFAOl5OHsKNMz7X+cnARVKlkFoIFm6GP9viPNTjhmCdOIy2BLG/ARuCrPoNL4gkrBpD3eQCdidM2u1he3suwUUxgZB2wkRlasAXWvrPAykKMaYD3F6uWfMZgWeitIICw9rC5G3BMzXDGX4RVXygq71vtfw/IwllaPgOGW9r5AlZKeUgnhneURMggf7B49KI2hZUROtQapmtfGWNl2qRnmMIokyuSr5WdluHspEwgbqXa3q0JW/UGF0/S1bK23Kbc87M2dghD1wo0j7f3j90YEZpsKvrOA4ze/6EYe+tJcchsCbJBBtSXnh8x/1iELLi+CcFcHuDDWEF1wIcWi9ElhVeyUovA5QhKe1hMAyowcbS8T+7rspLeSYwXday8Enw/FFnpVXeaM7TJRGJBlbVJvi2rA1Lx9pTJQUWPksk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6045199)(6060326)(6040361)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(6061324)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558021); SRVR:BLUPR0701MB1713; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1713; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1713; 4:fCVCu1Oqr2Gm+ca/JRFUi3TuRxaQJff8lT2ABM3Nmqx9NutpvHLjohWtWoQ+00tWduz4jraHNhP3ahvQz1sOD4YgqMvFr/cWuhJPM5qZgZb4kDFU4M0zgcqW0bIXAO8nzuRAlFSw3i89r8EBN8N1NEKOzypy0lg9fp1TrWv768+wQqxPZTmFDVy6lH6NsHD/7PqRQXFCvlNBIsBF+VegcNNGkD6OVEK8oRmK30vZOYJ98tEu3FaZH2d/jg484KQnRiUDRpE3FhMZfSqkhgA+dnrn/Umg9rTN5sg9MQ3uYfb1IsuJWIqW4wFvBukofgQCONGDLdklhQKVMSTwRvikcWKtrw2Z82405ypuNoNf3qKHDNSlpiIBg/lVkzXyckgfhJzze2Z2uv1WrjSqc4uIxxV2vg/fywrB3VFbS3/041fcRdFawRMSXmm9eP2jyz7nBiPpVIpQNG1zr7Yc+q5GHWNG1LnU/8Z8/Xd4ZYeQv33GHnPG+nhzkNQlN3H3n4uuAba2HBZi0gyek0ZBfg3C3ehCJLx/Enldi3mOc6eV9kjx1v+V0lYZIkcZxihflNqE6RXUuHFBJjh7EpzmqTFmopTuv404YvD35tK+eoetIalSKOIZ9F13zzwZcICvW2fuWBneEi+wtSo28eemJ9xImg== X-Forefront-PRVS: 01415BB535 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(7916002)(199003)(189002)(24454002)(377424004)(305945005)(50466002)(7736002)(101416001)(23726003)(3846002)(1076002)(6116002)(93886004)(7846002)(8666005)(42186005)(105586002)(68736007)(33656002)(97756001)(106356001)(39400400001)(2906002)(9686002)(39380400001)(83506001)(39410400001)(229853002)(47776003)(110136003)(38730400001)(4326007)(69596002)(5660300001)(46406003)(92566002)(81166006)(6916009)(66066001)(189998001)(4001150100001)(81156014)(54356999)(733004)(50986999)(76176999)(97736004)(42882006)(8676002)(4001350100001)(2950100002)(6666003)(39450400002)(53416004)(18370500001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1713; H:svelivela-lt.caveonetworks.com; 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: =?us-ascii?Q?1; BLUPR0701MB1713; 23:lmPPjPS12WNi9sanzFgaiAojNt/3XjTNI3jsS9P?= =?us-ascii?Q?kuA/0LzN3SYCWSqp5N7ndED7agAYNAzKmZLDlrKMil2xtqAE6/9kQe6pSHM7?= =?us-ascii?Q?yDELfELW38cRQHCKzL9pNX4lr4lEX8eZCzTruxrMLUZg16I0Nk6tI+bz8hXW?= =?us-ascii?Q?ReXVZM3CE/jel5+I5k8CVdpjpCRQ7ACfFH3ogals86S3oAUpwChEbRWCdHMK?= =?us-ascii?Q?hKonkKBI8yDDHv3GVVVd6LgJ9x1zGOxDHXUFjLeyJtCbKDIz1GR6YIqj/W4u?= =?us-ascii?Q?NUr651aE+zFV8501MdsuRoSZPXLgZHFPg7mRBhAZcNTHYVSNFJ5NndfdntZr?= =?us-ascii?Q?1tN42FW/WbD6WjVaic4bGytJvUQ2y1XUOT68UpIAqnF+mjN5BAXAKvxP3YZn?= =?us-ascii?Q?NopV9PQR21EzWfceqioAvt3CeGO+S+B0fAvY7lFeCIm2+vXWUBF416GpsOwj?= =?us-ascii?Q?xvla8i2AhVTdql4LAm1xycLSYdl3XG2QuEEtTJmg1N5FtvTizRYV30VRxO17?= =?us-ascii?Q?9CuYaqYlBpuj7c9Ai2ph5AC0DhwA6ZSq1C002Hsk2AY0pUiv7E+8GeRKfqs8?= =?us-ascii?Q?k+WaJyeMDM3CsgR4NN1CcdjyPkKKWW+HH0ISsoFsCFALdxcNkDGKpD4aatZf?= =?us-ascii?Q?CLIa93INzX4JbA8whR0WQPHfgsbs7h0NNDAgCVBUb3qMp+TXOmlC71qRmdO5?= =?us-ascii?Q?UIV+torfnBNqImKmsaXoJ28pMKFRKgcjcHPmileEsE8oIHrtlby80Xp2GNcI?= =?us-ascii?Q?2f6L26JIM/rjkBY1nKvs6LhVdZ6HWURWfqrW1Di8OaNxBQEKb6cCX4R9L6wD?= =?us-ascii?Q?WAmhBBT5MyouTzyJshE4We4KkmBun9yzL4HJYOqff1dKKMBx3E+gdxGZQT4n?= =?us-ascii?Q?aNHJMh/jI/YpTANrSm8247Jw3jj23KZrqYvxnHdMFzm/8KRb+Etg1H+8Nbcd?= =?us-ascii?Q?AB2g/GC/qOYsTGFIbP2bdhTx4GMNOrpbKTuGwxM6n+vG++o5mDU024HD5yZX?= =?us-ascii?Q?ytknaR+XpCYJ79hctuyw0NrtTZ87UELqSr0L4dtFU/eQmYvGSSJYvwrraGs/?= =?us-ascii?Q?cLc2aYq8ZpiBFsDYkVNIxqewRj+WZKpnpziOZvgKG0DCpKDrpjO104Oq3K60?= =?us-ascii?Q?w5Uv60P7naxCMIWX0f1/vjnxjoRdz2TuKEZyCFynTa2jfU5KppypZEAJkDdu?= =?us-ascii?Q?ZtIbCxfrC7nJa+0fuPv43xEeB1ibQjSvrWo45SaNPB5SbJzhivcCFpKKhNxc?= =?us-ascii?Q?ZY4JKA+SDZfelLQ1NM7mjnNC0g3ZREH1bKdgf8iy0s3GlTMtjB9vX9L857cs?= =?us-ascii?Q?4VPwlO9uk1dxxGcs3/fyBRHteALKRQyPC7/AKgRDKBr118EytSKOj43rBCwQ?= =?us-ascii?Q?xiC9Xu8f6muL8WSmQwRd8mnsvwkvPn1MvfLOXimEILoGVbn8gOJKjf8ipToB?= =?us-ascii?Q?dbRwWLgCvPatrmoILjtsjd/GnryKxkG2s4uFJ1u/cq4WvNMn1jM98?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1713; 6:Qzldi04cku+h8bT1eLf9YzDyXISboWjXimHr4h0sxFn598/btjCR7tlBCY4TpbSltt/Pm8YI1mJgT5TyKHdkHcRzwwFPfMDEfodOe/MZ0/kiW2GSJUTVyHQ4UFCF+gLtQDzaXbxiWaKcBCdKn4orF1C1pPYcvQgHisirb2u90E7l4I9Fb1dgrgsI/DWN76RZAIvwN9urjEvyj44Hto6kp7hdZ/DM3uk2jiht5g8DUHZOg6x1hul05MwmD2D4fFlXeFZiYSbaXQu8xD9hlLvZSrxsuh7AYCdrV7D9/dTyjpRCXqF0L2Ghv5KO0lqQw84yMF8wKyvgfPaih8goBvKeL9ndg8tr9iSMi9q4k+v62UU=; 5:VFMkA4+g1/i1rq22jKz8PNqGX+bGiWqIDYutw4gJUoXN4EnqA5b0C18EQVNuO7esyv4c5cJoLjipqw2Kx8LBJ7MbbDiSNop37yKOa8+//SlF0mUqCOskfGYkChyVmIyhkWzfZnaVK7lVYaDEmXg9Kg==; 24:JrAQshtdlcAbOfK2T3tvP5vVzA2cd5IdLYP+F8vC1s51i9PLP44CY0J6fsR4lArkf8FYqmT/5MSg5sK7NeiWkGF/vR7NmzPlX9t7ZzPWGdQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1713; 7:tE77KMcrEJd9MVpu2+Tnv4PhNFVqnjj4BXYeUZ3wDuE6SliF3kfKBSH8tXDKc+3Gz34D000TVBjGZ3jVhqdHPpMHG6ObVyCJpH0OwHAe50GRSszrBXrjzQu1FDDsRJKDwlLz0E29qo+b6+PdCKO1/wEK+rguOJcYab1WzORz15sO/FXcDV+IZGl8C/UjH1W7xYjLk0zioKmguJm5Qshd/7t8W1VV/T5cYkm2sqhOqNl11fiXye/SK0cW8Qm1qP7gd0D2TKF4/n4LGWOgbBmrZBerF8RR4PqkbZ9/7+Ecooavc1WspMO8ANZEptEfZUpDxbQjFl7MpMlOWXLxpUotdTWSF/oVUlybRP5ekQLIYPE= X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Nov 2016 04:01:47.8216 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1713 Subject: Re: [dpdk-dev] [PATCH 1/4] eventdev: introduce event driven programming model 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: Tue, 29 Nov 2016 04:03:22 -0000 On Mon, Nov 28, 2016 at 09:16:10AM +0000, Bruce Richardson wrote: > On Sat, Nov 26, 2016 at 08:24:55AM +0530, Jerin Jacob wrote: > > On Fri, Nov 25, 2016 at 11:00:53AM +0000, Bruce Richardson wrote: > > > On Fri, Nov 25, 2016 at 05:53:34AM +0530, Jerin Jacob wrote: > > > > On Thu, Nov 24, 2016 at 04:35:56PM +0100, Thomas Monjalon wrote: > > > > > 2016-11-24 07:29, Jerin Jacob: > > > > > > On Wed, Nov 23, 2016 at 07:39:09PM +0100, Thomas Monjalon wrote: > > > > > > > 2016-11-18 11:14, Jerin Jacob: > > > > > > > > +Eventdev API - EXPERIMENTAL > > > > > > > > +M: Jerin Jacob > > > > > > > > +F: lib/librte_eventdev/ > > > > > > > > > > > > > > > I don't think there is any portability issue here, I can explain. > > > > > > > > The application level, we have two more use case to deal with non burst > > > > variant > > > > > > > > - latency critical work > > > > - on dequeue, if application wants to deal with only one flow(i.e to > > > > avoid processing two different application flows to avoid cache trashing) > > > > > > > > Selection of the burst variants will be based on > > > > rte_event_dev_info_get() and rte_event_dev_configure()(see, max_event_port_dequeue_depth, > > > > max_event_port_enqueue_depth, nb_event_port_dequeue_depth, nb_event_port_enqueue_depth ) > > > > So I don't think their is portability issue here and I don't want to waste my > > > > CPU cycles on the for loop if application known to be working with non > > > > bursts variant like below > > > > > > > > > > If the application is known to be working on non-burst varients, then > > > they always request a burst-size of 1, and skip the loop completely. > > > There is no extra performance hit in that case in either the app or the > > > driver (since the non-burst driver always returns 1, irrespective of the > > > number requested). > > > > Hmm. I am afraid, There is. > > On the app side, the const "1" can not be optimized by the compiler as > > on downside it is function pointer based driver interface > > On the driver side, the implementation would be for loop based instead > > of plain access. > > (compiler never can see the const "1" in driver interface) > > > > We are planning to implement burst mode as kind of emulation mode and > > have a different scheme for burst and nonburst. The similar approach we have > > taken in introducing rte_event_schedule() and split the responsibility so > > that SW driver can work without additional performance overhead and neat > > driver interface. > > > > If you are concerned about the usability part and regression on the SW > > driver, then it's not the case, application will use nonburst variant only if > > dequeue_depth == 1 and/or explicit case where latency matters. > > > > On the portability side, we support both case and application if written based > > on dequeue_depth it will perform well in both implementations.IMO, There is > > no another shortcut for performance optimized application running on different > > set of model.I think it is not an issue as, in event model as each cores > > identical and main loop can be changed based on dequeue_depth > > if needs performance(anyway mainloop will be function pointer based). > > > > Ok, I think I see your point now. Here is an alternative suggestion. > > 1. Keep the single user API. > 2. Have both single and burst function pointers in the driver > 3. Call appropriately in the eventdev layer based on parameters. For > example: > > rte_event_dequeue_burst(..., int num) > { > if (num == 1 && single_dequeue_fn != NULL) > return single_dequeue_fn(...); > return burst_dequeue_fn(...); > } > > This way drivers can optionally special-case the single dequeue case - > the function pointer check will definitely be predictable in HW making > that a near-zero-cost check - while not forcing all drivers to do so. > It also reduces the public API surface, and gives us a single enqueue > and dequeue function. The alternative suggestion looks good to me. Yes, it makes sense to reduces the public API interface if possible. Regarding the implementation, I thought to have a bit approach like below to reduce the cost of additional AND operation.(with const "1", compiler can choose with correct one with out any overhead) rte_event_dequeue_burst(..., int num) { if (num == 1) return single_dequeue_fn(...); return burst_dequeue_fn(...); } "single_dequeue_fn" populated from the driver layer. In the absence of populating the "single_dequeue_fn" from the driver layer, The common code can create the single_dequeue_fn using driver provided "burst_dequeue_fn" something like generic_single_dequeue_fn(dev){ { dev->burst_dequeue_fn(..,1); } Any concerns? > > /Bruce >