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. > > Signed-off-by: Adrien Mazarguil <adrien.mazag...@6wind.com> > Signed-off-by: Declan Doherty <declan.dohe...@intel.com> > --- > 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 capability. > + > +- 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 PF). > + > +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 > + > +<http://dpdk.org/doc/guides/testpmd_app_ug/testpmd_funcs.html#flow- > synt > +ax>` > + ^^^^^^^^^^^^^^^^^^^^^^^^^ You're missing an underscore to complete the link for the case above its not clickable at the moment <...> Reviewed-by: Marko Kovacevic <marko.kovace...@intel.com>