From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id CEEB7A328D for ; Wed, 23 Oct 2019 06:53:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CB3EB1BF46; Wed, 23 Oct 2019 06:53:47 +0200 (CEST) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id 59E811BF3E for ; Wed, 23 Oct 2019 06:53:46 +0200 (CEST) Received: by mail-io1-f65.google.com with SMTP id 1so11986610iou.4 for ; Tue, 22 Oct 2019 21:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jFZE+VuTzixuJ59lLJ3XHxlYXvYWFsA2/JuBuVeoJQo=; b=Y2ucTELpC19A1QQVd+0MHWeFO7VRfjcl2cSKOEUrZHNAtFjc1zeYf8mFjG+0WiwgjU 3iyPgL8xGQ53PgNvKIewSRFBaLjgDbbxSdi68CktO4Yl2cJIl/GHznGjuCl7lXxWXrJd qb/Qig9uGJHzYrOkuRI+zdehj0pXha8ZEd9C1s1tcYrK9agWVvm/+N7d+bvC/dMhRE8a HzRtm0tNL2L0Lg/8p1SzCUklvUu80tGoA5+aTyTahtwLFCglhp+hMJcGI9epNyiXgp3/ DxilvfcYgz2/dbiYp2tgriKjHRHDXHOqaFJU3TRPgTY/AlhLzP9rAP7HLeszwxkqf+f8 79Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jFZE+VuTzixuJ59lLJ3XHxlYXvYWFsA2/JuBuVeoJQo=; b=boSm0QUptc84522gk/e4S3ejO1NvWo9AnHVomCZhqYbQEEr2kFStvIG008+Xzsb9uS XLpHXQUQtkB936zBm4hYjYrrFngAYtCne/Z1VgdbcdyfI3FA3wsgiFfk59kDIeLV2+VM RGw6oeKLxLA41E1KUcGGBAD3uCuFz3JxMf9x3yEiqVU4FZL53hyr8flBFYAohH7rAg8Q ehGeqgtd58uVjHtJMb3W6k55BHhE+aqOie2on3xgE2kvSfxZTKaq2In9P2PnXZOvL7MS BoPILh4FEjnN7eYI+lqgKy4SR5bpKq5hSAMFtcNU6KNdpcsRdxv45Xu3M4GNrjY1Zzgg PX0Q== X-Gm-Message-State: APjAAAXJ8XYV4gXUt7de/mnG77vPu1IfG3j0toJ4qJM1sOaFKEuxTgws 76WB1uXnT2ADcdAHdf5q1r9XtsAmi2ZdxD/wfZg= X-Google-Smtp-Source: APXvYqza0OoOPZDbFHSFYNmneZtce/0MugYBK30Jq4TRMjF5QEX+06kmRlGHMfd1XXvBVo/X0zQ6U9D+mUmVyaSqxzQ= X-Received: by 2002:a02:cea7:: with SMTP id z7mr7780402jaq.104.1571806425394; Tue, 22 Oct 2019 21:53:45 -0700 (PDT) MIME-Version: 1.0 References: <20191001064641.28404-1-nipun.gupta@nxp.com> <1F668163772FA946975B9466A9DFF729EDED27A9@ORSMSX122.amr.corp.intel.com> <1F668163772FA946975B9466A9DFF729EDEEDCA7@ORSMSX122.amr.corp.intel.com> <1F668163772FA946975B9466A9DFF729EDEEE736@ORSMSX122.amr.corp.intel.com> In-Reply-To: <1F668163772FA946975B9466A9DFF729EDEEE736@ORSMSX122.amr.corp.intel.com> From: Jerin Jacob Date: Wed, 23 Oct 2019 10:23:29 +0530 Message-ID: To: "Rao, Nikhil" Cc: Nipun Gupta , Jerin Jacob , dpdk-dev , Pavan Nikhilesh , Sunil Kumar Kori , "Richardson, Bruce" , "Kovacevic, Marko" , Ori Kam , "Nicolau, Radu" , "Kantecki, Tomasz" , "Van Haaren, Harry" , Hemant Agrawal Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] eventdev: flag to identify same destined packets enqueue X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Oct 22, 2019 at 3:12 PM Rao, Nikhil wrote: > > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerinjacobk@gmail.com] > > Sent: Tuesday, October 22, 2019 2:15 PM > > To: Rao, Nikhil > > Cc: Nipun Gupta ; Jerin Jacob = ; > > dpdk-dev ; Pavan Nikhilesh ; > > Sunil Kumar Kori ; Richardson, Bruce > > ; Kovacevic, Marko > > ; Ori Kam ; Nicolau, Rad= u > > ; Kantecki, Tomasz ; > > Van Haaren, Harry ; Hemant Agrawal > > > > Subject: Re: [dpdk-dev] [PATCH] eventdev: flag to identify same destine= d > > packets enqueue > > > > On Mon, Oct 21, 2019 at 5:05 PM Rao, Nikhil wrot= e: > > > > > > > -----Original Message----- > > > > From: Jerin Jacob [mailto:jerinjacobk@gmail.com] > > > > Sent: Thursday, October 3, 2019 3:57 PM > > > > To: Hemant Agrawal > > > > Cc: Rao, Nikhil ; Nipun Gupta > > > > ; Jerin Jacob ; dpdk-dev > > > > ; Pavan Nikhilesh ; Sunil > > > > Kumar Kori ; Richardson, Bruce > > > > ; Kovacevic, Marko > > > > ; Ori Kam ; Nicolau, > > > > Radu ; Kantecki, Tomasz > > > > ; Van Haaren, Harry > > > > > > > > Subject: Re: [dpdk-dev] [PATCH] eventdev: flag to identify same > > > > destined packets enqueue > > > > > > > > > > > > > > > > > But I am not able to recollect, Why Nikhil would like to use > > > > > > > the separate functions. Nikhil could you remind us why > > > > > > > rte_event_eth_tx_adapter_enqueue() can not be used for sendin= g > > > > > > > the packet for SW Tx adapter. > > > > > > > > > > > > > [Nikhil] The goal was to keep the workers using the loop below. > > > > > > > > > > > > while (1) { > > > > > > rte_event_dequeue_burst(...); > > > > > > (event processing) > > > > > > rte_event_enqueue_burst(...); } > > > > > > > > We do have specialized functions for specific enqueue use case like > > > > rte_event_enqueue_new_burst() or > > > > rte_event_enqueue_forward_burst() to avoid any performance impact. > > > > > > > > Since PMD agruments are same for rte_event_enqueue_burst() and > > > > rte_event_eth_tx_adapter_enqueue() > > > > assigning simple function pointer assignment to > > > > rte_event_eth_tx_adapter_enqueue as dev->txa_enqueue =3D > > > > dev->enqueue_burst > > > > would have worked to have same Tx function across all platfroms > > > > without peformance overhead. > > > > Offcouse I understand, Slow path direct event enqueue assigment > > > > needs different treatment. > > > > > > > > > > > > ie in fastpath. > > > > > > > > while (1) { > > > > rte_event_dequeue_burst(...); > > > > if (tx_stage) > > > > rte_event_eth_tx_adapter_enqueue()... > > > > } > > > > > > > > What do you say? > > > > > > > > > > Sorry missed this question previously - Unless I have misunderstood y= our > > email, the event processing stage would have if conditions for each of = the > > stages (or minimally the tx stage), no disagreement on that, the only d= ifference > > would be set up of the event[] arrays that are sent to > > rte_event_enqueue_burst() and rte_event_eth_tx_adapter_enqueue() result= ing > > in an additional call to rte_event_enqueue_burst(). If that=E2=80=99s t= rue, since the > > abstraction has a cost to it, should we be adding it ? > > > > It there is a cost then we should not be adding it. > > I think, the following scheme can avoid the cost by adding the followin= g in a > > _slow path_ as the prototype of the driver API is the same. > > > > dev->txa_enqueue =3D dev->enqueue_burst; > > > > I was thinking of the event loop below which results in 2 calls to rte_ev= ent_enqueue_burst() Agree. That would be an overhead for the SW driver. > > while (1) { > rte_event_dequeue_burst(...); > > for_all_events { > if (tx_stage) > event_tx[tx_cnt++] =3D ... > else > event_non_tx[non_tx_cnt++] =3D ... > > } > if (tx_cnt) > rte_event_eth_tx_adapter_enqueue(event_tx, tx_cnt); > if (non_tx_cnt) > rte_event_enqueue_burst(event_non_tx, non_tx_cnt); > } > > Thanks, > Nikhil