[dpdk-dev] [PATCH v4 1/4] eventdev: Add caps API and PMD callbacks for rte_event_eth_rx_adapter

Rao, Nikhil nikhil.rao at intel.com
Sun Sep 24 14:14:06 CEST 2017


On 9/21/2017 9:16 PM, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Fri, 22 Sep 2017 02:47:11 +0530
>> From: Nikhil Rao <nikhil.rao at intel.com>
>> To: jerin.jacob at caviumnetworks.com, bruce.richardson at intel.com
>> CC: gage.eads at intel.com, dev at dpdk.org, thomas at monjalon.net,
>>   harry.van.haaren at intel.com, hemant.agrawal at nxp.com, nipun.gupta at nxp.com,
>>   narender.vangati at intel.com, erik.g.carrillo at intel.com,
>>   abhinandan.gujjar at intel.com, santosh.shukla at caviumnetworks.com
>> Subject: [PATCH v4 1/4] eventdev: Add caps API and PMD callbacks for
>>   rte_event_eth_rx_adapter
>> X-Mailer: git-send-email 2.7.4
>>
>> The caps API allows application to get information
>> needed to configure the ethernet receive adapter for the eventdev and
>> ethdev pair.
>>
>> The PMD callbacks are used by the rte_event_eth_rx_xxx() APIs to
>> configure and control the ethernet receive adapter if packet transfers
>> from the ethdev to eventdev is implemented in hardware.
> 
> IMO, it better to split the cap PMD API and cap normative API into one patch and
> remaining PMD API to another patch.

OK.

> 
>>
>> For e.g., the ethdev, eventdev pairing maybe such that all of the
>> Eth Rx queues can only be connected to a single event queue, in
>> which case the application is required to pass in -1 as the queue id
>> when adding a receive queue to the adapter.
>>
>> Signed-off-by: Nikhil Rao <nikhil.rao at intel.com>
>> ---
>>   lib/librte_eventdev/rte_eventdev.h           |  33 +++++
>>   lib/librte_eventdev/rte_eventdev_pmd.h       | 173 +++++++++++++++++++++++++++
>>   lib/librte_eventdev/rte_eventdev.c           |  24 ++++
>>   lib/librte_eventdev/rte_eventdev_version.map |   8 ++
>>   4 files changed, 238 insertions(+)
>>
>> diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
>> index 128bc5221..a8bebac01 100644
>> --- a/lib/librte_eventdev/rte_eventdev.h
>> +++ b/lib/librte_eventdev/rte_eventdev.h
>> @@ -990,6 +990,39 @@ struct rte_event {
>>   	};
>>   };
>>   
>> +/* Ethdev Rx adapter capability bitmap flags */
>> +#define RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT	0x1
>> +/**< Eventdev can send packets to ethdev using internal event port */
>> +#define RTE_EVENT_ETH_RX_ADAPTER_CAP_SINGLE_EVENTQ	0x2
>> +/**< Ethdev Rx queues can be connected to single event queue */
> 
> I think, Its is more of limitation. Since we are expressing it as
> capability. How about changing it as RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ
> (same as exiting !RTE_EVENT_ETH_RX_ADAPTER_CAP_SINGLE_EVENTQ and SW driver has this capability)
> i.e Ethdev Rx queues of single ethdev port can be connected to multiple
> event queue.
>
OK. I agree that the MULTI_EVENTQ is better suited to be expressed as a 
capability.

>> +#define RTE_EVENT_ETH_RX_ADAPTER_CAP_FLOW_ID		0x4
>> +/**< Ethdev Rx adapter can set flow ID for event queue, if this flag
>> + * is unset, the application needs to provide a flow id when adding
> 
> Looking at implementation, If I understand it correctly, it not application
> "needs" to provide instead, it is application can provide. If so, I think,
> making it as RTE_EVENT_ETH_RX_ADAPTER_CAP_SET_FLOW_ID or
> RTE_EVENT_ETH_RX_ADAPTER_CAP_OVERRIDE_FLOW_ID makes more sense.
> 
If the FLOW_ID cap is not set, it is required for the application to 
provide it, else the application optionally can provide it but the 
feature of the application being able to provide (override) the flag 
should be a separate flag.

If it's only the override behavior that is required, we can rename the 
flag to OVERRIDE_FLOW_ID.

> something like,
> 
> #define RTE_EVENT_ETH_RX_ADAPTER_CAP_SET_FLOW_ID		0x4
> /**< If this flag is set then the application can override the default
>   * hash based flow id generated by the Rx adapter when the event
>   * enqueues to the event queue.
>   *
>   * @see rte_event_eth_rx_adapter_queue_conf::rx_queue_flags
>   * @see rte_event_eth_rx_adapter_queue_conf::ev::flow_id
>   */
> 
>>   
>> +int
>> +rte_event_eth_rx_adapter_caps_get(uint8_t dev_id, uint8_t eth_port_id,
>> +				uint32_t *caps)
>> +{
>> +	struct rte_eventdev *dev;
>> +
>> +	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
>> +	RTE_ETH_VALID_PORTID_OR_ERR_RET(eth_port_id, -EINVAL);
>> +
>> +	dev = &rte_eventdevs[dev_id];
>> +
>> +	if (caps == NULL)
>> +		return -EINVAL;
>> +	*caps = 0;
>> +
>> +	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->eth_rx_adapter_caps_get,
>> +				-ENOTSUP);
> 
> How about not returning the -ENOTSUP. Instead just call
> eth_rx_adapter_caps_get if it not NULL. By this way if a PMD does not
> have any cap, it does not need to implement this hook.

OK.

> 
>> +	return (*dev->dev_ops->eth_rx_adapter_caps_get)
>> +						(dev,
>> +						&rte_eth_devices[eth_port_id],
>> +						caps);
>> +}
>> +
>>   static inline int
>>   rte_event_dev_queue_config(struct rte_eventdev *dev, uint8_t nb_queues)
>>   {
>> diff --git a/lib/librte_eventdev/rte_eventdev_version.map b/lib/librte_eventdev/rte_eventdev_version.map
>> index 4c48e5f0a..996b361a5 100644
>> --- a/lib/librte_eventdev/rte_eventdev_version.map
>> +++ b/lib/librte_eventdev/rte_eventdev_version.map
>> @@ -51,3 +51,11 @@ DPDK_17.08 {
>>   	rte_event_ring_init;
>>   	rte_event_ring_lookup;
>>   } DPDK_17.05;
>> +
>> +
> Additional line feed.
> 
>> +DPDK_17.11 {
>> +	global:
>> +
>> +	rte_event_eth_rx_adapter_caps_get;
>> +
>> +} DPDK_17.08;
>> -- 
>> 2.14.1.145.gb3622a4
>>
> 



More information about the dev mailing list