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 D5CA0A0540; Tue, 14 Jul 2020 03:23:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9AFD51D656; Tue, 14 Jul 2020 03:23:14 +0200 (CEST) Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by dpdk.org (Postfix) with ESMTP id AF6411D64A for ; Tue, 14 Jul 2020 03:23:12 +0200 (CEST) Received: by mail-pf1-f196.google.com with SMTP id z3so6822575pfn.12 for ; Mon, 13 Jul 2020 18:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=t6RCJWV/eGi/W2moicxqIFWPNw3+YOY1nckjcTbnvAA=; b=DfqcFjUB0jsfaX2vI+mLxKSHTwxXOPJrh761w2QLADJClAMnJbvL2XYFj6wkgwcxRR MeZ5CEk/bLnOBiAKHcbKF6cOIBFdTvXWlg8yndVFRT+FydGpizTDiE/tCWm7z4LRc5ET 4oneFAiA1OUPlJV9K407wvawYTsnIGm+ry1gTTFjMWrHKdsCm7zgEBu8YSTiyXi3U+qB Uoa7gwE+WSE+ESuQyOlIxKzaz3MPIJXDXpMmgVPymtaNcotWndY4XR+IdqNFehYMIWpQ sdCzTNKmqnK6eiIhct0Qvk+ZLa2fDgv4IKw1dY1OB1O0D1HxodOU9qyOZWpzC7uSRQtF haTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=t6RCJWV/eGi/W2moicxqIFWPNw3+YOY1nckjcTbnvAA=; b=O5Ik1LH9Byzbd1Fg3H5eXAgU5qf4QDjcfv+AMQ+wnftFvk4KVkkBgvTTpEVMv0loJ4 jhBx7oyqvPFnPE5bnxETWrZbbBdCiNIlK4gczfUdoRthMhyfK0JxPDVIaEQ+oL9ao2zZ hKQ7+J3oQqq2pwOVZo+cVILh2pEhlNvaSGUkVdtY9kv8UmvOCMEixjcJCb8dwTXrxkJj Y/yz4iwGppAvNEMqD06IIr34X/S/BXGKgxvqPe8Xo7keEMckoCtIdegKf17Au/ZDFoOo fZ1KgWesaGu1+OIsJCS0Y4ckbvAKKSCiFUuuOwwBs0t43sk/pEuvQEFmadXbFUlnA5r0 Mt6A== X-Gm-Message-State: AOAM531/PeNNgAhLcK4DwAVvlI2pJdM/GALCHAxwJJKoG70dR1vAHLXv qNzacjZzUkTN9/BxH5mLpXsXkg== X-Google-Smtp-Source: ABdhPJwTZVLcLI6kfh5/hhHId9S9njGV7pwAnkNnI1kiknrIPqQLzYre2NvLu4btwzbF6NLx6bVtsw== X-Received: by 2002:a62:ce83:: with SMTP id y125mr2123764pfg.181.1594689791710; Mon, 13 Jul 2020 18:23:11 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id s6sm15046158pfd.20.2020.07.13.18.23.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jul 2020 18:23:11 -0700 (PDT) Date: Mon, 13 Jul 2020 18:23:08 -0700 From: Stephen Hemminger To: Lukasz Wojciechowski Cc: Thomas Monjalon , dev@dpdk.org, bruce.richardson@intel.com, david.marchand@redhat.com Message-ID: <20200713182308.63353bcd@hermes.lan> In-Reply-To: References: <20200422214555.11837-1-l.wojciechow@partner.samsung.com> <20200709134823.9176-1-l.wojciechow@partner.samsung.com> <2283396.fTMGzKxhym@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v3 0/4] introduce global debug flag 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" On Tue, 14 Jul 2020 00:39:43 +0200 Lukasz Wojciechowski wrote: > W dniu 11.07.2020 o=C2=A017:11, Thomas Monjalon pisze: > > 09/07/2020 15:48, Lukasz Wojciechowski: =20 > >> This set of patches introduces a global rte_debug flag for dpdk. > >> This will allow easy switch to debug build configuration using a single > >> flag. In the debug mode a RTE_DEBUG macro is defined to 1 > >> and for every enabled to be built library a RTE_DEBUG_{library name} > >> and for every enabled to be built driver > >> a RTE_DEBUG_{driver_class}_{driver_name} is also defined. > >> These macros can be used to place a debug code > >> inside #ifdef #endif clauses. > >> > >> The following requirements were discussed on the mailing list: > >> 1) The global debug flag is required to enable all the sanity checks > >> and validations that are normally not used due to performance reasons > >> > >> 2) The best option would be to have a single flag - not to introduce > >> too many build options > >> > >> 3) This option should be separated from meson "debug" option > >> (used for build with symbols) and can be called "rte_debug" > >> > >> 4) The currently existing DEBUG macros should not be replaced with > >> a RTE_DEBUG macro. This would allow to still enable them using > >> CFLAGS=3D"-D..." to test a single module (library, driver). =20 > > Please can we clarify this point? > > You mean not replacing driver macros with the global RTE_DEBUG? > > But we agree (next point) to replace existing macros? =20 > Yes, I'll try. >=20 > This point was added after discussion about using a single RTE_DEBUG=20 > flag for all debugs. > I think we all agreed that it will be better to keep separate flags for=20 > separate libraries or drivers instead of using only one RTE_DEBUG flag=20 > for all debugs. > e.g. in current version of patches there is a flag RTE_DEBUG_MBUF for=20 > debugs related to librte_mbuf. > This allows to enable only some debugs at compile time passing them to=20 > CFLAGS. Has anyone investigated doing static branches in userspace? It might mean doing self-modifying code. That would allow always keeping/compiling in the debug code but at zero run= time cost.