1.. SPDX-License-Identifier: BSD-3-Clause 2 Copyright(c) 2018 6WIND S.A. 3 4Switch Representation within DPDK Applications 5============================================== 6 7.. contents:: :local: 8 9Introduction 10------------ 11 12Network adapters with multiple physical ports and/or SR-IOV capabilities 13usually support the offload of traffic steering rules between their virtual 14functions (VFs), sub functions (SFs), physical functions (PFs) and ports. 15 16Like for standard Ethernet switches, this involves a combination of 17automatic MAC learning and manual configuration. For most purposes it is 18managed by the host system and fully transparent to users and applications. 19 20On the other hand, applications typically found on hypervisors that process 21layer 2 (L2) traffic (such as OVS) need to steer traffic themselves 22according on their own criteria. 23 24Without a standard software interface to manage traffic steering rules 25between VFs, SFs, PFs and the various physical ports of a given device, 26applications cannot take advantage of these offloads; software processing is 27mandatory even for traffic which ends up re-injected into the device it 28originates from. 29 30This document describes how such steering rules can be configured through 31the DPDK flow API (**rte_flow**), with emphasis on the SR-IOV use case 32(PF/VF steering) using a single physical port for clarity, however the same 33logic applies to any number of ports without necessarily involving SR-IOV. 34 35Sub Function 36------------ 37Besides SR-IOV, Sub function is a portion of the PCI device, a SF netdev 38has its own dedicated queues(txq, rxq). A SF netdev supports E-Switch 39representation offload similar to existing PF and VF representors. 40A SF shares PCI level resources with other SFs and/or with its parent PCI 41function. 42 43Sub function is created on-demand, coexists with VFs. Number of SFs is 44limited by hardware resources. 45 46Port Representors 47----------------- 48 49In many cases, traffic steering rules cannot be determined in advance; 50applications usually have to process a bit of traffic in software before 51thinking about offloading specific flows to hardware. 52 53Applications therefore need the ability to receive and inject traffic to 54various device endpoints (other VFs, SFs, PFs or physical ports) before 55connecting them together. Device drivers must provide means to hook the 56"other end" of these endpoints and to refer them when configuring flow 57rules. 58 59This role is left to so-called "port representors" (also known as "VF 60representors" in the specific context of VFs, "SF representors" in the 61specific context of SFs), which are to DPDK what the Ethernet switch 62device driver model (**switchdev**) [1]_ is to Linux, and which can be 63thought as a software "patch panel" front-end for applications. 64 65- DPDK port representors are implemented as additional virtual Ethernet 66 device (**ethdev**) instances, spawned on an as needed basis through 67 configuration parameters passed to the driver of the underlying 68 device using devargs. 69 70:: 71 72 -a pci:dbdf,representor=vf0 73 -a pci:dbdf,representor=vf[0-3] 74 -a pci:dbdf,representor=vf[0,5-11] 75 -a pci:dbdf,representor=sf1 76 -a pci:dbdf,representor=sf[0-1023] 77 -a pci:dbdf,representor=sf[0,2-1023] 78 -a pci:dbdf,representor=[pf[0-1],pf2vf[0-2],pf3[3,5]] 79 80- As virtual devices, they may be more limited than their physical 81 counterparts, for instance by exposing only a subset of device 82 configuration callbacks and/or by not necessarily having Rx/Tx capability. 83 84- Among other things, they can be used to assign MAC addresses to the 85 resource they represent. 86 87- Applications can tell port representors apart from other physical of virtual 88 port by checking the dev_flags field within their device information 89 structure for the RTE_ETH_DEV_REPRESENTOR bit-field. 90 91.. code-block:: c 92 93 struct rte_eth_dev_info { 94 ... 95 uint32_t dev_flags; /**< Device flags */ 96 ... 97 }; 98 99- The device or group relationship of ports can be discovered using the 100 switch ``domain_id`` field within the devices switch information structure. By 101 default the switch ``domain_id`` of a port will be 102 ``RTE_ETH_DEV_SWITCH_DOMAIN_ID_INVALID`` to indicate that the port doesn't 103 support the concept of a switch domain, but ports which do support the concept 104 will be allocated a unique switch ``domain_id``, ports within the same switch 105 domain will share the same ``domain_id``. The switch ``port_id`` is used to 106 specify the port_id in terms of the switch, so in the case of SR-IOV devices 107 the switch ``port_id`` would represent the virtual function identifier of the 108 port. 109 110.. code-block:: c 111 112 /** 113 * Ethernet device associated switch information 114 */ 115 struct rte_eth_switch_info { 116 const char *name; /**< switch name */ 117 uint16_t domain_id; /**< switch domain id */ 118 uint16_t port_id; /**< switch port id */ 119 }; 120 121 122.. [1] `Ethernet switch device driver model (switchdev) 123 <https://www.kernel.org/doc/Documentation/networking/switchdev.txt>`_ 124 125- For some PMDs, memory usage of representors is huge when number of 126 representor grows, mbufs are allocated for each descriptor of Rx queue. 127 Polling large number of ports brings more CPU load, cache miss and 128 latency. Shared Rx queue can be used to share Rx queue between PF and 129 representors among same Rx domain. ``RTE_ETH_DEV_CAPA_RXQ_SHARE`` in 130 device info is used to indicate the capability. Setting non-zero share 131 group in Rx queue configuration to enable share, share_qid is used to 132 identify the shared Rx queue in group. Polling any member port can 133 receive packets of all member ports in the group, port ID is saved in 134 ``mbuf.port``. 135 136Basic SR-IOV 137------------ 138 139"Basic" in the sense that it is not managed by applications, which 140nonetheless expect traffic to flow between the various endpoints and the 141outside as if everything was linked by an Ethernet hub. 142 143The following diagram pictures a setup involving a device with one PF, two 144VFs and one shared physical port 145 146:: 147 148 .-------------. .-------------. .-------------. 149 | hypervisor | | VM 1 | | VM 2 | 150 | application | | application | | application | 151 `--+----------' `----------+--' `--+----------' 152 | | | 153 .-----+-----. | | 154 | port_id 3 | | | 155 `-----+-----' | | 156 | | | 157 .-+--. .---+--. .--+---. 158 | PF | | VF 1 | | VF 2 | 159 `-+--' `---+--' `--+---' 160 | | | 161 `---------. .-----------------------' | 162 | | .-------------------------' 163 | | | 164 .--+-----+-----+--. 165 | interconnection | 166 `--------+--------' 167 | 168 .----+-----. 169 | physical | 170 | port 0 | 171 `----------' 172 173- A DPDK application running on the hypervisor owns the PF device, which is 174 arbitrarily assigned port index 3. 175 176- Both VFs are assigned to VMs and used by unknown applications; they may be 177 DPDK-based or anything else. 178 179- Interconnection is not necessarily done through a true Ethernet switch and 180 may not even exist as a separate entity. The role of this block is to show 181 that something brings PF, VFs and physical ports together and enables 182 communication between them, with a number of built-in restrictions. 183 184Subsequent sections in this document describe means for DPDK applications 185running on the hypervisor to freely assign specific flows between PF, VFs 186and physical ports based on traffic properties, by managing this 187interconnection. 188 189Controlled SR-IOV 190----------------- 191 192Initialization 193~~~~~~~~~~~~~~ 194 195When a DPDK application gets assigned a PF device and is deliberately not 196started in `basic SR-IOV`_ mode, any traffic coming from physical ports is 197received by PF according to default rules, while VFs remain isolated. 198 199:: 200 201 .-------------. .-------------. .-------------. 202 | hypervisor | | VM 1 | | VM 2 | 203 | application | | application | | application | 204 `--+----------' `----------+--' `--+----------' 205 | | | 206 .-----+-----. | | 207 | port_id 3 | | | 208 `-----+-----' | | 209 | | | 210 .-+--. .---+--. .--+---. 211 | PF | | VF 1 | | VF 2 | 212 `-+--' `------' `------' 213 | 214 `-----. 215 | 216 .--+----------------------. 217 | managed interconnection | 218 `------------+------------' 219 | 220 .----+-----. 221 | physical | 222 | port 0 | 223 `----------' 224 225In this mode, interconnection must be configured by the application to 226enable VF communication, for instance by explicitly directing traffic with a 227given destination MAC address to VF 1 and allowing that with the same source 228MAC address to come out of it. 229 230For this to work, hypervisor applications need a way to refer to either VF 1 231or VF 2 in addition to the PF. This is addressed by `VF representors`_. 232 233VF Representors 234~~~~~~~~~~~~~~~ 235 236VF representors are virtual but standard DPDK network devices (albeit with 237limited capabilities) created by PMDs when managing a PF device. 238 239Since they represent VF instances used by other applications, configuring 240them (e.g. assigning a MAC address or setting up promiscuous mode) affects 241interconnection accordingly. If supported, they may also be used as two-way 242communication ports with VFs (assuming **switchdev** topology) 243 244 245:: 246 247 .-------------. .-------------. .-------------. 248 | hypervisor | | VM 1 | | VM 2 | 249 | application | | application | | application | 250 `--+---+---+--' `----------+--' `--+----------' 251 | | | | | 252 | | `-------------------. | | 253 | `---------. | | | 254 | | | | | 255 .-----+-----. .-----+-----. .-----+-----. | | 256 | port_id 3 | | port_id 4 | | port_id 5 | | | 257 `-----+-----' `-----+-----' `-----+-----' | | 258 | | | | | 259 .-+--. .-----+-----. .-----+-----. .---+--. .--+---. 260 | PF | | VF 1 rep. | | VF 2 rep. | | VF 1 | | VF 2 | 261 `-+--' `-----+-----' `-----+-----' `---+--' `--+---' 262 | | | | | 263 | | .---------' | | 264 `-----. | | .-----------------' | 265 | | | | .---------------------' 266 | | | | | 267 .--+-------+---+---+---+--. 268 | managed interconnection | 269 `------------+------------' 270 | 271 .----+-----. 272 | physical | 273 | port 0 | 274 `----------' 275 276- VF representors are assigned arbitrary port indices 4 and 5 in the 277 hypervisor application and are respectively associated with VF 1 and VF 2. 278 279- They can't be dissociated; even if VF 1 and VF 2 were not connected, 280 representors could still be used for configuration. 281 282- In this context, port index 3 can be thought as a representor for physical 283 port 0. 284 285As previously described, the "interconnection" block represents a logical 286concept. Interconnection occurs when hardware configuration enables traffic 287flows from one place to another (e.g. physical port 0 to VF 1) according to 288some criteria. 289 290This is discussed in more detail in `traffic steering`_. 291 292Traffic Steering 293~~~~~~~~~~~~~~~~ 294 295In the following diagram, each meaningful traffic origin or endpoint as seen 296by the hypervisor application is tagged with a unique letter from A to F. 297 298:: 299 300 .-------------. .-------------. .-------------. 301 | hypervisor | | VM 1 | | VM 2 | 302 | application | | application | | application | 303 `--+---+---+--' `----------+--' `--+----------' 304 | | | | | 305 | | `-------------------. | | 306 | `---------. | | | 307 | | | | | 308 .----(A)----. .----(B)----. .----(C)----. | | 309 | port_id 3 | | port_id 4 | | port_id 5 | | | 310 `-----+-----' `-----+-----' `-----+-----' | | 311 | | | | | 312 .-+--. .-----+-----. .-----+-----. .---+--. .--+---. 313 | PF | | VF 1 rep. | | VF 2 rep. | | VF 1 | | VF 2 | 314 `-+--' `-----+-----' `-----+-----' `--(D)-' `-(E)--' 315 | | | | | 316 | | .---------' | | 317 `-----. | | .-----------------' | 318 | | | | .---------------------' 319 | | | | | 320 .--+-------+---+---+---+--. 321 | managed interconnection | 322 `------------+------------' 323 | 324 .---(F)----. 325 | physical | 326 | port 0 | 327 `----------' 328 329- **A**: PF device. 330- **B**: port representor for VF 1. 331- **C**: port representor for VF 2. 332- **D**: VF 1 proper. 333- **E**: VF 2 proper. 334- **F**: physical port. 335 336Although uncommon, some devices do not enforce a one to one mapping between 337PF and physical ports. For instance, by default all ports of **mlx4** 338adapters are available to all their PF/VF instances, in which case 339additional ports appear next to **F** in the above diagram. 340 341Assuming no interconnection is provided by default in this mode, setting up 342a `basic SR-IOV`_ configuration involving physical port 0 could be broken 343down as: 344 345PF: 346 347- **A to F**: let everything through. 348- **F to A**: PF MAC as destination. 349 350VF 1: 351 352- **A to D**, **E to D** and **F to D**: VF 1 MAC as destination. 353- **D to A**: VF 1 MAC as source and PF MAC as destination. 354- **D to E**: VF 1 MAC as source and VF 2 MAC as destination. 355- **D to F**: VF 1 MAC as source. 356 357VF 2: 358 359- **A to E**, **D to E** and **F to E**: VF 2 MAC as destination. 360- **E to A**: VF 2 MAC as source and PF MAC as destination. 361- **E to D**: VF 2 MAC as source and VF 1 MAC as destination. 362- **E to F**: VF 2 MAC as source. 363 364Devices may additionally support advanced matching criteria such as 365IPv4/IPv6 addresses or TCP/UDP ports. 366 367The combination of matching criteria with target endpoints fits well with 368**rte_flow** [6]_, which expresses flow rules as combinations of patterns 369and actions. 370 371Enhancing **rte_flow** with the ability to make flow rules match and target 372these endpoints provides a standard interface to manage their 373interconnection without introducing new concepts and whole new API to 374implement them. This is described in [6]_. 375 376.. [6] :doc:`flow_offload` 377 378Flow API (rte_flow) 379------------------- 380 381Extensions 382~~~~~~~~~~ 383 384Compared to creating a brand new dedicated interface, **rte_flow** was 385deemed flexible enough to manage representor traffic only with minor 386extensions: 387 388- Using physical ports, PF, SF, VF or port representors as targets. 389 390- Affecting traffic that is not necessarily addressed to the DPDK port ID a 391 flow rule is associated with (e.g. forcing VF traffic redirection to PF). 392 393For advanced uses: 394 395- Rule-based packet counters. 396 397- The ability to combine several identical actions for traffic duplication 398 (e.g. VF representor in addition to a physical port). 399 400- Dedicated actions for traffic encapsulation / decapsulation before 401 reaching an endpoint. 402 403Traffic Direction 404~~~~~~~~~~~~~~~~~ 405 406From an application standpoint, "ingress" and "egress" flow rule attributes 407apply to the DPDK port ID they are associated with. They select a traffic 408direction for matching patterns, but have no impact on actions. 409 410When matching traffic coming from or going to a different place than the 411immediate port ID a flow rule is associated with, these attributes keep 412their meaning while applying to the chosen origin, as highlighted by the 413following diagram 414 415:: 416 417 .-------------. .-------------. .-------------. 418 | hypervisor | | VM 1 | | VM 2 | 419 | application | | application | | application | 420 `--+---+---+--' `----------+--' `--+----------' 421 | | | | | 422 | | `-------------------. | | 423 | `---------. | | | 424 | ^ | ^ | ^ | | 425 | | ingress | | ingress | | ingress | | 426 | | egress | | egress | | egress | | 427 | v | v | v | | 428 .----(A)----. .----(B)----. .----(C)----. | | 429 | port_id 3 | | port_id 4 | | port_id 5 | | | 430 `-----+-----' `-----+-----' `-----+-----' | | 431 | | | | | 432 .-+--. .-----+-----. .-----+-----. .---+--. .--+---. 433 | PF | | VF 1 rep. | | VF 2 rep. | | VF 1 | | VF 2 | 434 `-+--' `-----+-----' `-----+-----' `--(D)-' `-(E)--' 435 | | | ^ | | ^ 436 | | | egress | | | | egress 437 | | | ingress | | | | ingress 438 | | .---------' v | | v 439 `-----. | | .-----------------' | 440 | | | | .---------------------' 441 | | | | | 442 .--+-------+---+---+---+--. 443 | managed interconnection | 444 `------------+------------' 445 ^ | 446 ingress | | 447 egress | | 448 v | 449 .---(F)----. 450 | physical | 451 | port 0 | 452 `----------' 453 454Ingress and egress are defined as relative to the application creating the 455flow rule. 456 457For instance, matching traffic sent by VM 2 would be done through an ingress 458flow rule on VF 2 (**E**). Likewise for incoming traffic on physical port 459(**F**). This also applies to **C** and **A** respectively. 460 461Transferring Traffic 462~~~~~~~~~~~~~~~~~~~~ 463 464Without Port Representors 465^^^^^^^^^^^^^^^^^^^^^^^^^ 466 467`Traffic direction`_ describes how an application could match traffic coming 468from or going to a specific place reachable from a DPDK port ID. This makes 469sense when the traffic in question is normally seen (i.e. sent or received) 470by the application creating the flow rule. 471 472However, if there is an entity (VF **D**, for instance) not associated with 473a DPDK port (representor), the application (**A**) won't be able to match 474traffic generated by such entity. The traffic goes directly to its 475default destination (to physical port **F**, for instance). 476 477:: 478 479 .-------------. .-------------. 480 | hypervisor | | VM 1 | 481 | application | | application | 482 `------+------' `--+----------' 483 | | | traffic 484 .----(A)----. | v 485 | port_id 3 | | 486 `-----+-----' | 487 | | 488 | | 489 .-+--. .---+--. 490 | PF | | VF 1 | 491 `-+--' `--(D)-' 492 | | | traffic 493 | | v 494 .--+-----------+--. 495 | interconnection | 496 `--------+--------' 497 | | traffic 498 | v 499 .---(F)----. 500 | physical | 501 | port 0 | 502 `----------' 503 504 505With Port Representors 506^^^^^^^^^^^^^^^^^^^^^^ 507 508When port representors exist, implicit flow rules with the "transfer" 509attribute (described in `without port representors`_) are be assumed to 510exist between them and their represented resources. These may be immutable. 511 512In this case, traffic is received by default through the representor and 513neither the "transfer" attribute nor traffic origin in flow rule patterns 514are necessary. They simply have to be created on the representor port 515directly and may target a different representor as described 516in `PORT_REPRESENTOR Action`_. 517 518Implicit traffic flow with port representor 519 520:: 521 522 .-------------. .-------------. 523 | hypervisor | | VM 1 | 524 | application | | application | 525 `--+-------+--' `----------+--' 526 | | ^ | | traffic 527 | | | traffic | v 528 | `-----. | 529 | | | 530 .----(A)----. .----(B)----. | 531 | port_id 3 | | port_id 4 | | 532 `-----+-----' `-----+-----' | 533 | | | 534 .-+--. .-----+-----. .---+--. 535 | PF | | VF 1 rep. | | VF 1 | 536 `-+--' `-----+-----' `--(D)-' 537 | | | 538 .--|-------------|-----------|--. 539 | | | | | 540 | | `-----------' | 541 | | <-- traffic | 542 `--|----------------------------' 543 | 544 .---(F)----. 545 | physical | 546 | port 0 | 547 `----------' 548 549Pattern Items And Actions 550~~~~~~~~~~~~~~~~~~~~~~~~~ 551 552PORT_REPRESENTOR Pattern Item 553^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 554 555Matches traffic entering the embedded switch from the given ethdev. 556 557- Matches **A**, **B** or **C** in `traffic steering`_. 558 559PORT_REPRESENTOR Action 560^^^^^^^^^^^^^^^^^^^^^^^ 561 562At embedded switch level, sends matching traffic to the given ethdev. 563 564- Targets **A**, **B** or **C** in `traffic steering`_. 565 566REPRESENTED_PORT Pattern Item 567^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 568 569Matches traffic entering the embedded switch from 570the entity represented by the given ethdev. 571 572- Matches **D**, **E** or **F** in `traffic steering`_. 573 574REPRESENTED_PORT Action 575^^^^^^^^^^^^^^^^^^^^^^^ 576 577At embedded switch level, send matching traffic to 578the entity represented by the given ethdev. 579 580- Targets **D**, **E** or **F** in `traffic steering`_. 581 582PORT Pattern Item 583^^^^^^^^^^^^^^^^^ 584 585Matches traffic originating from (ingress) or going to (egress) a physical 586port of the underlying device. 587 588Using this pattern item without specifying a port index matches the physical 589port associated with the current DPDK port ID by default. As described in 590`traffic steering`_, specifying it should be rarely needed. 591 592- Matches **F** in `traffic steering`_. 593 594PORT Action 595^^^^^^^^^^^ 596 597Directs matching traffic to a given physical port index. 598 599- Targets **F** in `traffic steering`_. 600 601PORT_ID Pattern Item 602^^^^^^^^^^^^^^^^^^^^ 603 604Matches traffic originating from (ingress) or going to (egress) a given DPDK 605port ID. 606 607Normally only supported if the port ID in question is known by the 608underlying PMD and related to the device the flow rule is created against. 609 610This must not be confused with the `PORT pattern item`_ which refers to the 611physical port of a device. ``PORT_ID`` refers to a ``struct rte_eth_dev`` 612object on the application side (also known as "port representor" depending 613on the kind of underlying device). 614 615- Matches **A**, **B** or **C** in `traffic steering`_. 616 617PORT_ID Action 618^^^^^^^^^^^^^^ 619 620Directs matching traffic to a given DPDK port ID. 621 622Same restrictions as `PORT_ID pattern item`_. 623 624- Targets **A**, **B** or **C** in `traffic steering`_. 625 626PF Action 627^^^^^^^^^ 628 629Directs matching traffic to the physical function of the current device. 630 631- Targets **A** in `traffic steering`_. 632 633VF Pattern Item 634^^^^^^^^^^^^^^^ 635 636Matches traffic originating from (ingress) or going to (egress) a given 637virtual function of the current device. 638 639If supported, should work even if the virtual function is not managed by 640the application and thus not associated with a DPDK port ID. Its behavior is 641otherwise similar to `PORT_ID pattern item`_ using VF port ID. 642 643Note this pattern item does not match VF representors traffic which, as 644separate entities, should be addressed through their own port IDs. 645 646- Matches **D** or **E** in `traffic steering`_. 647 648VF Action 649^^^^^^^^^ 650 651Directs matching traffic to a given virtual function of the current device. 652 653Same restrictions as `VF pattern item`_. 654 655- Targets **D** or **E** in `traffic steering`_. 656 657\*_ENCAP actions 658^^^^^^^^^^^^^^^^ 659 660These actions are named according to the protocol they encapsulate traffic 661with (e.g. ``VXLAN_ENCAP``) and using specific parameters (e.g. VNI for 662VXLAN). 663 664While they modify traffic and can be used multiple times (order matters), 665unlike `PORT_REPRESENTOR Action`_ and friends, they don't impact on steering. 666 667As described in `actions order and repetition`_ this means they are useless 668if used alone in an action list, the resulting traffic gets dropped unless 669combined with either ``PASSTHRU`` or other endpoint-targeting actions. 670 671\*_DECAP actions 672^^^^^^^^^^^^^^^^ 673 674They perform the reverse of `\*_ENCAP actions`_ by popping protocol headers 675from traffic instead of pushing them. They can be used multiple times as 676well. 677 678Note that using these actions on non-matching traffic results in undefined 679behavior. It is recommended to match the protocol headers to decapsulate on 680the pattern side of a flow rule in order to use these actions or otherwise 681make sure only matching traffic goes through. 682 683Actions Order and Repetition 684~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 685 686Flow rules are currently restricted to at most a single action of each 687supported type, performed in an unpredictable order (or all at once). To 688repeat actions in a predictable fashion, applications have to make rules 689pass-through and use priority levels. 690 691It's now clear that PMD support for chaining multiple non-terminating flow 692rules of varying priority levels is prohibitively difficult to implement 693compared to simply allowing multiple identical actions performed in a 694defined order by a single flow rule. 695 696- This change is required to support protocol encapsulation offloads and the 697 ability to perform them multiple times (e.g. VLAN then VXLAN). 698 699- It makes the ``DUP`` action redundant since multiple ``QUEUE`` actions can 700 be combined for duplication. 701 702- The (non-)terminating property of actions must be discarded. Instead, flow 703 rules themselves must be considered terminating by default (i.e. dropping 704 traffic if there is no specific target) unless a ``PASSTHRU`` action is 705 also specified. 706 707Switching Examples 708------------------ 709 710This section provides practical examples based on the established testpmd 711flow command syntax [2]_, in the context described in `traffic steering`_ 712 713:: 714 715 .-------------. .-------------. .-------------. 716 | hypervisor | | VM 1 | | VM 2 | 717 | application | | application | | application | 718 `--+---+---+--' `----------+--' `--+----------' 719 | | | | | 720 | | `-------------------. | | 721 | `---------. | | | 722 | | | | | 723 .----(A)----. .----(B)----. .----(C)----. | | 724 | port_id 3 | | port_id 4 | | port_id 5 | | | 725 `-----+-----' `-----+-----' `-----+-----' | | 726 | | | | | 727 .-+--. .-----+-----. .-----+-----. .---+--. .--+---. 728 | PF | | VF 1 rep. | | VF 2 rep. | | VF 1 | | VF 2 | 729 `-+--' `-----+-----' `-----+-----' `--(D)-' `-(E)--' 730 | | | | | 731 | | .---------' | | 732 `-----. | | .-----------------' | 733 | | | | .---------------------' 734 | | | | | 735 .--|-------|---|---|---|--. 736 | | | `---|---' | 737 | | `-------' | 738 | `---------. | 739 `------------|------------' 740 | 741 .---(F)----. 742 | physical | 743 | port 0 | 744 `----------' 745 746By default, PF (**A**) can communicate with the physical port it is 747associated with (**F**), while VF 1 (**D**) and VF 2 (**E**) are isolated 748and restricted to communicate with the hypervisor application through their 749respective representors (**B** and **C**) if supported. 750 751Examples in subsequent sections apply to hypervisor applications only and 752are based on port representors **A**, **B** and **C**. 753 754.. [2] :ref:`Flow syntax <testpmd_rte_flow>` 755 756Associating VF 1 with Physical Port 0 757~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 758 759Assign all port traffic (**F**) to VF 1 (**D**) indiscriminately through 760their representors 761 762:: 763 764 flow create 3 transfer 765 pattern represented_port ethdev_port_id is 3 / end 766 actions represented_port ethdev_port_id 4 / end 767 768:: 769 770 flow create 3 transfer 771 pattern represented_port ethdev_port_id is 4 / end 772 actions represented_port ethdev_port_id 3 / end 773 774 775Sharing Broadcasts 776~~~~~~~~~~~~~~~~~~ 777 778From outside to PF and VFs 779 780:: 781 782 flow create 3 transfer 783 pattern 784 represented_port ethdev_port_id is 3 / 785 eth dst is ff:ff:ff:ff:ff:ff / 786 end 787 actions 788 port_representor ethdev_port_id 3 / 789 represented_port ethdev_port_id 4 / 790 represented_port ethdev_port_id 5 / 791 end 792 793Note ``port_representor ethdev_port_id 3`` is necessary otherwise only VFs would receive matching 794traffic. 795 796From PF to outside and VFs 797 798:: 799 800 flow create 3 transfer 801 pattern 802 port_representor ethdev_port_id is 3 / 803 eth dst is ff:ff:ff:ff:ff:ff / 804 end 805 actions 806 represented_port ethdev_port_id 3 / 807 represented_port ethdev_port_id 4 / 808 represented_port ethdev_port_id 5 / 809 end 810 811From VFs to outside and PF 812 813:: 814 815 flow create 3 transfer 816 pattern 817 represented_port ethdev_port_id is 4 / 818 eth dst is ff:ff:ff:ff:ff:ff / 819 end 820 actions 821 represented_port ethdev_port_id 3 / 822 port_representor ethdev_port_id 3 / 823 end 824 825 flow create 3 transfer 826 pattern 827 represented_port ethdev_port_id is 5 / 828 eth dst is ff:ff:ff:ff:ff:ff / 829 end 830 actions 831 represented_port ethdev_port_id 3 / 832 port_representor ethdev_port_id 3 / 833 end 834 835Similar ``33:33:*`` rules based on known MAC addresses should be added for 836IPv6 traffic. 837 838Encapsulating VF 2 Traffic in VXLAN 839~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 840 841Assuming pass-through flow rules are supported 842 843:: 844 845 flow create 5 ingress 846 pattern eth / end 847 actions vxlan_encap vni 42 / passthru / end 848 849:: 850 851 flow create 5 egress 852 pattern vxlan vni is 42 / end 853 actions vxlan_decap / passthru / end 854 855Here ``passthru`` is needed since as described in `actions order and 856repetition`_, flow rules are otherwise terminating; if supported, a rule 857without a target endpoint will drop traffic. 858 859Without pass-through support, ingress encapsulation on the destination 860endpoint might not be supported and action list must provide one 861 862:: 863 864 flow create 3 transfer 865 pattern represented_port ethdev_port_id is 5 / end 866 actions vxlan_encap vni 42 / represented_port ethdev_port_id 3 / end 867 868 flow create 3 transfer 869 pattern 870 represented_port ethdev_port_id is 3 / 871 vxlan vni is 42 / 872 end 873 actions vxlan_decap / represented_port ethdev_port_id 5 / end 874