From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id E0F8E37B4 for ; Wed, 27 Feb 2019 12:24:31 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 4288B80005E; Wed, 27 Feb 2019 11:24:30 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 27 Feb 2019 11:24:24 +0000 To: Ferruh Yigit , Stephen Hemminger , CC: Igor Romanov References: <20190226213424.10567-1-stephen@networkplumber.org> <20190226213424.10567-6-stephen@networkplumber.org> <585db3f2-d9e6-1efd-b05f-7050758423a6@intel.com> From: Andrew Rybchenko Message-ID: Date: Wed, 27 Feb 2019 14:24:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <585db3f2-d9e6-1efd-b05f-7050758423a6@intel.com> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24458.002 X-TM-AS-Result: No-16.783800-8.000000-10 X-TMASE-MatchedRID: HXSqh3WYKfsOwH4pD14DsPHkpkyUphL9TI0NfY99MMnfUZT83lbkEO73 4x6nzMNivmnXuRR24wY54y8lWN5USAXl7w+ur8elEhGH3CRdKUVhBfGxmdHCguEnwmJWqjGcPkq rm3IbK/OMyIATyIbOmYKjoYyABoT3NuVzoZ6LieUiPTMUjkOgkl4KsHfYo5LQo55KfxwJS1wsWV dl3YcDsO3zSoJhBLBNapZ5uo8Kdw9wEqZbHFvammY0Io4Kxb86HAwy0XhreD35lA8aRaIEF6PFj JEFr+oloTCA5Efyn8AiEOZmeUqhz+FYyOmS7haB2TLA22GNQDKf44onm14u1KQRVOqTmJXT7UQb fZDCeZyMx8/oPQj8YQCu/np1SMha1wUYu16K06iYfhiXTQiFuAkrYwrjkf4Y X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--16.783800-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24458.002 X-MDID: 1551266671-eJxwlI_p6JN3 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 5/5] sfc: don't use RTE_LOGTYPE_PMD 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: Wed, 27 Feb 2019 11:24:32 -0000 On 2/27/19 2:21 PM, Ferruh Yigit wrote: > On 2/26/2019 9:34 PM, Stephen Hemminger wrote: >> The sfc driver was still using RTE_LOGTYPE_PMD which was superseded >> by local logging. >> >> Signed-off-by: Stephen Hemminger >> --- >> drivers/net/sfc/sfc.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/sfc/sfc.c b/drivers/net/sfc/sfc.c >> index 898603884fa0..2cd7126015fd 100644 >> --- a/drivers/net/sfc/sfc.c >> +++ b/drivers/net/sfc/sfc.c >> @@ -1115,12 +1115,12 @@ sfc_register_logtype(const struct rte_pci_addr *pci_addr, >> ++lt_prefix_str_size; /* Reserve space for prefix separator */ >> lt_str_size_max = lt_prefix_str_size + PCI_PRI_STR_SIZE + 1; >> } else { >> - return RTE_LOGTYPE_PMD; >> + return sfc_logtype_driver; >> } >> >> lt_str = rte_zmalloc("logtype_str", lt_str_size_max, 0); >> if (lt_str == NULL) >> - return RTE_LOGTYPE_PMD; >> + return sfc_logtype_driver; >> >> strncpy(lt_str, lt_prefix_str, lt_prefix_str_size); >> lt_str[lt_prefix_str_size - 1] = '.'; >> > Overall I think it is good idea to remove RTE_LOGTYPE_PMD, but sfc has a few > more usage of it around same manner, as a fallback value if allocating dynamic > one fails. > > > Andrew, > > Can be possible to update this sfc patch to completely eliminate RTE_LOGTYPE_PMD > usage? What do you think? > > Thanks, > ferruh I'm OK to use  sfc_logtype_driverif dynamic log type register fails, but what should I do if sfc_logtype_driverregister fails? Andrew.