From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Thu, 6 Oct 2016 16:20:55 +0200 (CEST) Received: by mail-wm0-f44.google.com with SMTP id i130so6934991wmg.1 for ; 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 To: "Kerlin, MarcinX" Cc: dev@dpdk.org, "De Lara Guarch, Pablo" , "Gonzalez Monroy, Sergio" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.