> > - Theme is based on your original rx adapter proposal but with eventpmd > > ops(not adapter ops).i.e Reuse as much of your existing Rx adapter > > implementation as common code and add hooks for HW based adapters. For > > example, before you add <ethdev, queue_id> to "rx_poll" in > > eth_poll_wrr_calc(), > > Check for eventdev PMD ops is available adding it HW. If yes, Don't add in > > "rx_poll" > > This seems better approach. Infact we were also thinking on similar approach > while > reviewing the initial patch. This will also avoid redundant code for creation > of services > by separate event PMD's. > > > > > adapter_api > > ------------ > > int rte_event_eth_rx_adapter_create(id, rte_event_eth_rx_adapter_conf *conf) > > int rte_event_eth_rx_adapter_queue_add(uint8_t id, uint8_t eth_dev_id, > > int32_t > > rx_queue_id, rte_event_eth_rx_adapter_queue_conf *conf); > > Just wanted to know your opinion on adding other adapters such as for crypto > devices. > > One way is to create separate adapter for crypto devices (or any other > devices which may > be linked with event devices). But this would again cause redundancy in > service creations. > > In my opinion these API's can be independent of "_eth" suffix and have an > enum of "device > type" in adapter_capablity, queue_add and queue_delete API, so that the model > is not > limited for one type of device. For this series only ethernet type be > supported but having > possibility of adding other devices in future. > > Views on this?
For timer adapter, we will have fastpath API like , "arming" and "canceling" the timers. IMO, semantically which will be different from eth_rx or crypto adapter for the creation side.So may it be worth to have separate adapter API for each subsystem to address the specific requirements.(timer adapter may have resolution, max timeout etc configuration parameters on adapter create()) >
