From: Ivan Malov <ivan.malov@oktetlabs.ru>
To: dev@dpdk.org
Cc: Ori Kam <orika@nvidia.com>, Eli Britstein <elibr@nvidia.com>,
Ilya Maximets <i.maximets@ovn.org>,
Thomas Monjalon <thomas@monjalon.net>,
Stephen Hemminger <stephen@networkplumber.org>,
Jerin Jacob <jerinj@marvell.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Ferruh Yigit <ferruh.yigit@xilinx.com>
Subject: [PATCH 09/13] doc: rework VF-related explanations in switch representation
Date: Fri, 12 Aug 2022 22:18:23 +0300 [thread overview]
Message-ID: <20220812191827.3187441-10-ivan.malov@oktetlabs.ru> (raw)
In-Reply-To: <20220812191827.3187441-1-ivan.malov@oktetlabs.ru>
The paragraph describing flow operation without representors
shows the use of traffic direction attributes in combination
with attribute "transfer". Such scenario has been deprecated.
Also, the paragraph mentions the use of deprecated action VF.
Drop irrelevant parts, adjust remaining text and the diagram.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
.../prog_guide/switch_representation.rst | 83 +++++++------------
1 file changed, 29 insertions(+), 54 deletions(-)
diff --git a/doc/guides/prog_guide/switch_representation.rst b/doc/guides/prog_guide/switch_representation.rst
index 9369e6e04c..3da30fc779 100644
--- a/doc/guides/prog_guide/switch_representation.rst
+++ b/doc/guides/prog_guide/switch_representation.rst
@@ -468,64 +468,39 @@ Without Port Representors
`Traffic direction`_ describes how an application could match traffic coming
from or going to a specific place reachable from a DPDK port ID. This makes
sense when the traffic in question is normally seen (i.e. sent or received)
-by the application creating the flow rule (e.g. as in "redirect all traffic
-coming from VF 1 to local queue 6").
-
-However this does not force such traffic to take a specific route. Creating
-a flow rule on **A** matching traffic coming from **D** is only meaningful
-if it can be received by **A** in the first place, otherwise doing so simply
-has no effect.
-
-A new flow rule attribute named "transfer" is necessary for that. Combining
-it with "ingress" or "egress" and a specific origin requests a flow rule to
-be applied at the lowest level
-
-::
-
- ingress only : ingress + transfer
- :
- .-------------. .-------------. : .-------------. .-------------.
- | hypervisor | | VM 1 | : | hypervisor | | VM 1 |
- | application | | application | : | application | | application |
- `------+------' `--+----------' : `------+------' `--+----------'
- | | | traffic : | | | traffic
- .----(A)----. | v : .----(A)----. | v
- | port_id 3 | | : | port_id 3 | |
- `-----+-----' | : `-----+-----' |
- | | : | ^ |
- | | : | | traffic |
- .-+--. .---+--. : .-+--. .---+--.
- | PF | | VF 1 | : | PF | | VF 1 |
- `-+--' `--(D)-' : `-+--' `--(D)-'
- | | | traffic : | ^ | | traffic
- | | v : | | traffic | v
- .--+-----------+--. : .--+-----------+--.
- | interconnection | : | interconnection |
- `--------+--------' : `--------+--------'
- | | traffic : |
- | v : |
- .---(F)----. : .---(F)----.
- | physical | : | physical |
- | port 0 | : | port 0 |
- `----------' : `----------'
-
-With "ingress" only, traffic is matched on **A** thus still goes to physical
-port **F** by default
-
-
-::
-
- testpmd> flow create 3 ingress pattern vf id is 1 / end
- actions queue index 6 / end
-
-With "ingress + transfer", traffic is matched on **D** and is therefore
-successfully assigned to queue 6 on **A**
+by the application creating the flow rule.
+However, if there is an entity (VF **D**, for instance) not associated with
+a DPDK port (representor), the application (**A**) won't be able to match
+traffic generated by such entity. The traffic goes directly to its
+default destination (to physical port **F**, for instance).
::
- testpmd> flow create 3 ingress transfer pattern vf id is 1 / end
- actions queue index 6 / end
+ .-------------. .-------------.
+ | hypervisor | | VM 1 |
+ | application | | application |
+ `------+------' `--+----------'
+ | | | traffic
+ .----(A)----. | v
+ | port_id 3 | |
+ `-----+-----' |
+ | |
+ | |
+ .-+--. .---+--.
+ | PF | | VF 1 |
+ `-+--' `--(D)-'
+ | | | traffic
+ | | v
+ .--+-----------+--.
+ | interconnection |
+ `--------+--------'
+ | | traffic
+ | v
+ .---(F)----.
+ | physical |
+ | port 0 |
+ `----------'
With Port Representors
--
2.30.2
next prev parent reply other threads:[~2022-08-12 19:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-12 19:18 [PATCH 00/13] ethdev: proceed with flow subsystem rework Ivan Malov
2022-08-12 19:18 ` [PATCH 01/13] ethdev: strip experimental tag off Rx metadata negotiate API Ivan Malov
2022-08-12 19:18 ` [PATCH 02/13] ethdev: strip experimental tag off port ID items and actions Ivan Malov
2022-08-15 12:59 ` Ori Kam
2022-08-12 19:18 ` [PATCH 03/13] ethdev: remove experimental tag from flow transfer proxy API Ivan Malov
2022-08-15 12:58 ` Ori Kam
2022-08-12 19:18 ` [PATCH 04/13] net/dpaa2: support represented port flow action Ivan Malov
2022-08-12 19:18 ` [PATCH 05/13] net/cnxk: " Ivan Malov
2022-08-12 19:18 ` [PATCH 06/13] app/testpmd: add port steering targets to sample " Ivan Malov
2022-08-12 19:18 ` [PATCH 07/13] doc: revisit outdated flow rule examples in testpmd tutorial Ivan Malov
2022-08-12 19:18 ` [PATCH 08/13] doc: add new port items and actions to switch representation Ivan Malov
2022-08-12 19:18 ` Ivan Malov [this message]
2022-08-12 19:18 ` [PATCH 10/13] ethdev: remove deprecated flow item PF Ivan Malov
2022-08-22 5:32 ` Ori Kam
2022-08-12 19:18 ` [PATCH 11/13] ethdev: remove deprecated flow item VF Ivan Malov
2022-08-22 5:50 ` Ori Kam
2022-08-12 19:18 ` [PATCH 12/13] ethdev: remove deprecated flow item PHY PORT Ivan Malov
2022-08-22 5:33 ` Ori Kam
2022-09-27 7:08 ` Thomas Monjalon
2022-09-27 16:18 ` Ajit Khaparde
2022-08-12 19:18 ` [PATCH 13/13] ethdev: remove deprecated flow action " Ivan Malov
2022-08-22 5:33 ` Ori Kam
2022-09-27 8:32 ` [PATCH 00/13] ethdev: proceed with flow subsystem rework Thomas Monjalon
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=20220812191827.3187441-10-ivan.malov@oktetlabs.ru \
--to=ivan.malov@oktetlabs.ru \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=elibr@nvidia.com \
--cc=ferruh.yigit@xilinx.com \
--cc=i.maximets@ovn.org \
--cc=jerinj@marvell.com \
--cc=orika@nvidia.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/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).