Re: [dpdk-dev] Question on examples/multi_process app

[Harish Patil <harish.patil@qlogic.com>]

>
>
>> >
>> >> -----Original Message-----
>> >> From: Richardson, Bruce
>> >> Sent: Wednesday, March 23, 2016 11:45 AM
>> >> To: Ananyev, Konstantin
>> >> Cc: Harish Patil; dev@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@dpdk.org] On Behalf Of Bruce
>> >>Richardson
>> >> > > Sent: Tuesday, March 22, 2016 9:38 PM
>> >> > > To: Harish Patil
>> >> > > Cc: dev@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