From: "Kerlin, MarcinX" <marcinx.kerlin@intel.com>
To: "Tootoonchian, Amin" <amin.tootoonchian@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>
Subject: Re: [dpdk-dev] [PATCH] ethdev: ensure consistent port id assignment
Date: Thu, 21 Jul 2016 13:54:50 +0000 [thread overview]
Message-ID: <68D830D942438745AD09BAFA99E33E81275B25@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <5905C8E33883CA46A8878E2D7724E215172927@ORSMSX109.amr.corp.intel.com>
Hi Amin,
> -----Original Message-----
> From: Tootoonchian, Amin
> Sent: Wednesday, July 20, 2016 5:08 PM
> To: Kerlin, MarcinX <marcinx.kerlin@intel.com>
> Cc: dev@dpdk.org; thomas.monjalon@6wind.com
> Subject: RE: [PATCH] ethdev: ensure consistent port id assignment
>
> Hi Marcin,
>
> Comments inline:
>
> > -----Original Message-----
> > From: Kerlin, MarcinX
> > Sent: Wednesday, July 20, 2016 1:51 AM
> > To: Tootoonchian, Amin <amin.tootoonchian@intel.com>
> > Cc: dev@dpdk.org; thomas.monjalon@6wind.com
> > Subject: RE: [PATCH] ethdev: ensure consistent port id assignment
> >
> > Hi Amin,
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tootoonchian,
> > > Amin
> > > Sent: Tuesday, July 12, 2016 4:01 AM
> > > To: thomas.monjalon@6wind.com
> > > Cc: dev@dpdk.org
> > > Subject: [dpdk-dev] [PATCH] ethdev: ensure consistent port id
> > > assignment
> > >
> > > The rte_eth_dev_allocate() code has an implicit assumption that the
> > > port id assignment in the secondary process is consistent with that
> > > of the primary. The current code breaks if the enumeration of
> > > ethdevs in primary and secondary processes are not identical (e.g.,
> > > when the black/whitelist and vdev args of the primary and secondary
> > > do not match, or when the primary dynamically adds/removes ethdevs).
> > >
> > > To fix this problem, rte_eth_dev_allocate() now looks up port id by
> > > name in a secondary process (making it explicit that ethdevs can
> > > only be created and initialized by the primary process). Upon
> > > releasing a port, the primary process zeros out eth_dev->data to
> > > avoid false positives in port id lookup by rte_eth_dev_get_port_by_name().
> > >
> > > Signed-off-by: Amin Tootoonchian <amin.tootoonchian@intel.com>
> > > ---
> > > lib/librte_ether/rte_ethdev.c | 44
> > > +++++++++++++++++++++++++++++------------
> > > --
> > > 1 file changed, 30 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/lib/librte_ether/rte_ethdev.c
> > > b/lib/librte_ether/rte_ethdev.c index
> > > 0a6e3f1..1801f57 100644
> > > --- a/lib/librte_ether/rte_ethdev.c
> > > +++ b/lib/librte_ether/rte_ethdev.c
> > > @@ -195,25 +195,37 @@ rte_eth_dev_allocate(const char *name, enum
> > > rte_eth_dev_type type)
> > > uint8_t port_id;
> > > struct rte_eth_dev *eth_dev;
> > >
> > > - port_id = rte_eth_dev_find_free_port();
> > > - if (port_id == RTE_MAX_ETHPORTS) {
> > > - RTE_PMD_DEBUG_TRACE("Reached maximum number of
> > > Ethernet ports\n");
> > > - return NULL;
> > > - }
> > > -
> > > if (rte_eth_dev_data == NULL)
> > > rte_eth_dev_data_alloc();
> > >
> > > - if (rte_eth_dev_allocated(name) != NULL) {
> > > - RTE_PMD_DEBUG_TRACE("Ethernet Device with name %s
> > > already allocated!\n",
> > > - name);
> > > - return NULL;
> > > + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> > > + port_id = rte_eth_dev_find_free_port();
> > > + if (port_id == RTE_MAX_ETHPORTS) {
> > > + RTE_PMD_DEBUG_TRACE("Reached maximum number
> > > of Ethernet ports\n");
> > > + return NULL;
> > > + }
> > > +
> > > + if (rte_eth_dev_allocated(name) != NULL) {
> > > + RTE_PMD_DEBUG_TRACE("Ethernet Device with name
> > > %s already allocated!\n",
> > > + name);
> > > + return NULL;
> > > + }
> > > + } else {
> > > + if (rte_eth_dev_get_port_by_name(name, &port_id) != 0) {
> >
> >
> > I was working also on this problem but I didn't send patch yet, so I
> > did review of your code.
> >
> > Condition (rte_eth_dev_get_port_by_name(name, &port_id) != 0) will
> > always fail.
> > Secondary process enter here and he will be looking for him name but
> > has not yet added and the application return NULL here e.g. we will
> > run app with device name pcap1 but this device is not on list and function
> return null.
>
> This is the intended behavior with this patch. Ports are to be created only by the
> primary process. This is required for correct operation IMO, because if we
> allow secondary processes to create ports dynamically (and locally use
> conflicting port ids) without any synchronization mechanism, they're
> guaranteed to overwrite each other's rte_eth_dev_data.
Thanks Amin for clarification,
I had another approach, that rte_eth_devices and rte_eth_dev_data should have
different offset of port_id and secondary process can also add devices.
as I now understand with this patch we will not be able do something like:
Primary:
./test-pmd -c 0xf -n 4 --socket-mem='512,0' -w 03:00.1 -w 03:00.0
--proc-type=primary --file-prefix=xz1 -- -i
Secondary:
./test-pmd -c 0xf0 --socket-mem='512,0' -n 4 -v -b 03:00.1 -b 03:00.0
--vdev 'eth_pcap0,rx_pcap=/var/log/device1.pcap,tx_pcap=/var/log/device2.pcap'
--proc-type=secondary --file-prefix=xz1 -- -i
Because secondary processes "Ports are to be created only by the primary process"?
I tried run and secondary process failed here:
else {
if (rte_eth_dev_get_port_by_name(name, &port_id) != 0) {
RTE_PMD_DEBUG_TRACE("Ethernet Device with name %s could not be found!\n",
name);
return NULL;
}
}
because he did not find the name "eth_pcap0"
+ Sergio, just like you added also in the next mail
>
> > > + RTE_PMD_DEBUG_TRACE("Ethernet Device with name
> > > %s could not be found!\n",
> > > + name);
> > > + return NULL;
> > > + }
> > > }
> > >
> > > eth_dev = &rte_eth_devices[port_id];
> > > eth_dev->data = &rte_eth_dev_data[port_id];
> > > - snprintf(eth_dev->data->name, sizeof(eth_dev->data->name), "%s",
> > > name);
> > > - eth_dev->data->port_id = port_id;
> > > +
> > > + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> > > + snprintf(eth_dev->data->name, sizeof(eth_dev->data->name),
> > > "%s", name);
> > > + eth_dev->data->port_id = port_id;
> > > + }
> > > +
> >
> >
> > 1. rte_eth_dev_data[port_id] -> port id should be shifted because
> > secondary process overwrite e.g. first position which is common with
> > primary process, so should be add at the end
> >
> > 2. If this condition is true only for primary it means that secondary
> > process can't add own name.
> > So this excludes with above line: "if
> > (rte_eth_dev_get_port_by_name(name,
> > &port_id) != 0)"?
>
> No, with this patch, secondary processes cannot add their own ports, but
> instead, through some mechanism, should ask the primary process to create
> the port for them.
>
> > I will send also my patch soon and we can compare and prepare a common
> > version. We should keep in mind also the hot plugging.
>
> Thanks Marcin! Indeed, I have been using this patch in an environment which
> we use hotplug very aggressively and I confirm that the patch works flawlessly.
> Of course, all processes using an about-to-be-removed port need to close and
> detach. For attaching, the primary attaches first and any secondary can attach
> next.
>
> Thomas, your thoughts?
>
> Thanks,
> Amin
next prev parent reply other threads:[~2016-07-21 13:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 2:01 Tootoonchian, Amin
2016-07-20 8:51 ` Kerlin, MarcinX
2016-07-20 15:07 ` Tootoonchian, Amin
2016-07-20 15:11 ` Thomas Monjalon
2016-07-20 17:25 ` Tootoonchian, Amin
2016-08-24 22:17 ` Tootoonchian, Amin
2017-09-04 14:53 ` Sergio Gonzalez Monroy
2018-12-21 15:30 ` Ferruh Yigit
2016-07-21 13:54 ` Kerlin, MarcinX [this message]
2016-07-22 19:56 ` Tootoonchian, Amin
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=68D830D942438745AD09BAFA99E33E81275B25@IRSMSX102.ger.corp.intel.com \
--to=marcinx.kerlin@intel.com \
--cc=amin.tootoonchian@intel.com \
--cc=dev@dpdk.org \
--cc=sergio.gonzalez.monroy@intel.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).