> > > >> -----Original Message----- > >> From: Richardson, Bruce > >> Sent: Wednesday, March 23, 2016 11:45 AM > >> To: Ananyev, Konstantin > >> Cc: Harish Patil; dev at dpdk.org > >> Subject: Re: [dpdk-dev] Question on examples/multi_process app > >> > >> On Wed, Mar 23, 2016 at 11:09:17AM +0000, Ananyev, Konstantin wrote: > >> > Hi everyone, > >> > > >> > > -----Original Message----- > >> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce > >>Richardson > >> > > Sent: Tuesday, March 22, 2016 9:38 PM > >> > > To: Harish Patil > >> > > Cc: dev at dpdk.org > >> > > Subject: Re: [dpdk-dev] Question on examples/multi_process app > >> > > > >> > > On Tue, Mar 22, 2016 at 08:03:42PM +0000, Harish Patil wrote: > >> > > > Hi, > >> > > > I have a question regarding symmetric_mp and mp_server > >>applications under > >> > > > examples/multi_process. In those apps, > >>rte_eth_promiscuous_enable() is > >> > > > called before rte_eth_dev_start(). Is this the correct way to > >>initialize > >> > > > the port/device? As per the description in > >> > > > http://dpdk.org/doc/api/rte__ethdev_8h.html: > >> > > > > >> > > > "The functions exported by the application Ethernet API to setup > >>a device > >> > > > designated by its port identifier must be invoked in the > >>following order: > >> > > > > >> > > > * rte_eth_dev_configure() > >> > > > * rte_eth_tx_queue_setup() > >> > > > * rte_eth_rx_queue_setup() > >> > > > * rte_eth_dev_start() > >> > > > > >> > > > Then, the network application can invoke, in any order, the > >>functions > >> > > > exported by the Ethernet API to get the MAC address of a given > >>device, to > >> > > > get the speed and the status of a device physical link, to > >> > > > receive/transmit [burst of] packets, and so on.? > >> > > > > >> > > > So should I consider this as an application issue or whether the > >>PMD is > >> > > > expected to handle it? If PMD is to handle it, then should the > >>PMD be: > >> > > > > >> > > > 1) Rejecting the Promisc config? OR > >> > > > 2) Cache the config and apply when dev_start() is called at later > >>point? > >> > > >> > Yes as I remember 2) is done. > >> > dev_start() invokes rte_eth_dev_config_restore(), which restores > >> > promisc mode, mac addresses, etc. > >> > > >> > > > > >> > > > Thanks, > >> > > > Harish > >> > > > > >> > > Good question. I think most/all of the Intel adapters, - for which > >>the app was > >> > > originally written, way back in the day when there were only 2 PMDs > >>in DPDK :) > >> > > - will handle the promiscuous mode call either before or after the > >>dev start. > >> > > Assuming that's the case, and if it makes life easier for other > >>driver writers, > >> > > we should indeed standardize on one supported way of doing things - > >>the way > >> > > specified in the documentation being that one way, I would guess. > >> > > > >> > > So, e1000, ixgbe maintainers - do you see any issues with forcing > >>the promiscuous > >> > > mode set API to be called after the call to dev_start()? > >> > > >> > Not sure, why do we need to enforce that restriction? > >> > Is there any problem with current way? > > Yes, at least with the our driver/firmware interface. The port/device > bring-up is carried out in a certain order which requires port config like > promisc mode is called after dev_start(). > > >> > >> It complicates things for driver writers is all, > > > >Not sure how? > >All this replay is done at rte_ethdev layer. > >Honestly, so far I don't remember any complaint about promisc on/off. > > > >> and conflicts slightly with > >> what is stated in the docs. > > > >Update the docs? :) > > Anyway, please let me know what you guys decide? If the app is changed > then nothing needs to done on driver side. Otherwise I have to think of > how to handle this. >
So you are saying that for your device if dev_ops->promiscuous_enable() is called before dev_ops->dev_start(), it would cause a problem right? Konstantin
