From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <3chas3@gmail.com> Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by dpdk.org (Postfix) with ESMTP id E59011B5C9 for ; Fri, 30 Nov 2018 23:28:11 +0100 (CET) Received: by mail-qt1-f193.google.com with SMTP id p17so7697136qtl.5 for ; Fri, 30 Nov 2018 14:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=We7+cfZUQRwOfsa2F13HLytjusoJBOc0AfD2kMhAnD8=; b=jXhWA4T8jRLRtxhc8F+KZD4BA6rmevBk1seLvoAm/bKbaDfKt1HsEa7f99MDPvIJfR qrc4Z1sECY29T5mb7nH4mNtEDcyscVd9S9InMmOn9AH3IEjqPA3vzFSKwuAcD5qlj3QP pMGlxZy3PebI41eRZdp0EbOOXqBXwLVcKuy4A1ha7xdZs1ATvRcm///gVMKt+fGXdls6 JYHg2gE1wlxvRGZhgPb3IGlPzZB+T3bS9E4YTnrwNtWo3FBkvgYSmG1ZrnWWbpCjce1g AvjdEJusJhjIFaBxX+k4RTG2+VPc/BOs92gnPB2754xEMRal1f45xJGIgxZLj+AAUvPN Tpxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=We7+cfZUQRwOfsa2F13HLytjusoJBOc0AfD2kMhAnD8=; b=TTjNtK5R+LAM5ajRyjL/zkz3/S6MVMOqCPglZGrP7ORkcT10uNX41yTBatQhD1d+Zl e1OXGubV1TLaOTtjhEqZIBY5HWf6U49QUs0qen5drjZ2MIYLF5KqFJ6ruhhDh8qtnKfg HHCMom7eSCJSzKYWCha43PSH+n3KS8YcFNg8Ay6pbQj8CJzErmZE/UWcUERyLLOP7cj6 E9C+mUNm+Asrt66pW4700VGipK9gFbifjr9gNa8lgY7ltWtByTG9egGmV6ApSDFDBhWu wSPB9nhtVKMOJ9L3htKjw88AOVMGLEEHazv0qi2buXYNujRhuilEQnu3w775WVMdPoIp HqMg== X-Gm-Message-State: AA+aEWZumc+1csNLDBwwgrSdCz2cV0m4xPDKWAAuR+qc0+MJWigU/2xf B5Vr5Aue/BRguyf3oYktn6o= X-Google-Smtp-Source: AFSGD/Wz8MsV5HCSy6/fgVsVqSohckh/xeN5u3t5c3KkRZuL9yxW0Jn4QOB4hVO1gJpMM9l0gx/eQQ== X-Received: by 2002:aed:25a6:: with SMTP id x35mr7189064qtc.228.1543616891179; Fri, 30 Nov 2018 14:28:11 -0800 (PST) Received: from [192.168.1.10] (pool-96-255-82-34.washdc.fios.verizon.net. [96.255.82.34]) by smtp.gmail.com with ESMTPSA id v50sm4339123qtc.7.2018.11.30.14.28.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Nov 2018 14:28:10 -0800 (PST) To: Linhaifeng , "dev@dpdk.org" Cc: "chas3@att.com" References: <1543469561-8864-1-git-send-email-haifeng.lin@huawei.com> <8fdfaff2-8f59-8d4b-db6c-a8a3c26fb4e2@gmail.com> <4099DE2E54AFAD489356C6C9161D5333958924EF@DGGEML502-MBS.china.huawei.com> From: Chas Williams <3chas3@gmail.com> Message-ID: <54d81172-c5df-44b9-27ea-2ce03adc8604@gmail.com> Date: Fri, 30 Nov 2018 17:28:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <4099DE2E54AFAD489356C6C9161D5333958924EF@DGGEML502-MBS.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] =?utf-8?b?562U5aSNOiAgW1BBVENIXSBuZXQvYm9uZGluZzogZml4?= =?utf-8?q?_double_fetch_for_active=5Fslave=5Fcount?= 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: Fri, 30 Nov 2018 22:28:12 -0000 The problem is that I can't see how the API can ever provide accurate information. By the time you have the information it is potentially stale. There really isn't a way to control if a slave is active since that is protocol dependent. rte_eth_bond_slaves_get() is safer in the sense that you control when the slaves are added and removed from the bonding group. You can ensure that you get a consistent answer. Hopefully your protocol doesn't especially care if the slave is active or not. You are sending the packets via rte_eth_bond_8023ad_ext_slow()? On 11/30/18 12:50 AM, Linhaifeng wrote: > Hi, Chars > > Thank you. > > I use it for send pkts to the dedicated queue of slaves. > > Maybe i should not use it. I would though another way. > > -----邮件原件----- > 发件人: Chas Williams [mailto:3chas3@gmail.com] > 发送时间: 2018年11月30日 11:27 > 收件人: Linhaifeng ; dev@dpdk.org > 抄送: chas3@att.com > 主题: Re: [dpdk-dev] [PATCH] net/bonding: fix double fetch for active_slave_count > > I guess this is slightly more correct. There is still a race here though. > After you make your copy of active_slave_count, the number of active slaves could go to 0 and the memcpy() would copy an invalid element, acitve_slaves[0]. There is no simple fix to this problem. Your patch reduces the opportunity for a race but doesn't eliminate it. > > What you are using this API for? > > On 11/29/18 12:32 AM, Haifeng Lin wrote: >> 1. when memcpy slaves the internals->active_slave_count 1 2. return >> internals->active_slave_count is 2 3. the slaves[1] would be a random >> invalid value >> >> Signed-off-by: Haifeng Lin >> --- >> drivers/net/bonding/rte_eth_bond_api.c | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/net/bonding/rte_eth_bond_api.c >> b/drivers/net/bonding/rte_eth_bond_api.c >> index 21bcd50..ed7b02e 100644 >> --- a/drivers/net/bonding/rte_eth_bond_api.c >> +++ b/drivers/net/bonding/rte_eth_bond_api.c >> @@ -815,6 +815,7 @@ >> uint16_t len) >> { >> struct bond_dev_private *internals; >> + uint16_t active_slave_count; >> >> if (valid_bonded_port_id(bonded_port_id) != 0) >> return -1; >> @@ -824,13 +825,14 @@ >> >> internals = rte_eth_devices[bonded_port_id].data->dev_private; >> >> - if (internals->active_slave_count > len) >> + active_slave_count = internals->active_slave_count; >> + if (active_slave_count > len) >> return -1; >> >> memcpy(slaves, internals->active_slaves, >> - internals->active_slave_count * sizeof(internals->active_slaves[0])); >> + active_slave_count * sizeof(internals->active_slaves[0])); >> >> - return internals->active_slave_count; >> + return active_slave_count; >> } >> >> int >>