From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Harish Patil <harish.patil@qlogic.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Question on examples/multi_process app
Date: Fri, 25 Mar 2016 14:18:42 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB97725836B21186@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <D3198068.185B9E%harish.patil@qlogic.com>
Hi Harish,
> >> >
> >> >> -----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.
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
next prev parent reply other threads:[~2016-03-25 14:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 20:03 Harish Patil
2016-03-22 21:38 ` Bruce Richardson
2016-03-23 11:09 ` Ananyev, Konstantin
2016-03-23 11:45 ` Bruce Richardson
2016-03-23 11:48 ` Ananyev, Konstantin
2016-03-24 6:52 ` Harish Patil
2016-03-24 11:18 ` Ananyev, Konstantin
2016-03-24 18:36 ` Harish Patil
2016-03-25 14:18 ` Ananyev, Konstantin [this message]
2016-03-29 22:58 ` Harish Patil
2016-03-30 18:53 ` Harish Patil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2601191342CEEE43887BDE71AB97725836B21186@irsmsx105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=harish.patil@qlogic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).