Re: [PATCH v2 1/6] eventdev: introduce event driven programming model

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

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