From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id D63801BAA4 for ; Thu, 26 Oct 2017 00:55:48 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id u138so4575991wmu.5 for ; Wed, 25 Oct 2017 15:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=TGAGZQj77TgAQw9bed/K9+xkgKyNnYUOx8ah8kNNI44=; b=XMW2CpPmcUG938X4tVhowzQxxAsn9ruenlyetPLCsFpFeGKp4S4hEMv/WCr8PPz6T5 zE/bL5ECNzUU7syCCc+TBb/4Vh1wbBYuDnqH0jlipIiygMdH0S0YJJ4mYAe+ew6Tn8om OdassCNNqzjHO+nY2xvCCyjB3KMSTlXuzi512oHvVIVGXXi+1xqWnvmJfNILGbI/Q9/W P8d/7fWyYIHtgCXrnQhI+f3XbkkOYcdyHEwxkKjCAofwaDVsCfIK4Y5lvlnNrJkmL5L0 up+TFU/CrYphly/a8IrbP/V1BemI1wXQcvKmjGjpS1Ttnd/cetfydO/rRmYOsdBk26yH JzDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=TGAGZQj77TgAQw9bed/K9+xkgKyNnYUOx8ah8kNNI44=; b=sWRvaYQ3O21NzMeASOv3DJo4AgrTONpzMH8umijT0Fe6hwNpdytsOZf6vkNP3M9UhP 8Wh2rHABZRXcfRJ9TArJbiziCviXTms3k8LO6woLlC8ITC0J9qTCdpAps3wwvJKAvRhL lYgS2UaCBBS389uqyAXriT5SEod6lUupK0FlpVLoust7zrGOXpXtwS8B7NUbJCyqg0n+ qJMVCYHE0UdQVJIMmbdrV8vFGY/UY8Aegt4laUmF2in3fA9/c2ByqMYrLMuPBZ7KghuV U+NJTPyCaKNvnESUg5Q3G5UJpbdC6flzoqhPunSsUjh4S8mi9h2i7fDY4IfOLBGBh07M GQeQ== X-Gm-Message-State: AMCzsaUUk1Oqz/+J9VMmgGzOEvvL5Q4BnedVWB8hUrLoIRnxoWCbt3zc 8kxYQxHJ9xU+A1z/q8wvzz3PmA== X-Google-Smtp-Source: ABhQp+TF1likEQTw3aeKlwj+OealCLEGcfT6SGLaRZw4wkMzUYD8CS+T+pQjcWSkIbylJ0RGJHxuBA== X-Received: by 10.28.140.18 with SMTP id o18mr3172713wmd.145.1508972148411; Wed, 25 Oct 2017 15:55:48 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id p78sm4376151wma.11.2017.10.25.15.55.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 15:55:47 -0700 (PDT) Date: Thu, 26 Oct 2017 00:55:29 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Ferruh Yigit Cc: Matan Azrad , "dev@dpdk.org" , "john.mcnamara@intel.com" Message-ID: <20171025225529.GA10890@bidouze.vm.6wind.com> References: <1505403124-44297-1-git-send-email-matan@mellanox.com> <4dd479dc-8d1e-7e6c-6100-7c71058d98b7@intel.com> <0b4190d7-dc1c-71d2-0e0b-13ab1d007e0c@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH] doc: update failsafe feature list X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 22:55:49 -0000 On Wed, Oct 25, 2017 at 11:44:39AM -0700, Ferruh Yigit wrote: > On 9/23/2017 10:55 PM, Matan Azrad wrote: > > Hi Ferruh > > > >> -----Original Message----- > >> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] > >> Sent: Friday, September 22, 2017 1:32 PM > >> To: Matan Azrad ; Gaetan Rivet > >> > >> Cc: dev@dpdk.org; john.mcnamara@intel.com > >> Subject: Re: [dpdk-dev] [PATCH] doc: update failsafe feature list > >> > >> On 9/19/2017 12:39 PM, Matan Azrad wrote: > >>> Hi Ferruh > >>> > >>>> -----Original Message----- > >>>> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] > >>>> Sent: Tuesday, September 19, 2017 2:00 PM > >>>> To: Matan Azrad ; Gaetan Rivet > >>>> > >>>> Cc: dev@dpdk.org; john.mcnamara@intel.com > >>>> Subject: Re: [dpdk-dev] [PATCH] doc: update failsafe feature list > >>>> > >>>> On 9/19/2017 11:04 AM, Matan Azrad wrote: > >>>>> > >>>>> Hi Ferruh > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] > >>>>>> Sent: Tuesday, September 19, 2017 12:27 PM > >>>>>> To: Matan Azrad ; Gaetan Rivet > >>>>>> > >>>>>> Cc: dev@dpdk.org > >>>>>> Subject: Re: [dpdk-dev] [PATCH] doc: update failsafe feature list > >>>>>> > >>>>>> On 9/14/2017 4:32 PM, Matan Azrad wrote: > >>>>>>> Add supported failsafe features to feature list. > >>>>>>> Remove stats per queue feature from failsafe feature list since > >>>>>>> queue_stats_mapping_set dev op has not implemented yet. > >>>>>>> > >>>>>>> Signed-off-by: Matan Azrad > >>>>>>> --- > >>>>>>> doc/guides/nics/features/failsafe.ini | 15 ++++++++++++++- > >>>>>>> 1 file changed, 14 insertions(+), 1 deletion(-) > >>>>>>> > >>>>>>> diff --git a/doc/guides/nics/features/failsafe.ini > >>>>>>> b/doc/guides/nics/features/failsafe.ini > >>>>>>> index a42e344..9f48455 100644 > >>>>>>> --- a/doc/guides/nics/features/failsafe.ini > >>>>>>> +++ b/doc/guides/nics/features/failsafe.ini > >>>>>>> @@ -4,20 +4,33 @@ > >>>>>>> ; Refer to default.ini for the full list of available PMD features. > >>>>>>> ; > >>>>>>> [Features] > >>>>>>> +Speed capabilities = Y > >>>>>>> Link status = Y > >>>>>>> Link status event = Y > >>>>>>> MTU update = Y > >>>>>>> Jumbo frame = Y > >>>>>>> +Scattered Rx = Y > >>>>>>> +LRO = Y > >>>>>>> +TSO = Y > >>>>>>> Promiscuous mode = Y > >>>>>>> Allmulticast mode = Y > >>>>>>> Unicast MAC filter = Y > >>>>>>> Multicast MAC filter = Y > >>>>>>> VLAN filter = Y > >>>>>>> +Ethertype filter = Y > >>>>>>> +N-tuple filter = Y > >>>>>>> +SYN filter = Y > >>>>>>> +Tunnel filter = Y > >>>>>>> +Flexible filter = Y > >>>>>>> +Hash filter = Y > >>>>>>> +Flow director = Y > >>>>>>> Flow control = Y > >>>>>>> Flow API = Y > >>>>>>> +QinQ offload = Y > >>>>>>> +L3 checksum offload = Y > >>>>>>> +L4 checksum offload = Y > >>>>>>> Packet type parsing = Y > >>>>>>> Basic stats = Y > >>>>>>> -Stats per queue = Y > >>>>>>> ARMv7 = Y > >>>>>>> ARMv8 = Y > >>>>>>> Power8 = Y > >>>>>> > >>>>>> I am not sure if claiming support for these features is correct. > >>>>>> Failsafe itself doesn't provide these features, but relies > >>>>>> underlying hardware which we don't really know what they supports > >>>>>> or not in this > >>>> stage. > >>>>>> > >>>>> > >>>>> Don't you think that almost all failsafe features rely underlying > >>>>> hardware or > >>>> sub PMDs? > >>>> > >>>> You are right, perhaps we should remove all. This is helpful to show > >>>> what device features are supported. For failsafe, is this information > >> useful? > >>>> > >>> Since there are features that failsafe cannot support without any sub > >>> PMD dependences (for example "Stats per queue") it is useful. > >> > >> Sorry, I missed your point. > >> > >> Device feature list documentation is good for: > >> - End user can easily see what to expect from a device/driver. > >> - To trace what features implemented for a device. > >> - To find out which device has a specific desired feature. > >> > >> For failsafe, it is a virtual overlay device on other physical devices. > >> > >> The supported architectures and provided documents features can be > >> useful. But why/how NIC related features can be useful since all they are > >> coming form underlay devices? > >> > > My point is that someone can understand from this list all failsafe PMD features which are not > > supported even if the failsafe sub devices PMD may support them. > > It may be possible to document them as "Feature = N" if you sure they are not > supported, > instead of saying the features that may or may not be supported as supported. > > > Please read section 31.1 in failsafe documentation: http://dpdk.org/doc/guides/nics/fail_safe.html > > Actually, the failsafe supported features is the logical AND between all its sub devices supported features and failsafe default features. > > I think this table should reflect the failsafe default features. > > So if any PMD doesn't support that feature, it won't be supported, right? If so > why we are documented it as supported. > > Agree to document default features independent from what PMD supports, as I said > before "supported architectures and provided documents" etc.. > > > It is very useful for failsafe user to compare failsafe features and sub devices features to infer which feature is going to be supported with failsafe combination. > > > > In addition, > > Even if the PMD part is only to set capability bit (NIC related features capability) user must know that failsafe is going to set it. > > Still this depends on if PMD supports it or not. > > Out of curiosity, how failsafe set the underlying PMD features, automatically or > based on user request? I guess it checks that all PMDs support feature before > setting it. > Hi Ferruh, I won't comment on the rest of the discussion, as I see merit to both positions and I am still undecided about what is most interesting to the user. On your last question: For ether ops, the fail-safe relies on the public ether API of the sub-device eth_dev. For interrupts, the fail-safe relies on user request or on specific PMD support for RMV_EVENT: it doesn't matter if the other sub-device does not support the RMV event, if one PMD supports it it will be enabled. For offloads, the fail-safe will do a logical AND of offload amongst the sub-device PMDs and restrict those to this subset. If a plugged-in PMD has a different set of supported offloads, the fail-safe throws an error. Generally, sub-device PMDs are expected to closely match feature-wise. > > > >>> > >>>>> > >>>>>> OK for dropping "Stats per queue" > >>>>>> > >>>>>>> > >>>>> > >>> > > > -- Gaëtan Rivet 6WIND