> > > > >> -----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. > >> >> /Bruce >