From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by dpdk.org (Postfix) with ESMTP id 6110F5F25 for ; Fri, 21 Dec 2018 15:44:43 +0100 (CET) Received: by mail-wm1-f65.google.com with SMTP id b11so5553456wmj.1 for ; Fri, 21 Dec 2018 06:44:43 -0800 (PST) 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=XokHkfTQtuIWSsj4IyrboIZllwEtUo0aixdjrZZYe/U=; b=XLStCoNlsGL04cwMO3tAvOg8rX/axxBCWaoi4IpqH0kFpatrGfAxNwQswoRpyN1uz5 JNvnda/LBIH5oXrGA7Rm0X2iuwcn+gSRgSfaWJlmJPoqKzYf2EMkwiydeM22Pjg9hShM Bubg/s2OMYQ43Fi+JDCG94AgYrTd8UXDljBikB0vMZt4Le+UbiKZ3DD92NsVxu5JbB0H L7xV0kulOh+iniy2AjG3GZBeQFYtvLtFB66S8FNAL9lAbvdNlbFBBFJmg4RWvp01umOC XjDl6B+fkPkYbYydS77h5RLF2i31WrtxTUdlZsGRYYguy+EttnrekmHT4KIO9wTx1R6M LJ/A== 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=XokHkfTQtuIWSsj4IyrboIZllwEtUo0aixdjrZZYe/U=; b=jR6c0j1X5eR7XUAVAX6TSpz9pY3taTfQPuw4727FiyOlMwLk5Lg9v2Pt3vOPoxdi8h oKSZ66sfyrgl6Jc4RilV2LQ7gxIvqMp/ZYQ4zMZ9Nhl4Y0y0hZFlLPsAa0VSN1h7MiSM C12RrnfiB9BXeJAqMv3SetQAb03+ZbRUiWGI1tn4OWHCX/y2FkzX5WU+1BjKvvpKj3Zf OoXlinbkltsEP/tzZ6Oullskp+xfdLb8jlP+EMXxnEh8DmAoPwfWpbvHANxaCuEz8IZF g597kQLQ4K1H9aOjvbkbLv5NnxbPfcMD5up9IP50sb3ep3oZzrExcuRoammcVc5I7knw lPzA== X-Gm-Message-State: AJcUukdC9T9stjNAGgkMsfCWZfiYZwbs4jLkO+u2qIEWCczx4HzLyzd8 2OgntLdQYU4/i42tFtbP1Yq22Q== X-Google-Smtp-Source: AFSGD/WrLvJxh9MnW3NGRNMkun0n07uxxbyGWgtjkuqnKELPS5aK/Pm47mZ5n2KrR3yj7QFx3EdsiA== X-Received: by 2002:a7b:c218:: with SMTP id x24mr3149190wmi.58.1545403482812; Fri, 21 Dec 2018 06:44:42 -0800 (PST) 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 r12sm16171807wrq.3.2018.12.21.06.44.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 21 Dec 2018 06:44:41 -0800 (PST) Date: Fri, 21 Dec 2018 15:44:21 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Ferruh Yigit Cc: Andrew Rybchenko , dev@dpdk.org, Ivan Malov Message-ID: <20181221144421.szwkakqp7vbn5v5v@bidouze.vm.6wind.com> References: <1539344187-21481-1-git-send-email-arybchenko@solarflare.com> <585c9670-07b6-abfa-027d-e4d07febb7d4@intel.com> <969cb7e3-6e1a-f5ac-ed1b-e4334f928b17@solarflare.com> <20181221131646.2yqimi7rejnebrvd@bidouze.vm.6wind.com> <305c20be-125f-b521-56a9-93c4f3c79076@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <305c20be-125f-b521-56a9-93c4f3c79076@intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] net/failsafe: add default Tx mbuf fast free capability 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: Fri, 21 Dec 2018 14:44:43 -0000 On Fri, Dec 21, 2018 at 01:59:20PM +0000, Ferruh Yigit wrote: > On 12/21/2018 1:16 PM, Gaëtan Rivet wrote: > > Hi Ferruh, Andrew, > > > > On Fri, Dec 21, 2018 at 03:52:07PM +0300, Andrew Rybchenko wrote: > >> Hi Ferruh, > >> > >> On 12/21/18 3:43 PM, Ferruh Yigit wrote: > >>> On 12/21/2018 12:28 PM, Andrew Rybchenko wrote: > >>>> On 12/21/18 3:12 PM, Ferruh Yigit wrote: > >>>>> On 10/12/2018 12:36 PM, Andrew Rybchenko wrote: > >>>>>> From: Ivan Malov > >>>>>> > >>>>>> This capability is reported when supported by the current emitting > >>>>>> sub-device. Failsafe PMD itself does not excercise fast free logic. > >>>>> I think overlay device capability reporting already discussed a few times, the > >>>>> question is if an overlay devices should claim a feature when it depends on > >>>>> underlay devices? > >>>> The capability may be reported by the failsafe since it is transparent from > >>>> fast free logic point of view. > >>> Why it is transparent? If one of the underlying device doesn't support/claim > >>> this feature, application can't use this feature with failsafe, isn't it? > > > > If a VF is forbidden by its PF from adding MAC addresses, the driver > > should still advertize support for "Unicast MAC filter" right? > > > > This is the same here. Fail-safe needs to forward configurations items > > to its sub-device for a feature to work. Sometimes, the hardware won't > > be sufficient. But the fail-safe itself still has the parts needed (even > > if it is only a flag to add to a feature list). > > I see your point, also I think it may be misleading for an overlay device to > announce a feature which is completely depends underlay devices. Anyway this may > be a nuance. > > I am OK with the change after Andrew's explanation, and as far as I understand > you are OK too, may I add your explicit ack to the patch? > Yes the patch is ok for me, thank you Ferruh. > > > > It is necessary, at the fail-safe level, to be able to describe the > > current feature set. This is what the feature list is for. There are > > important caveats to consider however, which is inherent to using the > > fail-safe. > > > > It does not mean those features should be removed from the fail-safe > > feature list. > > > >> > >> tx_offload_capa in failsafe is a mask to apply on sub-device capabilities. > >> So, if the capability is not supported by any sub-device it will not be > >> reported. > >> As well if there is the capability bit in the mask, it will not be reported > >> regardless > >> sub-devices capabilities. The description for the patch above tries to > >> explain it - > >> it looks like not that successful. > >> > >>>>> Given that no ack/review given to the patch, I am updating it as rejected. > >>>> Is it a new policy? I thought that it was vice versa before. > >>> Hi Andrew, > >>> > >>> Yes policy is other-way around indeed, when there is no comment at all default > >>> behavior is accept, but please take above paragraph as my comment to the patch. > >> > >> Got it. > >> > >>> And I was thinking it is a little controversial and there is no support to have > >>> it, so lets don't get it. What do you think? > >> > >> I see you motivation. > >> > >>>>>> Signed-off-by: Ivan Malov > >>>>>> Signed-off-by: Andrew Rybchenko > >>>>>> --- > >>>>>> doc/guides/nics/features/failsafe.ini | 1 + > >>>>>> drivers/net/failsafe/failsafe_ops.c | 1 + > >>>>>> 2 files changed, 2 insertions(+) > >>>>>> > >>>>>> diff --git a/doc/guides/nics/features/failsafe.ini b/doc/guides/nics/features/failsafe.ini > >>>>>> index e3c4c08f2..b6f3dcee6 100644 > >>>>>> --- a/doc/guides/nics/features/failsafe.ini > >>>>>> +++ b/doc/guides/nics/features/failsafe.ini > >>>>>> @@ -7,6 +7,7 @@ > >>>>>> Link status = Y > >>>>>> Link status event = Y > >>>>>> Rx interrupt = Y > >>>>>> +Fast mbuf free = Y > >>>>>> Queue start/stop = Y > >>>>>> Runtime Rx queue setup = Y > >>>>>> Runtime Tx queue setup = Y > >>>>>> diff --git a/drivers/net/failsafe/failsafe_ops.c b/drivers/net/failsafe/failsafe_ops.c > >>>>>> index 7f8bcd4c6..e3add404b 100644 > >>>>>> --- a/drivers/net/failsafe/failsafe_ops.c > >>>>>> +++ b/drivers/net/failsafe/failsafe_ops.c > >>>>>> @@ -78,6 +78,7 @@ static struct rte_eth_dev_info default_infos = { > >>>>>> DEV_RX_OFFLOAD_SECURITY, > >>>>>> .tx_offload_capa = > >>>>>> DEV_TX_OFFLOAD_MULTI_SEGS | > >>>>>> + DEV_TX_OFFLOAD_MBUF_FAST_FREE | > >>>>>> DEV_TX_OFFLOAD_IPV4_CKSUM | > >>>>>> DEV_TX_OFFLOAD_UDP_CKSUM | > >>>>>> DEV_TX_OFFLOAD_TCP_CKSUM | > >>>>>> > >> > > > -- Gaëtan Rivet 6WIND