From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) by dpdk.org (Postfix) with ESMTP id 2FAB1298F; Mon, 24 Oct 2016 16:54:56 +0200 (CEST) Received: by mail-wm0-f65.google.com with SMTP id o81so10176801wma.2; Mon, 24 Oct 2016 07:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lCU0w1rT9gDTEROhAp+zmcmW0n9d1DPW7MANJV4g1x0=; b=pSdqzhkG/m+g8GwTtAnmI+noGGfi37jFoVJBG7ZPzzxB3C07jErm9p02/C8Fm0ZvsV Re3gq79lWqL5mFq2kGknsC1UW3cyFw5c5yz3rG2MgGKhPeZA03+yUjVd2cc9YnH021Gj MlH5CwIPYDjUDPLm74sFYWUupTbJQO7TYlv5n0uaeU831n3erXxyt6o20kvmhS9jXjg5 BZMWoQD7avzyeyqziZG+XJnN0tnBORn/e4/22UbcqzUX0GvaIDsSzg5s+Jh9ymHJUc8h iOzz/HKxLJYzoVjNTfym8JsBEyveU0IHE9474SuPhjxsoHr3MFTvPZKjpzxMVcYFhF7B iGUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lCU0w1rT9gDTEROhAp+zmcmW0n9d1DPW7MANJV4g1x0=; b=ibiWUdwgApGL844dHOL0i7hf699txkv8Xi556XGDP+uM9uVEfK+L8xMviaAR2VKxId 3eYhm/aOMBkPyH6+8aHfkx1nBlw7NOqsbwejW0rSTlH8aTXqY2RMSHwSniEjImvUZhGA dZXDPlmNNBesJOtzOz0n8RDdn2s54+VjzCnykjnBagwhRLaEUGLbYu07JEfOXiwIIol4 /jzNpJRaDevzH6vmUkYDAZCQmutUkVBMjW92lRP2u2LCaC2lpTXSrtRiCmig1yJyl25i oba6sK5x9pkph6Kbd2uMbe3Xa5NYzEe3cjsC2+gF/sdOZD38fd//NB0G0FKQZRsan0eo GIZg== X-Gm-Message-State: ABUngvc4CwSPp3eepHSS9AJXJm8bcawqjPklMxwU+Lq7npf6Ui2la5jD7AMIxkb4MkLdcuaBfk1cZL9ndACfmw== X-Received: by 10.194.192.105 with SMTP id hf9mr12324052wjc.41.1477320895850; Mon, 24 Oct 2016 07:54:55 -0700 (PDT) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.92.206 with HTTP; Mon, 24 Oct 2016 07:54:54 -0700 (PDT) In-Reply-To: References: <1473251290-22053-1-git-send-email-i.maximets@samsung.com> From: Jan Blunck Date: Mon, 24 Oct 2016 10:54:54 -0400 X-Google-Sender-Auth: enc3CyleSZEzm-n7gST1G5Zkm9o Message-ID: To: Ilya Maximets Cc: dev@dpdk.org, Declan Doherty , Heetae Ahn , Yuanhan Liu , Eric Kinzie , Bernard Iremonger , stable@dpdk.org, Dyasly Sergey Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] Revert "bonding: use existing enslaved device queues" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 14:54:56 -0000 On Wed, Oct 19, 2016 at 5:47 AM, Ilya Maximets wrote: > On 18.10.2016 18:19, Jan Blunck wrote: >> On Tue, Oct 18, 2016 at 2:49 PM, Ilya Maximets wrote: >>> On 18.10.2016 15:28, Jan Blunck wrote: >>>> If the application already configured queues the PMD should not >>>> silently claim ownership and reset them. >>>> >>>> What exactly is the problem when changing MTU? This works fine from >>>> what I can tell. >>> >>> Following scenario leads to APP PANIC: >>> >>> 1. mempool_1 = rte_mempool_create() >>> 2. rte_eth_rx_queue_setup(bond0, ..., mempool_1); >>> 3. rte_eth_dev_start(bond0); >>> 4. mempool_2 = rte_mempool_create(); >>> 5. rte_eth_dev_stop(bond0); >>> 6. rte_eth_rx_queue_setup(bond0, ..., mempool_2); >>> 7. rte_eth_dev_start(bond0); >>> * RX queues still use 'mempool_1' because reconfiguration doesn't affect them. * >>> 8. rte_mempool_free(mempool_1); >>> 9. On any rx operation we'll get PANIC because of using freed 'mempool_1': >>> PANIC in rte_mempool_get_ops(): >>> assert "(ops_index >= 0) && (ops_index < RTE_MEMPOOL_MAX_OPS_IDX)" failed >>> >>> You may just start OVS 2.6 with DPDK bonding device and attempt to change MTU via 'mtu_request'. >>> Bug is easily reproducible. >>> >> >> I see. I'm not 100% that this is expected to work without leaking the >> driver's queues though. The driver is allowed to do allocations in >> its rx_queue_setup() function that are being freed via >> rx_queue_release() later. But rx_queue_release() is only called if you >> reconfigure the >> device with 0 queues. From what I understand there is no other way to >> reconfigure a device to use another mempool. >> >> But ... even that wouldn't work with the bonding driver right now: the >> bonding master only configures the slaves during startup. I can put >> that on my todo list. >> >> Coming back to your original problem: changing the MTU for the bond >> does work through rte_eth_dev_set_mtu() for slaves supporting that. In >> any other case you could (re-)configure rxmode.max_rx_pkt_len (and >> jumbo_frame / enable_scatter accordingly). This does work without a >> call to rte_eth_rx_queue_setup(). > > Thanks for suggestion, but using of rte_eth_dev_set_mtu() without > reconfiguration will require to have mempools with huge mbufs (9KB) > for all ports from the start. This is unacceptable because leads to > significant performance regressions because of fast cache exhausting. > Also this will require big work to rewrite OVS reconfiguration code > this way. > Anyway, it isn't the MTU only problem. Number of rx/tx descriptors > also can't be changed in runtime. > > > I'm not fully understand what is the use case for this 'reusing' code. > Could you, please, describe situation where this behaviour is necessary? The device that is added to the bond was used before and therefore already has allocated queues. Therefore we reuse the existing queues of the devices instead of borrowing the queues of the bond device. If the slave is removed from the bond again there is no need to allocate the queues again. Hope that clarifies the usecase, Jan > > Best regards, Ilya Maximets. > >>> >>>> >>>> On Wed, Sep 7, 2016 at 2:28 PM, Ilya Maximets wrote: >>>>> This reverts commit 5b7bb2bda5519b7800f814df64d4e015282140e5. >>>>> >>>>> It is necessary to reconfigure all queues every time because configuration >>>>> can be changed. >>>>> >>>>> For example, if we're reconfiguring bonding device with new memory pool, >>>>> already configured queues will still use the old one. And if the old >>>>> mempool be freed, application likely will panic in attempt to use >>>>> freed mempool. >>>>> >>>>> This happens when we use the bonding device with OVS 2.6 while MTU >>>>> reconfiguration: >>>>> >>>>> PANIC in rte_mempool_get_ops(): >>>>> assert "(ops_index >= 0) && (ops_index < RTE_MEMPOOL_MAX_OPS_IDX)" failed >>>>> >>>>> Cc: >>>>> Signed-off-by: Ilya Maximets >>>>> --- >>>>> drivers/net/bonding/rte_eth_bond_pmd.c | 10 ++-------- >>>>> 1 file changed, 2 insertions(+), 8 deletions(-) >>>>> >>>>> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c b/drivers/net/bonding/rte_eth_bond_pmd.c >>>>> index b20a272..eb5b6d1 100644 >>>>> --- a/drivers/net/bonding/rte_eth_bond_pmd.c >>>>> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c >>>>> @@ -1305,8 +1305,6 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev, >>>>> struct bond_rx_queue *bd_rx_q; >>>>> struct bond_tx_queue *bd_tx_q; >>>>> >>>>> - uint16_t old_nb_tx_queues = slave_eth_dev->data->nb_tx_queues; >>>>> - uint16_t old_nb_rx_queues = slave_eth_dev->data->nb_rx_queues; >>>>> int errval; >>>>> uint16_t q_id; >>>>> >>>>> @@ -1347,9 +1345,7 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev, >>>>> } >>>>> >>>>> /* Setup Rx Queues */ >>>>> - /* Use existing queues, if any */ >>>>> - for (q_id = old_nb_rx_queues; >>>>> - q_id < bonded_eth_dev->data->nb_rx_queues; q_id++) { >>>>> + for (q_id = 0; q_id < bonded_eth_dev->data->nb_rx_queues; q_id++) { >>>>> bd_rx_q = (struct bond_rx_queue *)bonded_eth_dev->data->rx_queues[q_id]; >>>>> >>>>> errval = rte_eth_rx_queue_setup(slave_eth_dev->data->port_id, q_id, >>>>> @@ -1365,9 +1361,7 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev, >>>>> } >>>>> >>>>> /* Setup Tx Queues */ >>>>> - /* Use existing queues, if any */ >>>>> - for (q_id = old_nb_tx_queues; >>>>> - q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) { >>>>> + for (q_id = 0; q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) { >>>>> bd_tx_q = (struct bond_tx_queue *)bonded_eth_dev->data->tx_queues[q_id]; >>>>> >>>>> errval = rte_eth_tx_queue_setup(slave_eth_dev->data->port_id, q_id, >>>>> -- >>>>> 2.7.4 >>>>> >>>> >>>> >>>> >> >> >>