From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44])
 by dpdk.org (Postfix) with ESMTP id C87B85A0A
 for <dev@dpdk.org>; Thu,  6 Oct 2016 16:20:55 +0200 (CEST)
Received: by mail-wm0-f44.google.com with SMTP id i130so6934991wmg.1
 for <dev@dpdk.org>; Thu, 06 Oct 2016 07:20:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=6wind-com.20150623.gappssmtp.com; s=20150623;
 h=from:to:cc:subject:date:message-id:user-agent:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=CyKANeggwePEEA9yWog0wfXgxQ/U7bVjEW10sPCWB8s=;
 b=2HzY1sIbEn25P0dXavPQVF02WYHA5QYlu960Wj9dmGiq7RR1HFaAwZXQQCNf9zt4v1
 +1APIxckWj9JDwp79TtN7JsYofRwHltTcCZph3csKfvCQjF08i4Gz5m+gB8aHQlbyHix
 L0SP4+SkdiDDbrczmC/4V0y/VCp85G0aTr7Y8+tJBiGyBIqmL+sORRYuur6KjTeJ8qhu
 wf4CiygkhxtHodW7ygoMqDMs5k8e0Vkfykzi9GfgX1LLTi6PNJXL0YR9rOS1KwScsUzK
 NNDaZR+RNMiVVZeQh8z9nFFtophQ0dL8dO5SxBVB1K4qpF8F0qSxZu5hM/fm8L27ddK2
 v2UQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent
 :in-reply-to:references:mime-version:content-transfer-encoding;
 bh=CyKANeggwePEEA9yWog0wfXgxQ/U7bVjEW10sPCWB8s=;
 b=JqJ7TCBPXGddkCYJDGSXDTDkitKZJawuagkTuplp6sK8/7TMb/uqQMr8qLB/SqdO5L
 boWO6gVvcnwVrH6kFdcOiFIcBKW92CbiwIcWk01NuGMPZNg/XNf6qk8oTZ+Ts2y7pafs
 +awxZgul/MFSra2yy2gtWUWLJWF5UDdQAAFZ1sNzXi/NAVdJ/DG/GSH+7yxHjKhk5BtN
 Jk1T+nwS7V95knybYNmQaNlFoekqzaBnN2An5nqIdSuKEaq+PNYv4bcoFRmRPJUmEDMI
 3KYAPuZTjrw8DZLw78ddEbsGUKFXX1nUfc76/CIGkiORDvU81Op/jWVgNIlIzWn7FUdb
 giwg==
X-Gm-Message-State: AA6/9RmZsfB/mzbRP4q3bVStruPcbZIDr70wTRy4pWwWt/GQKm5KHhFqg/1ecpc4beIUhPbC
X-Received: by 10.28.229.149 with SMTP id c143mr6621646wmh.95.1475763655567;
 Thu, 06 Oct 2016 07:20:55 -0700 (PDT)
Received: from xps13.localnet (102.202.154.77.rev.sfr.net. [77.154.202.102])
 by smtp.gmail.com with ESMTPSA id z17sm15180073wmz.23.2016.10.06.07.20.53
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 06 Oct 2016 07:20:54 -0700 (PDT)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Kerlin, MarcinX" <marcinx.kerlin@intel.com>
Cc: dev@dpdk.org, "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
 "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>
Date: Thu, 06 Oct 2016 16:20:47 +0200
Message-ID: <1556703.BdlfNHUksg@xps13>
User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; )
In-Reply-To: <68D830D942438745AD09BAFA99E33E812BE4BC@IRSMSX102.ger.corp.intel.com>
References: <1474974783-4861-2-git-send-email-marcinx.kerlin@intel.com>
 <1538060.S3DiiuebUu@xps13>
 <68D830D942438745AD09BAFA99E33E812BE4BC@IRSMSX102.ger.corp.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH v5 1/2] librte_ether: add protection against
	overwrite device data
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Oct 2016 14:20:56 -0000

2016-10-06 13:57, Kerlin, MarcinX:
> Hi Thomas,
> 
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 
> > Hi Marcin,
> > 
> > 2016-09-30 16:00, Marcin Kerlin:
> > > Added protection against overwrite device data in array
> > > rte_eth_dev_data[] for the next secondary applications. Secondary
> > > process appends in the first free place rather than at the beginning.
> > > This behavior prevents overwriting devices data of primary process by
> > secondary process.
> > 
> > I've just realized that you are trying to fix an useless code.
> > Why not just remove the array rte_eth_dev_data[] at first?
> 
> because pointer to rte_eth_dev_data in rte_eth_devices[] is 
> just to array rte_eth_dev_data[].
> 
> rte_ethdev.c:214 
> eth_dev->data = &rte_eth_dev_data[port_id];

This line indicates that the pointer data is to the struct rte_eth_dev_data
of the port_id, not the array of every devices.

> > We already have the array rte_eth_devices[] and there is a pointer to
> > rte_eth_dev_data in rte_eth_dev.
> 
> As you write above there is a pointer, but after run secondary testpmd this pointer
> will indicate data which hold from now data for secondary testpmd.
[...]
I think I've understood the bug.
I'm just saying you are fixing a weird design (rte_eth_dev_data[]).

> > Is it just a workaround to be able to lookup the rte_eth_dev_data memzone in
> > the secondary process?
> 
> No it is not workaround, it is protection against overwrite device data.
> I think that my cover letter good explain what is wrong. I did there
> short debug log.

I'm talking about the initial introduction of rte_eth_dev_data[]
which seems to be a workaround for multi-process without touching
rte_eth_devices[] allocated as a global variable (not a memzone).

> > So wouldn't it be saner to have rte_eth_devices[] in a memzone?
> 
> So you mean that move rte_eth_devices[] to memzone + remove rte_eth_dev_data[].

Yes

> What will indicate pointer inside rte_eth_dev  rte_eth_devices[]:
> (struct rte_eth_dev_data *data;  /**< Pointer to device data */)

After thinking more about it, I realize that rte_eth_devices cannot be
in a shared memzone because of its local pointers.

Sorry for the noise, I'll reconsider your patch.