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 259411B44D for ; Mon, 14 Jan 2019 08:32:54 +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 1C2488005E; Mon, 14 Jan 2019 07:32:52 +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; Mon, 14 Jan 2019 07:32:45 +0000 To: Thomas Monjalon , "Wiles, Keith" CC: Nithin Kumar Dabilpuram , "Yigit, Ferruh" , "dev@dpdk.org" , "Jerin Jacob Kollanukkaran" References: <20190107143951.30076-1-ndabilpuram@marvell.com> <8373161.2Fht6qqTaI@xps> <17CD35BA-B70C-4F7C-A90B-636BB02148C8@intel.com> <7520504.p0jQqc19KO@xps> From: Andrew Rybchenko Message-ID: Date: Mon, 14 Jan 2019 10:32:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <7520504.p0jQqc19KO@xps> 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-24362.003 X-TM-AS-Result: No-19.051500-8.000000-10 X-TMASE-MatchedRID: WMT2WRIkHPMOwH4pD14DsPHkpkyUphL9X5TqQagR07ejD9XxfoENjofE 1TdytQOEfsIfixHvnM9yQVFfTzFjliJcv5X7ObmJNOTokZutCG4pWss5kPUFdEsHGbVW/dGwi09 soBkXVyUiR9Ooric5uero1m5bXlGzSSU9VkttdoFVTfJWlqPdDNIv4RV84lHT+TdKNkxxkWTGyv qbtGWMEeCmk0NN5S6FmiY/pts15BVfZdCQVmQaDxmCYUYerLHrEeXPNyiMU04dTIwEQt3c4xvTQ KD1lRA9h4eVjjZCqheM5TCLNNgDPdlvZnMi/3c/olVO7uyOCDV8yGO3dvk8/QJ1vk7thYuGUdfE Kc10rU4vQVE0yOGFpYqBZeVCt3Cf0nbjHOkZyPk+W6N2SzBTBwfnX3+9Fm452Yajy1P9W1XSUaS e3PSxAfdoK1MEIGGXeTjw/FyRX6RNfs8n85Te8oMbH85DUZXyseWplitmp0j+efAnnZBiL0OAfB u/XeE8NCG13B+YSDQxYi6fcXn6DJAp7KkpfqQv6jxK1Mq/erRMbir114qMlADVNaKWHbm6YMzCp ObNONfulbZMtI+rXyKPowb6QQUD X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--19.051500-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24362.003 X-MDID: 1547451173-dNyyyRollGOQ Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2] ethdev: report error on name truncation 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: Mon, 14 Jan 2019 07:32:54 -0000 On 1/14/19 12:21 AM, Thomas Monjalon wrote: > 13/01/2019 21:19, Wiles, Keith: >>> On Jan 13, 2019, at 2:02 PM, Thomas Monjalon wrote: >>> 13/01/2019 20:28, Wiles, Keith: >>>>> On Jan 13, 2019, at 9:38 AM, Nithin Kumar Dabilpuram wrote: >>>>> --- a/lib/librte_ethdev/rte_ethdev.c >>>>> +++ b/lib/librte_ethdev/rte_ethdev.c >>>>> + if (rc >= RTE_MEMZONE_NAMESIZE) { >>>>> + RTE_ETHDEV_LOG(ERR, "truncated name"); >>>>> + rte_errno = ENAMETOOLONG; >>>>> + return NULL; >>>>> + } >>>> I we are already returning an error here should the RTE_LOG be DEBUG >>>> and not ERR. >>>> Of course this does mean we would have to check return codes :-) >>> In the general case, we should always log the errors as RTE_LOG_ERR, >>> no matter it is handled and logged again at an upper level. >>> Don't you think so? >> My only concern is cluttering up the console output and developers should be checking return codes, which I know we do not do sometimes in DPDK. >> I think we need to do some cleaning up of DPDK and test return codes or make the function return void, but that is a different problem then this one. >> >> If we are fine with this type of log style then we can leave it. To me is just seem redundant if we are returning a code the calling function should report the error. In some cases we will get two or more messages about the same problem depending on the call path. > The log can be different at different levels. > The deepest log will give details, while other logs will give context. > > The more error logs we have, the better it may be for the user. > I understand the concern about keeping logs clean, but for errors, > I don't see possible redundancy as a spam. > > Anyone else think differently? Error logs are bad if an API assumes retries to be used to resolve it (if buffer is insufficient, increase buffer and retry). But it is not the case here. Theoretically it is possible here (provide shorter name), but very unlikely. So, I'm OK with the added error log.