From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 28BF229CF for ; Thu, 6 Oct 2016 15:57:57 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP; 06 Oct 2016 06:57:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,454,1473145200"; d="scan'208";a="177039511" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by fmsmga004.fm.intel.com with ESMTP; 06 Oct 2016 06:57:55 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.198]) by IRSMSX107.ger.corp.intel.com ([169.254.10.95]) with mapi id 14.03.0248.002; Thu, 6 Oct 2016 14:57:53 +0100 From: "Kerlin, MarcinX" To: Thomas Monjalon CC: "dev@dpdk.org" , "De Lara Guarch, Pablo" , "Gonzalez Monroy, Sergio" Thread-Topic: [PATCH v5 1/2] librte_ether: add protection against overwrite device data Thread-Index: AQHSGyRENUzbhZI1jkOj78RFQIWo3aCbJHgAgAAhgTA= Date: Thu, 6 Oct 2016 13:57:53 +0000 Message-ID: <68D830D942438745AD09BAFA99E33E812BE4BC@IRSMSX102.ger.corp.intel.com> References: <1474974783-4861-2-git-send-email-marcinx.kerlin@intel.com> <1475244055-6309-1-git-send-email-marcinx.kerlin@intel.com> <1475244055-6309-2-git-send-email-marcinx.kerlin@intel.com> <1538060.S3DiiuebUu@xps13> In-Reply-To: <1538060.S3DiiuebUu@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 13:57:57 -0000 Hi Thomas, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Thursday, October 06, 2016 11:41 AM > To: Kerlin, MarcinX > Cc: dev@dpdk.org; De Lara Guarch, Pablo ; > Gonzalez Monroy, Sergio > Subject: Re: [PATCH v5 1/2] librte_ether: add protection against overwrit= e > device data >=20 > Hi Marcin, >=20 > 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. >=20 > 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=20 just to array rte_eth_dev_data[]. rte_ethdev.c:214=20 eth_dev->data =3D &rte_eth_dev_data[port_id]; > 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. 1) run testpmd [primary] rte_eth_devices[0].data.name =3D 3:0.1 2) run testpmd [secondary] This testpmd overwrite first index in rte_eth_dev_data[] 3:0.1 -> eth_pcap0 3) back to testpmd [primary] rte_eth_devices[0].data.name =3D eth_pcap0 from now in primary testpmd our device name is eth_pcap0 but should be 3:0.= 1 >=20 > 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.=20 > 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_dat= a[]. What will indicate pointer inside rte_eth_dev rte_eth_devices[]: (struct rte_eth_dev_data *data; /**< Pointer to device data */) If I did not understand you please clarify more. Regards, Marcin >=20 > Sergio, as the multi-process maintainer, I guess you have an idea :)