Re: [dpdk-dev] [PATCH v4 4/4] eventdev: Add tests for event eth Rx adapter APIs

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

On 10/3/2017 5:06 PM, Pavan Nikhilesh Bhagavatula wrote:
> On Fri, Sep 22, 2017 at 02:47:14AM +0530, Nikhil Rao wrote:
> 
> Hi Nikhil,
> 
> 
>> Add unit tests for rte_event_eth_rx_adapter_xxx() APIs
>>
>> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
>> ---
>>   test/test/test_event_eth_rx_adapter.c | 399 ++++++++++++++++++++++++++++++++++
>>   test/test/Makefile                    |   1 +
>>   2 files changed, 400 insertions(+)
>>   create mode 100644 test/test/test_event_eth_rx_adapter.c
>>
>> diff --git a/test/test/test_event_eth_rx_adapter.c b/test/test/test_event_eth_rx_adapter.c
>> new file mode 100644
>> index 000000000..5d448dc27
> <snip>
>> +
>> +static int
>> +testsuite_setup(void)
>> +{
>> +	int err;
>> +	err = init_ports(rte_eth_dev_count());
>> +	TEST_ASSERT(err == 0, "Port initialization failed err %d\n", err);
>> +
>> +	struct rte_event_dev_config config = {
>> +			.nb_event_queues = 1,
>> +			.nb_event_ports = 1,
>> +			.nb_events_limit  = 4096,
>> +			.nb_event_queue_flows = 1024,
>> +			.nb_event_port_dequeue_depth = 16,
>> +			.nb_event_port_enqueue_depth = 16
>> +	};
>> +
> 
> Some eth devices like octeontx[1] use event device to receive packets, So in
> this special case it would require to stop the event device before configuring
> the event device as it is already started in port_init.
> 
> Calling rte_event_dev_stop(0) here would satisfy such use case.

Hi Pavan,

port_init is starting the eth device not the event device.

Moving init_ports to after rte_event_dev_configure should also work ?

> 
> [1] http://dpdk.org/ml/archives/dev/2017-August/073982.html
> 
>> +	err = rte_event_dev_configure(0, &config);
>> +	TEST_ASSERT(err == 0, "Event device initialization failed err %d\n",
>> +			err);
>> +
>> +	err = rte_event_eth_rx_adapter_caps_get(0, 0, &default_params.caps);
>> +	TEST_ASSERT(err == 0, "Failed to get adapter cap err %d\n",
> 
> <snip>
> 
>> +
>> +static int
>> +adapter_queue_add_del(void)
>> +{
>> +	int err;
>> +	struct rte_event ev;
>> +	uint32_t cap;
>> +
>> +	struct rte_event_eth_rx_adapter_queue_conf queue_config;
>> +
>> +	err = rte_event_eth_rx_adapter_caps_get(0, 0, &cap);
>> +	TEST_ASSERT(err == 0, "Expected 0 got %d", err);
>> +
>> +	ev.queue_id = 0;
>> +	ev.sched_type = RTE_SCHED_TYPE_ATOMIC;
>> +	ev.priority = 0;
>> +
>> +	queue_config.rx_queue_flags = 0;
>> +	if (!(cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_FLOW_ID)) {
>> +		ev.flow_id = 1;
>> +		queue_config.rx_queue_flags =
>> +			RTE_EVENT_ETH_RX_ADAPTER_QUEUE_FLOW_ID_VALID;
>> +	}
>> +	queue_config.ev = ev;
>> +	queue_config.servicing_weight = 1;
>> +
> 
> As mentioned above[1] in case of HW accelerated coprocessors the eth_port has
> to be stopped before reconfiguring the eth queue to event queue remapping.
> Calling rte_eth_dev_stop(0) is required before trying to map the eth queue.
> 

Is it possible to do this internally within the queue_add call ?

If not, the application would call rte_eth_dev_stop() if 
RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT is set or do we need a 
separate capability for this ?

>> +	err = rte_event_eth_rx_adapter_queue_add(0, rte_eth_dev_count(),
>> +					-1, &queue_config);
>> +	TEST_ASSERT(err == -EINVAL, "Expected -EINVAL got %d", err);
>> +
>> +	if (!(cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_SINGLE_EVENTQ)) {
>> +		err = rte_event_eth_rx_adapter_queue_add(0, 0, 0,
>> +							&queue_config);
>> +		TEST_ASSERT(err == 0, "Expected 0 got %d", err);
>> +
>> +		err = rte_event_eth_rx_adapter_queue_del(0, 0, 0);
>> +		TEST_ASSERT(err == 0, "Expected 0 got %d", err);
>> +
>> +		err = rte_event_eth_rx_adapter_queue_add(0, 0, -1,
>> +							&queue_config);
>> +		TEST_ASSERT(err == 0, "Expected 0 got %d", err);
>> +
>> +		err = rte_event_eth_rx_adapter_queue_del(0, 0, -1);
>> +		TEST_ASSERT(err == 0, "Expected 0 got %d", err);
>> +	} else {
>> +		err = rte_event_eth_rx_adapter_queue_add(0, 0, 0,
>> +							&queue_config);
>> +		TEST_ASSERT(err == -EINVAL, "Expected EINVAL got %d", err);
>> +
>>
> <snip>
> 
> Thanks,
> Pavan
>