All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hideyuki Yamashita <yamashita.hideyuki@po.ntt-tx.co.jp>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, Gaetan Rivet <gaetan.rivet@6wind.com>
Subject: Re: How to replace rte_eth_dev_attach with rte_eal_hotplug_add
Date: Thu, 27 Sep 2018 10:38:11 +0900	[thread overview]
Message-ID: <201809270138.w8R1cJHm000890@ccmail04.silk.ntt-tx.co.jp> (raw)
In-Reply-To: <2330393.uxWCJWc828@xps>

Dear Thomas,

Thanks for your answer.
It took me a little time to digest answer.
Please see inline.


> 21/09/2018 09:19, Hideyuki Yamashita:
> > Dear Gaetan and Thomas, 
> > 
> > Thanks for your answer.
> > Please see inline.
> > 
> > > 20/09/2018 11:09, Ga?an Rivet:
> > > > On Thu, Sep 20, 2018 at 05:46:37PM +0900, Hideyuki Yamashita wrote:
> > > > > Hello,
> > > > > 
> > > > > From dpdk 18.08 release rte_eth_dev_attach and 
> > > > > rte_eth_dev_detach becom deprecated API and 
> > > > > it is recommended to replace with rte_eal_hotplug_add
> > > > > and rte_eal_hotplug_remove.
> > > > > 
> > > > > My program uses  above mentioned deprecated APIs
> > > > > and have to replace those.
> > > > > Note that my program uses attach to attach vhost, pcap pmd.
> > > > > 
> > > > > My question is whether it is correct to replace those as following:
> > > > > find rte_eth_dev_attach function in rte_ethdev.c and
> > > > > migrate those content into my program.
> > > > > 
> > > > > e.g. 
> > > > > lib/librte_ethdev/rte_ethdev.c line 643-686 for attach
> > > > > lib/librte_ethdev/rte_ethdev.c line 690-720 for detach
> > > > > 
> > > > > Your advice/guidance are much appreciated.
> > > > > Thanks!
> > > > 
> > > > Hello Hideyuki,
> > > > 
> > > > You could use this code for guidance, while leaving the ethdev
> > > > specificities such as verifying the eth_dev_count_total(). The hotplug
> > > > function would already return an error if the PMD was not able to create
> > > > the necessary devices.
> > > > 
> > > > The main issue might be to find the port_id of your new port.
> > > > You won't be able to use eth_dev_last_created_port, so you would have to
> > > > iterate over the ethdev using RTE_ETH_FOREACH_DEV and find the one
> > > > matching your parameters (you might for example match the rte_device
> > > > name with the name you used in hotplug_add, as there is no standard
> > > > naming scheme at the ethdev level).
> > First of all, thank for your answering to my question.
> > But I have questions.
> > (Sorry, I have poor knowledge about dpdk and have many basic questions)
> > 
> > Q1. 
> > Why eth_dev_last_created_port can not be used?
> > When I look into rte_eth_dev_atthach in 18.08, it calls 
> > 
> > *port_id = eth_dev_last_created_port;
> > 
> > at the end of the function.
> 
> You can have a race condition.
Please elaborate me a bit more.

Is it correct understanding that race condition 
includes
- read information before port is available
- other device may be plugged (or unplugged)
and so using "eth_dev_last_created_port" is 
NOT reliable?


> > Q2. 
> > Is it possible to use rte_eth_dev_get_port_by name 
> > instead of calling RTE_ETH_FOREACH_DEV or using
> > eth_dev_last_created_port?	
> 
> This function works only if you know the ethdev name generated by the PMD.
Thanks
 
> > Q3. 
> > If answer to Q2 is no, then how can I get device name from each device?
> > For example, rte_eth_dev_info_get takes port_id as its
> > argument.But what I want to know is the port id of the specified device
> > name.
> 
> If you want the ethdev port ids created after probing (based on devargs),
> you probably want to request it with the same devargs.
> I will try to work on something for this need.
> For now, the most reliable solution is to use the notifications.

I think I have two alternatives:
Alt1:
call "rte_eal_hotplug_add"
and retrieve port_id for newly plugged device
using RTE_ETH_FOREACH_DEV.
(as Gaetan said)

Alt2:
call "rte_eth_dev_callback_register"  to subscribe "port probe" event
and "rte_eal_hotplug_add"
and finally get notification including port id.
(As you said)

My question is which is better alternative?
Are there any bad point on Alt1 like using
eth_dev_last_created_port?
(e.g. port not available when called RTE_ETH_FOREACH_DEV)

BR,
Hideyuki Yamashita
NTT TechnoCross

> > > It is recommended to register a callback to receive the notifications
> > > of new ethdev ports.
> > > So it may be a change of programming style: sync vs async.
> > Thanks for your advice.
> > In general, I agree.
> > 
> > But what is the example of notification that program can receive
> > after device hotplugged?
> > Device unplugged notification like specified in rte_eth_event_type?
> 
> Yes, look at these ones:
>     RTE_ETH_EVENT_NEW,      /**< port is probed */
>     RTE_ETH_EVENT_DESTROY,  /**< port is released */
> 
> > If there are code in example, it is highly appreciated.
> 
> You can register a callback with
> 	rte_eth_dev_callback_register(RTE_ETH_ALL, RTE_ETH_EVENT_NEW, ...)
> like done in drivers/net/failsafe/failsafe.c
> 
> 
> 

  reply	other threads:[~2018-09-27  1:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-20  8:46 How to replace rte_eth_dev_attach with rte_eal_hotplug_add Hideyuki Yamashita
2018-09-20  9:09 ` Gaëtan Rivet
2018-09-20 13:02   ` Thomas Monjalon
2018-09-21  7:19     ` Hideyuki Yamashita
2018-09-21  9:16       ` Thomas Monjalon
2018-09-27  1:38         ` Hideyuki Yamashita [this message]
2018-09-27  8:58           ` Thomas Monjalon
2018-09-27 10:40             ` Hideyuki Yamashita
2018-09-27 11:39               ` Thomas Monjalon
2018-10-22  4:34                 ` Hideyuki Yamashita
2018-10-22  6:55                   ` Thomas Monjalon
2018-10-22 11:24                     ` Hideyuki Yamashita
2018-10-22 12:01                       ` Thomas Monjalon
2018-10-23  1:52                         ` Hideyuki Yamashita
2018-10-23  7:34                           ` Thomas Monjalon
2018-10-25  2:54                             ` Hideyuki Yamashita
2018-10-25  6:48                               ` Thomas Monjalon
2018-10-25  9:46                                 ` Hideyuki Yamashita
2018-10-25 10:35                                   ` Thomas Monjalon
2018-09-27 13:48               ` Andrzej Ostruszka

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=201809270138.w8R1cJHm000890@ccmail04.silk.ntt-tx.co.jp \
    --to=yamashita.hideyuki@po.ntt-tx.co.jp \
    --cc=dev@dpdk.org \
    --cc=gaetan.rivet@6wind.com \
    --cc=thomas@monjalon.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.