From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F32CAA00BE for ; Tue, 3 May 2022 21:04:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E40DE427F4; Tue, 3 May 2022 21:04:47 +0200 (CEST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2044.outbound.protection.outlook.com [40.107.243.44]) by mails.dpdk.org (Postfix) with ESMTP id 97B5F40C35; Tue, 3 May 2022 21:04:44 +0200 (CEST) ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=KJ1yyBQ1SXM6npXCILGpZiiHHZjBv9rlIM9FFk4lNV2SJU+SMm0G4tpUqWOcKLD0nzgqnF9Y9vi1hlt+iJCrSx7ULN30mW01E4/hM6CZwYI6nkJ34fk3/YWsH9PWfleYtzDnINT4iO8pI26489hAlZqfWADEo+TOEX04AE9DSeniLQJGV38UYiO/26vkAYon4KHCrupKi1IQvQUy7Ypy6vWeVGql8Bz21xy2kTVmhu6Hr2VUqTVlnNKua3P3qJGFOLNmtOVlBnswXMe3d4BAmf5u/ImVMWPdBgLWiS+BedfxlGI10iv6DiQzilJ254y4oApselZMAjUFGylWg86b2A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hqd0bJ8AuMEXI4pFIWcLJKOFVjWjz20/rZi/JBHRQtk=; b=nua0ZIH7VVPdjOsQ2PRjqwS/4JByLItebK2g3tGePOx8RH/xFo/6TN84pkzcpRBHOMR8nsDVMWPZ9HEpjNvtKMasYAUzxi0doMmAuBZcOOpBoiqslol75zuCWCBohkbSUw8Zo7fmoefECIdB+DdxEsVIezkzlyV7dh6j7EYw1GiQX6LHeIYW+1giHvMnZKoZL7ZmIVrNUp5qDjhxr52vby4tFZtK5Y81t6ulIa3x9kAmOUruQxpoM9Y8joFjuzvZlEO6pKNpz/1MuiJF1i4Adk2f3RMnbZwEnXAWJedVEVGKmmwKeHrys4P431Z1uaSyqDMakwi+8IJh5HI5lZcWwA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 20.83.241.18) smtp.rcpttodomain=att.com smtp.mailfrom=xilinx.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=xilinx.com; dkim=none (message not signed); arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=xilinx.com] dmarc=[1,1,header.from=xilinx.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hqd0bJ8AuMEXI4pFIWcLJKOFVjWjz20/rZi/JBHRQtk=; b=CmnXqw228+hCdbg4A00V6SXSvatw9fhZMZFWiC+7g1y2eRqrrEG0J0iujKDGMdGEIXTMMvqaeLKACcfOvyAExZ17iLpwBSjtWs0gQ5BHsTaAstDqN3k/pjhSmpP0F64YY2xwF9Ig4RfKf20shw/Vpp5csoOG5zCyF8SZcu5Lqy4= Received: from BN9PR03CA0854.namprd03.prod.outlook.com (2603:10b6:408:13d::19) by MW4PR02MB7393.namprd02.prod.outlook.com (2603:10b6:303:7c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.24; Tue, 3 May 2022 19:04:42 +0000 Received: from BN1NAM02FT033.eop-nam02.prod.protection.outlook.com (2603:10b6:408:13d:cafe::e9) by BN9PR03CA0854.outlook.office365.com (2603:10b6:408:13d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.13 via Frontend Transport; Tue, 3 May 2022 19:04:42 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 20.83.241.18) smtp.mailfrom=xilinx.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=xilinx.com; Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates 20.83.241.18 as permitted sender) receiver=protection.outlook.com; client-ip=20.83.241.18; helo=mailrelay000000.14r1f435wfvunndds3vy4cdalc.xx.internal.cloudapp.net; Received: from mailrelay000000.14r1f435wfvunndds3vy4cdalc.xx.internal.cloudapp.net (20.83.241.18) by BN1NAM02FT033.mail.protection.outlook.com (10.13.3.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.12 via Frontend Transport; Tue, 3 May 2022 19:04:42 +0000 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam08lp2049.outbound.protection.outlook.com [104.47.74.49]) by mailrelay000000.14r1f435wfvunndds3vy4cdalc.xx.internal.cloudapp.net (Postfix) with ESMTPS id 4988641F77; Tue, 3 May 2022 19:04:41 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rt8dJtwTAP0P5KqEU4Zbyl2pu3fyzFZgDOHu8NzWA/R1aaRob8KS/PV+sQvRF0nAlDLEG+9tdHLzOVuxAnOzmtuTxx08rZ96oaovx3/P0qqyMa8FHybTmhSgYic20ZPynRwuhdk1S6P7Dgy3Ixz2aVTq39o9/ubCinLjVuIm+t6K2lkRWK1CuU/pn3JZL3TFMAcwHpXPBZJE7ZR/yT/4I35Xv8VgphiHa+IQ6bsNPAjQXO19u/HFI27LDwuX5hqJb1VZDwCEVmJeibvBhG0D+bCUgPW81Ehj01TXnd7LQLSDs0T946Oyi7zfb5JVRmSUsw7Fd19A+YFIfdl0m2zwlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hqd0bJ8AuMEXI4pFIWcLJKOFVjWjz20/rZi/JBHRQtk=; b=m/KSiG3UWdm/GcWX6+PelPW2mwMjrc1vkPs4nYnZeAYiOOAtDXCrkCYPRURqJQP+pOb7DqSeZP6E5hHTxCWDci6clQzTv6U7gYd033IR9+Bbr5byr6KOcKJm15RdtbCmSCKb5ymnvVskFOcZ/6dYozUjnsMaQptaHKJhnh++TeKXt+T8bFQ1q4/o2UoTWhQRrp6SoLjIfYzRyNZ40DYfOvGq22o5RO7bHDipr+lh7p/9J1fnL3cEl9EwjQ68IH+LOW0n/gl5btfzWBZRG/3Ay9WOva1qQWgNQrsQE7CdorSLbaNQ8FVxM/SfRg6cu4hdTzMKpsoc4ubtRItnG1OKvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 149.199.80.198) smtp.rcpttodomain=huawei.com smtp.mailfrom=xilinx.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=xilinx.com; dkim=none (message not signed); arc=none Received: from BN9PR03CA0156.namprd03.prod.outlook.com (2603:10b6:408:f4::11) by BY5PR02MB6290.namprd02.prod.outlook.com (2603:10b6:a03:1b1::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.12; Tue, 3 May 2022 19:04:38 +0000 Received: from BN1NAM02FT035.eop-nam02.prod.protection.outlook.com (2603:10b6:408:f4:cafe::17) by BN9PR03CA0156.outlook.office365.com (2603:10b6:408:f4::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.24 via Frontend Transport; Tue, 3 May 2022 19:04:37 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 149.199.80.198) smtp.mailfrom=xilinx.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=xilinx.com; Received: from xir-pvapexch01.xlnx.xilinx.com (149.199.80.198) by BN1NAM02FT035.mail.protection.outlook.com (10.13.2.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5227.15 via Frontend Transport; Tue, 3 May 2022 19:04:36 +0000 Received: from xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) by xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Tue, 3 May 2022 20:04:35 +0100 Received: from smtp.xilinx.com (172.21.105.197) by xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) with Microsoft SMTP Server id 15.1.2176.14 via Frontend Transport; Tue, 3 May 2022 20:04:35 +0100 Envelope-to: humin29@huawei.com, dev@dpdk.org, lihuisong@huawei.com, stable@dpdk.org, chas3@att.com, radu.nicolau@intel.com, arybchenko@solarflare.com, thomas@monjalon.net Received: from [10.71.119.91] (port=40213) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1nlxp5-0005b3-26; Tue, 03 May 2022 20:04:35 +0100 Message-ID: <0b879860-1465-4bd2-a15a-530306202586@xilinx.com> Date: Tue, 3 May 2022 20:04:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH V2 1/4] net/bonding: fix non-active slaves aren't stopped Content-Language: en-US To: "Min Hu (Connor)" , CC: Huisong Li , , Chas Williams , Radu Nicolau , Andrew Rybchenko , Thomas Monjalon References: <20211025063922.34066-1-humin29@huawei.com> <20220324030036.4761-1-humin29@huawei.com> <20220324030036.4761-2-humin29@huawei.com> <212e85ef-228a-d31e-e5a1-8b2331c7eef9@xilinx.com> <447752cb-d01b-df08-b5b9-0d331a20bf26@huawei.com> From: Ferruh Yigit In-Reply-To: <447752cb-d01b-df08-b5b9-0d331a20bf26@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 1 X-MS-Office365-Filtering-Correlation-Id: 53ec33ad-434e-41d3-d13f-08da2d37c7a3 X-MS-TrafficTypeDiagnostic: BY5PR02MB6290:EE_|BN1NAM02FT033:EE_|MW4PR02MB7393:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: IyPXTRffCeL6yG9XcJUKMTFfHsPHmG3pTIK+KLr5NIyJtBrmUosarQ9UKQJwWPljYlhYXHbthSuoIcDQAkCSEK455wXt2mYz04pJ4MWLyb/GDzp411S34jyFMbAaze/W+yji2VcWhtz6aMv2QAvaTuDFQQ6CMjjoAfIXhmzQAOTtnnRNNviciELYSyYq61ItdS+jzCvul0GHjHJUACGivjf3yZsd3+TDWnkwwI8EK3R+r9ogFP7LY5Kz05C3FRjaInvkVjz10ofnD9rqR2TuMeSRj4wPgjDUAVr6M4LTe2jkhMeWLEAGoPYPLxuxU1g0Yfm05ye6FpjhnViDGBrkKcxpRb1Lu0lXk7JWaqHkVSXA16/urYeu3JHSArn/IGlCofpnW9ZbmOaujgmO2Fz1naBK9oOSySY6JbxgK8yP/j06i98CkO0VQaxnzAMdDRs+rfIB8kosh7cra8IEPv1FdRpx8kJ2jWXUu476tavTG4+6387I0zmF0SJIlHtIgOiiq3vc1FLfzpJIeetf/rBWjApJPN7ggCdUY1dHYGl8U4SEYvfFO2TQhLosohhFDd6JYXzS2kY4jT7cxvl6ACn/uM9z+2p0ssl5lIHgHhCcl+/Pg704GmQz1DxSCwarguZykfNNPKmJXgTYIftNoyc5AAWy5xRuzEZGIbzA4l8LQExgzmGKP1oUHIYAxIN7LIwtxM7MniQZKlzdYudm8T5O47RHWybl6/nc3pxuuTzD5y0= X-Forefront-Antispam-Report-Untrusted: CIP:149.199.80.198; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:xir-pvapexch01.xlnx.xilinx.com; PTR:unknown-80-198.xilinx.com; CAT:NONE; SFS:(13230001)(4636009)(36840700001)(46966006)(40470700004)(40460700003)(36756003)(47076005)(336012)(426003)(36860700001)(356005)(54906003)(110136005)(508600001)(186003)(4326008)(31696002)(2616005)(70206006)(70586007)(5660300002)(8676002)(7636003)(44832011)(316002)(2906002)(31686004)(26005)(83380400001)(82310400005)(53546011)(9786002)(8936002)(50156003)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR02MB6290 X-MS-Exchange-Transport-CrossTenantHeadersStripped: BN1NAM02FT033.eop-nam02.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 0e8d477e-5a89-422b-4d09-08da2d37c45b X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rMzBhF2hvrcrvC0Kx4PFMaSV/p63CB6XdBHNv5peNLhRGGf2EPPQVgsmsPU+S7H9fJU9wwQcLSirab6EzzKlFrp82VY4e+I7e2/Jwa51SY6H+hGgFw0GJm6k+0MLg0FYH83FCp5Y88WL0dbroXbwCAFISRxqrrdJloy/QdTeOT2mwAZYuug0t3gMsnA+sISGF1pNSudauDBC6j+bqCx6QV6r33BcPAojIsIsY31EanIvQ1Jpsrw18/5U66IhmQrzl43plYAszRo2JakPs67nDAgdeyVWwn7XTQRbvlYJEx0us1WWcOYH7Pf15MHdL14y3E0jijqpvG5tQelU7BfuDv2/0GlmHg5ky6Rqdo1ySIvbyoLlEec36thoQXMA4JVJzdYHmVMev1rjRk9iPHkfwa2FW9Rguf2mlP8WwjrVUC9sZPP4tSgzXYMV6FXriwu8VewHQq+3kRYa+OrEom/FBKZWwv8g0DgSWj2ZoaYptAZhySJRGS/6i4JTCK/MdvjyI0JfYK0gJBx2uBr2MxVrc6hUOf22KQEXnBnjZ/eaEEDOWCpVj6QCN7zJtLT+vOBtVPXFFYiH5D1gHV66mxJ3rcLJPaI6glYAFj/6DujxvGnrvPPTZOcKPweYIV5Ch/f96PlGzZQJEyvnyNa9MzD/EH94b4qr2A5oekVSeIz6n10Ly46Rg1wT497WAOrKw5RJbd2zZBeaiwsLspjQBOs3grp9Z9w6nKVJWN+1WyaKceMMzrgPb0JEilaoxV4BJCGShKrlqXT/lXVV55AXI5acDg== X-Forefront-Antispam-Report: CIP:20.83.241.18; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mailrelay000000.14r1f435wfvunndds3vy4cdalc.xx.internal.cloudapp.net; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230001)(4636009)(46966006)(36840700001)(40470700004)(53546011)(31696002)(2906002)(26005)(508600001)(9786002)(8936002)(36756003)(44832011)(5660300002)(8676002)(83380400001)(4326008)(81166007)(70206006)(336012)(426003)(47076005)(31686004)(40460700003)(82310400005)(186003)(316002)(54906003)(110136005)(2616005)(36860700001)(50156003)(36900700001)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 May 2022 19:04:42.0481 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 53ec33ad-434e-41d3-d13f-08da2d37c7a3 X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[20.83.241.18]; Helo=[mailrelay000000.14r1f435wfvunndds3vy4cdalc.xx.internal.cloudapp.net] X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TreatMessagesAsInternal-BN1NAM02FT033.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR02MB7393 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On 5/3/2022 7:54 AM, Min Hu (Connor) wrote: > Hi, Ferruh, > > 在 2022/4/29 21:31, Ferruh Yigit 写道: >> On 4/29/2022 7:45 AM, Min Hu (Connor) wrote: >>> Hi, Ferruh, >>> >>> 在 2022/4/27 2:19, Ferruh Yigit 写道: >>>> On 3/24/2022 3:00 AM, Min Hu (Connor) wrote: >>>>> From: Huisong Li >>>>> >>>>> When stopping a bonded port, all slaves should be deactivated. But >>>>> only >>>> >>>> s/deactivated/stopped/ ? >>> not agreed. deactivated and stopped are different state for slave. >>> >> >> Just to clarify the sentences, otherwise I see the 'stopped' and >> 'deactivated' states are different. >> Next sentences complains that not all ports are stopped: "But only >> active slaves are stopped.", so I thought intention in this sentences >> to claim that all slaves should be stopped (but it mentions all slaves >> should be 'deactivated'). >> As long as you address the disconnection between two sentences, I >> don't mind the wording. > Actually, there is something wrong with the wording. > Yes, I should take your advice. > >> >>>> >>>>> active slaves are stopped. So fix it and do "deactivae_slave()" for >>>>> active >>>> >>>> s/deactivae_slave()/deactivate_slave()/ >>>> >>> agreed. >>> >>>>> slaves. >>>> >>>> Hi Connor, >>>> >>>> When a bonding port is closed, is it clear if all slave ports or >>>> active slave ports should be stopped? >>> Yes, I think all the slave ports should be stopped(or try to be >>> stopped). >>>> >>>>> >>>>> Fixes: 0911d4ec0183 ("net/bonding: fix crash when stopping mode 4 >>>>> port") >>>>> Cc: stable@dpdk.org >>>>> >>>>> Signed-off-by: Huisong Li >>>>> Signed-off-by: Min Hu (Connor) >>>>> --- >>>>>   drivers/net/bonding/rte_eth_bond_pmd.c | 20 +++++++++++--------- >>>>>   1 file changed, 11 insertions(+), 9 deletions(-) >>>>> >>>>> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c >>>>> b/drivers/net/bonding/rte_eth_bond_pmd.c >>>>> index b305b6a35b..469dc71170 100644 >>>>> --- a/drivers/net/bonding/rte_eth_bond_pmd.c >>>>> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c >>>>> @@ -2118,18 +2118,20 @@ bond_ethdev_stop(struct rte_eth_dev *eth_dev) >>>>>       internals->link_status_polling_enabled = 0; >>>>>       for (i = 0; i < internals->slave_count; i++) { >>>>>           uint16_t slave_id = internals->slaves[i].port_id; >>>>> + >>>>> +        internals->slaves[i].last_link_status = 0; >>>>> +        ret = rte_eth_dev_stop(slave_id); >>>>> +        if (ret != 0) { >>>>> +            RTE_BOND_LOG(ERR, "Failed to stop device on port %u", >>>>> +                     slave_id); >>>>> +            return ret; >>>> >>>> Should it return here or try to stop all ports? >>>> What about to record the return status, but keep continue to stop >>>> all ports. And return error if any of the stop failed? > Well, I am glad you have found something unreasaonable about 'stop'. > Let us see API 'rte_eth_dev_stop' > > rte_eth_dev_stop(dev) > { >     .... >     dev->data->dev_started = 0; >     ret = (*dev->dev_ops->dev_stop)(dev) >     retur ret; > } > This is unreasaonable. No matter 'dev_ops->dev_stop' succeed or fail, > the state 'dev_started ' will always set to be '0'. > > But this does not only influence bonding device but other devices like > eth dev or vdev. > This is the bug in rte ethdev level. I will send another patch to fix > it. > Hi Connor, I agree this is an issue in the API, cc'ed Andrew and Thomas. I vaguely remember that "dev_started = 0" was required for some dev_ops, but not quite sure, let me check this. At worst we can do as following to be sure: dev->data->dev_started = 0; ret = (*dev->dev_ops->dev_stop)(dev) if (ret) dev->data->dev_started = 1; Also we need to clarify in the API documentation (.h file), what is the status of the device if 'rte_eth_dev_stop()' returned error. Btw, would you be OK to separate this ethdev patch from your bonding patch, to not stuck your series because of ethdev one. > >>> I think no need to do this. APP only see the bonded device. If bonded >>> device stop failed, it means it works failed. And the number of >>> "stopped" successfully slave does not make any sense. >>> >> >> OK if trying to stop as much as possible 'slave' devices doesn't make >> sense, we can keep as it is. >> >> Btw, when functions fails at this point, bonding device itself already >> marked as stopped, right? And some of the slave devices may be stopped >> already before failure. >> I don't know how confusing this is for the user, that stop() function >> is failed but bonding device state is 'stopped'. I don't know if >> function should recover at least bonding device status (back to >> started) on failure, what do you think? >> >>>> >>>>> +        } >>>>> + >>>>> +        /* active slaves need to deactivate. */ >>>> >>>> " active slaves need to be deactivated. " ? >>> agreed. >>>> >>>>>           if (find_slave_by_id(internals->active_slaves, >>>>>                   internals->active_slave_count, slave_id) != >>>>> -                        internals->active_slave_count) { >>>>> -            internals->slaves[i].last_link_status = 0; >>>>> -            ret = rte_eth_dev_stop(slave_id); >>>>> -            if (ret != 0) { >>>>> -                RTE_BOND_LOG(ERR, "Failed to stop device on port %u", >>>>> -                         slave_id); >>>>> -                return ret; >>>>> -            } >>>>> +                internals->active_slave_count) >>>> >>>> I think original indentation for this line is better. >>>> >>> agreed. >>>>>               deactivate_slave(eth_dev, slave_id); >>>>> -        } >>>>>       } >>>>>       return 0; >>>> >>>> . >> >> .