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 9969C4C8F for ; Thu, 28 Feb 2019 07:49:34 +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 ECBC3BC0053; Thu, 28 Feb 2019 06:49:32 +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; Thu, 28 Feb 2019 06:49:26 +0000 To: Stephen Hemminger CC: Ferruh Yigit , , Igor Romanov References: <20190226213424.10567-1-stephen@networkplumber.org> <20190226213424.10567-6-stephen@networkplumber.org> <585db3f2-d9e6-1efd-b05f-7050758423a6@intel.com> <20190227103043.3b62103b@shemminger-XPS-13-9360> From: Andrew Rybchenko Message-ID: Date: Thu, 28 Feb 2019 09:49:22 +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: <20190227103043.3b62103b@shemminger-XPS-13-9360> 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-24460.003 X-TM-AS-Result: No-15.875900-8.000000-10 X-TMASE-MatchedRID: +f/wAVSGjugOwH4pD14DsPHkpkyUphL9TI0NfY99MMnfUZT83lbkEO73 4x6nzMNivmnXuRR24wY54y8lWN5USAXl7w+ur8elEhGH3CRdKUVhBfGxmdHCguEnwmJWqjGcPkq rm3IbK/OMyIATyIbOmQYyTjFQl/YKST2lYXtlRQx17gHAyAFr0+dIlGzDlIXiSSUXkvSVAdz2wu +LPoaXV0O9T3iX2kefe0l01i2yef825XOhnouJ5SI9MxSOQ6CSXgqwd9ijktCjnkp/HAlLXCxZV 2XdhwOw7fNKgmEEsE2fd/oqkQC/1Pz/jVa2JSBDDRBjlWdDIA0cDDLReGt4PfmUDxpFogQXo8WM kQWv6iWhMIDkR/KfwKeluit/pcFplxhPCV6M7c3wahwNha9XGYTpgdnPD7DpJrnFy47uS+oVT4f f90723OlRl0xkvSnyPEexnJIn2Ee7ocntp+ViC5xf/FT0qton4QyO5D9tYvF+3BndfXUhXQ== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--15.875900-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24460.003 X-MDID: 1551336573-bVpv2v0epzV6 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: Thu, 28 Feb 2019 06:49:35 -0000 On 2/27/19 9:30 PM, Stephen Hemminger wrote: > On Wed, 27 Feb 2019 14:24:21 +0300 > Andrew Rybchenko wrote: > >> 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. > I don't like drivers that try to do something different than every other driver in DPDK. > The solarflare driver is doing lots of extra effort to have multiple fine grain log types. > Not sure if there is any value to this. In a real world situation for diagnosis you would > want to turn on logs across everything in the driver, then filter as needed later. We really use logging configuration facilities which we have in the driver and, thanks to dynamic logging design (IMO really good design), both your and our logging usage scenarios can coexist. Andrew.