[09/13] doc: rework VF-related explanations in switch representation
Checks
Commit Message
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(-)
@@ -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