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

["Rao, Nikhil" <nikhil.rao@intel.com>]

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)

	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.


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 ?

Nikhil