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 1C04CA0093;
Tue, 8 Nov 2022 16:25:30 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id DE0E940151;
Tue, 8 Nov 2022 16:25:29 +0100 (CET)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com
[66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 5612C400D4
for <dev@dpdk.org>; Tue, 8 Nov 2022 16:25:28 +0100 (CET)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
by mailout.nyi.internal (Postfix) with ESMTP id BC7FC5C012A;
Tue, 8 Nov 2022 10:25:26 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
by compute4.internal (MEProxy); Tue, 08 Nov 2022 10:25:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
cc:cc:content-transfer-encoding:content-type:date:date:from:from
:in-reply-to:in-reply-to:message-id:mime-version:references
:reply-to:sender:subject:subject:to:to; s=fm1; t=1667921126; x=
1668007526; bh=tte2YXVMsObjCdBv0ML2iCySaahQYci3TYAO+ijOf8o=; b=C
mYMCCmBGEsKlBLTbcg0Au3VJUxGYqEJt4ciP8pYwZKGbiHcAKFc1zDTr/9BnUcmS
cxScPGyWO3T8v1OEAaRarcM494++UJGNdltQNg1bNSzkDQ4HzeLHmBDWgcZ2gSjA
+V+CFZkQPO2Sah3LJroO2RLia9Q+r01BOLX37rbDYwzQumoth/FlOZGTwOLxjz6e
CzXkrK1ULwVfhcPCOfIcDfK8HaWphzgOlkxrsqPNDrpipIy6kPtMh6RECliQ7hKY
sgRVvdwfB7jXmR8Y0egupBDKyNX4aFMkty5VmQ9xxC2GpM0A88emVFyEjJGnJV/K
+y5DzYRgeImOfk/9n/KGg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:date:date:feedback-id:feedback-id:from:from
:in-reply-to:in-reply-to:message-id:mime-version:references
:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1667921126; x=
1668007526; bh=tte2YXVMsObjCdBv0ML2iCySaahQYci3TYAO+ijOf8o=; b=b
Q9LXwIl9O+Ywq6pvxjkLsZkNSpCRmulilap5eDMIl1FyhqO1OQUzxWSQQwcTPEho
J904lxk1Dv4CC6KwDKAxAaFSmDxJCXDESGo01MP5mosDG3WDdp9LeSsuDYBK5eX9
TKYA8LNLfYPDd5qUyE+uEpDahaybDUKwzalicwM3ZzVEwuxY9df19sO/l0qg1MnL
9IpvwAN5whrfuyX0XYmprEIRNwyJ2hLaj1eVQ7TMIcaqcSNz9d5qgqhumYXcvFrM
VtXixzxbBvPWo/HFwXB1JdRWVV08FYrKH+D59CGae1XT1NY1kI6vJyf5aHqoBYKY
UKHn1bjzYdSy9EoeQLMjA==
X-ME-Sender: <xms:5nRqY_oimPoBeVG_oM9TG9zh-_dOhTE48GMMFUCBE6z6GhGAy6WjrQ>
<xme:5nRqY5qcobSeNsdGSJiWEuEI_-QIPSZpeo88tnIsvWxWynELi57lR60KKD-FCTmJt
wfrI7X90CbT8DkmBw>
X-ME-Received: <xmr:5nRqY8Nh2vxtoyMxmFVUZir8nC-Gy5k0aUcCWXhlcJ4nDWov6Ru0BJ0bk2CyZyPYBssGh61pLi2tA0AMXSxIrt3lRw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedtgdejkecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek
gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh
homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:5nRqYy4-eFucM88HXCVkZJMC3cIiikiUwcHef-x1hEg8YgnGjjpjXg>
<xmx:5nRqY-6Ru2wtjqDuH8z1ki07CCtvIX6uVfzh2Et7-8zRWuBJIXVpgQ>
<xmx:5nRqY6iSRz2VfdeFkbs27GKUNeItI8D9MW4UtySGGC2cOM1mugWQfg>
<xmx:5nRqYwtBQYxrsFip2-anGGmFPHbpQ7rz18ABV22RbYTroFX0SKc02Q>
Feedback-ID: i47234305:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
8 Nov 2022 10:25:25 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: Rongwei Liu <rongweil@nvidia.com>, matan@nvidia.com, viacheslavo@nvidia.com,
orika@nvidia.com, Aman Singh <aman.deep.singh@intel.com>,
Yuying Zhang <yuying.zhang@intel.com>, Ferruh Yigit <ferruh.yigit@amd.com>,
dev@dpdk.org, rasland@nvidia.com
Subject: Re: [PATCH v4] ethdev: add special flags when creating async transfer
table
Date: Tue, 08 Nov 2022 16:25:23 +0100
Message-ID: <1712111.oqx4rD5t72@thomas>
In-Reply-To: <ff20d7fb-6945-6e6b-3d03-14e724d70123@oktetlabs.ru>
References: <cc84a711-22a5-7bb6-3d22-08e9f88ee0b7@oktetlabs.ru>
<2068231.htQpZWrp2x@thomas>
<ff20d7fb-6945-6e6b-3d03-14e724d70123@oktetlabs.ru>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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>
Errors-To: dev-bounces@dpdk.org
08/11/2022 15:38, Andrew Rybchenko:
> On 11/8/22 16:29, Thomas Monjalon wrote:
> > 08/11/2022 12:47, Andrew Rybchenko:
> >> On 11/8/22 14:39, Andrew Rybchenko wrote:
> >>> On 11/4/22 13:44, Rongwei Liu wrote:
> >>>> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> >>>> index 8858b56428..1eab12796f 100644
> >>>> --- a/lib/ethdev/rte_flow.h
> >>>> +++ b/lib/ethdev/rte_flow.h
> >>>> @@ -5186,6 +5186,34 @@ rte_flow_actions_template_destroy(uint16_t
> >>>> port_id,
> >>>> */
> >>>> struct rte_flow_template_table;
> >>>> +/**
> >>>> + * @warning
> >>>> + * @b EXPERIMENTAL: this API may change without prior notice.
> >>>> + *
> >>>> + * Special optional flags for template table attribute.
> >>>> + * Each bit stands for a table specialization
> >>>> + * offering a potential optimization at PMD layer.
> >>>> + * PMD can ignore the unsupported bits silently.
> >>>> + */
> >>>> +enum rte_flow_template_table_specialize {
> >>>> + /**
> >>>> + * Specialize table for transfer flows which come only from wire.
> >>>> + * It allows PMD not to allocate resources for non-wire
> >>>> originated traffic.
> >>>> + * This bit is not a matching criteria, just an optimization hint.
> >>>> + * Flow rules which match non-wire originated traffic will be missed
> >>>> + * if the hint is supported.
> >>
> >> Sorry, but if so, the hint changes behavior.
> >
> > Yes the hint may change behaviour.
> >
> >> Let's consider a rule which matches both VF originating and
> >> wire originating traffic. Will the rule be missed (ignored)
> >> regardless if the hint is supported or not?
> >
> > If the hint RTE_FLOW_TRANSFER_WIRE_ORIG is used,
> > the PMD may assume the table won't be used for traffic
> > which is not coming from wire ports.
> > As a consequence, the table may be implemented on the path
> > of wire traffic only.
> > In this case, the traffic coming from virtual ports
> > won't be affected by this table.
> > To answer the question, a rule matching both virtual and wire traffic
> > will be applied in a table affecting only wire traffic,
> > so it will still apply (not completely ignored).
>
> If so, it is not a hint. It becomes matching criteria
> which should be in pattern as we discussed.
It is not a strict matching because the PMD is free to support it or not.