From patchwork Fri Aug 12 19:18:23 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ivan Malov X-Patchwork-Id: 114941 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 54BFAA0543; Fri, 12 Aug 2022 21:19:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CE23642C4D; Fri, 12 Aug 2022 21:18:38 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 6606540A7F for ; Fri, 12 Aug 2022 21:18:31 +0200 (CEST) Received: from bree.oktetlabs.ru (bree.oktetlabs.ru [192.168.34.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPS id 38B90C5; Fri, 12 Aug 2022 22:18:31 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 38B90C5 Authentication-Results: shelob.oktetlabs.ru/38B90C5; dkim=none; dkim-atps=neutral From: Ivan Malov To: dev@dpdk.org Cc: Ori Kam , Eli Britstein , Ilya Maximets , Thomas Monjalon , Stephen Hemminger , Jerin Jacob , Andrew Rybchenko , Ferruh Yigit Subject: [PATCH 09/13] doc: rework VF-related explanations in switch representation Date: Fri, 12 Aug 2022 22:18:23 +0300 Message-Id: <20220812191827.3187441-10-ivan.malov@oktetlabs.ru> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220812191827.3187441-1-ivan.malov@oktetlabs.ru> References: <20220812191827.3187441-1-ivan.malov@oktetlabs.ru> MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 Reviewed-by: Andrew Rybchenko --- .../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