doc add limitation for VIC/mlx5/ESXi

Signed-off-by: Hanoh Haim <hhaim@cisco.com>

2 files changed, 74 insertions, 2 deletions

diff --git a/doc/trex_book.asciidoc b/doc/trex_book.asciidoc
index c59aa1f1..de5801fd 100755
--- a/doc/trex_book.asciidoc
+++ b/doc/trex_book.asciidoc
@@ -2789,6 +2789,35 @@ There is a task to automate the production of thess reports
 * run TRex server with '-v 7' for example `$sudo ./t-rex-64 -i -v 7`
 
 
+==== Limitations/Issues
+
+* The order of the mlx5 PCI addrees in /etc/trex_cfg.yaml should be in the same order reported by `./dpdk_setup_ports.py` tool see link:https://groups.google.com/forum/#!searchin/trex-tgn/unable$20to$20run$20rx-check$20with$204$20port%7Csort:relevance/trex-tgn/DsORbw3AbaU/IT-KLcZbDgAJ[issue_thread] and link:https://trex-tgn.cisco.com/youtrack/issue/trex-295[trex-295] else there would be reported this error.
+
+.Will work
+[source,bash]
+----
+ - version         : 2
+   interfaces      : ["03:00.0","03:00.1"]
+   port_limit      : 2 
+----
+
+.Will not work
+[source,bash]
+----
+ - version         : 2
+   interfaces      : ["03:00.1","03:00.0"]
+   port_limit      : 2 
+----
+
+.The error 
+[source,bash]
+----
+ PMD: net_mlx5: 0x7ff2dcfcb2c0: flow director mode 0 not supported
+ EAL: Error - exiting with code: 1
+   Cause: rte_eth_dev_filter_ctrl: err=-22, port=2
+----
+
+
 === Cisco VIC support 
 
 anchor:ciscovic_support[]
@@ -2871,6 +2900,10 @@ PMD: rte_enic_pmd: vNIC MAC addr 00:25:b5:99:00:5c wq/rq 256/512 mtu 1500, max
 
 * Stateless mode ``per stream statistics'' feature is handled in software (No hardware support like in X710 card).
 * link:https://trex-tgn.cisco.com/youtrack/issue/trex-272[QSFP+ issue]
+* VLAN 0 Priority Tagging
+If a vNIC is configured in TRUNK mode by the UCS manager, the adapter will priority tag egress packets according to 802.1Q if they were not already VLAN tagged by software. If the adapter is connected to a properly configured switch, there will be no unexpected behavior.
+In test setups where an Ethernet port of a Cisco adapter in TRUNK mode is connected point-to-point to another adapter port or connected though a router instead of a switch, all ingress packets will be VLAN tagged. TRex can work with that see more link:http://www.cisco.com/c/en/us/support/docs/servers-unified-computing/ucs-c-series-rack-servers/117637-technote-UCS-00.html[upstream VIC]
+Upstream the VIC always tags packets with an 802.1p header.In downstream it is possible to remove the tag (not supported by TRex yet)
 
 
 === More active flows   
diff --git a/doc/trex_faq.asciidoc b/doc/trex_faq.asciidoc
index 6558ba38..55e83f4e 100644
--- a/doc/trex_faq.asciidoc
+++ b/doc/trex_faq.asciidoc
@@ -85,10 +85,10 @@ Not yet. Support for FM10K and Mellanox Connectx5 is under development.
 
 ==== Is there a GUI?
 TRex team is not developing it.
-You can find GUI for statless mode developed by Exalt company in 
+You can find GUI for statless mode developed by Exalt/XORED company in 
 link:https://github.com/exalt-tech/trex-stateless-gui#trex-stateless-gui-beta[this link]. +
 There is also work in progress for packet editor (not released yet) in link:https://github.com/cisco-system-traffic-generator/trex-packet-editor[here]. +
-New stateless GUI features are developed in link:https://github.com/cisco-system-traffic-generator/trex-stateless-gui[here]. This is also work in progress, not released yet.
+New stateless GUI features are developed in link:https://github.com/cisco-system-traffic-generator/trex-stateless-gui[here]. v3.1.1 was released 
 
 ==== What is the maximum number of ports per TRex application?
 12 ports
@@ -226,6 +226,45 @@ Note: you might need additional Linux packages for that:
 ** sudo apt install build-essential
 
 
+==== Running with ESXi/KVM I get WATCHDOG crash 
+
+While running TRex on ESXi/KVM I get this error 
+
+[source,bash]
+----
+terminate called after throwing an instance of 'std::runtime_error'
+  what():  WATCHDOG: task 'ZMQ sync request-response' has not responded for more than 1.58321 seconds - timeout is 1 seconds
+ 
+*** traceback follows ***
+ ./_t-rex-64-o() [0x48aa96]
+ /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) 
+ __poll + 45
+ /home/trex/v2.05/libzmq.so.3(+0x26642) 
+ /home/trex/v2.05/libzmq.so.3(+0x183da) 
+ /home/trex/v2.05/libzmq.so.3(+0x274c3) 
+ /home/trex/v2.05/libzmq.so.3(+0x27b95) 
+ /home/trex/v2.05/libzmq.so.3(+0x3afe9) 
+ TrexRpcServerReqRes::fetch_one_request(std::string&)
+ TrexRpcServerReqRes::_rpc_thread_cb() + 1062
+ /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb1a40) 
+ /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182) 
+ clone + 109
+----
+
+Try to disable Hypervisor Hyper thread (HT) for TRex threads . two TRex threads can't share cores.
+Moving to 'none' (ESXi) only disable sharing of hyper threading, this mitigates the problem but does not solve it.
+The full solution is to provide pinning of cores *exclusively* to TRex.
+This means making sure on your Hypervisor that *only* TRex VM gets those specific cores and no other guest shares them.
+(we handle Linux processor affinity but cannot handle the Hypervisor affinity)
+If you cannot make sure your cores are pinned to the TRex guest you can run TRex without watchdog:
+
+[source,bash]
+----
+$sudo ./t-rex-64 -i --no-watchdog
+----
+
+This will hide the problem that some threads do not get reasonable response time, but will allow to work anyway.
+
 
 ===  Stateful