From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 9FFEE2BA7 for ; Wed, 24 May 2017 06:30:28 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 May 2017 21:30:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,384,1491289200"; d="scan'208";a="104680198" Received: from nikhilr-mobl6.amr.corp.intel.com (HELO [10.106.138.137]) ([10.106.138.137]) by orsmga005.jf.intel.com with ESMTP; 23 May 2017 21:30:23 -0700 From: "Rao, Nikhil" To: Jerin Jacob , Gage Eads References: <1494362326-19832-1-git-send-email-gage.eads@intel.com> <20170511163840.GA18505@jerin> X-Mozilla-News-Host: news://proxy.jf.intel.com Cc: dev@dpdk.org, thomas@monjalon.net, bruce.richardson@intel.com, harry.van.haaren@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com, narender.vangati@intel.com, nikhil.rao@intel.com Message-ID: <59250C5E.6020008@intel.com> Date: Wed, 24 May 2017 10:00:22 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20170511163840.GA18505@jerin> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC] eventdev: add event adapter for ethernet Rx queues X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 04:30:29 -0000 Hi Jerin, Comments inline. Also, another function needed is bool rte_event_eth_rx_adapter_multithread_capable(void). This would be used to set the "multithread_capable" service core configuration parameter. Thanks, Nikhil On 5/11/2017 10:08 PM, Jerin Jacob wrote: > -----Original Message----- >> Date: Tue, 9 May 2017 15:38:46 -0500 >> From: Gage Eads >> To: dev@dpdk.org >> CC: nikhil.rao@intel.com, jerin.jacob@caviumnetworks.com, >> thomas@monjalon.net, bruce.richardson@intel.com, >> harry.van.haaren@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com, >> narender.vangati@intel.com >> Subject: [RFC] eventdev: add event adapter for ethernet Rx queues >> X-Mailer: git-send-email 2.7.4 >> >> From: Nikhil Rao > > Hi Nikhil and Gage, > > Thanks for the RFC. A few questions and comments below. > Looks like SW has more constraints on event producer side, after we > finalize on this RFC(I guess only a few minor changes are only required). > I will align other[1] RFC based on _your_ RFC as we need to > converge on name space and we can't duplicate configs like struct > rte_event_dev_producer_conf etc > > [1] > http://dpdk.org/ml/archives/dev/2017-May/065341.html > > > >> + */ >> + >> +#ifdef __cplusplus >> +extern "C" { >> +#endif >> + >> +#include >> +#include >> +#include >> + >> +/* struct rte_eth_rx_event_adapter_queue_config flags definitions */ >> +#define RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID 0x1 >> +/*< This flag indicates the flow identifier is valid */ >> + >> +struct rte_eth_rx_event_adapter_config { > > Since this code is going to be at lib/librte_eventdev, We must start all > public symbols and file name with rte_event_*. > > example: > May be this structure can be changed as rte_event_eth_rx_adapter_config OK. > > >> + uint8_t event_dev_id; >> + /**< Event device identifier */ >> + uint8_t rx_event_port_id; >> + /**< Event port identifier, the adapter enqueues mbuf events to this >> + * port >> + */ >> +}; >> + >> +struct rte_eth_rx_event_adapter_queue_config { >> + uint32_t rx_queue_flags; >> + /**< Flags for handling received packets */ > > Better to add references with @see > example: > @see RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID OK. > >> + uint16_t servicing_weight; >> + /**< Relative polling frequency of ethernet receive queue, if this >> + * is set to zero, the Rx queue is interrupt driven >> + */ >> + struct rte_event ev; >> + /**< >> + * The values from the following event fields will be used when >> + * enqueuing mbuf events: >> + * - event_queue_id: Targeted event queue ID for received packets. >> + * - event_priority: Event priority of packets from this Rx queue in >> + * the event queue relative to other events. >> + * - sched_type: Scheduling type for packets from this Rx queue. >> + * - flow_id: If the RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID bit >> + * is set in rx_queue_flags, this flow_id is used for all >> + * packets received from this queue. Otherwise the flow ID >> + * is set to the RSS hash. > > This scheme is good. I was duplicating the elements in "struct > rte_event_dev_producer_conf" > > IMO, We need to set ev.event_type == RTE_EVENT_TYPE_ETHDEV implicitly in > library. > You can mention that here as a info. OK. > >> + */ >> +}; >> + >> +struct rte_eth_rx_event_adapter_run_args { >> + uint8_t id; >> + /**< Adapter identifier */ >> + unsigned int max_nb_rx; >> + /**< The adapter can return early if it has processed at least >> + * max_nb_rx mbufs. This isn't treated as a requirement; batching may >> + * cause the adapter to process more than max_nb_rx mbufs. >> + */ >> +}; >> + >> +struct rte_eth_rx_event_adapter_stats { >> + uint64_t rx_poll_count; >> + /**< Receive queue poll count across both polled and interrupt mode >> + * queues >> + */ >> + uint64_t rx_packets; >> + /**< Received packet count */ >> + uint64_t rx_enq_fail; >> + /**< Eventdev enqueue failed count */ >> + uint64_t rx_enq_retry; >> + /**< Eventdev enqueue retry count */ >> +}; >> + >> +/** >> + * Create a new ethernet Rx event adapter with the specified identifier. >> + * >> + * @param adapter_id >> + * Event adapter identifier. >> + * @param config >> + * Event adapter config parameters. >> + * @return >> + * - 0: Success >> + * - <0: Error code on failure >> + */ >> +int rte_eth_rx_event_adapter_create( >> + uint8_t id, >> + const struct rte_eth_rx_event_adapter_config *config); >> + > > One adapter creates one service function. right? > It is good to mention the mapping.It is missing in the doc. Yes, in this case, the application creates a service per adapter, it may create multiple Rx event adapters with each adapter handling a subset of Rx queues. As per Harry's patch, only DPDK internal components are expected to request service cores, once Harry posts an updated patch, I will make any necesssary changes and post the next version of this patch. >> +/** >> + * Free an event adapter >> + * >> + * @param id >> + * Adapter identifier. >> + * @return >> + * - 0: Success >> + * - <0: Error code on failure >> + */ >> +int rte_eth_rx_event_adapter_free(uint8_t id); >> + >> +/** >> + * Add eth device to the event adapter >> + * >> + * @param id >> + * Adapter identifier. >> + * @param eth_dev_id >> + * Port identifier of the Ethernet device. >> + * @return >> + * - 0: Success >> + * - <0: Error code on failure >> + */ >> +int rte_eth_rx_event_adapter_dev_add(uint8_t id, uint8_t eth_dev_id); > > rte_eth_event_rx_queue_add() also have eth_dev_id.What is the > significance of eth_dev_id here. Looks like eth_dev_id is a duplicate info. > > if it is duplicate or it can be avoided then I propose to reduce the number > of APIs for easiness of application programming(i.e removing rte_eth_rx_event_adapter_dev_add, > rte_eth_rx_event_adapter_dev_del) OK. > > You can also mention the following for better clarify. If following is > true.If not, What do you think about, co-existence of poll and event mode? Yes, its true. > The rte_eth_rx_burst() result is undefined if application invokes on > bounded ethdev_port and rx_queue_id. > >> + >> +/** >> + * Delete eth device from an event adapter >> + * >> + * @param id >> + * Adapter identifier. >> + * @param eth_dev_id >> + * Port identifier of the Ethernet device. >> + * @return >> + * - 0: Success >> + * - <0: Error code on failure >> + */ >> +int rte_eth_rx_event_adapter_dev_del(uint8_t id, uint8_t eth_dev_id); >> + >> +/** >> + * Add receive queue to event adapter >> + * >> + * @param id >> + * Adapter identifier. >> + * @param eth_dev_id >> + * Port identifier of Ethernet device. >> + * @param rx_queue_id >> + * Ethernet device receive queue index. >> + * @param config >> + * Additonal configuration structure. >> + * @return >> + * - 0: Success, Receive queue added correctly. >> + * - <0: Error code on failure. >> + */ >> +int rte_eth_event_rx_queue_add( >> + uint8_t id, >> + uint8_t eth_dev_id, >> + uint16_t rx_queue_id, > > How about changing it as int32_t rx_queue_id and -1 to denote all Rx > queues configured for given eth_dev_id are added. This will avoid the > case where application needs to call this API one by one when application > interested in all the queues. Sounds good. >> + const struct rte_eth_rx_event_adapter_queue_config *config); >> + > > Don't we need rte_eth_event_rx_queue_del() for tear down? > Yes.