From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v4 05/10] qede: Add core driver Date: Thu, 31 Mar 2016 14:51:49 -0700 Message-ID: <20160331145149.58e750c8@xeon-e3> References: <1459315705-25001-1-git-send-email-rasesh.mody@qlogic.com> <1459315705-25001-6-git-send-email-rasesh.mody@qlogic.com> <20160330093926.6bff277c@xeon-e3> <20160330153743.63605112@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "bruce.richardson@intel.com" , "thomas.monjalon@6wind.com" , "dev@dpdk.org" , Rasesh Mody To: Harish Patil Return-path: Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by dpdk.org (Postfix) with ESMTP id 4EC688025 for ; Thu, 31 Mar 2016 23:51:35 +0200 (CEST) Received: by mail-pa0-f43.google.com with SMTP id zm5so74935036pac.0 for ; Thu, 31 Mar 2016 14:51:35 -0700 (PDT) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 31 Mar 2016 19:36:55 +0000 Harish Patil wrote: > > >=20 > >On Wed, 30 Mar 2016 22:16:51 +0000 > >Harish Patil wrote: > > > >> > > >> >On Tue, 29 Mar 2016 22:28:20 -0700 > >> >Rasesh Mody wrote: > >> > > >> >> + > >> >> +static void qede_print_adapter_info(struct qede_dev *qdev) > >> >> +{ > >> >> + struct ecore_dev *edev =3D &qdev->edev; > >> >> + struct qed_dev_info *info =3D &qdev->dev_info.common; > >> >> + char ver_str[QED_DRV_VER_STR_SIZE] =3D { 0 }; > >> >> + > >> >> + RTE_LOG(INFO, PMD, > >> >> + " Chip details : %s%d\n", > >> >> + ECORE_IS_BB(edev) ? "BB" : "AH", > >> >> + CHIP_REV_IS_A0(edev) ? 0 : 1); > >> >> + > >> >> + sprintf(ver_str, "%s %s_%d.%d.%d.%d", QEDE_PMD_VER_PREFIX, > >> >> + edev->ver_str, QEDE_PMD_VERSION_MAJOR, QEDE_PMD_VERSION_MINOR, > >> >> + QEDE_PMD_VERSION_REVISION, QEDE_PMD_VERSION_PATCH); > >> >> + strcpy(qdev->drv_ver, ver_str); > >> >> + RTE_LOG(INFO, PMD, " Driver version : %s\n", ver_str); > >> >> + > >> >> + ver_str[0] =3D '\0'; > >> >> + sprintf(ver_str, "%d.%d.%d.%d", info->fw_major, info->fw_minor, > >> >> + info->fw_rev, info->fw_eng); > >> >> + RTE_LOG(INFO, PMD, " Firmware version : %s\n", ver_str); > >> >> + > >> >> + ver_str[0] =3D '\0'; > >> >> + sprintf(ver_str, "%d.%d.%d.%d", > >> >> + (info->mfw_rev >> 24) & 0xff, > >> >> + (info->mfw_rev >> 16) & 0xff, > >> >> + (info->mfw_rev >> 8) & 0xff, (info->mfw_rev) & 0xff); > >> >> + RTE_LOG(INFO, PMD, " Management firmware version : %s\n", ver_str= ); > >> >> + > >> >> + RTE_LOG(INFO, PMD, " Firmware file : %s\n", QEDE_FW_FILE_NAME); > >> > > >> >This means the driver is far too chatty in the logs. > >> >Can't this be made DEBUG level? > >> > > >> Not clear what is the issue here? > >> RTE_LOG is used here to display basic adapter info like firmware/driver > >> versions etc without the need to enable any debug flags. > >> The driver debug logging is under the control of appropriate debug > >>flags. > >>=20 > > > >The DPDK log messages end up being examined by tech support and customer= s. > >Too much code puts extra stuff in so it is hard to find the real problem. > >This is obviously debug info, so either: > > 1) make it conditionally compiled > > 2) change log level to DEBUG > > 3) remove it. > > >=20 > This is not really a debug msg per se. We want it to be printed on the > stdout unconditionally (displayed only once) so that we can readily know > what firmware/driver/hw versions we are dealing with. We don=E2=80=99t wa= nt to > depend on the apps to print those and many of the apps may not do so > including testpmd. Even the linux drivers prints basic stuff under dmesg. > We have found this to be useful for triage and would like to retain it if > there is no objection. And Linux drivers are wrong to do this. This a case where developer thinks = printing stuff is important, but for operations it isn't. Better to provide this info thro= ugh some API, (maybe DPDK needs extensions to get_info). Also, you don't have to format twice, once into a buffer (with sprintf) the= n again by calling RTE_LOG. Not only that sprintf() is guaranteed to null terminate t= he string, so your paranoid ver_str[0] =3D 0; is not needed either. Sorry for being so picky, but you are getting the feedback that comes from experience dealing with large volumes of log info.