> -----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? > > 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? :) > > /Bruce
