From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 50F359A9E for ; Tue, 2 Jun 2015 04:14:11 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 01 Jun 2015 19:14:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,536,1427785200"; d="scan'208";a="735332556" Received: from shwdeisgchi017.ccr.corp.intel.com (HELO [10.239.66.47]) ([10.239.66.47]) by fmsmga002.fm.intel.com with ESMTP; 01 Jun 2015 19:14:09 -0700 Message-ID: <556D1170.5050604@intel.com> Date: Tue, 02 Jun 2015 10:14:08 +0800 From: "Liang, Cunming" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Hemminger References: <1432198563-16334-1-git-send-email-cunming.liang@intel.com> <1432889125-20255-1-git-send-email-cunming.liang@intel.com> <1432889125-20255-13-git-send-email-cunming.liang@intel.com> <20150529082722.26b22923@urahara> <556C1C41.6000107@intel.com> <20150601062735.68cd9714@urahara> In-Reply-To: <20150601062735.68cd9714@urahara> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v9 12/12] abi: fix v2.1 abi broken issue X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 02:14:11 -0000 Hi Stephen, On 6/1/2015 9:27 PM, Stephen Hemminger wrote: > On Mon, 1 Jun 2015 16:48:01 +0800 > "Liang, Cunming" wrote: > >> Hi Stephen, >> >> On 5/29/2015 11:27 PM, Stephen Hemminger wrote: >>> On Fri, 29 May 2015 16:45:25 +0800 >>> Cunming Liang wrote: >>> >>>> +#ifdef RTE_EAL_RX_INTR >>>> +extern int >>>> rte_eth_dev_rx_intr_ctl(uint8_t port_id, int epfd, int op, void *data); >>>> +#else >>>> +static inline int >>>> +rte_eth_dev_rx_intr_ctl(uint8_t port_id, int epfd, int op, void *data) >>>> +{ >>>> + RTE_SET_USED(port_id); >>>> + RTE_SET_USED(epfd); >>>> + RTE_SET_USED(op); >>>> + RTE_SET_USED(data); >>>> + return -1; >>>> +} >>>> +#endif >>> Doing ABI compatibility is good but hard. >>> >>> I think it would be better not to provide the functions for rx_intr_ctl unless >>> the feature was configured on. That way anyone using them with incorrect config >>> would detect failure at build time, rather than run time. >> I tend to not agree. For rx_intr_ctl/rx_intr_ctl_q, no matter w/ or w/o >> RTE_EAL_RX_INTR, it's necessary to check the return value. >> The failure return shall cause application give up using epoll waiting >> on the specified epfd for the port, and then degraded to pure polling mode. >> So I think these failure should be handled by the caller. > It is always best to fail as early in the development process as possible. > What possible benefit could there be from allowing application to be linked > and run with incorrect configuration. In fact you'll always detect failure at build time if your application insist to call rx_intr_ctl with port_conf.intr_conf.rxq=1. As port_conf.intr_conf.rxq is not defined when RTE_EAL_RX_INTR is not defined. If you ignore port_conf.intr_conf.rxq, no matter RTE_EAL_RX_INTR is defined or not, you always will get failure return when calling rx_intr_ctl. So I think the behavior doesn't break 'fail as early in the development process as possible'. And I'd like to expose all new APIs in this version, if we don't provide this API, what about rte_intr_rx_ctl or others? They're probably used by other user application as well.