[dpdk-dev] Question on examples/multi_process app

[Ananyev, Konstantin]

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.
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?

Konstantin