From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by dpdk.org (Postfix) with ESMTP id BB9C15A4B for ; Thu, 5 Mar 2015 21:41:23 +0100 (CET) Received: by wibhm9 with SMTP id hm9so18215440wib.2 for ; Thu, 05 Mar 2015 12:41:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mVrm4SooXUrlxuNzTGSaF2SIEBaEy/D3vpqPeV9hPyY=; b=Wy05zdwoXHlMAvXqfXychqUd5KywjN2UPMk8IA7uSAIx4m208luUmo5VtB1WWGjomn Uyp1Pf8AMuh/ZmTatQKjPD1YD9+pdNIiNtKF+nAbiV5IBpddkLJYLgq4OYIVjsgggBmL h13/JBbH6yGx/xvxZQNPhwmuK/lSeJwb+r5HyWNn/JBUBxi4o+jF4Kpv6vJmht2fvflA n8t77Xj2ymnO/vdWJz+fW1G/ZgHlbm56TN224JRyg/BoQnpxXFcXLn+91Yz5eRJ9oK1P vUwZxyZ+oLx2qWjE72+g3HPfmCQ+jVE6sFUVwKTNfUKklGj1+L/VEP7z3uh4F+xkHbxH J95g== X-Gm-Message-State: ALoCoQkLojbf4dbE8i/Lb/pzfRsocEaBoaBfWsplp6gN6v8L2okqHF7nxZGUr/4PQfX8ArwjtQ/s MIME-Version: 1.0 X-Received: by 10.180.104.66 with SMTP id gc2mr69193276wib.34.1425588083571; Thu, 05 Mar 2015 12:41:23 -0800 (PST) Received: by 10.194.81.196 with HTTP; Thu, 5 Mar 2015 12:41:23 -0800 (PST) Received: by 10.194.81.196 with HTTP; Thu, 5 Mar 2015 12:41:23 -0800 (PST) In-Reply-To: <5205726.Fyxt8xNiqp@xps13> References: <1425554885-16901-1-git-send-email-vladz@cloudius-systems.com> <1835214.fEP04vn92S@xps13> <54F865C7.8030203@cloudius-systems.com> <5205726.Fyxt8xNiqp@xps13> Date: Thu, 5 Mar 2015 22:41:23 +0200 Message-ID: From: Vladislav Zolotarov To: Thomas Monjalon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 20:41:24 -0000 On Mar 5, 2015 9:14 PM, "Thomas Monjalon" wrote: > > 2015-03-05 16:18, Vlad Zolotarov: > > > > On 03/05/15 16:01, Thomas Monjalon wrote: > > > 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. > > > > Of course! When the version bumps, the #ifdef I've mentioned above may > > be replaced with the version check. > > > > > > > >> 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. > > > > This is exactly what my patch does. But that's not ending there - there > > is a new feature bit added in rte_eth_rxmode (enable_lro) and in order > > to compile the application has to know somehow if this bit is present or > > not. How do u propose to do this now? > > I think it would be better to define something like RTE_HAS_LRO in rte_ethdev.h. Ok. So i'll change it in v4. > > > Of course, I can put such macro in my own tree but then I'll have to > > rebase all the time and inform other developers that will have to work > > against my tree (and not upstream as it's supposed to be) - to update. > > This sounds like a hassle thus I added this macro to resolve this issue > > until the version is bumped. > > > > > > > >>> What is the benefit of disabling it? > > >> No benefit whatsoever. > >