From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <vladz@cloudius-systems.com> Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by dpdk.org (Postfix) with ESMTP id 9035D5921 for <dev@dpdk.org>; Thu, 5 Mar 2015 14:39:30 +0100 (CET) Received: by lbiz11 with SMTP id z11so25377378lbi.13 for <dev@dpdk.org>; Thu, 05 Mar 2015 05:39:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=h073HoVsTXJYx37/O/DiVwNtobFBdv0nGFsrd1v6VpU=; b=S70G3RyryOu/4BTSaOYHbVm7hbL8Q+YTHPx5bv1yOdT/VeAulJCRO85vR2HXyEmTKK YU3i8NA7akSF0pXlnbkeJtUFL0gyF9++nCpBPwwx7oeWnII7ejhjG8t8j3tsPJhykAxC Oius1yP0pQdZ72QNplqem45uunoPSW0pthMinMcYShV+pnedHVArf3r+e1QRPMQis8lR Lso0PtCJBZnxeUc5F0j0ul9gGN9SxPwEpKgZcL1ZwLIlDGStDbFSyc0jjaCZgA8K3tvQ pO0Jk+OmJm46afeLKiqywYcBCYZM23m9U30iKShtaogeJXgpxvZrBBmAf7SJEIfYhuKY xDrA== X-Gm-Message-State: ALoCoQnQ3YOhGSuhXugxK0KfSZu7ZGQ51k01q7z1MYQ0Wjwxn2iWbaeZIkuA4FgQ474Kmfho//Va X-Received: by 10.112.133.225 with SMTP id pf1mr7933167lbb.33.1425562770272; Thu, 05 Mar 2015 05:39:30 -0800 (PST) Received: from [10.0.0.166] ([212.143.139.214]) by mx.google.com with ESMTPSA id zo8sm1280120lbc.37.2015.03.05.05.39.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 05:39:29 -0800 (PST) Message-ID: <54F85C8F.3010501@cloudius-systems.com> Date: Thu, 05 Mar 2015 15:39:27 +0200 From: Vlad Zolotarov <vladz@cloudius-systems.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Thomas Monjalon <thomas.monjalon@6wind.com> References: <1425554885-16901-1-git-send-email-vladz@cloudius-systems.com> <1425554885-16901-6-git-send-email-vladz@cloudius-systems.com> <3557886.R5Xnb4aBPR@xps13> In-Reply-To: <3557886.R5Xnb4aBPR@xps13> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 05 Mar 2015 13:39:30 -0000 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 <vladz@cloudius-systems.com> >> --- >> 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 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). > 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. 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. >