[dpdk-dev] Question on examples/multi_process app

[Harish Patil]

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

>
>> 
>> /Bruce
>