From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0047.outbound.protection.outlook.com [104.47.2.47]) by dpdk.org (Postfix) with ESMTP id 966115F5B; Wed, 14 Mar 2018 18:41:15 +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=fZguvnWrapb+VCqOisDTkMNNFcr6/y2ivj41wWAnnXY=; b=KP11OBZ4ESd5GrlbVzCIBkPOWi/ZkHCQ+XiMLWBTtdJHtGsPNYd30weKWRUbdJbkaIXNmIumBlEO6R+ZuQhQfofoLKAksv2kQrnaM6noPNGS45qVWFsj5EMlQ9apmr2vkxSQDZk/rytjzCkQ8tfV6hN+l+sRQMljliKQL4XeYmg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; Received: from yongseok-MBP.local (209.116.155.178) by VI1PR0501MB2045.eurprd05.prod.outlook.com (2603:10a6:800:36::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Wed, 14 Mar 2018 17:41:11 +0000 Date: Wed, 14 Mar 2018 10:40:59 -0700 From: Yongseok Koh To: Adrien Mazarguil , Nelio Laranjeiro Cc: dev@dpdk.org, shahafs@mellanox.com, stable@dpdk.org Message-ID: <20180314174058.GA31022@yongseok-MBP.local> References: <21fb91002768a627d9c7f3d81e0c8a12fbf6811f.1518684427.git.nelio.laranjeiro@6wind.com> <20180313215443.GB26229@yongseok-MBP.local> <20180314121856.GK3994@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180314121856.GK3994@6wind.com> User-Agent: Mutt/1.9.3 (2018-01-21) X-Originating-IP: [209.116.155.178] X-ClientProxiedBy: CO2PR05CA0100.namprd05.prod.outlook.com (2603:10b6:104:1::26) To VI1PR0501MB2045.eurprd05.prod.outlook.com (2603:10a6:800:36::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 83f065df-b51d-4bc5-9c44-08d589d2c7cb X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0501MB2045; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0501MB2045; 3:hVQIMm9rwBCxPrK5aaFI7DHZUyWSOR2LXIlyXGDCfAqHus5qoxArjubnYVxE7Gc/R+qbNyNhkaqaHxzBhvs9Ur9kQ/wm1p4/Y04NrFlZK5bbs2EoE398yV2g23exj1eyoAfKLS3A8NR5EJAcPsVP4mWAHWb6/U2JxO4WzS8pG2O29uiUrG38VWrrCRyg0A45FYrSOTrOCkGz/yZiUHuE03yO1g0Gq2ObU2UEoLR54UtvbMjm7onop9wxoRndhPlu; 25:mm+K2ENXXO/5/RkmQpPLpLkdsaCckYgeedEZ+BKxQSSOp9ypESyDorLlYqoAHysZPT2qGkELnsYrlnaOA1VgOhAdu5IdorP2uxx9uYFOjt+V/DAFIWlVpths1JLcj0Dc9NY1NW9hi2QfEHNzdPe11vkcj7KKuaFwCZi72+Lm+5/fwJcZeLSgZSmMoPVJmujhHZZz90T58PKaWUOZIrLVJf6Taon9zNHVGtz/LqxjzZE5Wz35uOzHgUy8d6iQ4cS4vh9wQ8+aRABARt/TayH0BdaSPrBUGNacvBgEYyL0QdaJNhfPgaYLpIBnGwXfBiNeOrQX9trQ0OC1r8c5ea96Gw==; 31:AauvWd4sw6HPzJONGwXAjKEr3Ohvm7PYoPpXytUOEJpgITU1Fo8Sczc9d/5d5FSp/EVZrVFAtuhR+srp0xL8DDcQucffpLztu2gxxh+bU/MgcjyiKhVx2yTbaJR8/yXO9Ih3csqdMXgQx3c85Kjkzgo4kOO0Oyx9IPLUgkxg6YIVkaa38fWZjVIpPZwtx1wO3LEBMYjknB/VKp5bM5zDzp/arehop/ibcQ5/HcoWEMI= X-MS-TrafficTypeDiagnostic: VI1PR0501MB2045: X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; VI1PR0501MB2045; 20:+WJS0jmblehOfp6CL+o3ZGwq2dS1ftzDLCO1OHvFU4kW+wn8AOvPQbC1p7qg/KyBF5yG+8SN0111FPJjtrip3mTY6VIDKRSCSbgVlEqICi1TGFzc62oEcgHgWgZ3F93FHVIDCveXnx8MSx205PMs3nT7jEqaylMMZqkRCK0HSn1QGF3ByRuYJw/YFzLKyyBsZyu5KUVZD8R3UxvVWcLO8Sj5WifCvjGAJTJ8oz3GTggg+9D+6MxRo4A4tO/Bg2lklPsgW56/QxbUS6RatelbZVdbqG9RcgJA9fC/UySNvDAN9XbHCiyyEjSQH+HQaBjg0DpsuT2fmejrJbV5hkxeXFp307wkX/4HbaxMQ1FfyE+2yoO3tSDVMk76XEaCGMFj8Aq7r9irh7DmC1B2y5I/mAoLFtQHUGkD6+692GXdc5opNRLnlBc7dBU2Gaud27oGKiV2IPHhXB+VgO7FMUGFyhQi7PVVShq7YuJGj3Vjxc4TPvGmFzeJjCwSzl4luLN1; 4:EHxXdpZABEXxFE5SyVEJsYhg2rZ7W9Rk7gg0unhakHfn+dk4Xn42Ih5eIeI51acH3xDZ8K7pcswFzy3Grvi4VKsUK5h+wGUE5y88nheMEFTu4e5dpgMxl/Mg4akmWxuNujzFD2FleRbuxdWnb0wGhOUD/AoNqv/szZ1KLY5zMZuDCNBfs72m5LM6X/Dz97+dM80IvGjO7NTAcH5wq6m5yap+OsSi/DWejfTOLJ6/kIcXC226ABagU41niG5WoTVZbHnP8Z2U65idG7hatfChkAY9XkvpdPdQgkqvjAPWiwt8s6XUEXnabZMROP4FANZHrebQjDXpzabuUvJGD+MFibvyL7fJAkNDzu9UAmcsgUnPN+PwnzU2/ry60Y2Tdvxp X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(189930954265078)(45079756050767); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231221)(944501244)(52105095)(93006095)(93001095)(6055026)(6041310)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0501MB2045; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0501MB2045; X-Forefront-PRVS: 0611A21987 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(396003)(39830400003)(366004)(376002)(189003)(199004)(6506007)(9686003)(386003)(6306002)(45080400002)(16526019)(55016002)(8936002)(186003)(6246003)(97736004)(53936002)(59450400001)(229853002)(93886005)(66066001)(47776003)(25786009)(16586007)(26005)(4326008)(316002)(52116002)(575784001)(305945005)(105586002)(76176011)(966005)(7696005)(2950100002)(58126008)(6666003)(33896004)(7736002)(68736007)(110136005)(478600001)(5660300001)(2906002)(50466002)(33656002)(86362001)(8676002)(81156014)(81166006)(3846002)(98436002)(106356001)(6116002)(1076002)(23726003)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0501MB2045; H:yongseok-MBP.local; 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; VI1PR0501MB2045; 23:OR0eZFYjhPMVxL06QX4e/2DMeCMBuaa+Cf77AmN?= =?us-ascii?Q?DFsUSPoAmAlnp71oKYOqMYnoUw2E8aliGvdRe+SuNi8sMJc4uPy8HKlwO/TW?= =?us-ascii?Q?8x+YRDm+yQQFF9PvmafR8v9H/LSmFna1CcKeKBMla2Ellflt4g3U50yMpR9V?= =?us-ascii?Q?GR/x56VkEXCNJpth4zzMKnyZncThv4boEx15Z7jKT+clxty8MBTzIEo6BmEk?= =?us-ascii?Q?U5yszLkVqTKfQi0IWUd5wgovcZJtQv9Dbu+CKtsbtPq/BqfYCKF6WEcvxYDG?= =?us-ascii?Q?hdu92bYR84y/KgZ0hWWHplm8nPgRF8tOdolIekR2lojOxUfcgKfjc0Wav5gK?= =?us-ascii?Q?IAJOl9YGdO2pGrCpXp1Ue/bZwrSjmWgdgJG0lwZvhgdBcx8pIuPaXKycsMdH?= =?us-ascii?Q?QqhVY7uVs8/klVnn7R39WWC1TykVva7QN9pW3h8PDhiMh/Ko8rmr7roxCF1X?= =?us-ascii?Q?giyX5ACvdrydSI8zTPGX69ob6FSr45eQK7a6qlt70rcPaXQ78yfeKGwzghXM?= =?us-ascii?Q?b1cuxbEiald6Uf+LiKz7XjaLP46WbCGHWzne/M4iGHtoH8+kudTKA20qAapG?= =?us-ascii?Q?hwoc49mN4hCB0fVP/vTdXR5IMCIhkvwsE8LyuTl2s6hgyI64gY+eFsoeepmD?= =?us-ascii?Q?h0byfLTdUs5nSxSRvUpJPcc9n5RSzvNrP7glhfxmNjEaf8DnG5SO0gfjyfEg?= =?us-ascii?Q?HLRoElblfnJNafwzka/2rIakmA0BNVXi20caPnIl04oqqFWUOrNqWpvva03S?= =?us-ascii?Q?zSE4hYE+/N43bpwJ5aUsrMc/snwbJFNEyW3fpONHjz2u8fgNyBEKbSRtn56d?= =?us-ascii?Q?aLJNyWTSCFUOAlLUgpCy59rWK5LK4hhq1T3LCVaGTRBzgf+Oh6C41OOJ3oAH?= =?us-ascii?Q?lIIrWawN5xYjrJVE5RjUpXQGnitDvYl+KXmRGOAgZODv4EQuFaZNCapQVhvQ?= =?us-ascii?Q?08Sy0anbh0uvOI63uHL+ct/l95CYAhhdA/xo+FVK4LBSkW8Qd9NRP2dtvj0R?= =?us-ascii?Q?HKRC4Wwo4kyricyO6NPCY/ixeXyAwjuEP8tj/2sRDXjtdeneLVl5JTlrrGI+?= =?us-ascii?Q?VU4axJSLNDb3p3NyOEWPngYeZCDRaongyncRvfZMpypMvjhr2/7ADyuuUTh+?= =?us-ascii?Q?0g/mt/W2cHR1madohTt6LT0GFE67vdcZH7Yc9JGF5mpccDNyJxyDWzQO2dkN?= =?us-ascii?Q?m1dCxEnyo1sXtEYUBAHPCk+ew/yGVrfNE8R+pNC5sPiCgIhM/q8YG5JLDAcF?= =?us-ascii?Q?Moa9cl/G/8zdSbUNIsdtuuF5brz+/9u1QGFXRFiHIE+iIriM00GAQZalRh+l?= =?us-ascii?Q?PvKR+k6EBwks8jGqc7augTD9EqGen1LMDmCl9FQOEFF1BWILh+zjEtVw0ryz?= =?us-ascii?Q?RcUKeEw=3D=3D?= X-Microsoft-Antispam-Message-Info: RsADU8EpAvRLSiobf8gdXOmHrIgjan5QqMgoUibDFy0AmdZAxjZ3R7cI1jjS0ku/VCVwc0r62Xohq4OAoN9+0Yge/z9QZC2uBVF9Q8wZzZPtXkESE0ftFVRdJWplmkWxyA6441DM0Vu0D71FP5OyOd6jPCC66MQ+HbsKwEZoeftatxqyK+e0lUHKYfASbtyN X-Microsoft-Exchange-Diagnostics: 1; VI1PR0501MB2045; 6:aXW6WNgb2jtmZBJbzLP2rXLQl/cgwxRCC8Rg/8gw+FrjrefLv8zMNShlopi4qCuLk2clWQctlZh3e5Ye5AUTeJZXAscTifmq+IBSEa+EJmmJkTwZfX+R/nxTv7uTSlJmNBZxoYj0wDO3KEcxsaW7os3IRZC5ZoHZ0yBi8OzXA5PN/cAyGEq9uOIULE3caYx6tfj1mzEXxAbRT2Orm4AkTtknoF0Ar2TdwCsHxhg3/cvkkRwEVSYZoamZs3A7tjwoksjzzYHHvI1xW3YeSbo0Tl+Un5JlZsVYAOrYa4gslkIi1LMXE+tpK+Lp+CP3iHx13RayY/Z0ErBlLFQD2l6r850ZqlkXXayGIgJFz51+XRg=; 5:bxY3lhwfHcTYLm28x+c/QQ0DMRCuthjZGBh3bhbWV2MKQfqDAfqKXlN817FiwmAWQs9YGFXWryJoQCcDa1I4d5S/u0gUIumwXfQUjxhtKn7A8dULJxAjkWuTXkqiqPwhrC2TLGXxTtvb3wUmXYaqeADpOe54ZRsCsCKT924y5co=; 24:94a7c2fpPKu7e0+J7Cq+smzEJHOcHm3L7D6HFqvP6c+PRg/HU2kQ7BwvxDkBu0EzDxKxS0b3w9azZd2UHez6JY07gULGcbGfqs4eR7jcpko=; 7:gJ4UIXFAQcwRejIQzW2rGmMJOZww7+Ug0/q0x2G4aPGK2RQ2XFcM4MEvmAUx3Qu/gcl+Dg1BwtPrRA9+lbOCgX/WsDeI6u6WifF8apEx9nx0q5wC3Xzo4KzyNnMLRilxNNRmv1ELofClbGic1tIA1lUgNAOq6pZogt+TaCs5tOQvO7ftKPBtoaO+BA9Lf1Jlwfz4rretWKf4CyaTGqCJdMov4B4/TDzUzVmPt6SrPT5MZcSB1v/nhwETy1pD4FhQ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2018 17:41:11.8127 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 83f065df-b51d-4bc5-9c44-08d589d2c7cb X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0501MB2045 Subject: Re: [dpdk-dev] [PATCH v2 2/3] net/mlx5: fix link status behavior X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 17:41:15 -0000 On Wed, Mar 14, 2018 at 01:18:56PM +0100, Adrien Mazarguil wrote: > On Tue, Mar 13, 2018 at 02:54:44PM -0700, Yongseok Koh wrote: > > On Mon, Mar 12, 2018 at 02:43:18PM +0100, Nelio Laranjeiro wrote: > > > This behavior is mixed between what should be handled by the application > > > and what is under PMD responsibility. > > > > > > According to DPDK API: > > > - link_update() should only query the link status [1] > > > - link_set_{up,down}() should only set the link to the according status [1] > > > - dev_{start,stop}() should enable/disable traffic reception/emission [2] > > > > The description of rte_eth_dev_set_link_up() is [1] : > > The device rx/tx functionality will be disabled if success, and it can > > be re-enabled with a call to rte_eth_dev_set_link_up() > > > > This means, if user runs "set link-down port 0" on testpmd, traffic should stop > > by disabling Rx/Tx on device. But unfortunately, mlx5 doesn't have a way to stop > > device but it rather relies on kernel implementation - e.g. SIOCSIFFLAGS. So, > > even if the command is run, traffic goes on. I guess the original > > implementation might be needed to workaround this situation. > > > > Shall we talk to HW and driver people regarding how to access dev (or PHY) from > > user-level? > > > > [1] https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpdk.org%2Fdoc%2Fapi%2Frte__ethdev_8h.html%23a51d7a0d2bb4202f9ebf9f174ba1f6e5c&data=02%7C01%7Cyskoh%40mellanox.com%7C346b9914b7664dcf0e7008d589a5cb53%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636566267555398866&sdata=Ad1%2FyQqyXeifXFJjxMMRxq81YGpF7nEFHvaX28nncl8%3D&reserved=0 > > As you mentioned, since the mlx5 PMD doesn't really own the device, it > doesn't have the final say on whether traffic still flows after putting the > link down at the DPDK level. It has been worked around by replacing burst > callbacks with no-ops since up/down ethops were added [3]. > > Problem is that updating burst callback pointers while traffic is flowing > has always been more or less unsafe. It's not necessarily atomic and only > really safe to do when traffic is guaranteed to be stopped (i.e. after > dev_stop() was called by the application). Moreover these no-ops don't > prevent device RX queues from still getting filled up. > > Looking at the original implementation [4][5], other PMDs simply have to > turn off the laser or some such which doesn't prevent RX/TX functions from > working as before except traffic happens to be lost instead of ending up > rejected by dedicated burst callbacks. > > The main purpose of up/down callbacks and the reason they were implemented > in mlx5 is that customers want to see something happen at the carrier level > on the remote end (as with other PMDs) when a DPDK port is brought up or > down. This is why they are seldom implemented in other PMDs for VF > eth_dev_ops given those can't control PHY. > > Actively preventing traffic is secondary and either has a performance impact > (permanent status check in the data plane) or is somewhat unsafe (live > replacement of burst callbacks). > > Given the above, I'm in favor of removing the no-ops. Applications are the > ones performing up/down calls, they manage the administrative status of > interfaces and should refrain from calling TX/RX burst functions > afterward. Carrier status is left to PMDs and can't necessarily be modified. > > [3] 62072098b54e ("mlx5: support setting link up or down") > [4] 915e67837586 ("ethdev: API for link up and down") > [5] c38f4f83edc0 ("ixgbe: link up and down") Adrien, Nelio Please don't get me wrong. I didn't mean to defend the status quo. I didn't like the null burst function either since I firstly joined this project. I was just mentioning it was anyway non-compliant to the document and suggesting to find out a better way if any, e.g. accessing PHY. Even if you don't think it is a critical matter, there's no need to change the kernel flag and we just can make dev_set_link_down/up() return without doing anything. If we can't/don't change carrier status in the functions and those funcs have no effect, how about not changing the kernel interface flag? Or, if you still insist no change is needed in this patch, that is also fine to me as this isn't a critical path and doesn't have any erroneous behavior. Thanks, Yongseok