> > >> > >> >> -----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 > >
Yes, with the way it is implemented currently it would pose a problem. Please note that it can be addressed in the driver, not an issue. However, I wanted to be sure if the app behavior is correct. Either ways, please let me know - I can take care of both. Thanks, Harish
