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 2E1E4A0C45; Mon, 13 Sep 2021 22:02:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E3A6440151; Mon, 13 Sep 2021 22:02:02 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id BC0114014F for ; Mon, 13 Sep 2021 22:02:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631563321; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GtcKxL8iMwhH99ctXesMueD+a+ZeLcbNSPtXPsERAyo=; b=fxoTqK088VvkKHbqG65LEu9eS051wGbQ8P+BfHcmwS7finTwG6U4cVPtzTW8XUbbhoaUO3 b5/sLDwhK6XIeOqcxwN2CGO9D/mYVDTnRwrbw/4NO3A254r38b5MFpzwzLw4LrVNGLIhCB dTpiE8ZvaLw6AmdgAZ7eCFybXD3HrwU= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-212-uiyU4xFDPtiEnw9JXyDGJw-1; Mon, 13 Sep 2021 16:02:00 -0400 X-MC-Unique: uiyU4xFDPtiEnw9JXyDGJw-1 Received: by mail-qv1-f71.google.com with SMTP id ci14-20020a056214054e00b0037a75ff56f9so10538929qvb.23 for ; Mon, 13 Sep 2021 13:02:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=GtcKxL8iMwhH99ctXesMueD+a+ZeLcbNSPtXPsERAyo=; b=O+eBT3erMEsal4XtXhkN3doPfzavhx5BjOmW36lp7HuiC3LcyFKfnEqNY29LNnIG+C fW14GzSmwhS3+LHbbvbjyUSTrlCAWl93k9phAMfBFZ0EqX9p9In2tI/g7N8jhzndmfy3 nzuDJxKLw0eUeBdtXUhhzm8bz3gbi2blWy9ldh+qr7TNZ1blTTQhke/LS0+QYXEpBBx2 pdqpxEjOsMgosFR0dZ5tD/TKUOOO77AIDhLo9/yziQbZfPobtffipFiv1g5znJ6bPMuE vBgogfQlluDcHow2HpTIjc14/9vEYBfZ17vWvG6nNazCEFPQQ9Kc14dQpViKHr/HhakX SKQQ== X-Gm-Message-State: AOAM532zguhBbVa94ObwHvR6VQEa1AtRxxsWWc9EfZlRgy2CM0+R95NO ezzYnbfomEB3JrznLghoYxs54d8OpHj05I2TpXIqREquVk71886Tpt9E4j4vC3X7AIlhc4IXnYq oKTA= X-Received: by 2002:a05:6214:122e:: with SMTP id p14mr1326558qvv.37.1631563319866; Mon, 13 Sep 2021 13:01:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwsKLb1kZxhRKknun+8s0/O2RfMlPrKNBdttkZPnrcsqcfKuHMxorKvmcNt+qCpId2bKD6a7A== X-Received: by 2002:a05:6214:122e:: with SMTP id p14mr1326540qvv.37.1631563319648; Mon, 13 Sep 2021 13:01:59 -0700 (PDT) Received: from localhost.localdomain (075-142-250-213.res.spectrum.com. [75.142.250.213]) by smtp.gmail.com with ESMTPSA id c28sm6049489qkl.69.2021.09.13.13.01.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Sep 2021 13:01:59 -0700 (PDT) To: "Chautru, Nicolas" , "dev@dpdk.org" , "gakhil@marvell.com" Cc: "thomas@monjalon.net" , "hemant.agrawal@nxp.com" , "Zhang, Mingshan" , "Joshi, Arun" References: <1631063741-28631-1-git-send-email-nicolas.chautru@intel.com> <1631063741-28631-7-git-send-email-nicolas.chautru@intel.com> From: Tom Rix Message-ID: Date: Mon, 13 Sep 2021 13:01:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=trix@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v3 6/6] bbdev: reduce warning level for one scenario X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" On 9/13/21 10:03 AM, Chautru, Nicolas wrote: >> -----Original Message----- >> From: Tom Rix >> Sent: Sunday, September 12, 2021 5:55 AM >> To: Chautru, Nicolas ; dev@dpdk.org; >> gakhil@marvell.com >> Cc: thomas@monjalon.net; hemant.agrawal@nxp.com; Zhang, Mingshan >> ; Joshi, Arun >> Subject: Re: [PATCH v3 6/6] bbdev: reduce warning level for one scenario >> >> >> On 9/7/21 6:15 PM, Nicolas Chautru wrote: >>> Queue setup may genuinely fail when adding incremental queues for a >>> given priority level. In that case application would attempt to >>> configure a queue at a different priority level. >>> Not an actual error. >>> >>> Signed-off-by: Nicolas Chautru >>> --- >>> lib/bbdev/rte_bbdev.c | 7 ++++--- >>> 1 file changed, 4 insertions(+), 3 deletions(-) >>> >>> diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c index >>> fc37236..defddcf 100644 >>> --- a/lib/bbdev/rte_bbdev.c >>> +++ b/lib/bbdev/rte_bbdev.c >>> @@ -528,9 +528,10 @@ struct rte_bbdev * >>> ret = dev->dev_ops->queue_setup(dev, queue_id, (conf != NULL) ? >>> conf : &dev_info.default_queue_conf); >>> if (ret < 0) { >>> - rte_bbdev_log(ERR, >>> - "Device %u queue %u setup failed", dev_id, >>> - queue_id); >>> + /* This may happen when trying different priority levels */ >>> + rte_bbdev_log(INFO, >>> + "Device %u queue %u setup failed", >>> + dev_id, queue_id); >> This change is just changing the log level, which is fine. >> >> I am looking at how the error handling is done for the function. >> >> It seems like the bailing is done in the middle of change the queue state. >> >> ex/ the block above this one >> >> /* Release existing queue ... */ >> >> Does this leave the queue in a bad state ? > Hi Tom, > That would not be related to that change indeed. > > The queue would end up in a not configured when rte_bbdev_queue_configure() fails but then can still be configured again without limitation (worst thing than can happen is that queue_release is called, hence leaves the queue in a deterministic state, unconfigured but ready to be configured). > Note that queue_release() just removes the configuration of the queue, but the queue is still there and can be configured again (actual total number of queues unchanged, based on number previously set with rte_bbdev_setup_queues()). So its in a bad state, but outside the scope of this commit. Reviewed-by: Tom Rix Tom > > Thanks > Nic > >> Tom >> >>> return ret; >>> } >>>