DPDK patches and discussions
 help / color / mirror / Atom feed
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

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