-----Original Message----- > Date: Sun, 24 Sep 2017 17:44:06 +0530 > From: "Rao, Nikhil" <nikhil....@intel.com> > To: Jerin Jacob <jerin.ja...@caviumnetworks.com> > CC: bruce.richard...@intel.com, gage.e...@intel.com, dev@dpdk.org, > tho...@monjalon.net, harry.van.haa...@intel.com, hemant.agra...@nxp.com, > nipun.gu...@nxp.com, narender.vang...@intel.com, > erik.g.carri...@intel.com, abhinandan.guj...@intel.com, > santosh.shu...@caviumnetworks.com > Subject: Re: [PATCH v4 1/4] eventdev: Add caps API and PMD callbacks for > rte_event_eth_rx_adapter > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.3.0 > > 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....@intel.com> > > > To: jerin.ja...@caviumnetworks.com, bruce.richard...@intel.com > > > CC: gage.e...@intel.com, dev@dpdk.org, tho...@monjalon.net, > > > harry.van.haa...@intel.com, hemant.agra...@nxp.com, nipun.gu...@nxp.com, > > > narender.vang...@intel.com, erik.g.carri...@intel.com, > > > abhinandan.guj...@intel.com, santosh.shu...@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 > > > +/* 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.
Yes. OVERRIDE_FLOW_ID behavior makes sense to me. Please update the doxygen comments as well.
