DPDK patches and discussions
 help / color / mirror / Atom feed
From: Matan Azrad <matan@mellanox.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
	Gaetan Rivet <gaetan.rivet@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"john.mcnamara@intel.com" <john.mcnamara@intel.com>
Subject: Re: [dpdk-dev] [PATCH] doc: update failsafe feature list
Date: Thu, 2 Nov 2017 05:53:56 +0000	[thread overview]
Message-ID: <HE1PR0502MB36594785F0D58B5FC4C0E085D25C0@HE1PR0502MB3659.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <fbe5a084-bd1c-d2f1-6a4e-41ec24931b07@intel.com>

Hi Ferruh, Gaetan

> -----Original Message-----
> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com]
> Sent: Thursday, November 2, 2017 12:34 AM
> To: Matan Azrad <matan@mellanox.com>; Gaetan Rivet
> <gaetan.rivet@6wind.com>
> Cc: dev@dpdk.org; john.mcnamara@intel.com
> Subject: Re: [dpdk-dev] [PATCH] doc: update failsafe feature list
> 
> On 10/25/2017 11:44 AM, 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 <matan@mellanox.com>; Gaetan Rivet
> >>> <gaetan.rivet@6wind.com>
> >>> 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 <matan@mellanox.com>; Gaetan Rivet
> >>>>> <gaetan.rivet@6wind.com>
> >>>>> 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 <matan@mellanox.com>; Gaetan Rivet
> >>>>>>> <gaetan.rivet@6wind.com>
> >>>>>>> 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 <matan@mellanox.com>
> >>>>>>>> ---
> >>>>>>>>  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.
> 
> Nak for the patch, its status updated in patchwork.
> 
Why?
It should be superseded later, the stats per queue should be removed any way.
 Moreover, I think we should solve it in a different way if you don't agree to mark them as supported.
Maybe we can add special sign to this table or add star in failsafe name(maybe change color) and explain there that any supported feature by failsafe depends on sub devices support.
User must know all the features allowed by failsafe otherwise we should remove all of the failsafe feature in this table(because all of them depend on sub devices support ).
What do you think?

> >
> >> Please read section 31.1 in failsafe documentation:
> >>
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpd
> >>
> k.org%2Fdoc%2Fguides%2Fnics%2Ffail_safe.html&data=02%7C01%7Cmatan
> %40m
> >>
> ellanox.com%7C3ad1faf403e14c85ad6508d5217899ea%7Ca652971c7d2e4d9b
> a6a4
> >>
> d149256f461b%7C0%7C0%7C636451724233800703&sdata=i1si8wQIGS3GSqG
> WI2LyK
> >> 19N6oUMeVA07rzkmSkgZXk%3D&reserved=0
> >> 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.
> >
> >>
> >>>>
> >>>>>>
> >>>>>>> OK for dropping "Stats per queue"
> >>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> >


  reply	other threads:[~2017-11-02  5:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-14 15:32 Matan Azrad
2017-09-18 13:51 ` Mcnamara, John
2017-09-19  9:27 ` Ferruh Yigit
2017-09-19 10:04   ` Matan Azrad
2017-09-19 11:00     ` Ferruh Yigit
2017-09-19 11:39       ` Matan Azrad
2017-09-22 10:32         ` Ferruh Yigit
2017-09-24  5:55           ` Matan Azrad
2017-10-25 18:44             ` Ferruh Yigit
2017-10-25 22:55               ` Gaëtan Rivet
2017-11-01 22:33               ` Ferruh Yigit
2017-11-02  5:53                 ` Matan Azrad [this message]
2017-11-02 17:48                   ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=HE1PR0502MB36594785F0D58B5FC4C0E085D25C0@HE1PR0502MB3659.eurprd05.prod.outlook.com \
    --to=matan@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=gaetan.rivet@6wind.com \
    --cc=john.mcnamara@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).