From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by dpdk.org (Postfix) with ESMTP id 3E7FD5A74 for ; Thu, 5 Mar 2015 15:01:36 +0100 (CET) Received: by wevk48 with SMTP id k48so9665984wev.7 for ; Thu, 05 Mar 2015 06:01:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=EL/lq10MjoOExg65mZ4UqUJ5ThVHke0yWXDwyBKVYtY=; b=ezu68dcW+QjEaujS2YQaUy05qJS+HCwlCcDzdxQSq9yalSI2R2ZRFLKgHcwT/hiSLC uFx9qytaJipqh3NBV/Ol74uRw6tw6SRwTO0JUKLVYMOmOAU3iFVMguObOwSQ0OkVd/8b lRTa4Xu/+V4VpxKupYmp0yohXc6LGs3nSe/MyMGxpg4IWresEs/0c4/ONWKhmElWBBot NUIjMNgBR6ob4wPB6vi+FJitLdOfpzLTUgbZHZ92k+ErMnpOQ4I51KKXShSu0GSbjklp HSVCb2jqIY91D4vcR7YjiWUnfbGDRJecHfdQrWLQk5rxdI0VLCCEq4CHHmPm5rbzDCcM 6ukg== X-Gm-Message-State: ALoCoQnUYZPS6x+1hW5w6D6F+tRnuGhG3zNcZUAGluiO3F4zthRUWww0WbZx9L501VWpNkoZYs7k X-Received: by 10.194.133.196 with SMTP id pe4mr19485088wjb.76.1425564096130; Thu, 05 Mar 2015 06:01:36 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id m4sm11780308wik.20.2015.03.05.06.01.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 06:01:35 -0800 (PST) Date: Thu, 05 Mar 2015 06:01:35 -0800 (PST) X-Google-Original-Date: Thu, 05 Mar 2015 15:01 +0100 From: Thomas Monjalon To: Vlad Zolotarov Message-ID: <1835214.fEP04vn92S@xps13> Organization: 6WIND User-Agent: KMail/4.14.4 (Linux/3.18.4-1-ARCH; KDE/4.14.4; x86_64; ; ) In-Reply-To: <54F85C8F.3010501@cloudius-systems.com> References: <1425554885-16901-1-git-send-email-vladz@cloudius-systems.com> <3557886.R5Xnb4aBPR@xps13> <54F85C8F.3010501@cloudius-systems.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 5/6] common_linuxapp: Added CONFIG_RTE_ETHDEV_LRO_SUPPORT option 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: Thu, 05 Mar 2015 14:01:36 -0000 2015-03-05 15:39, Vlad Zolotarov: > > On 03/05/15 15:19, Thomas Monjalon wrote: > > 2015-03-05 13:28, Vlad Zolotarov: > >> Enables LRO support in PMDs. > >> > >> Signed-off-by: Vlad Zolotarov > >> --- > >> config/common_linuxapp | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/config/common_linuxapp b/config/common_linuxapp > >> index 97f1c9e..5b98595 100644 > >> --- a/config/common_linuxapp > >> +++ b/config/common_linuxapp > >> @@ -137,6 +137,7 @@ CONFIG_RTE_MAX_ETHPORTS=32 > >> CONFIG_RTE_LIBRTE_IEEE1588=n > >> CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16 > >> CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y > >> +CONFIG_RTE_ETHDEV_LRO_SUPPORT=y > > > > Sorry I don't really follow this ixgbe discussion but I wonder why you > > would add a compile time option for this feature. > > The only reason is to be able to detect that the feature is present in > the DPDK version u r compiling against because of the API change. > Currently, this can't be done using the DPDK version thus we may either Why you cannot use version? In development phase? When released, you'll be able to test >= 2.1. > do a try-compilation and if it fails define some application-level macro > disabling > the feature usage or we may define a macro in the library level > (together with tons of other such macros like those in the patch snippet > above). I'd prefer a request rte_eth_dev_info_get() to advertise that the feature is available with the device and driver. Please let's try to remove config options and #ifdefs. > > What is the benefit of disabling it? > > No benefit whatsoever. > > > And if really needed, this patch would make more sense merged with the > > code under ifdef. > > I strongly disagree - the amount of #ifdefs in the DPDK source is > absolutely enormous. It makes reading and understanding the code really > hard. I agree. You misunderstand me. I was just saying that this patch should be merged. > Therefore, I tried to reduce the amount of time the already existing > macros have to be queried (see PATCH4). And of course I don't see any > sense of adding new ones more than really needed. And in LRO case - it's > a single time, where the feature is manifested by the HW.