From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id E6BF858C6 for ; Wed, 27 Feb 2019 14:05:36 +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-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 2C454B000C0; Wed, 27 Feb 2019 13:05:35 +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 13:05:29 +0000 To: Ferruh Yigit , Stephen Hemminger , CC: Igor Romanov , Olivier MATZ References: <20190226213424.10567-1-stephen@networkplumber.org> <20190226213424.10567-6-stephen@networkplumber.org> <585db3f2-d9e6-1efd-b05f-7050758423a6@intel.com> <7766ed09-9807-2c81-ec21-9b225bfeea7a@intel.com> <9f01db85-b80c-fa2d-25cd-d3cb6d139812@intel.com> From: Andrew Rybchenko Message-ID: Date: Wed, 27 Feb 2019 16:05:26 +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: <9f01db85-b80c-fa2d-25cd-d3cb6d139812@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-17.915600-8.000000-10 X-TMASE-MatchedRID: 1GZI+iG+MtcOwH4pD14DsPHkpkyUphL9TI0NfY99MMnfUZT83lbkEO73 4x6nzMNivmnXuRR24wY54y8lWN5USAXl7w+ur8elEhGH3CRdKUVhBfGxmdHCguEnwmJWqjGcPkq rm3IbK/OMyIATyIbOmSFSCMcrPhV8VCFefQRV3M4LPVZHwod7gAGZ/+APXW9kymP/1piI/6G7CG rJz6r8kPnci8g75LfDgbBogp3pUoUNEBcdUjAZg8G0UNgaZpYqmRKFhwukYf0fTpbqvC281QuVM ctAPCgtEeHflL4ZdKr9Vaa04yzrEd5ZokMflaoNDRBjlWdDIA2dNwtHz5PMSniPLuLao1y93SlE gVuyN9tvuYnoduGWEV+24nCsUSFNt7DW3B48kkGyO81X3yak8z1fyKoCOincjU6fGnG2LoSXBgk xblS2hUpVl5ErJNd6vxm+JZTzcL+gCBa0EuIU+3++XTuNM9WB714ZQL+W68iJvIGua8Tj3Q== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--17.915600-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24458.002 X-MDID: 1551272736-hw70y5uxo1Nz 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 13:05:37 -0000 On 2/27/19 3:19 PM, Ferruh Yigit wrote: > On 2/27/2019 11:50 AM, Ferruh Yigit wrote: >> On 2/27/2019 11:24 AM, 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? >> Right. Same concern is valid for all dynamic log registration but we are >> ignoring it. >> >> What do you think instead of each pmd/lib cover the error case, >> 'rte_log_register_type_and_pick_level()' & 'rte_log_register()' always return >> valid value. Like if they fail internally, return 'RTE_LOGTYPE_GENERIC' kind of >> value. Above makes sense. > Changing the log functions is one above step, are you OK to replace all > occurrence of 'RTE_LOGTYPE_PMD' with 'sfc_logtype_driver' in > 'sfc_register_logtype()', there is one more occurrence than this patch updates. Yes > I see your point to keep the one in 'sfc_driver_register_logtype()', perhaps we > can address it later separately with above suggestion or something else. OK. Thanks, Andrew.