Thread (41 messages) 41 messages, 6 authors, 2017-09-04

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

From: Jerin Jacob <hidden>
Date: 2017-08-03 06:23:46

-----Original Message-----
Date: Wed, 2 Aug 2017 19:19:32 +0000
From: "Eads, Gage" <redacted>
To: Jerin Jacob <redacted>, "Rao, Nikhil"
 [off-list ref]
CC: "dev@dpdk.org" <redacted>, "thomas@monjalon.net"
 [off-list ref], "Richardson, Bruce" [off-list ref],
 "Van Haaren, Harry" [off-list ref], "hemant.agrawal@nxp.com"
 [off-list ref], "nipun.gupta@nxp.com" [off-list ref],
 "Vangati, Narender" [off-list ref], "Gujjar, Abhinandan S"
 [off-list ref]
Subject: RE: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues


<snip>
quoted
quoted
quoted
5) specifying rte_event_eth_rx_adapter_conf.rx_event_port_id on
rte_event_eth_rx_adapter_create() would waste one HW eventdev port
if its happen to be used RX_ADAPTER_CAP_INBUILT_PORT on
rte_event_eth_rx_adapter_queue_add().
quoted
quoted
unlike SW eventdev port, HW eventdev ports are costly so I think, We
need to have another eventdev PMD ops to create service/producer ports.
Or any other scheme that creates
rte_event_eth_rx_adapter_conf.rx_event_port_id
on demand by common code.
One solution is:

struct rte_event_eth_rx_adapter_conf {
    uint8_t dev_id;

    int (*conf_cb)(uint8_t id, uint8_t port_id, uint32_t flags, struct
rte_event_eth_rx_adapter_conf *conf);

    unsigned int max_nb_rx;

    int event_port_id;

    char service_name[];
}

Where dev_id and conf_cb have to be specified in the create call, but
event_port_id and service_name will be filled in when conf_cb() is
invoked
I was thinking like event_port_id will be rte_event_port_count() + 1.
ie When adapter needs the additional port, It can
- stop the eventdev
- reconfigure with rte_event_queue_count() , rte_event_port_count() + 1
- start the eventdev.

The only problem with callback is that all the application needs to implement it.
If you think, application need more control then we can expose callback and if it
is NULL then default handler can be called in common code.
I don't think we can rely on there being another port available -- a user may have configured the sw eventdev with all 64 ports, for instance.
On that case, irrespective any scheme(callback vs non callback) the
adapter creation would fail. Right?
What if the user is required to calculate cfg.nb_event_ports as a function of the RX_ADAPTER_CAP_INBUILT_PORT capability (i.e. add a port if the capability is not set), such that a reconfigure is not required?
We have only one NON INBUILT eventdev port per adapter. Right? i.e in the v1 spec it was rte_event_eth_rx_adapter_conf.event_port_id,
How about it can be rte_event_port_count() + 1 ? Since we are NOT
linking this port, the context call be kept in adapter itself. Right?
As for application control: that would be a useful option in the conf_cb scheme. Some apps will want to configure the adapter's port (its new_event_threshold, its queue depths) differently from the default.
struct rte_event_port_conf * can be passed on the adapter create if
application needs more control.
Thanks,
Gage
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help