From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0061.outbound.protection.outlook.com [104.47.34.61]) by dpdk.org (Postfix) with ESMTP id D5EDB1E4DB for ; Sun, 10 Jun 2018 14:13:13 +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:X-MS-Exchange-SenderADCheck; bh=Vu2GgRHWQgcQ+R5TGb68b3o2UKdUpzWst8RQZEBmskw=; b=os903zcZlZh2cLIesnTC4jREMt+hthKnVtkX2U8F8D2xCpeaKqeCMM/EdG2z5FhgZJp640MsNSc7MKDurnWHOw5j7tcUZuVYpjsa7gOAmCr7o+eRe8vkstyDCVpeokZGQxi0IAZ7fC4rVinVPNXI4/DIZfzurV88YseM+5NLz/o= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (118.143.155.128) by CY1PR07MB2524.namprd07.prod.outlook.com (2a01:111:e400:c636::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.17; Sun, 10 Jun 2018 12:13:08 +0000 Date: Sun, 10 Jun 2018 17:42:57 +0530 From: Jerin Jacob To: "Rao, Nikhil" Cc: hemant.agrawal@nxp.com, dev@dpdk.org, narender.vangati@intel.com, abhinandan.gujjar@intel.com, gage.eads@intel.com Message-ID: <20180610121256.GA4792@jerin> References: <1527260924-86922-1-git-send-email-nikhil.rao@intel.com> <20180530072633.GA2015@jerin> <72136c5d-64ba-247c-97a8-728054935e7c@intel.com> <20180604051058.GA1913@jerin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) X-Originating-IP: [118.143.155.128] X-ClientProxiedBy: HK0PR04CA0022.apcprd04.prod.outlook.com (2603:1096:203:36::34) To CY1PR07MB2524.namprd07.prod.outlook.com (2a01:111:e400:c636::15) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY1PR07MB2524; X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2524; 3:uYfJVxVF2l+OqSZ1nhP+dfyMcK1FSPN/mFVLd8tUGFkw0G20ETyXzrG/pEZ0NXPJV/tFcvu7Zd0OphV3+7janwLFzLhJqmL2ALTGD0pLmnOxS/bMrZlM0N4GV3dnXvdQb62gU3hj0DVj9HpGPbcvEZ9+Z+KsIo0R7ORB8btcvuUpOSbc2CVjFJ4pA3LunL0yNmL26Mj0Y8Xm7MNS8GPPM/QQrfFy0AYCgDdw5ox4ildgDGX+300EMa4eSUbQwT4n; 25:NJnSgQOQIuaW9L8YFyLvOyuyR1nlNa5Notr3R5J5whLPRQSJUiMt9LVwiEKqxof1t5vlnRDLFvB3VeBtBxpukU6fzzMZai/VLclkgbD5tmKTAg82AK4o2+3IkhaHO4xhHzoOUs5Xuiap+DGB8MmLOvGIvgceQlSlJykwPVNZBx+kEeqbOnhdRxDSMa7FZxlppw4Kv9R7FIE4qOVnklt49tCO8zPoH7Q8DSVOvlbflTW+Vs9rx5Ick0HvC6ku+p3Z6Kbyt2769BlgyLVgiU5TCdMobiS6nN2gE65anPB5IQBhblTZozJ9pljnYrWDYIkvTys/RAu9LfFIvSkpN+zLcQ==; 31:ze0ot7lPp9N/3Xz0MNOl5pReYgZ44bF8iFalZh3L5P3CQ0Xf6pMVYZTbmRNjNmF+7a893gRwq9glwh+db25c5YJSa1ZTViZYoZn7z92vrodr44+cCzu0E1NBPZB4HUJ/QD/eQHnXTV87vAEUqcJllpLaWWXcZOKH3K/P/4nrc5nvxaNxyMCMt+8IErzz1eheXbOilH/jmlHPzkr8YFEX4OJjyzb9vsnROfSsNJ4MrD8= X-MS-TrafficTypeDiagnostic: CY1PR07MB2524: X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2524; 20:KEZoCLyaPX451JkaH0r24dU+s+AKetvd4CsmsPpPZ4Xq41H0FjERttBYrQy0DYOVhErKrCFSe0ANwe1T3HcBAxcwbILZxYIDF7S+YzWlpo6ms25vEMqBvvwy6Q0Zn0U7PPxoUQUHOXTnmzgjfTjxNVWTaOexOMKWiDqTPuIN0sIJETNTDGSX4Ohvo5oRvM+L0ifh1/8WUsnbAvB8NDJk9ENJ1zXG4M+5JHzzABTeIsdfWTpggIVrOxTGRKEHFn7gllSozC/KQ/zESiNMe6QT+crPF7zuJ1rnhyiFZRNHq+m5crFvLWMSCutANsGYgYsEgnArMLGGQ8wNnFyRBdGzc+IV5AXhM7oSls0ZgjWUIdAaafJV1XPcA+Wq5Ed36DhiuKxFlcqxg1jXVX0/TEN74//oz986ztDPYHHm+gzV69QVy3gtFcuKst3hQ7GTNbbJECioZpV2PJBisXhHn1KGwcHdFbe54boO/G9zJw64iEAQaHJwcyUaSUKCTU2vJZIcg83tOHEaddv77paX8HaMVWK0Fjoqe/eKf57+4sCgo1r2j5NZ4rYwMA77BMGytkSAD7vOciAGhmG0wIXRElRS+gCp8wdZH/fUoOcYm6o2jmg= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(788757137089)(228905959029699); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(944501410)(52105095)(10201501046)(93006095)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:CY1PR07MB2524; BCL:0; PCL:0; RULEID:; SRVR:CY1PR07MB2524; X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2524; 4:8R/yMItAWJSd5XGmnH69F6Bz9aRa7j5rKCi6+aqJG+Fxxb+3Ru7b9LQF1w4usvzs3c/NDvu4nTTQvAR2Vs4EhsOPrm+eLxOKJpwukRrNpsWgEl2oXmOrY3vm2c6xqGfUZVNcSplD6d5ph1faBnsNcMcHbRLk9YrNeSVfqh16u3J3KrwbBEp6hAOENdyKCw5x40kWEaKBVBeL0EuTpdrRcIENdQtei3vvN23BPR2f/f4VmN86UzUbGtYUaNgMYJT9srI/DSV5xP5zKkR9L6lAD4pa6S89SZ6ZwTcchTSW28lVrk5E64wQtGuG2KXTfAtF9OTyP9Hwx3yHEqwjWSruxvw1duPWl4tYOgj58lDmc4t1kxFd1wmQw22JvrGrt2o8 X-Forefront-PRVS: 0699FCD394 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(396003)(39850400004)(366004)(376002)(39380400002)(346002)(199004)(189003)(13464003)(57704003)(186003)(11346002)(42882007)(33716001)(2906002)(6246003)(316002)(9686003)(93886005)(58126008)(47776003)(53936002)(229853002)(16586007)(4326008)(8656006)(55016002)(1076002)(105586002)(106356001)(33656002)(3846002)(23726003)(68736007)(25786009)(72206003)(66066001)(478600001)(53546011)(386003)(7736002)(305945005)(50466002)(6116002)(6496006)(52116002)(6666003)(97736004)(76176011)(33896004)(81156014)(16526019)(6916009)(446003)(486006)(5660300001)(956004)(8676002)(476003)(8936002)(26005)(44832011)(81166006)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR07MB2524; H:jerin; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR07MB2524; 23:OZ9+nk3MRb50w6rE/BxfXFg/uK2SbHFIwKPwkCx9+?= =?us-ascii?Q?gDohDa7kdH/rKpPaGgkzcFmxBBZ56wWPebmPn2lNy5Kbsy8E58WSZE+Fa4Lc?= =?us-ascii?Q?W1oUxbtU/3PEnsWms+pY6LHR/YtMl2EyOCIQtSeDjwTttp6q0/mOG1JInHJG?= =?us-ascii?Q?Fa7SmbXOFtzLzrc3u0CmlBiqNiMVXAvv5prdMQf4FpjZi2VnShXGqCua0aaA?= =?us-ascii?Q?g+fa25C0/1X2DcM9/3MSbRmfjDE0q1m9+HSfqr6Vr9hmS0rqifqRoA8cauec?= =?us-ascii?Q?BYephE62mijbs8pFyvODwcDCFSTtlYJ4gOF4BpUnFrwifTNAMsW/YOgX4Ayi?= =?us-ascii?Q?ZvOWo661wFw0etB2W72B7zmv4W6lzgThBn79CUebaqorlbxJTwSazjRPQk8j?= =?us-ascii?Q?oikqvw+Yl55vPX1jCXE6MFvlqe3jMefc/z0HQI6yqN8ycERlwAgmrMRqITW2?= =?us-ascii?Q?xjcpYJbXJAymuTCnf/7hBOw0pqHXF0uec6wsy7kJECT8/UFI7NFp3JK8z9ax?= =?us-ascii?Q?0Xrb73suwFL4O8dGsrX5g2Gr67wwpsAiPdC+MyBYrnlK5AkIfeOHXAMKzBVA?= =?us-ascii?Q?6G/ksO1EBntRoFuXyu7SQFi+Eg0ywNzOMd25bHxcIU/aiERC6OT6aMudVQTV?= =?us-ascii?Q?ZRWXJvzSbsSqtvX4e3H3iBTCPf2PkiBTuvNEmGE2MNZl+HAGkZfzP8V4yt51?= =?us-ascii?Q?EgmFL+WbOGlb71QmGzMkjHTOvPsteekn1pICnhLL335Q5RK0nTbxjZDbpHrf?= =?us-ascii?Q?mOYPT+6aC5Vr9na2NKSEdoDfizwqvz0Qlh8PToZKVV3CPfP/xNLZIzUauYiK?= =?us-ascii?Q?NvuhNnLnsyNfFc5hrA+ByVKqjyTnYHpbvWgPWkzDdXEZayYXcXWBfQJ7BZde?= =?us-ascii?Q?69pLFH0HxgxYOvQjiV3CKcp30OX+3IzqK3BilUMVmwTIEHCKM+jQ7VLXJZRG?= =?us-ascii?Q?Hax+FTGWa1oE59ftlFXLHr72YJt4OEtHBKMrIVH8gU2pqVML977QmXdim5zQ?= =?us-ascii?Q?JSuIICji3MWlWkBHODqwIuDqS4aORvStdFDnw7GUdkbDY03upor/9a5wGv8o?= =?us-ascii?Q?AbH0rFbboB4xGtZ6K1EU3iFK400ozhZ6ruRNEdKuxWXvAS5sBfC/m8T88gZb?= =?us-ascii?Q?dfutC7Ymb6GOzGTkbJDM+9FSuvLncgPMwlAF/ybvwyBbrQp7DpeAUVqWrHjQ?= =?us-ascii?Q?A1eOHI36agHtXQbH3WU0ifNVP9nv7uTDPo+ybYpAVoxIleu7u0e6Y3zRxefg?= =?us-ascii?Q?qfTihY7fIA5lXLXuBi1GVTUh7e7qcSqaTboG92ovT4D/3L9K7YklXAGT1eOe?= =?us-ascii?Q?Tt++ln14QY1V9x797Fn0eWWFaQ1MWw/jJOO+HjAPDtp6riH8OJuuB6FqctT/?= =?us-ascii?Q?n5rtneMWyzbX5M0W/rR1I5K8AHVkOMsY4FqksEiDO4KHhdJNZIISdBF+leqQ?= =?us-ascii?Q?VAYny5ULQ=3D=3D?= X-Microsoft-Antispam-Message-Info: 0vYyvShOUknWawPEgn9GmRlsKeivJ93V+WBs7vJoa6b96esocZvzoto0WHpA4H6lK8Cif4yFMctQZvFzJWaqqDKCqo0wiBtxKPoMqzQLUyq3F4Cd0tCKwfETjjuiheCxTspXRtnQPPg95gVHxuxt4MGZawLDh4NeCM+bXQ+YkA7a3LtK9ApYJH8vvZfKUjDC X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2524; 6:20AuxbphUXPReHRtu8PK6/+TgwKC7v2VMdoSQCb2Fei+YbRZBTl3BPcwlGefgN8Wno2D0IEIW8qwpeWHw97iW0oJifQgnTU87Je4RkiuUH1Cr2o6K2Yhgm7QR6Q0RSnlD9eOTT5oC7t1ikHI+U6yzNu7mIfpsSPD3Dyoa2CqMWtvV1EB1ukNwwY2oL0em6iZv3hPsd2mGWM7+u8g49mW3LH8FXhd1AaDXGSDSYiZTQ2M4NtZSZUFYYmwiPtbGE3cAtEHRURgxm5tA1764/T/L71pdeOPhva98Y16QXyoXC1YhIVwEMTsSHu/tmRjlD67KYaGMJQEzPPc2rVoAWbJeYMIFwHkal2FRfWVuQbo8TyBfMOf6gONsdiXOwxuorv3C7oF3PFPYGemtTcVvDup1YkCJIGT3kQLiQ4wZOkR+n/uqgGKpmJHVDFOKRuRnQanqaG+eP3MxUfyaL6I4VMhSQ==; 5:EbdG6F9pXo/H7YjwBlqoXqwDsVy+esWkFc5TWROhsRfpDcgf0aqXguZKmzfug2kvDHrZC6nf5renpIFrrBQXSKsMmX5Y0btC1Oy7OOrxji7BkkTmrGND7I7KSb2Y4JRaHMba2annrEatANLYI2mQxpomx62KUpZfz2Hmn/PO/48=; 24:ko7J8y5cAhq/c75Wo6WehapnQjGX4CHgYnVq/bk55BmAlPvXuGAOvfO2zz68/0vfkxIhypXaZIp14uCcfRq5zdFuhGDjlGL7aw+tPKwEiQk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2524; 7:cYs28fCF1lCWLs/QnHhHeJkLoES4sWppAYugi8vdYWrotIcXR5wYDZTbOMGMnmDoEdDFzcsxLyQL/nzuxBGquukSTYZfrbCH0GDNCYFfU2ak26hgZ33dIf3dNk5Y/qdt9SpeS+URDpZC5SNfqok7pYfU0q90z9Ugwhe6rPp75BCVju3xA0jgoEImNRQRMI+E0xtJdIW4Dk+gRNE+ZUl2T3kFB5c9E8k2pKkWYLu0hhkyGYzdC2dXRTHfl9aIdpiL X-MS-Office365-Filtering-Correlation-Id: f24e6781-171a-4441-ef28-08d5cecb887e X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2018 12:13:08.4337 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f24e6781-171a-4441-ef28-08d5cecb887e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2524 Subject: Re: [dpdk-dev] [RFC] eventdev: event tx adapter APIs 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: , X-List-Received-Date: Sun, 10 Jun 2018 12:13:14 -0000 -----Original Message----- > Date: Tue, 5 Jun 2018 14:54:58 +0530 > From: "Rao, Nikhil" > To: Jerin Jacob > CC: hemant.agrawal@nxp.com, dev@dpdk.org, narender.vangati@intel.com, > abhinandan.gujjar@intel.com, gage.eads@intel.com, nikhil.rao@intel.com > Subject: Re: [RFC] eventdev: event tx adapter APIs > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.8.0 > > On 6/4/2018 10:41 AM, Jerin Jacob wrote: > > -----Original Message----- > > > Date: Fri, 1 Jun 2018 23:47:00 +0530 > > > From: "Rao, Nikhil" > > > To: Jerin Jacob > > > CC: hemant.agrawal@nxp.com, dev@dpdk.org, narender.vangati@intel.com, > > > abhinandan.gujjar@intel.com, gage.eads@intel.com, nikhil.rao@intel.com > > > Subject: Re: [RFC] eventdev: event tx adapter APIs > > > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > > > Thunderbird/52.8.0 > > > > > > > > > Hi Jerin, > > > > > > > The workers invoke rte_event_enqueue_burst() to their local port not to the > > > extra port as you described. The queue ID specified when > > > enqueuing is linked to the the adapter's port, the adapter reads these > > > events and transmits mbufs on the > > > ethernet port and queue specified in these mbufs. The diagram below > > > illustrates what I just described. > > > > > > +------+ > > > | | +----+ > > > |Worker+-->+port+--+ > > > | | +----+ | +----+ > > > +------+ | +-->+eth0| > > > | +---------+ +-------+ | +----+ > > > +--+ | +----+ | +---+ +----+ > > > | Queue +-->+port+-->+Adapter|------>+eth1| > > > +--+ | +----+ | +---+ +----+ > > > +------+ | +---------+ +-------+ | +----+ > > > | | +----+ | +-->+eth2| > > > |Worker+-->+port+--+ +----+ > > > | | +----+ > > > +------+ > > > > > > Makes sense. One suggestion here, Since we have ALL type queue and > > normal queues, Can we move the queue change or sched_type change code > > from the application and move that down to function pointer abstraction(any > > way adapter knows which queues to enqueue for), that way we can have same > > final stage code for ALL type queues and Normal queues. > > > Yes, I see the queue/sched type change approach followed in > pipeline_worker_tx.c, a queue id can be provided in > rte_event_eth_tx_adapter_conf > > +struct rte_event_eth_tx_adapter_conf { > + uint8_t event_port_id; > + /**< Event port identifier, the adapter dequeues mbuf events from this > + * port. > + */ > + uint16_t tx_metadata_off; > + /**< Offset of struct rte_event_eth_tx_adapter_meta in the private > + * area of the mbuf > + */ > + uint32_t max_nb_tx; > + /**< The adapter can return early if it has processed at least > + * max_nb_tx mbufs. This isn't treated as a requirement; batching may > + * cause the adapter to process more than max_nb_tx mbufs. > + */ > +}; > > > > > > The worker core will receive events pointing to mbufs that need to be > > > transmitted to different > > > ports/queues, as described above. The port and the queue will be populated > > > in the mbuf and the > > > API can be as below > > > > > > uint16_t rte_event_eth_tx_adapter_enqueue(uint8_t instance_id, uint8_t event_port_id, const struct rte_event ev[], uint16_t nb_events); > > > > > > Let me know if that works for you. > > > > Yes. That API works for me. I think, we can leverage "struct > > rte_eventdev" area for adding new function pointer. Just like > > enqueue_new_burst, enqueue_forward_burst variants, we can add one more > > there, so that we can reuse that hot cacheline for all fastpath function pointer case. > > That would translate to adding "uint8_t dev_id" on the above API. > The dev_id can be derived from the instance_id, does that work ? Do we need to that in fastpath?, IMO, if you can do that in slow path then it is fine. > > I need some clarification on the configuration API/flow. The > eventdev_pipeline sample app checks if DEV_TX_OFFLOAD_MT_LOCKFREE flag is > set on all ethernet devices and if so, uses the pipeline_worker_tx path as > opposed to the "consumer" function, Yes > if we were to use the adapter to replace > some of the sample code then it seems like the > RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT is hardware assist for the > pipeline worker tx mode, the adapter would support 2 modes (consumer and > worker_tx, borrowing terminology from the sample), worker_tx would only be > supported if the eventdev supports > RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT (at least in the first version) Yes. 1) I think, rte_event_eth_tx_adapter_enqueue() function can simply call, struct rte_eventdev *dev = &rte_eventdevs[dev_id]; return (*dev->eth_tx_adapter_enqueue)(...); 2) You can expose generic version of "eth_tx_adapter_enqueue" in Tx adapter. If drivers does not set the "eth_tx_adapter_enqueue" function pointer or DEV_TX_OFFLOAD_MT_LOCKFREE flag is NOT set on all ethernet devices _then_ in common code we can assign eth_tx_adapter_enqueue function pointer as your generic Tx adapter function pointer. 3) I think, you can focus only on generic "consumer" case as you can not test "worker_tx" case. We are planning to add more optimized raw "worker_tx" case in driver(Point 2 will allow that by having driver specific "eth_tx_adapter_enqueue" function pointer). /Jerin > > Thanks, > Nikhil >