> > > >Hi Harish, > >> >> > >> >> >> -----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. > >If that's a real HW limitation, then my opinion yes, we probably better >address it. No its not a HW limitation. It can be handled.
>Though not sure what is the best way: >1) just update the docs and rely on users to read them carefully and >write the > proper code >2) Inside rte_eth_promiscuous_enable/disable check for dev_started flag, >and if it is not set either > a) return an error or > b) update data->promiscuous, but don't invoke >dev_ops->promiscuous_enable() > and rely on rte_eth_dev_config_restore() to set it later. >Wonder what do people think? > >BTW, what about other settings? >MAC addresses, multicast mode, etc? >Are all these things affected too? Probably yes. I feel I should fix the driver - that seems more appropriate. Please confirm. > >Konstantin >
