> Date: Wed, 9 Aug 2017 19:24:30 +0000
> From: "Eads, Gage" <gage.e...@intel.com>
> To: Jerin Jacob <jerin.ja...@caviumnetworks.com>
> CC: "Rao, Nikhil" <nikhil....@intel.com>, "firstname.lastname@example.org" <email@example.com>,
> "tho...@monjalon.net" <tho...@monjalon.net>, "Richardson, Bruce"
> <bruce.richard...@intel.com>, "Van Haaren, Harry"
> <harry.van.haa...@intel.com>, "hemant.agra...@nxp.com"
> <hemant.agra...@nxp.com>, "nipun.gu...@nxp.com" <nipun.gu...@nxp.com>,
> "Vangati, Narender" <narender.vang...@intel.com>, "Gujjar, Abhinandan S"
> Subject: RE: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues
> > > > > >
> > > > >
> > > > > 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?
> > >
> > > 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:
> > > - 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.
I am in favor adding more logic in helper function(I believe, first one ) so
that it will help
application reuse the helper functions for the normal case.