From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 6CFBBA00E6 for ; Tue, 19 Mar 2019 16:05:59 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8A4662BAF; Tue, 19 Mar 2019 16:05:58 +0100 (CET) Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by dpdk.org (Postfix) with ESMTP id 015611DBD for ; Tue, 19 Mar 2019 16:05:56 +0100 (CET) Received: by mail-qt1-f193.google.com with SMTP id v32so22466148qtc.10 for ; Tue, 19 Mar 2019 08:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=BVuqFBo3zYqQH1I0HEVN+8C+QVgfsTSQyuxqq58QBmI=; b=BS8TYdyM23bUnIwndvpHiqwlaUiGNR2zg10DA7/Ty6xXu94Sm5e2gdm2TuwTqm2XjU h4gOk71KsFFPs8vqOtmYDjZOgeWMLyuQSqbTIp6E9J69AMNOmyvZ2hDBavo+fWD11GPT Q7u/2WhqBGMZnY8o0pSTA7gzvk+1j8vr7j2vnwblCw012I4Q8gOlsI70QtpaAzROXgMU 3V0hqAqEhIcIZJe9YbBe4Ja7/Clli1WQcy8a42uEuyGIqBnGG2TMmrw/Skt6b+n9nOo9 LaAYt0KpySnT+oGQDZlyPk2kPV0Hw+MSeR+Q0q7eBYOr+fyV6IYQYSH9I/rJqjBFVV/y snaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BVuqFBo3zYqQH1I0HEVN+8C+QVgfsTSQyuxqq58QBmI=; b=cE9zIdn4Ib09di9IFOtal0vN3VgLH5rgr809R7xNp6brYBdxXMWAFZ7nucveH/jbcA qN5CgLY72hWszfMTpt+Vgav1dES2YnOyrtiR2f8UK1IV5A0h3C8sSQL3jkhQc6nWGjo+ TqYyTvijuGWeL+Chsnt67/9A0JBqbnEfcUJPnJhIU9JUP+EFOIylUpuG7tR+09wuZrqq gdZfeLNi4OTFz6J/GHcNLWGZ/A4+8qZZYmMMXPCFRATptuemagUCXx6SQW8j42jtRrrk VXI5DzgjwQx96to4I8O9HCxDwBV0JqYksCJcSBP6wWFhOExUGolOxvRWhZKjLxP2kPSy d3DQ== X-Gm-Message-State: APjAAAWximvcaXCe2sgrfny45U6Lz+cAiQMJZ+CMRWdjfOTKSuULmGFs J2Jeos8jRUZbpRWHZL9sIdotE0P8 X-Google-Smtp-Source: APXvYqzbsxsKqVAuq/xWK6jg9iQuHhdDonQ3wBm45/QHO7L6vskrL9Y+AdxIrQOU7WMZ5KjKuRtkdw== X-Received: by 2002:aed:3b14:: with SMTP id p20mr2409738qte.240.1553007956042; Tue, 19 Mar 2019 08:05:56 -0700 (PDT) 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 u64sm11830345qki.24.2019.03.19.08.05.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Mar 2019 08:05:55 -0700 (PDT) To: hfli@netitest.com, declan.doherty@intel.com, chas3@att.com, dev@dpdk.org References: <001a01d4de37$ec097f80$c41c7e80$@netitest.com> From: Chas Williams <3chas3@gmail.com> Message-ID: <99fe680a-13e2-3d90-2fb2-4a389a50fd56@gmail.com> Date: Tue, 19 Mar 2019 11:05:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <001a01d4de37$ec097f80$c41c7e80$@netitest.com> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] 8023ad bond tx crashed if one port has 2 more tx queues 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190319150554.K0OvbrZibslvABvwWaeLKvhY4jRvWS_ntWp2bZV3Coc@z> On 3/19/19 5:41 AM, hfli@netitest.com wrote: > Hi Guys, > > I found a bug in dpdk bond code, while one port has 2 more tx queues, > 8023ad bond port will be crashed in tx burst. > > Just analyzed the code below, if 2 more CPU cores send packets on a port > by different tx queue, the arrays like > > slave_port_ids/ dist_slave_port_ids/ slave_tx_fail_coun/ slave_bufs will > be shared by all of cores, it will be crashed in this function. I am afraid that I don't understand this description. I believe that these are allocated on the stack and shouldn't be shared between threads. There isn't any locking currently in the driver. You need to stop the data path before making changes to the slaves (with the exception of link status) attached to the bonding device. > Is there any better solution for this? For now, I just add lock for > rte_eth_tx_burst. > > static uint16_t > > bond_ethdev_tx_burst_8023ad(void *queue, struct rte_mbuf **bufs, > uint16_t nb_bufs) > > { > struct bond_tx_queue *bd_tx_q = (struct bond_tx_queue *)queue; > struct bond_dev_private *internals = bd_tx_q->dev_private; > uint16_t slave_port_ids[RTE_MAX_ETHPORTS]; > uint16_t slave_count; > > uint16_t dist_slave_port_ids[RTE_MAX_ETHPORTS]; > uint16_t dist_slave_count; > > /* 2-D array to sort mbufs for transmission on each slave into */ > struct rte_mbuf *slave_bufs[RTE_MAX_ETHPORTS][nb_bufs]; > > /* Number of mbufs for transmission on each slave */ > uint16_t slave_nb_bufs[RTE_MAX_ETHPORTS] = { 0 }; > > /* Mapping array generated by hash function to map mbufs to > slaves */ > uint16_t bufs_slave_port_idxs[RTE_MAX_ETHPORTS] = { 0 }; > uint16_t slave_tx_count, slave_tx_fail_count[RTE_MAX_ETHPORTS] > = { 0 }; > uint16_t total_tx_count = 0, total_tx_fail_count = 0; > > Thanks and Regards, > > Haifeng >