Message ID | 1516293317-30748-3-git-send-email-matan@mellanox.com (mailing list archive) |
---|---|
State | Superseded, archived |
Delegated to: | Ferruh Yigit |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 81C091B378; Thu, 18 Jan 2018 17:35:43 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10071.outbound.protection.outlook.com [40.107.1.71]) by dpdk.org (Postfix) with ESMTP id 195A91B369; Thu, 18 Jan 2018 17:35:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=abpo6U4VAEb3VLn3T2I2ohwcb8mlDcZX7xkKXF+Zlqs=; b=idIczvQHZT+TD/FidDXE2nDaRhKomsP/0LV+F+KH4ydHS8ON/lrI9xWlOX9sr3dgjkuTR2Vlid8Z2tcOZhj0uW584BDkYZw33UrruV4MT4/geqeaugMwb3SXXtPXmqMTJkX55bE9sHO17LqZfpSSEgyQJnXMbFQjiRDYwfPue0Y= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=matan@mellanox.com; Received: from mellanox.com (37.142.13.130) by VI1PR0502MB3806.eurprd05.prod.outlook.com (2603:10a6:803:12::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Thu, 18 Jan 2018 16:35:34 +0000 From: Matan Azrad <matan@mellanox.com> To: Thomas Monjalon <thomas@monjalon.net>, Gaetan Rivet <gaetan.rivet@6wind.com>, Jingjing Wu <jingjing.wu@intel.com> Cc: dev@dpdk.org, Neil Horman <nhorman@tuxdriver.com>, Bruce Richardson <bruce.richardson@intel.com>, Konstantin Ananyev <konstantin.ananyev@intel.com>, stable@dpdk.org Date: Thu, 18 Jan 2018 16:35:12 +0000 Message-Id: <1516293317-30748-3-git-send-email-matan@mellanox.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1516293317-30748-1-git-send-email-matan@mellanox.com> References: <1515318351-4756-1-git-send-email-matan@mellanox.com> <1516293317-30748-1-git-send-email-matan@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [37.142.13.130] X-ClientProxiedBy: VI1PR0802CA0021.eurprd08.prod.outlook.com (2603:10a6:800:aa::31) To VI1PR0502MB3806.eurprd05.prod.outlook.com (2603:10a6:803:12::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 493454a2-19ba-4c6f-0bb8-08d55e917fb0 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:VI1PR0502MB3806; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0502MB3806; 3:o+zmyVnrzKl1/cu/h6n2oLPua7qdp15X1sjWjN6yVbJp4OHPrjAsdBNPuir88ISmrrSNvfkaX/i9vlG+DgBQ4bTdqOBISTW8PHeDEbQWgCvZbLmFHd58PaAd7aaJQylLFLDCy4rgUN4NywS3uLh+JxgYNwMC6G67lQMW8nMuBWjcURNQ7Hlt70p1u0T2nwMB1/pZt2WLzKxrT2MYVcRR+aIfScaeddxV65fKlFfm1JCGFZ2iUny2Up6yG++YmaTI; 25:hOwuXfWyZAdLO3d2b+Tk22/9TIWztufloSQNLsFuPf/jaPRKudQzUh02ylY+ZF1rsYJntGy04TXlI8se42+cD1eZOXv1E8/pEjuw2aZxKIO6/M943SoMA3gJY8/vwhdgjeBPT5NblyiwwaGCjgAoHH+mx2KYuRewk+PzdAnJsQxWkqKQ/n55EZCos4MTbGaK4fPti/xxCiOWG0EbPwtPl0KcgY8U/59oIfYmYwZHOyXKRJZVcY8b+lHwuI9N+hBrgaXKzLPfbPoTWcb3wRITnlfGBI2qpgyZ54XzoXaLWuswXVoAvOItJMJyqo1tu4Qbzb0xssydOS4hGFFRDt7R2g==; 31:jOyoploRIEhbdJe2FPVTOeOPs9CoWLO759slg+nL4yiJTePSJHPztE9lWvtRoQVzWXhLpfC6fpKEuDy8EWBvPkUF5f5ZgrfCi7tvG9FmfgadRgzua/8YemlaFreyg74vo0uyvkUYolGS7/klTneUPmaUhC+xY3ddDdUEjU5qb5rrMkAtP5x6Iwepk2NFgGgvF3iU6AvRWgjgUGc8j+uBipqy8ENXkTwpx0Q53Jry/vw= X-MS-TrafficTypeDiagnostic: VI1PR0502MB3806: X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; VI1PR0502MB3806; 20:qQ7EvgdAUrwguzsulyQMxBBSZXx5Vzt+3/s1NcDjE13xW2fIKE9SLhlmKRFsleE9Go+/c7aFpWvPF0SpYgAD4+XzlFQY1SgvFnJ8fqo8mcqZ/HEQU46PmhDtRQnoNgOZ6NQOiVKhTRrdiyyEL58vBxEpTIv+XVD0q4DIL2ip71I/150nVLDewEvzj/KXPG2r6hSzIhl5gQYbDCv5EtS15EtLXt3F8M2QTedFnXLuwSC81FVtr2ivC5pK5CZNx0RQSg2FcH5Ye6tinBUiULLwb3nve0k8JVfaIqzZIyoUN0b7FGzYWlarJ2oBBJefDZ2R1bMZ85ji20mjZREJdGogx/RJqdUeuDjBMf+/r1OZDtA0QEk3x55peV8+IMbqEAEO7i/71pstFowN8aofCpZU83hpF1Bysp6mdAHTOPHYKqT9q6VpRq6AtIyPEunpvfxilqjb1wi/dXUEZgqCXD+H1Yf3COyN0nRu/GUsLNnoSza+UucjV8rnVt1EmDiCIy9m; 4:MkXWgOQVuV+vyotba5A5K9ee4qBeEi578WXZyd4ZsBtvMWRmkFqpQxcDlKkV3hEYDCLzyAweQcI1gSPYSwgMAcYREpayRv6yLzSNd1VfHItqOcr9rOOmwy9ZfJzMy25u9AQPuhIcnBpRLJ5FsbanRXCahv31F0v/pkVPGQInO8seqMqIWLr5O0Vg0WpzH99g64t+ZC4n7vOhcMeBE4WX/B6LHMMibiN6dpTqrJu/MEYzEuX6FaQAy9PCtBLKSNdD4JHIaTJ7GzU9JldVyjROisyl/vYww4rcXy/0plmOYT4zovmAifTlCz5O0poCozmdP8CGvStsg/3gUN1BBC6a2A== X-Microsoft-Antispam-PRVS: <VI1PR0502MB3806CD9FB7E9150D3A4E8CF9D2E80@VI1PR0502MB3806.eurprd05.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(788757137089)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231023)(2400064)(944501161)(6055026)(6041268)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0502MB3806; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR0502MB3806; X-Forefront-PRVS: 05568D1FF7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(376002)(39380400002)(366004)(189003)(199004)(2950100002)(47776003)(4720700003)(478600001)(21086003)(50466002)(86362001)(106356001)(7736002)(16586007)(76176011)(305945005)(59450400001)(36756003)(3846002)(25786009)(386003)(52116002)(55016002)(7696005)(4326008)(97736004)(33026002)(51416003)(54906003)(53936002)(68736007)(16526018)(6116002)(316002)(105586002)(110136005)(5660300001)(2906002)(6666003)(66066001)(50226002)(81156014)(81166006)(48376002)(69596002)(8676002)(26005)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0502MB3806; H:mellanox.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR0502MB3806; 23:6cce9KgigM91/haenHg8OTYPW+0/48DJoCDdwap?= N/ch0WJVKBtaheCSQjmkZWBUKgTapSdqpLM4V2oMQ3dG1e9h3hWBJZCC3UmO5wyKLE+9MCEaHHXW9rPptWgINDZHAo00rCgdW2Sccgmm/tWid3hUua9s4r6V+x2b2Pztn+92ZmZlqUD0Eq31DVkn62eSDQIiFD8zCPvQKdl/BxgR/ukFJ+7nRSxBckrK3lmbAap0mKjyEqK4YB9AMUsl5emgIgd8P8upWKaG8K+ZtZFgYua86+Q2e1jKD/4VFMRv7TUBa8DlXkLxVb+bQKME2tHPgi/d/dfR2EAAuAeSRwsvAL9QGl3LimUW+BpRlgEBPiWuAYrv72jImC0xKIXoKRKgpxBTHiq4VYFbwEnDSftWobIoDyxi3/gJYAVuijnG9bdnqq0XNmU66xNVNeE7d3w7qT+Ik3pvwtJhgP4lpDrEbqPtO78NcQMf/MP6pZhHeFMLiiHvdup13kP4OoUDjBcnJ3Veh9I8nmgSD2j4e+PvLMN3Wa00friSimCJN6Fr3Cgd7zyW14k19PgLM58SAyRZh/7Mimw4QU8ie3Oc2qpWmFTIvaaLh8BG46MIDQFKoTnuP+BzQFLJ8zSzGNP6yxk9kyxndJ606KRzgaFwoq7shDqwpTXfUWdTFw/knbmjK0hHaYrGCL/LHFXWNpyLe+TVxM5fMnkaN3SRpXJ21oIsI/vmtkDo5PIFlesL7m0Ty4GLzUqLloLx7iXpuPl1bwcx254wYWlhHj0SBvhEr6DhSG+NsQQkS/2JDSKUk0L0jmhQvfcm/eoRx+yur5inceobIUjVYWcwSKJF1k7RzS0oHhc7vcCazDI0qOc7d1OEJGF0q6rAo/GVqXEiVTA7FfLgqE/XVUL6tnq40xjruN60LHX0fmpoQFpduEUwXtx3oJH5UWuJsV2UF0ejXlz5boTF+Cj1XsP28WzifpD445uUB8a98etZ44bTysdfsBpCJilAgaM9YrqKuZ6exSdiCzikLK5MG8y+WxU7oyWrN/veCdfi6FW5ezO7ywR4W6Teq2Cc4CMtXM30q+OxfUtbYWzDKkkRUuni3LuTmlSuVv8kcQrV2ZRZbAKFZmuSSW7khELftdznmoXUS98cpIV+/0Uf6RL9OI4I6E9eIfFjv95qHX/G6haGPz/QRgu29zM48sruqaqHcPJi4sChO+adRHV0G X-Microsoft-Exchange-Diagnostics: 1; VI1PR0502MB3806; 6:hO74dhoSVNAbk2HbQUItFa8e9c8HfEAyzDQRVZxDEz+6rthaSpj5peFCMzxFFYd3YRrHXzsXS0MTb2XHm5abWOx4YbN0m3GyDgdrBU1ow54Ewj6jFIb84uuoMe83K6CumCMVYDyt8AEMzt6JucVulIaVZCEZ44t2/Yp7RIaLdcvBM6GT7MUmvGwQDIhAz+tRween4uL/mrvcZvTg1bvzlalkBFUCGUi4T56ZNlRfKbgIym0V0jhRk2zg8gGUPFHWe/FrRBkLOzoBY6TYNzZ1TsuWaMMPvukBC2VobYMkGrcrAGAxZiSEb8vOldqIjWr2XKFuoLPTDhXGN5nRucvcqgE+TUTuQgxBN4VJmNemL2Q=; 5:mdQczVkw0Z+K9PgYsRvqcJx5HvIXh/HMx6jQx3ySVLvpAmYcmmMlJ/c4d1ITpErFid6d/V3sF5lCey1uH3II3fvJ6rbmyNaJ1YqDUMW5A+iXGhhyK76aduCTILVG4unaiCTN147IWOlYzx09xfJvkAjhGmt001p3HaRG/vlRD5Y=; 24:JgFCcE0jFjtZWXoLDhWbWcgopuFZJ2abZ9lw5UlZ8nKMe+61r4tM/X/hbsc4SKWyekglDnCbiqAMsb54ULGwflY5N+ld8KMFq1LOMK1I9j8=; 7:oHYY0FZL0Eo9zqgW5XkkgrwO0s+PDMYox6O8ED+AJzJELUY16uaM1bYUbNtzCc/7qy5obrQzExunmzCZXBTV37vMJuKMg/wOIJ9tlOvCTQw+X15d3p/3elXgXN22cciwqHaeYJJXiAZss4afKXjIJPjEFjIsCK2xYEJhUzwPU7oZshcXKYdQl8cITMR9sgVpfzL739Xwx01uoIdWgJG90gCccYLIrkvEbJvqbPFcmI3OT++h6IFST++WqNXXInwI SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2018 16:35:34.0024 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 493454a2-19ba-4c6f-0bb8-08d55e917fb0 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0502MB3806 Subject: [dpdk-dev] [PATCH v3 2/7] ethdev: fix used portid allocation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://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: <https://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Checks
Context | Check | Description |
---|---|---|
ci/checkpatch | success | coding style OK |
ci/Intel-compilation | fail | apply patch file failure |
Commit Message
Matan Azrad
Jan. 18, 2018, 4:35 p.m. UTC
rte_eth_dev_find_free_port() found a free port by state checking.
The state field are in local process memory, so other DPDK processes
may get the same port ID because their local states may be different.
Replace the state checking by the ethdev port name checking,
so, if the name is an empty string the port ID will be detected as
unused.
Fixes: d948f596fee2 ("ethdev: fix port data mismatched in multiple process model")
Cc: stable@dpdk.org
Suggested-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Signed-off-by: Matan Azrad <matan@mellanox.com>
---
lib/librte_ether/rte_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
18/01/2018 17:35, Matan Azrad: > rte_eth_dev_find_free_port() found a free port by state checking. > The state field are in local process memory, so other DPDK processes > may get the same port ID because their local states may be different. > > Replace the state checking by the ethdev port name checking, > so, if the name is an empty string the port ID will be detected as > unused. > > Fixes: d948f596fee2 ("ethdev: fix port data mismatched in multiple process model") > Cc: stable@dpdk.org > > Suggested-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > Signed-off-by: Matan Azrad <matan@mellanox.com> Acked-by: Thomas Monjalon <thomas@monjalon.net>
> -----Original Message----- > From: Matan Azrad [mailto:matan@mellanox.com] > Sent: Thursday, January 18, 2018 4:35 PM > To: Thomas Monjalon <thomas@monjalon.net>; Gaetan Rivet <gaetan.rivet@6wind.com>; Wu, Jingjing <jingjing.wu@intel.com> > Cc: dev@dpdk.org; Neil Horman <nhorman@tuxdriver.com>; Richardson, Bruce <bruce.richardson@intel.com>; Ananyev, Konstantin > <konstantin.ananyev@intel.com>; stable@dpdk.org > Subject: [PATCH v3 2/7] ethdev: fix used portid allocation > > rte_eth_dev_find_free_port() found a free port by state checking. > The state field are in local process memory, so other DPDK processes > may get the same port ID because their local states may be different. > > Replace the state checking by the ethdev port name checking, > so, if the name is an empty string the port ID will be detected as > unused. > > Fixes: d948f596fee2 ("ethdev: fix port data mismatched in multiple process model") > Cc: stable@dpdk.org > > Suggested-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > Signed-off-by: Matan Azrad <matan@mellanox.com> > --- > lib/librte_ether/rte_ethdev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c > index 156231c..5d87f72 100644 > --- a/lib/librte_ether/rte_ethdev.c > +++ b/lib/librte_ether/rte_ethdev.c > @@ -164,7 +164,7 @@ struct rte_eth_dev * > unsigned i; > > for (i = 0; i < RTE_MAX_ETHPORTS; i++) { > - if (rte_eth_devices[i].state == RTE_ETH_DEV_UNUSED) > + if (rte_eth_dev_share_data->data[i].name[0] == '\0') I know it is not really necessary, but I'd keep both (just in case): if (rte_eth_devices[i].state == RTE_ETH_DEV_UNUSED) && rte_eth_dev_share_data->data[i].name[0] == '\0') Aprart from that: Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > return i; > } > return RTE_MAX_ETHPORTS; > -- > 1.8.3.1
Hi Konstantin From: Ananyev, Konstantin, Friday, January 19, 2018 2:40 PM > > -----Original Message----- > > From: Matan Azrad [mailto:matan@mellanox.com] > > Sent: Thursday, January 18, 2018 4:35 PM > > To: Thomas Monjalon <thomas@monjalon.net>; Gaetan Rivet > > <gaetan.rivet@6wind.com>; Wu, Jingjing <jingjing.wu@intel.com> > > Cc: dev@dpdk.org; Neil Horman <nhorman@tuxdriver.com>; Richardson, > > Bruce <bruce.richardson@intel.com>; Ananyev, Konstantin > > <konstantin.ananyev@intel.com>; stable@dpdk.org > > Subject: [PATCH v3 2/7] ethdev: fix used portid allocation > > > > rte_eth_dev_find_free_port() found a free port by state checking. > > The state field are in local process memory, so other DPDK processes > > may get the same port ID because their local states may be different. > > > > Replace the state checking by the ethdev port name checking, so, if > > the name is an empty string the port ID will be detected as unused. > > > > Fixes: d948f596fee2 ("ethdev: fix port data mismatched in multiple > > process model") > > Cc: stable@dpdk.org > > > > Suggested-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > > Signed-off-by: Matan Azrad <matan@mellanox.com> > > --- > > lib/librte_ether/rte_ethdev.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/lib/librte_ether/rte_ethdev.c > > b/lib/librte_ether/rte_ethdev.c index 156231c..5d87f72 100644 > > --- a/lib/librte_ether/rte_ethdev.c > > +++ b/lib/librte_ether/rte_ethdev.c > > @@ -164,7 +164,7 @@ struct rte_eth_dev * > > unsigned i; > > > > for (i = 0; i < RTE_MAX_ETHPORTS; i++) { > > - if (rte_eth_devices[i].state == RTE_ETH_DEV_UNUSED) > > + if (rte_eth_dev_share_data->data[i].name[0] == '\0') > > I know it is not really necessary, but I'd keep both (just in case): > if (rte_eth_devices[i].state == RTE_ETH_DEV_UNUSED) && > rte_eth_dev_share_data->data[i].name[0] == '\0') > Since, as you, I don't think it is necessary, searched again and didn't find reason to that, What's about RTE_ASSERT(rte_eth_devices[i].state == RTE_ETH_DEV_UNUSED); Instead? > Aprart from that: Acked-by: Konstantin Ananyev > <konstantin.ananyev@intel.com> > > > return i; > > } > > return RTE_MAX_ETHPORTS; > > -- > > 1.8.3.1
Hi Matan, > > Hi Konstantin > > From: Ananyev, Konstantin, Friday, January 19, 2018 2:40 PM > > > -----Original Message----- > > > From: Matan Azrad [mailto:matan@mellanox.com] > > > Sent: Thursday, January 18, 2018 4:35 PM > > > To: Thomas Monjalon <thomas@monjalon.net>; Gaetan Rivet > > > <gaetan.rivet@6wind.com>; Wu, Jingjing <jingjing.wu@intel.com> > > > Cc: dev@dpdk.org; Neil Horman <nhorman@tuxdriver.com>; Richardson, > > > Bruce <bruce.richardson@intel.com>; Ananyev, Konstantin > > > <konstantin.ananyev@intel.com>; stable@dpdk.org > > > Subject: [PATCH v3 2/7] ethdev: fix used portid allocation > > > > > > rte_eth_dev_find_free_port() found a free port by state checking. > > > The state field are in local process memory, so other DPDK processes > > > may get the same port ID because their local states may be different. > > > > > > Replace the state checking by the ethdev port name checking, so, if > > > the name is an empty string the port ID will be detected as unused. > > > > > > Fixes: d948f596fee2 ("ethdev: fix port data mismatched in multiple > > > process model") > > > Cc: stable@dpdk.org > > > > > > Suggested-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > > > Signed-off-by: Matan Azrad <matan@mellanox.com> > > > --- > > > lib/librte_ether/rte_ethdev.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/lib/librte_ether/rte_ethdev.c > > > b/lib/librte_ether/rte_ethdev.c index 156231c..5d87f72 100644 > > > --- a/lib/librte_ether/rte_ethdev.c > > > +++ b/lib/librte_ether/rte_ethdev.c > > > @@ -164,7 +164,7 @@ struct rte_eth_dev * > > > unsigned i; > > > > > > for (i = 0; i < RTE_MAX_ETHPORTS; i++) { > > > - if (rte_eth_devices[i].state == RTE_ETH_DEV_UNUSED) > > > + if (rte_eth_dev_share_data->data[i].name[0] == '\0') > > > > I know it is not really necessary, but I'd keep both (just in case): > > if (rte_eth_devices[i].state == RTE_ETH_DEV_UNUSED) && > > rte_eth_dev_share_data->data[i].name[0] == '\0') > > > Since, as you, I don't think it is necessary, searched again and didn't find reason to that, > What's about > RTE_ASSERT(rte_eth_devices[i].state == RTE_ETH_DEV_UNUSED); > Instead? Sounds ok to me. Konstantin > > > Aprart from that: Acked-by: Konstantin Ananyev > > <konstantin.ananyev@intel.com> > > > > > return i; > > > } > > > return RTE_MAX_ETHPORTS; > > > -- > > > 1.8.3.1
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c index 156231c..5d87f72 100644 --- a/lib/librte_ether/rte_ethdev.c +++ b/lib/librte_ether/rte_ethdev.c @@ -164,7 +164,7 @@ struct rte_eth_dev * unsigned i; for (i = 0; i < RTE_MAX_ETHPORTS; i++) { - if (rte_eth_devices[i].state == RTE_ETH_DEV_UNUSED) + if (rte_eth_dev_share_data->data[i].name[0] == '\0') return i; } return RTE_MAX_ETHPORTS;