From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by dpdk.org (Postfix) with ESMTP id 0CDEB2BBD for ; Fri, 20 Jan 2017 13:55:30 +0100 (CET) Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo03.seg.att.com(mxl_mta-7.2.4-7) with ESMTP id 3c802885.2b6353491940.3014604.00-2466.6182926.nbfkord-smmo03.seg.att.com (envelope-from ); Fri, 20 Jan 2017 12:55:31 +0000 (UTC) X-MXL-Hash: 588208c30864792e-00468564c080f234b6fb39f0adfdf11d1870001b Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo03.seg.att.com(mxl_mta-7.2.4-7) over TLS secured channel with ESMTP id 0c802885.0.3014601.00-2250.6182921.nbfkord-smmo03.seg.att.com (envelope-from ); Fri, 20 Jan 2017 12:55:29 +0000 (UTC) X-MXL-Hash: 588208c12433cfd9-53b34c6a77e801e99711e04a2f1bdc3d18b9bc0a Received: from [192.168.38.17] (84.52.89.52) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 20 Jan 2017 12:55:23 +0000 To: Ferruh Yigit , References: <1484822644-12624-1-git-send-email-arybchenko@solarflare.com> <1484824340-16107-1-git-send-email-arybchenko@solarflare.com> From: Andrew Rybchenko Message-ID: <447a90b6-8abc-825b-788d-ecb7d6809490@solarflare.com> Date: Fri, 20 Jan 2017 15:55:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [84.52.89.52] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.000.1202-22834.003 X-TM-AS-Result: No--16.650400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=HuVwbhnS c=1 sm=1 tr=0 a=8P+NB+fYZDP74ap4g4d9Kw==] X-AnalysisOut: [:17 a=RB3BGLmKESwA:10 a=IgFoBzBjUZAA:10 a=zRKbQ67AAAAA:8 a] X-AnalysisOut: [=Ltkvh2OdcGATv1cCYJsA:9 a=pILNOxqGKmIA:10 a=QyXUC8HyAAAA:8] X-AnalysisOut: [ a=o3z68CXTVy482gqgTj4A:9 a=sbTzujUO6m1WQRz9:21 a=_W_S_7Ve] X-AnalysisOut: [coQA:10 a=PA03WX8tBzeizutn5_OT:22 a=avl4LiGQNoF5OB0DmCJ7:2] X-AnalysisOut: [2] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [193.34.186.16] Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2] net/sfc: do not panic if alarms are not supported 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: Fri, 20 Jan 2017 12:55:31 -0000 On 01/20/2017 03:36 PM, Ferruh Yigit wrote: > On 1/19/2017 11:12 AM, Andrew Rybchenko wrote: >> Alarms are not supported on the FreeBSD. >> Application must poll link status periodically itself using >> rte_eth_link_get_nowait() to avoid management event queue overflow. >> >> Fixes: 2de39f4e1310 ("net/sfc: periodic management EVQ polling using alarm") >> >> Signed-off-by: Andrew Rybchenko >> Reviewed-by: Andrew Lee >> Reviewed-by: Andy Moreton >> --- >> v2: >> - fix spelling >> >> drivers/net/sfc/sfc_ev.c | 12 ++++++++---- >> 1 file changed, 8 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/net/sfc/sfc_ev.c b/drivers/net/sfc/sfc_ev.c >> index c788986..fe6de6f 100644 >> --- a/drivers/net/sfc/sfc_ev.c >> +++ b/drivers/net/sfc/sfc_ev.c >> @@ -499,10 +499,14 @@ >> >> rc = rte_eal_alarm_set(SFC_MGMT_EV_QPOLL_PERIOD_US, >> sfc_ev_mgmt_periodic_qpoll, sa); >> - if (rc != 0) >> - sfc_panic(sa, >> - "cannot rearm management EVQ polling alarm (rc=%d)", >> - rc); >> + if (rc == -ENOTSUP) { >> + sfc_warn(sa, "alarms are not supported"); >> + sfc_warn(sa, "management EVQ must be polled indirectly using no-wait link status update"); > Who is the audience of this message, I am just trying to understand. DPDK application developer > If this is for application developer, perhaps function should return and > error and log should be a debug log. Unfortunately there is no way to know if application will poll the link status with no-wait. So, we cannot distinguish when it is OK to continue (yes alarms are not supported, but application is aware) and when is it not OK (alarms are not supported and application is unaware). > Or if it is for end user of the application, and this issue is something > that prevents app run properly, perhaps application should return error > instead of logging warning. > > Overall I am a little suspicious about warn/err level of logs that does > not alter the execution path. I would like to hear more comments indeed. > > >> + } else if (rc != 0) { >> + sfc_err(sa, >> + "cannot rearm management EVQ polling alarm (rc=%d)", >> + rc); >> + } >> } >> >> static void >> >>