From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v2 1/6] eventdev: introduce event driven programming model Date: Wed, 14 Dec 2016 12:25:54 +0530 Message-ID: <20161214065552.GC21135@localhost.localdomain> References: <1479447902-3700-2-git-send-email-jerin.jacob@caviumnetworks.com> <1480996340-29871-1-git-send-email-jerin.jacob@caviumnetworks.com> <1480996340-29871-2-git-send-email-jerin.jacob@caviumnetworks.com> <20161206165119.GB22224@bricha3-MOBL3.ger.corp.intel.com> <20161207185303.GA7001@svelivela-lt.caveonetworks.com> <20161208093048.GA55440@bricha3-MOBL3.ger.corp.intel.com> <20161208204115.GA13798@svelivela-lt.caveonetworks.com> <20161209151142.GA14536@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: , , , , To: Bruce Richardson Return-path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0071.outbound.protection.outlook.com [104.47.40.71]) by dpdk.org (Postfix) with ESMTP id A3BD5201 for ; Wed, 14 Dec 2016 07:56:20 +0100 (CET) Content-Disposition: inline In-Reply-To: <20161209151142.GA14536@bricha3-MOBL3.ger.corp.intel.com> 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 Fri, Dec 09, 2016 at 03:11:42PM +0000, Bruce Richardson wrote: > On Fri, Dec 09, 2016 at 02:11:15AM +0530, Jerin Jacob wrote: > > On Thu, Dec 08, 2016 at 09:30:49AM +0000, Bruce Richardson wrote: > > > On Thu, Dec 08, 2016 at 12:23:03AM +0530, Jerin Jacob wrote: > > > > On Tue, Dec 06, 2016 at 04:51:19PM +0000, Bruce Richardson wrote: > > > > > On Tue, Dec 06, 2016 at 09:22:15AM +0530, Jerin Jacob wrote: > > > > > I think this might need to be clarified. The device doesn't need to be > > > > > reconfigured, but does it need to be stopped? In SW implementation, this > > > > > affects how much we have to make things thread-safe. At minimum I think > > > > > we should limit this to having only one thread call the function at a > > > > > time, but we may allow enqueue dequeue ops from the data plane to run > > > > > in parallel. > > > > > > > > Cavium implementation can change it at runtime without re-configuring or stopping > > > > the device to support runtime load balancing from the application perspective. > > > > > > > > AFAIK, link establishment is _NOT_ fast path API. But the application > > > > can invoke it from worker thread whenever there is a need for re-wiring > > > > the queue to port connection for better explicit load balancing. IMO, A > > > > software implementation with lock is fine here as we don't use this in > > > > fastpath. > > > > > > > > Thoughts? > > > > > > > > > > > I agree that it's obviously not fast-path. Therefore I suggest that we > > > document that this API should be safe to call while the data path is in > > > operation, but that it should not be called by multiple cores > > > simultaneously i.e. single-writer, multi-reader safe, but not > > > multi-writer safe. Does that seem reasonable to you? > > > > If I understand it correctly, per "event port" their will be ONLY ONE > > writer at time. > > > > i.e, In the valid case, Following two can be invoked in parallel > > rte_event_port_link(dev_id, 0 /*port_id*/,..) > > rte_event_port_link(dev_id, 1 /*port_id*/,..) > > > > But, not invoking rte_event_port_link() on the _same_ event port in parallel > > > > Are we on same page? > > > > Jerin > > > Not entirely. Since our current software implementation pushes the events > from the internal queues to the ports, rather than having the ports pull > the events, the links are tracked at the qid level rather than at the > port one. So having two link operations on two separate ports at the > same time could actually conflict for us, because they attempt to modify > the mappings for the same queue. That's why for us the number of > simultaneous link calls is important. > However, given that this is not fast-path, we can probably work around > this with locking internally. The main ask is that we explicitly Yes, It is in slow-path. IMO, no harm in adding the lock internally and it helps the application too. > document what are the expected safe and unsafe conditions under which > this call can be made. As we agreed and it is a norm in DPDK that operation on same queue id (in our case same port id) _cannot_ not be invoked in parallel. Apart from the above constrain, Let us know what are other constrains you want to add(if any). > > /Bruce