[dpdk-dev] Question on examples/multi_process app

Harish Patil harish.patil at qlogic.com
Wed Mar 30 00:58:58 CEST 2016


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



More information about the dev mailing list