From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 012E0A0C4E;
	Thu, 22 Jul 2021 13:07:47 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 820D04014D;
	Thu, 22 Jul 2021 13:07:47 +0200 (CEST)
Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com
 [209.85.167.42]) by mails.dpdk.org (Postfix) with ESMTP id 2F32B40040
 for <dev@dpdk.org>; Thu, 22 Jul 2021 13:07:46 +0200 (CEST)
Received: by mail-lf1-f42.google.com with SMTP id a12so7875277lfb.7
 for <dev@dpdk.org>; Thu, 22 Jul 2021 04:07:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to
 :mime-version:content-transfer-encoding;
 bh=9PS8g6TZpySNPqvGx7SPwK+eEhN8xpLEDrGch3TN438=;
 b=ZJ98hNsu3GHS5peOZNyJHSx6otHkwTSModnw+Pwo2yu7mjpnxgz48ScDIVTyTlkYGw
 jrQp9ECPqmylPlWjDDdmqN91f6zaEdUw0/egBMPUQS7gBa+jXOEkZnh5H1igqt8XuHom
 147MwlWQifzp6HK5PPCqg2FJHB0efawZFSMe3S2vBMI/IEpMFrfNxW1OqOc5yttpjWHo
 bvBHFmbhFQ6G3UzweN5blw373hRfvJ1HmDy9vjtJ9raW/o9ocAKeH/SEZJfpNPg5y5uZ
 dCCpeNUydrxFdbR6kTbvKHq/6Wj04OA388fJxVIGHb0gRsySFIud/i4LStzIOTmIE3DW
 cOeg==
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:in-reply-to
 :references:reply-to:mime-version:content-transfer-encoding;
 bh=9PS8g6TZpySNPqvGx7SPwK+eEhN8xpLEDrGch3TN438=;
 b=ZITI7JryNK69K3tdFOFGX/tQJA7RSyjYBMADPCrEIFDW65TaHSoBMtXTef3Po72pl0
 4f5Gk5WZXGacD65TGZbArYTb94d3nvXebUPYFF2XhYWtQ8kUayu9VfuDdfI4E+mdNxA3
 pTwEz7gXLWCy/v9kMVvdDqrDR3Q54JBojWTvgnKnz3fdKCiHxrR1+g22yv6yLlDhn8v+
 vPpB/M7NjpMwIbW7vQkXiAodOV2HF3V5yniBlrLvyg2sF1fHaRmKvuUzP7RQJX7UKYqm
 /N/HhQTExkrLmpLB2SGTScpXGT+S2I9HDSJI0q3DRs8L3Y23q0QBW/TfBWe7xo7o2PlR
 535A==
X-Gm-Message-State: AOAM5309vdfb97cnyxuDRBLdfKpQnuay8CNta59nJrHDo7TnDiCFYH93
 hs70K3MQjoEygZKdBPqh7gY=
X-Google-Smtp-Source: ABdhPJxwqKmweoLidJknNCLAy+ESyex2c/tYpRoxnHPRnAleH6bq8M2r52p6CnVzAstbAFzkWW4pWA==
X-Received: by 2002:a05:6512:cf:: with SMTP id
 c15mr30063104lfp.317.1626952065641; 
 Thu, 22 Jul 2021 04:07:45 -0700 (PDT)
Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru.
 [37.110.65.23])
 by smtp.gmail.com with ESMTPSA id h1sm1952988lfk.187.2021.07.22.04.07.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 Jul 2021 04:07:45 -0700 (PDT)
Date: Thu, 22 Jul 2021 14:07:43 +0300
From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: Martin Havlik <xhavli56@stud.fit.vutbr.cz>, Matan Azrad
 <matan@nvidia.com>, Shahaf Shuler <shahafs@nvidia.com>, Viacheslav
 Ovsiienko <viacheslavo@nvidia.com>, Thomas Monjalon <thomas@monjalon.net>,
 Asaf Penso <asafp@nvidia.com>, Jiawei Wang <jiaweiw@nvidia.com>, Bing Zhao
 <bingz@nvidia.com>, Xueming Li <xuemingl@nvidia.com>, Tal Shnaiderman
 <talshn@nvidia.com>, Shun Hao <shunh@nvidia.com>, Ciara Power
 <ciara.power@intel.com>, Bruce Richardson <bruce.richardson@intel.com>,
 Michael Baum <michaelba@nvidia.com>, Raslan Darawsheh <rasland@nvidia.com>,
 dev@dpdk.org, Jan Viktorin <viktorin@cesnet.cz>
Message-ID: <20210722140743.10a0634f@sovereign>
In-Reply-To: <b4a15a30-f127-d882-b8cb-9bdc036ba217@oktetlabs.ru>
References: <20210721155550.188663-2-xhavli56@stud.fit.vutbr.cz>
 <b4a15a30-f127-d882-b8cb-9bdc036ba217@oktetlabs.ru>
X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH 1/4] doc: clarify RTE flow behaviour on port
 stop/start
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
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>
Reply-To: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2021-07-22 13:32 (UTC+0300), Andrew Rybchenko:
> On 7/21/21 6:55 PM, Martin Havlik wrote:
> > It is now clearly stated that RTE flow rules can be
> > created only after the port is started.
> > 
> > Signed-off-by: Martin Havlik <xhavli56@stud.fit.vutbr.cz>
> > ---
> >   doc/guides/nics/mlx5.rst | 6 +++++-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
> > index f5b727c1ee..119d537adf 100644
> > --- a/doc/guides/nics/mlx5.rst
> > +++ b/doc/guides/nics/mlx5.rst
> > @@ -1790,21 +1790,25 @@ Notes for rte_flow
> >   ------------------
> >   
> >   Flows are not cached in the driver.
> >   When stopping a device port, all the flows created on this port from the
> >   application will be flushed automatically in the background.
> >   After stopping the device port, all flows on this port become invalid and
> >   not represented in the system.
> >   All references to these flows held by the application should be discarded
> >   directly but neither destroyed nor flushed.
> >   
> > -The application should re-create the flows as required after the port restart.
> > +The application should re-create the flows as required after the port is
> > +started again.
> > +
> > +Creating flows before port start is not permitted. All flows the application
> > +wants to create have to be created after the port is started.  
> 
> I'm not 100% sure that it is always OK for applications, but in an
> attempt to make it OK we should:
>   - mention isolated mode if application dislikes default flow rules and
>     would like to control it
>   - mention what happens if restart happens internally, e.g. in order to
>     recover from broken state. I guess in this case we need an event and
>     application must register callback and handle it.

I think this callback would be an unnecessary complication.
What is the notion of internal restart or recovery event, in the first place?

Port can move to some "inconsistent state" (from rte_flow_flush description).
What this means is unspecified, I guess in this state the port can only be
stopped or closed if it's not started. Which brings the port to a consistent
state where the behavior is already specified.