From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E3A06A04F9; Fri, 10 Jan 2020 10:06:58 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6E85E1E90D; Fri, 10 Jan 2020 10:06:58 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 192C91E887 for ; Fri, 10 Jan 2020 10:06:57 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 421A121B1B; Fri, 10 Jan 2020 04:06:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 10 Jan 2020 04:06:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=7i0J/zGjunsv2pODYc/x3KfajmEV9qAraAQ3wEsnZOE=; b=bLobDdw36d3/ +nx/5N6MwnbB5VQxmBjiixzd/ytXm748fudUbbc5isweHeHwCRe2ygaRr6MJHE/K 0KaITD/xGAfMc+2suZ1LHAWvYgWk6aU8B3v9lIzvguvvHpPL6oxyarEFPFv+WOIp Y5AuedLajONsaE4An1M3kQUlIYPtPPU= 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=7i0J/zGjunsv2pODYc/x3KfajmEV9qAraAQ3wEsnZ OE=; b=QSWLWnV9d82BP5LcM2UBGTQXNImY78uBZB4E7EJpJdAjJmrGiCgoa3k6K OMIPl5KXG+HSQ/2WkNdWbS3sH/M+rvLYYUXu3MNO8sl+/PA/Wu2zkCGc2CVLisdI 6f795QET68mGIKXAmt+wiuO2+iNchm/n9Z1ZtGxA31rPFd+AVusBF77XR9oEeVrC pgSq/fXRCumZcWVQDaXWCuHxvIBgScSUHekIx4zWV5OnxPSp+BjsE34V1Qp3Yo9B UgjXQH5o2BizD17ExHU0RLrq7jtNbsMgNAKZuk4PR9KvooJ2RQL6/bXXlMp6bRfJ V+P4EASHTazp1sFZNeW6xkhW+ilYg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeifecutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghsucfo ohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkphepje ejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgr shesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C612A8005B; Fri, 10 Jan 2020 04:06:53 -0500 (EST) From: Thomas Monjalon To: Slava Ovsiienko Cc: Ferruh Yigit , "dev@dpdk.org" , Matan Azrad , Raslan Darawsheh , Ori Kam Date: Fri, 10 Jan 2020 10:06:51 +0100 Message-ID: <35082105.XM6RcZxFsP@xps> In-Reply-To: References: <1578500161-20156-1-git-send-email-viacheslavo@mellanox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 4/4] net/mlx5: engage free on completion queue 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" 09/01/2020 17:22, Slava Ovsiienko: > From: Ferruh Yigit > > On 1/9/2020 3:27 PM, Slava Ovsiienko wrote: > > > From: Ferruh Yigit > > >> On 1/9/2020 10:56 AM, Viacheslav Ovsiienko wrote: > > >>> + assert(ci != txq->cq_pi); > > >>> + assert((txq->fcqs[ci & txq->cqe_m] >> 16) == cqe- > > >>> wqe_counter); > > >> > > >> And same comments on these as previous patches, we spend some effort > > >> to remove the 'rte_panic' from drivers, this is almost same thing. > > >> > > >> I think a driver shouldn't decide to exit whole application, it's > > >> effect should be limited to the driver. > > >> > > >> Assert is useful for debug and during development, but not sure > > >> having them in the production code. > > > > > > IIRC, "assert" is standard C function. Compiled only if there is no NDEBUG > > defined. > > > So, assert does exactly what you are saying - provide the debug break > > > not allowing the bug to evolve. And no this break in production code. > > > > > > > Since mlx driver is using NDEBUG defined, what you said is right indeed. But > > why not using RTE_ASSERT to be consistent with rest. There is a specific config > > option to control assert (RTE_ENABLE_ASSERT) and anyone using it will get > > different behavior with mlx5. > > We have the dedicated option to control mlx5 debug: > CONFIG_RTE_ENABLE_ASSERT controls the whole DPDK. No, it controls the whole DPDK except mlx PMDs. > CONFIG_RTE_LIBRTE_MLX5_DEBUG controls NDEBUG for mlx5 > > From my practice - I switch the mlx5 debug option (in the process of the debugging/testing > datapath and checking the resulting performance, by directly defining NDEBUG in mlx5.h and > not reconfiguring/rebuilding the entire DPDK), this fine grained option seems to be useful. I don't like having mlx PMDs behave differently. It make things difficult for newcomers. And with meson, such options are cleaned up.