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

-----Original Message-----
From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
Sent: Wednesday, August 9, 2017 11:20 AM
To: Eads, Gage <redacted>
Cc: Rao, Nikhil <redacted>; dev@dpdk.org; thomas@monjalon.net;
Richardson, Bruce [off-list ref]; Van Haaren, Harry
[off-list ref]; hemant.agrawal@nxp.com;
nipun.gupta@nxp.com; Vangati, Narender [off-list ref];
Gujjar, Abhinandan S [off-list ref]
Subject: Re: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues

-----Original Message-----

quoted

Date: Wed, 9 Aug 2017 02:23:15 +0000
From: "Eads, Gage" <redacted>
To: Jerin Jacob <redacted>
CC: "Rao, Nikhil" <redacted>, "dev@dpdk.org"
[off-list ref],  "thomas@monjalon.net" [off-list ref],

"Richardson, Bruce"

quoted

 [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"

quoted

 [off-list ref]
Subject: RE: [PATCH 1/2] eventdev: add event adapter for ethernet Rx
queues

quoted

-----Original Message-----
From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
Sent: Thursday, August 3, 2017 1:23 AM
To: Eads, Gage <redacted>
Cc: Rao, Nikhil <redacted>; dev@dpdk.org;
thomas@monjalon.net; Richardson, Bruce [off-list ref];
Van Haaren, Harry [off-list ref];
hemant.agrawal@nxp.com; nipun.gupta@nxp.com; Vangati, Narender
[off-list ref]; Gujjar, Abhinandan S
[off-list ref]
Subject: Re: [PATCH 1/2] eventdev: add event adapter for ethernet Rx
queues

-----Original Message-----

quoted

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"

quoted

 [off-list ref], "nipun.gupta@nxp.com"
[off-list ref],  "Vangati, Narender"

[off-list ref], "Gujjar, Abhinandan S"

quoted

 [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.

quoted

quoted

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

quoted

quoted

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?

quoted

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?

It could be. Thinking on it some more, I'm a little concerned about doing

configuration without the application's knowledge. Possible issues that could
arise:

quoted

- The user later reconfigures the event device with fewer ports and
the adapter's port becomes invalid, or reconfigures it with more ports
and begins using the port the adapter is using
- rte_event_port_count() + 1 extends beyond the PMD's capabilities
(the sw PMD is hard-coded to support a max of 64 ports, for example)

Having the user be responsible for the port configuration could avoid these

problems. Since the user needs to check the <eventdev, ethdev> pair's
capabilities for the CAP_ADD_QUEUE anyway, they could also check for
INBUILT_PORT and decide whether or not to request an additional port at
eventdev configure time -- thereby ensuring they don't waste a port when using
hardware with inbuilt ports. And this keeps the configuration code in one place
(the app), rather than spread across the app, adapter, and potentially the
conf_cb.

OK.Sounds reasonable.May be we can push the responsibility to application.We
could have a helper function using the proposed adapter API. That helper
function would create the adapter based on the capability for the _default_
case.
Applications free to use the raw adapter API to get more control if required.
Otherwise we will duplicate the code in all the applications.

Makes sense. Are you thinking the helper function would do stop + reconfig with additional port + start + setup port, or just setup the port with an ID the app supplies (only when a port is required, of course)? The second one could be done with little additional code -- the app just needs to check if an additional port is needed when configuring the eventdev, and another helper function could take a list of <eventdev, ethdev> pairs and return true if any don't have an inbuilt port.