From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kovacevic, Marko" Subject: Re: [PATCH v7 1/9] doc: add switch representation documentation Date: Mon, 16 Apr 2018 15:55:07 +0000 Message-ID: <6DC05C7C5F25994B81B3F2F214251F6635FD3B@IRSMSX103.ger.corp.intel.com> References: <20180328135433.20203-1-declan.doherty@intel.com> <20180416130605.6509-1-declan.doherty@intel.com> <20180416130605.6509-2-declan.doherty@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Adrien Mazarguil , "Yigit, Ferruh" , Thomas Monjalon , "Shahaf Shuler" , "Doherty, Declan" , Adrien Mazarguil To: "Doherty, Declan" , "dev@dpdk.org" Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 9CD4EAAD0 for ; Mon, 16 Apr 2018 17:55:13 +0200 (CEST) In-Reply-To: <20180416130605.6509-2-declan.doherty@intel.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Small changes commented below. > Add document to describe the model for representing switching capable > devices in DPDK, using a general ethdev port model and through port > representors. This document also details the port model and the rte_flow > semantics required for flow programming, as well as listing some example > use cases. >=20 > Signed-off-by: Adrien Mazarguil > Signed-off-by: Declan Doherty > --- > doc/guides/prog_guide/index.rst | 1 + > doc/guides/prog_guide/switch_representation.rst | 837 > ++++++++++++++++++++++++ > 2 files changed, 838 insertions(+) <...> > +- As virtual devices, they may be more limited than their physical > + counterparts, for instance by exposing only a subset of device > + configuration callbacks and/or by not necessarily having Rx/Tx capabil= ity. > + > +- Among other things, they can be used to assign MAC addresses to the > + resource they represent. > + > +- Applications can tell port representors apart from other physcial of > +virtual > + port by checking the dev_flags field within their device information > + structure for the RTE_ETH_DEV_REPRESENTOR bit-field. physcial / physical > +.. code-block:: c > + > + struct rte_eth_dev_info { > + .. > + uint32_t dev_flags; /**< Device flags */ > + .. > + }; In the code block above tabs were used you can use spaces instead <...> > +Extensions > +~~~~~~~~~~ > + > +Compared to creating a brand new dedicated interface, **rte_flow** was > +deemed flexible enough to manage representor traffic only with minor > +extensions: > + > +- Using physical ports, PF, VF or port representors as targets. > + > +- Affecting traffic that is not necessarily addressed to the DPDK port > +ID a > + flow rule is associated with (e.g. forcing VF traffic redirection to P= F). > + > +For advanced uses: > + > +- Rule-based packet counters. > + > +- The ability to combine several identical actions for traffic > +duplication > + (e.g. VF representor in addition to a physical port). > + > +- Dedicated actions for traffic encapsulation / decapsulation before > + reaching a endpoint. > + ^^^^^^^^^^^^^ reaching an endpoint <...> > +Switching Examples > +------------------ > + > +This section provides practical examples based on the established > +Testpmd flow command syntax [2]_, in the context described in `traffic > +steering`_ > + > +:: > + > + .-------------. .-------------. .-------------. > + | hypervisor | | VM 1 | | VM 2 | > + | application | | application | | application | > + `--+---+---+--' `----------+--' `--+----------' > + | | | | | > + | | `-------------------. | | > + | `---------. | | | > + | | | | | > + .----(A)----. .----(B)----. .----(C)----. | | > + | port_id 3 | | port_id 4 | | port_id 5 | | | > + `-----+-----' `-----+-----' `-----+-----' | | > + | | | | | > + .-+--. .-----+-----. .-----+-----. .---+--. .--+---. > + | PF | | VF 1 rep. | | VF 2 rep. | | VF 1 | | VF 2 | > + `-+--' `-----+-----' `-----+-----' `--(D)-' `-(E)--' > + | | | | | > + | | .---------' | | > + `-----. | | .-----------------' | > + | | | | .---------------------' > + | | | | | > + .--|-------|---|---|---|--. > + | | | `---|---' | > + | | `-------' | > + | `---------. | > + `------------|------------' > + | > + .---(F)----. > + | physical | > + | port 0 | > + `----------' > + > +By default, PF (**A**) can communicate with the physical port it is > +associated with (**F**), while VF 1 (**D**) and VF 2 (**E**) are > +isolated and restricted to communicate with the hypervisor application > +through their respective representors (**B** and **C**) if supported. > + > +Examples in subsequent sections apply to hypervisor applications only > +and are based on port representors **A**, **B** and **C**. > + > +.. [2] `Flow syntax > + > + synt > +ax>` > + ^^^^^^^^^^^^^^^^^^^^^^^^^ You're missing an underscore to complete the link for the case above its no= t clickable at the moment <...> Reviewed-by: Marko Kovacevic