From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Zolotarov Subject: Re: API feature check _HAS_ Date: Sun, 29 Nov 2015 11:07:44 +0200 Message-ID: <565AC060.1060903@cloudius-systems.com> References: <13076727.eWbPQotoSK@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit To: Thomas Monjalon , dev@dpdk.org Return-path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id 04F3E2A1A for ; Sun, 29 Nov 2015 10:07:48 +0100 (CET) Received: by wmuu63 with SMTP id u63so95772998wmu.0 for ; Sun, 29 Nov 2015 01:07:47 -0800 (PST) In-Reply-To: <13076727.eWbPQotoSK@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 11/26/15 22:35, Thomas Monjalon wrote: > When introducing LRO, Vlad has defined the macro RTE_ETHDEV_HAS_LRO_SUPPORT: > http://dpdk.org/browse/dpdk/commit/lib/librte_ether/rte_ethdev.h?id=8eecb329 > > It allows to use the feature without version check (before the release or > after a backport). > Do you think it is useful? > Should we define other macros RTE_[API]_HAS_[FEATURE] for each new feature > or API change? The main purpose of the above macro was to identify the presence of the new field in the rte_eth_rxmode during the period of time when there was no other way to know it. Once this may be concluded based on the release version I see no reason to keep it. > It's time to fix it before releasing the 2.2 version.