From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D9950A04B3; Mon, 16 Dec 2019 08:39:04 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5EDD01C127; Mon, 16 Dec 2019 08:39:04 +0100 (CET) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id 4EB1E1C126 for <dev@dpdk.org>; Mon, 16 Dec 2019 08:39:03 +0100 (CET) Received: by mail-io1-f66.google.com with SMTP id a22so5914775ios.3 for <dev@dpdk.org>; Sun, 15 Dec 2019 23:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xcSB0TMBuVqwICa/g3Q2XM2OshD9NvTRz6gHUTRPxAI=; b=Pp3vluSa3C8Q+7L4JW6cfPdwuvOcXdmorOY7C/cYbZ76wtE7yOnB4UFVOg3Xpbz7zS eja8v7QFFaEaA8arWz/ergNnKVsF5eINo/uJFuBs76QJ0ENVus9nyeBKV/KpErf2N803 m2oiNw+epMiTiBrO4Q5SERqOl2RU9pGSdwE9+iJhBgGJUD72bav/10UMlT+dQX1dL1h3 VNwNRozTVBfV+D5l+tY93HVVhGHu5vMg2lcsF5Ad9Ykk+WqFSjyAhn+Mm4+jYje12hAj 8bHhRAUZNASmYnqgpqgfg76hXn0cawmakKuzfgm14s5vIddzvJpo6J34rBOOVO2MVNlC CvtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xcSB0TMBuVqwICa/g3Q2XM2OshD9NvTRz6gHUTRPxAI=; b=I4zW4adxbX/XRkXlLwu42XjqiJd+y67HrlKEMAsScGk6rqBJS1YLJbWGVW/X8E+U30 rNcMk6mytJKUTROO5HixGg39GVqLwFoAODV9U106RxkxaogwmUkxb0glpEKgFK+8HkjV 7QSl5aCK7VusAtchswGytqMvc0sUronGcCRUhLfGPKttC3w8D6EDqvvTubXRlI9QeKu4 WdNoF0Igipcb/M7W4oi5tTPLk18htKtflWkrCaKc1GC20ew4Zf4h34u5Xmc4xOEbGsZP Y5sIhsdC6cWTLYR3I7OSOkDA4rtbslp+hjBjTI0xQyZV6Ub5jqMb/mo0S4eacFPMH8Vk +orA== X-Gm-Message-State: APjAAAXU3GdnyljGG8eUPjTOLvAe/m4izS0vq521Jldiz1bWjGPBwaS1 wadzGIN5tx2z0Zis2ZHC06RR4VQMmR+3Zhfx43g= X-Google-Smtp-Source: APXvYqzh/zzQ1yLZt8CXQ7fqfgIBmUbybM3Jwb1DmI/nfz+HooiTiC73NVPEJPqxPhDVZuheQ27HwzXk9L2l4UuuijE= X-Received: by 2002:a5e:8516:: with SMTP id i22mr17950025ioj.130.1576481942378; Sun, 15 Dec 2019 23:39:02 -0800 (PST) MIME-Version: 1.0 References: <1574165145-23960-1-git-send-email-arybchenko@solarflare.com> <1788171.neaCWyZYis@xps> <CALBAE1MFRoMfPj2foiTY0mk-kCZWeSTvGERT0rGRj8F-m5OR+g@mail.gmail.com> <1832509.BOePYM8p3J@xps> <CALBAE1OA5wukbT-WVeOx_qhrbqg6F=3kJU_EEDcB0k0j+UaERA@mail.gmail.com> <f84e8ca3-9fa2-7441-1024-edae7e2d4dcf@solarflare.com> <CALBAE1NsZ9FiEmhEyv2g=R+_7vcnC5JwiFM0vSAFwNXH2auAfA@mail.gmail.com> <12030c31-8a03-ca14-272f-e3bc01652721@solarflare.com> In-Reply-To: <12030c31-8a03-ca14-272f-e3bc01652721@solarflare.com> From: Jerin Jacob <jerinjacobk@gmail.com> Date: Mon, 16 Dec 2019 13:08:46 +0530 Message-ID: <CALBAE1OEjcLN+bmah4j5ZBRMNo=4_jDQgS=oEM9PpuYiSA6LXw@mail.gmail.com> To: Andrew Rybchenko <arybchenko@solarflare.com> Cc: Thomas Monjalon <thomas@monjalon.net>, Ferruh Yigit <ferruh.yigit@intel.com>, Pavan Nikhilesh <pbhagavatula@marvell.com>, Neil Horman <nhorman@tuxdriver.com>, John McNamara <john.mcnamara@intel.com>, Marko Kovacevic <marko.kovacevic@intel.com>, dpdk-dev <dev@dpdk.org>, Ori Kam <orika@mellanox.com>, David Marchand <david.marchand@redhat.com>, Olivier Matz <olivier.matz@6wind.com>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com> Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 3/3] ethdev: improve flow mark Rx offload deprecation notice X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Mon, Dec 9, 2019 at 2:47 PM Andrew Rybchenko <arybchenko@solarflare.com> wrote: > > On 12/5/19 11:12 AM, Jerin Jacob wrote: > > On Mon, Dec 2, 2019 at 5:27 PM Andrew Rybchenko > > <arybchenko@solarflare.com> wrote: > >> >> >>> > >>> Ack. > >> > >> Yes, I agree as well, but in general we already have an > >> exception MBUF_FAST_FREE which is just a nice wrap for > >> enabled by default support for mbufs from different > >> mempools and support for mbuf reference counters. > >> I don't suggest to change it. Just want to highlight > >> that we already have exceptions (nicely wrapped). > >> That's why I would not touch packet type parsing > >> "offload". Packet type parsing is not just on/off and > >> adding on/off in addition to existing API looks overkill. > >> Yes, it is one more exception, but nicely wrapped as well. > > > > I am all for making offloads disabled by default. > > > >> > >>>>> And what would be DEFAULT behavior for the mbuf MARK updation feature? > >>>>> (That's where this thread started). > >>>> > >>>> As all other features, mark is disabled by default. > >>>> Using a rte_flow rule, it can be enabled. > >>>> No need to pre-enable it. > >>> > >>> Ok. > >> > >> But it returns us to the point where we started [1]: > >> > >> The problem: > >> ~~~~~~~~~~~~ > >> PMD wants to know before port start if application wants to > >> to use flow MARK/FLAG in the future. It is required because: > >> > >> 1. HW may be configured in a different way to reserve resources > >> for MARK/FLAG delivery. > >> > >> 2. Datapath implementation choice may depend on it (e.g. vPMD > >> is faster, but does not support MARK). > >> > >> opt-in/opt-out solution has drawbacks mentioned above. > >> Also I'm not sure if opt-in/opt-out is per-queue or per-port. > >> (Offloads may be naturally per-queue and it is a big advantage). > >> > >> IMHO feature which should be opt-out is almost equivalent to > >> offload enabled by default. It has the same negative properties > >> as enabled by default offloads. > >> > >> Am I missing something again? > >> > >> From my point of view I see no problem in necessity to say > >> in advance (before device start) that application would like > >> to use some features at run time. > > > > I agree with your problem definition and solution as offload. > > > > I think, our constraint is, we can not change functional ABI behavior > > for the next year. i.e The existing application should work for the > > next year without > > changing the code. > > > > I think, it all boiling down to adhere to that constraint or not for > > this specific case. > > May be the escape is to avoid consistency checks in generic > code (not sure that such checks are doable/required in this > case, but anyway) and make the behaviour change vendor/driver- > specific. I understand that it is far from ideal solution. > > May be offload should be combined with opt-out as a way to > disable. I.e. offload is positive (not negative), but enabled > by default (i.e. automatically added to offloads as we do > for RSS_HASH) with an experimental opt-out to disable it. > > As the result: > 1. There is no changes in behaviour from application point of > view. > 2. Application which care about performance and ready to use > experimental opt-out to optimize performance can do it. > (i.e. use opt-out to avoid the offload enabled by default). > 3. Later when window to normalize behaviour opens, opt-out > becomes NOP (i.e. it still could be preserved for some > time to simplify transition). > 4. The offload is enabled by default during transition > period only since it represents a feature which had > no offload flag before and was always enabled before. > 5. As an offload the feature may be controlled per-device > and per-queue natively. Looks good to me. It makes sense to have a generic opt API to have for year ABI, which works on - per queue/per port - Enable by default to keep backward compatible. - Have a generic signature to allow probe() all the enabled opt-in features and then disable if required by the application. - I think, rte_eth_dev_set_ptypes() needs to change to generic API as it comes under opt-in/out scheme. > > It still does not sort out "necessity to enable twice" > concern which for specified above "the problem", IMO, > contradicts to "disabled by default offloads" (I read > it as "the best performance" by default). > > > Once that is decided, we can wrap it in offload flags vs opt scheme > > (by default enabled scheme). > > Yes. May be I don't understand all the details of the opt > scheme right now, but I don't like what I can imagine as > described above. > > >> > >> Yes, all features which may be controlled at run-time are > >> headache for optimizations (VLAN offloads). > >> > >> [1] > >> http://inbox.dpdk.org/dev/f170105b-9c60-1b04-cb18-52e0951ddcdb@solarflare.com/ >