From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id AD6181B4DC for ; Thu, 2 Aug 2018 18:14:25 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 26C1A21A1E; Thu, 2 Aug 2018 12:14:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 02 Aug 2018 12:14:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=/uD9uat94ij4rsHGiFF+s31Fla bX5jwbyrq7Sn8t5Ns=; b=ZyPxvYl3J5I11kr9Kni5YtBm/hPSVvSlztFDm+Rv4t uKOVvDfmCbhgSvHsCwgClX6rVsihAJuYfu/TuG74MHr9emf3yYqMQkGKvNaWPFiv OEwRJbMLcw9+mB6Any/TaFcWQP/JaN15ztoKZa7vNNpews8zGCckXlvIu2cm+Tp2 g= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=/uD9ua t94ij4rsHGiFF+s31FlabX5jwbyrq7Sn8t5Ns=; b=SnKkFYyFKBp9zV49zDlpwE UhgELJK3+J2oVBLLUSl1d+bbvNQhWZhcxCyBGtvsNzkbmDytlqaHudYl/IMcHFqZ Jlrlv2c5P/FRG7Eua+UnAV40FVRB5UUyFS2cgTTX//AaHDWWjLV3YYpJOW99JmVX 8Xpd8EuOiLmOG/gYA2XVvWrS7uReGD3ZEtfyNAVNIFSQEoyiX4g+dzpgfonUOtJH 0Z1QtmXwRu/I9hHaP1c7rFPWq8l8W6IsgAe0T+yUgSBTPHqGcrm0L0HahPiHimOp LXd615WhFUil7PjM9wcGFwffuPnx6SaOUqTjkdGoiuUfokm/bjux/z+rxIZjq9mw == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D184910284; Thu, 2 Aug 2018 12:14:22 -0400 (EDT) From: Thomas Monjalon To: Kevin Traynor , Andrew Rybchenko Cc: dev@dpdk.org, Ferruh Yigit Date: Thu, 02 Aug 2018 18:14:17 +0200 Message-ID: <7727240.AGfPpAcRVp@xps> In-Reply-To: <581602cf-36ba-2d6f-03ab-b00e9817f2a8@redhat.com> References: <1533213223-24028-1-git-send-email-ktraynor@redhat.com> <00c35ad3-e063-b14e-ef56-e4308ec83f52@solarflare.com> <581602cf-36ba-2d6f-03ab-b00e9817f2a8@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] ethdev: decrease log level for successful API 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: Thu, 02 Aug 2018 16:14:26 -0000 02/08/2018 16:52, Kevin Traynor: > On 08/02/2018 03:41 PM, Andrew Rybchenko wrote: > > On 02.08.2018 17:09, Kevin Traynor wrote: > >> On 08/02/2018 02:52 PM, Andrew Rybchenko wrote: > >>> On 02.08.2018 16:35, Kevin Traynor wrote: > >>>> On 08/02/2018 01:59 PM, Andrew Rybchenko wrote: > >>>>> On 02.08.2018 15:33, Kevin Traynor wrote: > >>>>>> @@ -1319,5 +1319,5 @@ struct rte_eth_dev * > >>>>>> if (dev->data->dev_started == 0) { > >>>>>> - RTE_ETHDEV_LOG(ERR, > >>>>>> + RTE_ETHDEV_LOG(DEBUG, > >>>>>> "Device with port_id=%"PRIu16" already stopped\n", > >>>>>> port_id); > >>>>> I would suggest to use WARNING here. Yes, it is not an error since > >>>>> nothing bad has > >>>>> happened and we handle duplicate stop and duplicate start, > >>>>> but I think it is bad that (buggy?) application does it. Making it > >>>>> debug > >>>>> we simply > >>>>> hide it too much. > >>>>> > >>>> I think an application following the documented API is not bad or > >>>> buggy. > >>> I've failed to find the place were it is documented that device/queue > >>> may be stopped/started twice. Could you point out? > >>> Yes, return value 0 means success, but it is a separate thing. > >>> > >> I was commenting directly on the API and it's documentation e.g. below > >> for dev start. I'm not aware of other documentation specifying how it > >> can/cannot be called. > > > > I would not say so. "0: Success. Ethernet device started" means that > > function managed to do the job and finally the device is started. > > > > Never-mind it is not that important and already paid to much attention. > > I've included in CC other ethdev maintainers (who should be there from > > the very beginning). I don't mind if it is acked by other ethdev maintainer > > and applied. It is definitely not an error as it is now. Thanks. > > > > Sure, sounds good - I'm glad we agree on something :-) I'll leave it for > a day and can re-spin tomorrow. I would like to give an opinion, but unfortunately it's hard to decide. For sure, it should not be a WARNING level (used for non-fatal errors). What else do we have? NOTICE, INFO and DEBUG. I think it can be INFO.