Re: [dpdk-dev] [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues

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

-----Original Message-----
> Date: Thu, 13 Jul 2017 08:56:48 +0530
> From: "Rao, Nikhil" <nikhil.rao@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> CC: gage.eads@intel.com, dev@dpdk.org, thomas@monjalon.net,
>  bruce.richardson@intel.com, harry.van.haaren@intel.com,
>  hemant.agrawal@nxp.com, nipun.gupta@nxp.com, narender.vangati@intel.com,
>  Abhinandan Gujjar <abhinandan.gujjar@intel.com>, nikhil.rao@intel.com
> Subject: Re: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
>  Thunderbird/52.2.1
> 
> On 7/10/2017 4:11 PM, Jerin Jacob wrote:
> > -----Original Message-----
> > > 
> > > I also think that the application should be able to call create() with > 1
> > > ports. This would allow a single service to poll multiple NICs with WRR
> > > priority.
> > 
> > Good point.
> > 
> > Can we realize the same use case like below?
> > - Instead of applying WRR over multiple NIC ports and adding the logic in Rx
> >    adapter, How about applying the WRR over multiple service function and
> >    move the WRR logic to service function layer.
> > 
> > i.e
> > one adapter is
> > - one service function(adapter_queue_add() will be used to add more
> >    queues)
> > - one constant set of ops.
> > 
> > Advantages:
> > - WRR over service functions will be useful as other service functions
> > can utilize it as it is not strictly specific to Rx adapter.
> > - In order to work with, below mentioned use cases, RX adapter ops needs
> >    to be constant and it will decided on the _adapter_create where "eth_port_id"
> > and "dev_id" specified.
> > 
> > 1) Ethdev HW is not capable of injecting the packets and SW eventdev
> > driver(All existing ethdev PMD + drivers/event/sw PMD combination)
> > 2) Ethdev HW is not capable of injecting the packets and not compatible
> > HW eventdev driver(All existing ethdev PMD + driver/event/octeontx PMD
> > combination)
> > 3) Ethdev HW is capable of injecting the packet to compatible
> > HW eventdev driver.
> > 
> > - it will remove the below side effect(queue add/del API needs port_id)
> > 
> > Thoughts?
> 
> Re: Multiple ports within a adapter
> 
> 1) 	1:N adapter:port can work if the op is constant across all the
> 	ports (_adapter_create() gets to determine that)

Yes. But ops may not be constant, if we consider the above three models.

> 
> 	WRR is specified on a per queue basis - The polling sequence
> 	built from the weights of all queues in the adapter (across all
> 	ports)
> 
> 
> 	struct rte_event_eth_rx_adapter_queue_conf {
> 	...
> 	 	uint16_t servicing_weight;
> 	/**< Relative polling frequency of ethernet receive queue, if this
> 	 * is set to zero, the Rx queue is interrupt driven (unless rx queue
> 	 * interrupts are not enabled for the ethernet device)
> 	 */
> 	...
> 	}
> 
>         The downside is that a port needs to be specified when 	
> 	add/deleting a queue. Another thought is to do away with
> 	the concept of an adapter ID, and only use port IDs, but there
> 	is a possibility for  2 Rx queues of the same port to be
> 	associated with 2 different adapter IDs. from an API perspective
> 	you could specify any of ports[i] in the info/conf() APIs and
> 	that seems a bit odd.
> 
> 	In summary, I agree, lets drop this idea.

OK. Great.

> 
> 
> 2) 	Re: Service function implementation of WRR
> 
> 	Within a service like the Rx adapter the notion of WRR is 	
> 	relative polling frequency of the ethernet receive queue,
> 	polling a tap interface may be more heavy weight than the a HW
> 	NIC PMD poll, so WRR for the Rx adapter  may not correlate with
> 	CPU utilization i.e, if that is a metric for some other service.
> 	If WRR is based on different metrics across services, I am not
> 	sure how we would able to specify WRR across services. Perhaps
> 	as services get more use, we maybe able to come up
> 	some common requirements.
> 
> How about if multiple adapters can specify the same service, 	
> function in the _configure() call. A service can run multiple
> adapters with WRR across all queues in the service ?

Yes, It make sense. With ops scheme, multiple adapter can have same
service. But, I am not sure, what you really meant by "in _configure()"
call. But in any case, We can model around whatever scheme that works for SW PMD.
HW scheme will have constrain on "Multiple ports within a adapter",
Except that constraint, everything else we can model around SW PMD
requirements.