Message ID | 20180410061631.50301-1-shahafs@mellanox.com (mailing list archive) |
---|---|
State | Accepted, 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 C591A1BA37; Tue, 10 Apr 2018 08:16:53 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0042.outbound.protection.outlook.com [104.47.0.42]) by dpdk.org (Postfix) with ESMTP id 7F08E1B8AD; Tue, 10 Apr 2018 08:16:51 +0200 (CEST) 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=p+O6+XBQrrtxA5JH5Tfs3YwTTg27Afw5UsCagAplxEk=; b=q2KamSWZ1u23BkKi8Y9RqaJvIYhof14QhsywlVJ7zdLg2C4a+moFggUSua6bq3BZuwXLUUkaSKqlEnqkpn1B0luCBFh9a5Jq4fjdBbd9AcTez/+F8lDvzoIe3XaRypmR5voNcgeoo8ptuTPHEzcFgWSnnmJGxjVpGgtlY3iTTHs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=shahafs@mellanox.com; Received: from mellanox.com (141.226.120.58) by VI1PR05MB4431.eurprd05.prod.outlook.com (2603:10a6:803:42::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Tue, 10 Apr 2018 06:16:48 +0000 From: Shahaf Shuler <shahafs@mellanox.com> To: ferruh.yigit@intel.com, thomas@monjalon.net Cc: dev@dpdk.org, stable@dpdk.org, stephen@networkplumber.org, nelio.laranjeiro@6wind.com Date: Tue, 10 Apr 2018 09:16:31 +0300 Message-Id: <20180410061631.50301-1-shahafs@mellanox.com> X-Mailer: git-send-email 2.12.0 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [141.226.120.58] X-ClientProxiedBy: VI1PR0601CA0013.eurprd06.prod.outlook.com (2603:10a6:800:1e::23) To VI1PR05MB4431.eurprd05.prod.outlook.com (2603:10a6:803:42::26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 60da3025-85c9-4769-df0a-08d59eaaa52e X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR05MB4431; X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB4431; 3:hWQmOiwS4H32IEdFM1fvFzkBm/JTYOogEELUHJYL/u1Kd7OirrOMllG6SaX8ytGmfwqBGBLOVncxHNAEwHcgmgx8SJXFESan92SJ9dqHMmHJQrVXNiNaS5XbSQqkYFaq1nxSA4xxNjizLrRlQ9X5THZW6sehkOcboFlnmqpSWXYv5ekvQu36pUvqw03mOWx2Aoj9PB6hyVoP8ya+kqKMA4+tF8Isw4RczQe93OYRByDkSCvSy0PZ4FEH9MK5kGSI; 25:1bvCESbzUax6iYb2dLbHMy6u1BYj5qfVFWwK5bqnwn1h8VK1pJ6vmMSEvd3naReVb2UHGEzTMIgk/nIkiWkBHPPIABwyacM4mD+4Z98jmbgBQDBaG+jZId2g1FQwuzv5gD4V2soa7nN6pq6vrd2U8M9xAiQG+y3HL2GDmaTc9/QbXstUDkfN3mPv3XklNKdQ/QzTeHeSep6gQFil62D1Ws+P5E/hxZE8pKwXleM/PYP/u1gdMcfG5PxLXIohcKqmap+6Ekp2mT+M6Sg3HZQeGZM5ZjDpWcW7pHDRAAtjzaGVbho+zjT+qDVEvUJWRVt2724RsouRh7lFqsW7k27BBA==; 31:6VhMsXSVfoCXUcLq+Fkb44Yyme9ng5UZ6JnPpMGZZGQklYv9E9HKbMytVdZ1HnNzf4yd9TLyJIkrDmPOSgXYrBrBMQuVCUKA9n59JDIbREGwOmCn9efO6lzG+stcnf8k/hJrk1+MgRPONENJgfV9KTHcMc+wYFDkpG7jOOSpl9SH9/EeMIbnP2rT6NCQNr28ihOVbTjWklnIDZivTXbJpAehMhlCtHYVsxf7NuJVCDg= X-MS-TrafficTypeDiagnostic: VI1PR05MB4431: X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB4431; 20:J2O2VMUyibMs/ZGPpKeqkFynnyDEA+DacHfr0dwBdEoG9QCLSef6hMV2eMzW+aZe04G+pOQm3h4cKfavhxc/N4JpN+LULRX3gBylomkGYPzLQ2zZYjA4j4IrTxwzzmiDes9XxDgA3ZLfK02FME1SdNRTdCCDrgBSFX+YMDXUbaqmQFvHyhTC5Rq3CvKTAeDK5nE1eglyGAc8pQyU7OHxgOm3uMf4Oqp986UHLdLmpLkbQxxpoAMO1IBEYGuDrlb0tADyXZY1Srl1hkr+nAbcWqze+bAiMe3E8l2VKZrHNhOo/CVb1WG0vvixW7MYCeN5vm+lJlbTfIw9rl0gYxPDPLYBTQXzbcFq8ShfxTRonb9BnHU4hRaPb7wIGH+TxStThAkt3WrTsl/zWJuxxe/flsTOnevsi+cP1C4ZUR1wAChKWtROX9HSY1C+E+kFo0UErQAyyCpf22orbVW+lFLAm4kvngK1Wum5NCRLgqaScDYePxcfy1sA5RlWHvNNalMS; 4:Ps58lSF8yPxPMjyWumDTurTg/khgNNqxD2/7nfXxPEHt7Sj87SYCIL8q+ywCcXDlYhprvEBixxKlOaZstz13e3maJSdtmSpslR2GdWlLSrdsks/Sy8rKZZd47KqbZ62wdmXfdrjtQHWqZzKyRYJMoaXWwBf+nq5sFtyK8dzaaDQgGesZjqC/sj9Iu3++VDvhs2ZjtSO5Nj56qQQ1cAysePk2ioX92ujInUMhFmhxMP/CxG/7Cxtd6byfLqncPMGds03EcMgGlcmdNGl6joEpyw== X-Microsoft-Antispam-PRVS: <VI1PR05MB44319528867322AB4C4592D0C3BE0@VI1PR05MB4431.eurprd05.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:VI1PR05MB4431; BCL:0; PCL:0; RULEID:; SRVR:VI1PR05MB4431; X-Forefront-PRVS: 0638FD5066 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(979002)(39380400002)(376002)(366004)(39860400002)(396003)(346002)(189003)(199004)(7696005)(69596002)(2616005)(956004)(52116002)(106356001)(51416003)(3846002)(486006)(81156014)(86362001)(105586002)(26005)(476003)(186003)(21086003)(36756003)(16526019)(386003)(6116002)(8936002)(50226002)(97736004)(1076002)(8676002)(478600001)(1857600001)(55016002)(5660300001)(4326008)(48376002)(50466002)(305945005)(53936002)(68736007)(2906002)(25786009)(81166006)(6666003)(59450400001)(316002)(16586007)(66066001)(47776003)(7736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB4431; H:mellanox.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR05MB4431; 23:x0EIayMsHE5TYpMgLKCUXvTHaJFjtcJQXmUe5jAXJ?= aWPqAK08REhQVfFX3wBbvJQ9ovA+j7X8Jp/Lp7yjPX66dE2bvGGNfJE4120kjCm608i7Pvba/9LGwHYO3JKdZGkGKS8hSQ7gqD5WpnD5hf3fevmCgValLVixX1MHS6tVUqyb0XXE7d8sVl5C+A57JK7HWCXcnD7F26vmCkbnx76tdrpdKtkevsfJbjDbefz5eH9FvHlg+8Pt1OuJ461q3N/Qo7We1vo3gOzIQxzIa2NIgbhswEUt4Biujpc+EzwampIWZsFTUr0wxhfMs/5LwpQxddcMgEBc+YiGNqYB7l11+e0qEDmSZzULEmjO9ByIfDI4QpmXkD5tK2fuzJqrKFZsa6myS1gqVrDEUrwaRTsNaxQu3ox/NFc+XSVbL8T6OSJTNfXREfM64YGQ6w8T2Mq62S1eMKC19Yt+ZTmj/SARlA2NILLhyseQ7IJ583Z00NH/hYumeOQcqUVsYkOEgZ6e2HOlgiB8YdGO174WiX3haZff6yiEGjlsPQtRFpYNaTsJDi/pIPw2NwJ7ptX/P28NPzVwAfiTe1oE24qcG0q6DMRlmqaV8kyYhgG+sfAq/gGCY8dYZsJtGGhyPmP9zgF7zKpHvQLvUi6ROqKu8djDNs4Sz+j6ndk5yA4F6VeQUa21H4Co5I6xWA0ujUA7HqIy5xBu3+GpKGHlLJbpmlgLz2lKW6w0SX2E6+tNWit2ii7qezVMC1GN6xHQ3xnbOboE+YLa7w3Vli3lGKHt0vw/LFb3wuAJaviXtWsxIE64fjjaZam9xaGSOS/l0837XS1uE1W5UUuakkLAWv7zBsmpqvwDuMhELgihA5EPkUuYOL8l1yJ6hN0ykgnK5r0rYcCXMpGTyOMTdY939/f8PVhs+kiu03mMY46J11xwTrcN1qGEqIt60HD3/GAcO52QIG+mIiT3KVHk/3MeH0ocEBvrb6/cebribl89GEuvikODlP/1NH5/oY8S3DzxS8cjZEgENpwoofRrQ9DIHde7Xet/LcYeHaK8IL3UnXGl/upGFUUBpbhTOznLJTlLGEubuG94poq7AilSSud2T6V99BDTnhkDlOO/GBLdeKtb0Knzm5r7GUZrh2mph+W3L52sjvcMb1AOoX2PkG661UESYgX7fxOm9wfbaozfiz5qQkXqCfnI8AzWiD62FdAL+kklCByowUaGob12qFauf2Me/xo7Fir/YlZghK/q6LO+h6p96a4Yva73wnMLZVVQaqexhylK6rrirNBGo/EKvG90wnyMw== X-Microsoft-Antispam-Message-Info: MrTQwDd+53aHMpayBQWiKYhyAQiaZxWHASN9fqqIhSLDw60gc+xQNCz6IkSU/dMlHjASdCYsLnI2VlhpWvizSeJY7WZjLzwtRDFLcZMmTuZLsQrHWWjnGHYBuyz2Ya98WUxZ+q6bouFXZBwxcRtIq6usKvkysgfL+9oHEVEIEXP0weboEt/mkH96HnY9OMHj X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB4431; 6:7xkPhA/ETNfUhf9+0wD9TTtE+UAnihM0VJYJDuVThkk4yzU4MOawhR3XwwGM9jKiGqHmJn203RFxrhmHmWUE+9hdq2uIffXgIqp4a/z+wlNpT9CmqdurGNQXbT1VJ2I4jby/cMLLg3+7L74vMIHdirjhymysiz8dc02tdJQmaBjURcyIg1MmtdiYx8rnF3Us24c4Afml3A7rTG2U8pKjmRFF2LYxnNwH+PGUBKuZEDpYS9GdVX1zwwl88bBXY8oznPxtp0DtTULVibRCck8U+B8wG+hODzYEGWoBzZfar/dP4UL0Mrig6w/ZyVBJ8IvmZbReKkwdd0zEUkliuyOT1moJk7taPf8NUc521nQ18FNRmClbXESTgsqP3vywmjDiKxyw24/EH3iDNSLbQ5H837DI5sYjo5297IE1jvSP6//UCqnCGAeXOkFWACUzDfBnS/drUOR+AhlGphlMYD8JlA==; 5:IPIzdWMXH9xWAb8iJAHdjalLPU2qb3Dq/aU4BhpDuo60AcbCMsyqv9mKmX8XGnVelmzp6rnRdEoGLqYdp3sT4CYIh68y3BpaBtpx7Md44lv5Z8xyLigRZYUs5zYTnbLd4mm3+kP6AT1VFtPhWHJM6znjcXcpQH5xNn+8SFucAkQ=; 24:SzvqIffejsU/n+vKv+gvaQVb3tSHrMdSQ/tILbTlZEIRIWf6xh58B2PCnXqetjzweAcW6ofP4HQaMlyJ7XZQ+xiqQA2SaS4nospx/sWerfg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB4431; 7:hqJVlT1LsWVXhJUxzB5gR/J/4VVqSmHiwVpiimt7G9KcT3CHoInN3ENrLITPWrWT48H/i3r2U0jcPd0mVS9OAx0h8pLkxvVp1868/IPVaefpPE/ftIFovYPF82VHt8nMWpZfPHIObZEpF/B3MQEWqv+8zdtClzC9oqcyCSzW+vgkaNCYKsQbCQCb+MRYtfgn0DDV75DXdz4Lc2I6adfZX8HfftIb6h9qw4faMC/54HJfAXapDYD4iFL6U3TpnsT4 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Apr 2018 06:16:48.9015 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 60da3025-85c9-4769-df0a-08d59eaaa52e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB4431 Subject: [dpdk-dev] [PATCH] ethdev: fix link status query 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 | success | Compilation OK |
Commit Message
Shahaf Shuler
April 10, 2018, 6:16 a.m. UTC
When application works with LSC interrupts the ethdev layer skips
the PMD callback and update according to the link status exists on
device data. It is because it assumes the link status on the device data
is the correct one since any link change is processed by the application.
As multiple PMDs install the link status interrupt handler only on port
start and uninstall it on port stop, the link status may be incorrect in
case the query is called after port stop or before port start.
Fixing the query implementation to use the PMD callback for such cases.
Fixes: b77d21cc2364 ("ethdev: add link status get/set helper functions")
Cc: stable@dpdk.org
Cc: stephen@networkplumber.org
Cc: nelio.laranjeiro@6wind.com
Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
---
lib/librte_ether/rte_ethdev.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Comments
On Tue, Apr 10, 2018 at 09:16:31AM +0300, Shahaf Shuler wrote: > When application works with LSC interrupts the ethdev layer skips > the PMD callback and update according to the link status exists on > device data. It is because it assumes the link status on the device data > is the correct one since any link change is processed by the application. > > As multiple PMDs install the link status interrupt handler only on port > start and uninstall it on port stop, the link status may be incorrect in > case the query is called after port stop or before port start. It seems also logical to not process interrupts from stopped device, for them accessing to the link status should always end by calling the devop function. This patch is the result of discussion on thread [1]. > Fixing the query implementation to use the PMD callback for such cases. > > Fixes: b77d21cc2364 ("ethdev: add link status get/set helper functions") > Cc: stable@dpdk.org > Cc: stephen@networkplumber.org > Cc: nelio.laranjeiro@6wind.com Acked-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com> > Signed-off-by: Shahaf Shuler <shahafs@mellanox.com> > --- > lib/librte_ether/rte_ethdev.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c > index 2c74f7e049..0857670ebe 100644 > --- a/lib/librte_ether/rte_ethdev.c > +++ b/lib/librte_ether/rte_ethdev.c > @@ -1789,7 +1789,8 @@ rte_eth_link_get(uint16_t port_id, struct rte_eth_link *eth_link) > RTE_ETH_VALID_PORTID_OR_RET(port_id); > dev = &rte_eth_devices[port_id]; > > - if (dev->data->dev_conf.intr_conf.lsc) > + if (dev->data->dev_conf.intr_conf.lsc && > + dev->data->dev_started) > rte_eth_linkstatus_get(dev, eth_link); > else { > RTE_FUNC_PTR_OR_RET(*dev->dev_ops->link_update); > @@ -1806,7 +1807,8 @@ rte_eth_link_get_nowait(uint16_t port_id, struct rte_eth_link *eth_link) > RTE_ETH_VALID_PORTID_OR_RET(port_id); > dev = &rte_eth_devices[port_id]; > > - if (dev->data->dev_conf.intr_conf.lsc) > + if (dev->data->dev_conf.intr_conf.lsc && > + dev->data->dev_started) > rte_eth_linkstatus_get(dev, eth_link); > else { > RTE_FUNC_PTR_OR_RET(*dev->dev_ops->link_update); > -- > 2.12.0 > Thanks, [1] https://dpdk.org/ml/archives/dev/2018-April/094788.html
10/04/2018 10:20, Nélio Laranjeiro: > On Tue, Apr 10, 2018 at 09:16:31AM +0300, Shahaf Shuler wrote: > > When application works with LSC interrupts the ethdev layer skips > > the PMD callback and update according to the link status exists on > > device data. It is because it assumes the link status on the device data > > is the correct one since any link change is processed by the application. > > > > As multiple PMDs install the link status interrupt handler only on port > > start and uninstall it on port stop, the link status may be incorrect in > > case the query is called after port stop or before port start. > > It seems also logical to not process interrupts from stopped device, > for them accessing to the link status should always end by calling the > devop function. > > This patch is the result of discussion on thread [1]. > > > Fixing the query implementation to use the PMD callback for such cases. > > > > Fixes: b77d21cc2364 ("ethdev: add link status get/set helper functions") > > Cc: stable@dpdk.org > > Cc: stephen@networkplumber.org > > Cc: nelio.laranjeiro@6wind.com > > Acked-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com> > > > Signed-off-by: Shahaf Shuler <shahafs@mellanox.com> Looks OK Acked-by: Thomas Monjalon <thomas@monjalon.net>
On 4/10/2018 9:29 AM, Thomas Monjalon wrote: > 10/04/2018 10:20, Nélio Laranjeiro: >> On Tue, Apr 10, 2018 at 09:16:31AM +0300, Shahaf Shuler wrote: >>> When application works with LSC interrupts the ethdev layer skips >>> the PMD callback and update according to the link status exists on >>> device data. It is because it assumes the link status on the device data >>> is the correct one since any link change is processed by the application. >>> >>> As multiple PMDs install the link status interrupt handler only on port >>> start and uninstall it on port stop, the link status may be incorrect in >>> case the query is called after port stop or before port start. >> >> It seems also logical to not process interrupts from stopped device, >> for them accessing to the link status should always end by calling the >> devop function. >> >> This patch is the result of discussion on thread [1]. >> >>> Fixing the query implementation to use the PMD callback for such cases. >>> >>> Fixes: b77d21cc2364 ("ethdev: add link status get/set helper functions") >>> Cc: stable@dpdk.org >>> Cc: stephen@networkplumber.org >>> Cc: nelio.laranjeiro@6wind.com >> >> Acked-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com> >> >>> Signed-off-by: Shahaf Shuler <shahafs@mellanox.com> > > Looks OK > > Acked-by: Thomas Monjalon <thomas@monjalon.net> Applied to dpdk-next-net/master, thanks.
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c index 2c74f7e049..0857670ebe 100644 --- a/lib/librte_ether/rte_ethdev.c +++ b/lib/librte_ether/rte_ethdev.c @@ -1789,7 +1789,8 @@ rte_eth_link_get(uint16_t port_id, struct rte_eth_link *eth_link) RTE_ETH_VALID_PORTID_OR_RET(port_id); dev = &rte_eth_devices[port_id]; - if (dev->data->dev_conf.intr_conf.lsc) + if (dev->data->dev_conf.intr_conf.lsc && + dev->data->dev_started) rte_eth_linkstatus_get(dev, eth_link); else { RTE_FUNC_PTR_OR_RET(*dev->dev_ops->link_update); @@ -1806,7 +1807,8 @@ rte_eth_link_get_nowait(uint16_t port_id, struct rte_eth_link *eth_link) RTE_ETH_VALID_PORTID_OR_RET(port_id); dev = &rte_eth_devices[port_id]; - if (dev->data->dev_conf.intr_conf.lsc) + if (dev->data->dev_conf.intr_conf.lsc && + dev->data->dev_started) rte_eth_linkstatus_get(dev, eth_link); else { RTE_FUNC_PTR_OR_RET(*dev->dev_ops->link_update);