Big drop rate (bps) while number of opackets and ipackets are equal

598 views
Skip to first unread message

gpano...@gmail.com

unread,
Oct 24, 2018, 5:35:43 AM10/24/18
to TRex Traffic Generator
Hi,
I have a setup with TREX running on a VM sending traffic to an another VM which runs a VPE passthough ip pipeline sending the traffic back to the TREX vm. TREX-vm and vPE-vm use vhostuser interfaces which are bind to the interfaces of an ovs-dpdk running on the host machine. So I send traffic from one network interface of TREX-vm, through the host ovs-dpdk, to the vPE-vm from which it gets back to an another network interface of TREX-vm.

Vms have 4 CPU and 8 Gb RAM each, with Ubuntu 16.04
TREX version 2.45
OVS 2.10.0
DPDK 17.11.3

TREX is running in stateless mode and I use the file stl/udp_1pkt_simple.py for traffic generator. So when I execute it the drop rate is 9.38 Mbps but the number of packets sent and received is the same. Should this happen? If not, can you help me to check what's the problem?

# ./trex-console
# trex>start -f stl/udp_1pkt_simple.py -m 10mbps --port 0

# ./t-rex-64 -i
-Per port stats table
ports | 0 | 1
-----------------------------------------------------------------------------------------
opackets | 176583 | 0
obytes | 11301312 | 0
ipackets | 0 | 176524
ibytes | 0 | 706096
ierrors | 0 | 0
oerrors | 0 | 0
Tx Bw | 10.01 Mbps | 0.00 bps

-Global stats enabled
Cpu Utilization : 0.2 % 11.7 Gb/core
Platform_factor : 1.0
Total-Tx : 10.01 Mbps
Total-Rx : 625.44 Kbps
Total-PPS : 19.55 Kpps
Total-CPS : 0.00 cps

Expected-PPS : 0.00 pps
Expected-CPS : 0.00 cps
Expected-BPS : 0.00 bps

Active-flows : 0 Clients : 0 Socket-util : 0.0000 %
Open-flows : 0 Servers : 0 Socket : 0 Socket/Clients : -nan
drop-rate : 9.38 Mbps
current time : 14.8 sec
test duration : 0.0 sec

hanoh haim

unread,
Oct 24, 2018, 6:04:15 AM10/24/18
to gpano...@gmail.com, trex...@googlegroups.com
Hi,
Have a look into xstats to understand where the dropped packets are. It seems as a virtio dpdk driver issue



--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To post to this group, send email to trex...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/2a970d08-52cf-46fd-823a-700c334e6283%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Hanoh
Sent from my iPhone

Georgia Panoutsakopoulou

unread,
Oct 25, 2018, 9:28:04 AM10/25/18
to hhaim...@gmail.com, trex...@googlegroups.com
Thank you for the reply! I checked the output of tcpdump on ovs ports, which are bind with trex transmission and reception ports, and it seems that packet's length and contents are the same on both ports. Maybe ovs-dpdk is not the problem?
What else can affect the received bytes shown on trex?

# ./openvswitch-2.10.0/utilities/ovs-tcpdump -i vhost-user1 -evvvA 
15:56:07.278012 00:00:00:00:00:03 (oui Ethernet) > 00:00:00:00:00:04 (oui Ethernet), ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 38)
    bpe-ssl.ams.hpecore.net.1025 > 48.0.0.1.12: [udp sum ok] UDP, length 10
E..&....@.:.....0.........aaxxxxxxxxxx........

# ./openvswitch-2.10.0/utilities/ovs-tcpdump -i vhost-user2 -evvvA 
15:56:08.278026 00:00:00:00:00:03 (oui Ethernet) > 00:00:00:00:00:04 (oui Ethernet), ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 38)
    bpe-ssl.ams.hpecore.net.1025 > 48.0.0.1.12: [udp sum ok] UDP, length 10
E..&....@.:.....0.........aaxxxxxxxxxx........

The output of xstas on TRex was:
# trex>stats -x --port 0 1
Xstats

trex>stats --xz
Xstats

            Name:              |     Port 0:     |     Port 1:     
-------------------------------+-----------------+----------------
rx_good_packets                |               0 |            6150 
tx_good_packets                |            6150 |               0 
rx_good_bytes                  |               0 |               0 
tx_good_bytes                  |          369000 |               0 
rx_missed_errors               |               0 |               0 
rx_errors                      |               0 |               0 
tx_errors                      |               0 |               0 
rx_mbuf_allocation_errors      |               0 |               0 
rx_q0packets                   |               0 |            6150 
rx_q0bytes                     |               0 |               0 
rx_q0errors                    |               0 |               0 
tx_q0packets                   |            6150 |               0 
tx_q0bytes                     |          369000 |               0 
rx_q0_good_packets             |               0 |            6150 
rx_q0_good_bytes               |               0 |               0 
rx_q0_errors                   |               0 |               0 
rx_q0_multicast_packets        |               0 |               0 
rx_q0_broadcast_packets        |               0 |               0 
rx_q0_undersize_packets        |               0 |               0 
rx_q0_size_64_packets          |               0 |               0 
rx_q0_size_65_127_packets      |               0 |               0 
rx_q0_size_128_255_packets     |               0 |               0 
rx_q0_size_256_511_packets     |               0 |               0 
rx_q0_size_512_1023_packets    |               0 |               0 
rx_q0_size_1024_1518_packets   |               0 |               0 
rx_q0_size_1519_max_packets    |               0 |               0 
tx_q0_good_packets             |            6150 |               0 
tx_q0_good_bytes               |          369000 |               0 
tx_q0_errors                   |               0 |               0 
tx_q0_multicast_packets        |               0 |               0 
tx_q0_broadcast_packets        |               0 |               0 
tx_q0_undersize_packets        |            6150 |               0 
tx_q0_size_64_packets          |               0 |               0 
tx_q0_size_65_127_packets      |               0 |               0 
tx_q0_size_128_255_packets     |               0 |               0 
tx_q0_size_256_511_packets     |               0 |               0 
tx_q0_size_512_1023_packets    |               0 |               0 
tx_q0_size_1024_1518_packets   |               0 |               0 
tx_q0_size_1519_max_packets    |               0 |               0 


Best Regards  

gpano...@gmail.com

unread,
Oct 30, 2018, 7:02:59 AM10/30/18
to TRex Traffic Generator
Hi,

Experimenting further with TRex’s capture capability, I came up to the observation that both TX and RX packets, on all ports, are identical and of the same size (60 B).
Specifically, the contents of every packet are the following (with the only difference that MAC addresses are swapped for the RX/TX paths of every port):

```Type: UDP, Size: 60 B, TS: 5.06 [sec]

#40 Port: 0 ◀── RX
trex(service)>
Type: UDP, Size: 60 B, TS: 56.07 [sec]
trex(service)> ###[ Ethernet ]###
dst = 00:00:00:00:00:03
src = 00:00:00:00:00:04
type = IPv4
###[ IP ]###
version = 4
ihl = 5
tos = 0x0
len = 38
id = 1
flags =
frag = 0
ttl = 64
proto = udp
chksum = 0x3ac5
src = 16.0.0.1
dst = 48.0.0.1
\options \
###[ UDP ]###
sport = 1025
dport = 12
len = 18
chksum = 0x6161
###[ Raw ]###
load = 'xxxxxxxxxx'
###[ Padding ]###
load = '\x00\x00\x00\x00\x00\x00\x00\x00'```



In this scenario, I used:
- stl/udp_1pkt_simple.py
- 1 pps transmition rate
- packet generation from both ports (0 1)

At the same time, the stats from TRex server's console are something like the following:

```-Per port stats table
ports | 0 | 1
-----------------------------------------------------------------------------------------
opackets | 1705 | 1705
obytes | 109120 | 109120
ipackets | 1705 | 1705
ibytes | 6820 | 6820
ierrors | 0 | 0
oerrors | 0 | 0
Tx Bw | 500.42 bps | 500.42 bps

-Global stats enabled
Cpu Utilization : 0.4 % 0.0 Gb/core
Platform_factor : 1.0
Total-Tx : 1.00 Kbps
Total-Rx : 62.55 bps
...```


What's interesting with this snapshot is that the average outgoing packet size (109120/1705=64B) agrees with the outcome of the capture, while for the incoming path (6820/1705=4B) it does not.

So, does this all suggest a reporting bug in TRex server's console?

hanoh haim

unread,
Oct 30, 2018, 7:24:23 AM10/30/18
to gpano...@gmail.com, TRex Traffic Generator
You destination MAC is probably not correct so the NIC filter it but count it in the packets counter.
Try to use NIC MAC addr using L3 command 

Hanoh

--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To post to this group, send email to trex...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

gpano...@gmail.com

unread,
Oct 30, 2018, 8:05:45 AM10/30/18
to TRex Traffic Generator
Hi,

Do you mean that the 00:00:00:00:00:{03,04} MAC addresses are invalid for TRex?
I have changed the MAC addresses of my VM's interfaces to de:ad:be:ef:11:22 and de:ad:be:ef:33:44, but again I observe the same behavior.
Here is trex_cfg.yaml:


```### Config file generated by dpdk_setup_ports.py ###

- port_limit: 2
version: 2
interfaces: ['00:04.0', '00:05.0']
port_info:
- dest_mac: de:ad:ba:be:33:44 # MAC OF LOOPBACK TO IT'S DUAL INTERFACE
src_mac: de:ad:ba:be:11:22
- dest_mac: de:ad:ba:be:11:22 # MAC OF LOOPBACK TO IT'S DUAL INTERFACE
src_mac: de:ad:ba:be:33:44

platform:
master_thread_id: 0
latency_thread_id: 1
dual_if:
- socket: 0
threads: [2,3]```


Also, can you give me more details about the "L3 command"? Is it something TRex-specific?

Thanks in advance

hanoh haim

unread,
Oct 30, 2018, 8:09:53 AM10/30/18
to gpano...@gmail.com, TRex Traffic Generator
Just set IP in the trex_cfg.yaml 
In the Console there is a L3 command that does the same

          - ip         : 1.1.1.1
            default_gw : 2.2.2.2
          - ip         : 2.2.2.2
            default_gw : 1.1.1.1


For more options, visit https://groups.google.com/d/optout.
--

gpano...@gmail.com

unread,
Oct 30, 2018, 9:56:57 AM10/30/18
to TRex Traffic Generator
Hi Hanoch,

Changing trex_cfg.yaml according to your instructions does not change anything.

The capture (e.g. at port's 0 RX queue) is the same as before and seems valid:

#39 Port: 0 :arrow_backward:── RX
trex(service)>
Type: UDP, Size: 60 B, TS: 38.04 [sec]
trex(service)> ###[ Ethernet ]###
dst = de:ad:ba:be:11:22
src = de:ad:ba:be:33:44
type = IPv4
###[ IP ]###
version = 4
ihl = 5
tos = 0x0
len = 38
id = 1
flags =
frag = 0
ttl = 64
proto = udp
chksum = 0x3ac5
src = 16.0.0.1
dst = 48.0.0.1
\options \
###[ UDP ]###
sport = 1025
dport = 12
len = 18
chksum = 0x6161
###[ Raw ]###
load = 'xxxxxxxxxx'
###[ Padding ]###
load = '\x00\x00\x00\x00\x00\x00\x00\x00'

Do you have any other idea of where I could dig deeper into?

Thanks,
Georgia

hanoh haim

unread,
Oct 30, 2018, 9:59:50 AM10/30/18
to gpano...@gmail.com, TRex Traffic Generator
Could you send the counters output

>stats -x 

From the Console and the output of

./t-rex-64 -i -v 7

Hanoh

--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To post to this group, send email to trex...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

gpano...@gmail.com

unread,
Oct 30, 2018, 10:23:10 AM10/30/18
to TRex Traffic Generator
Hi Hanoch,

Please find below the outputs you asked:

trex@trex:/opt/nfv/trex/v2.45$ sudo ./t-rex-64 -i -v 7
sudo: unable to resolve host trex
Starting Scapy server.... Scapy server is started
Trying to bind to igb_uio ...
/usr/bin/python dpdk_nic_bind.py --bind=igb_uio 0000:00:04.0 0000:00:05.0
The ports are bound/configured.
Starting TRex v2.45 please wait ...
Using configuration file /etc/trex_cfg.yaml
port limit : 2
port_bandwidth_gb : 10
if_mask : None
is low-end : 0
stack type :
thread_per_dual_if : 1
if : 00:04.0, 00:05.0,
enable_zmq_pub : 1
zmq_pub_port : 4500
m_zmq_rpc_port : 4501
src : 00:00:00:00:00:00
dest : 00:00:00:00:00:00
src : 00:00:00:00:00:00
dest : 00:00:00:00:00:00
memory per 2x10G ports
MBUF_64 : 16380
MBUF_128 : 8190
MBUF_256 : 8190
MBUF_512 : 8190
MBUF_1024 : 8190
MBUF_2048 : 4095
MBUF_4096 : 128
MBUF_9K : 512
TRAFFIC_MBUF_64 : 65520
TRAFFIC_MBUF_128 : 32760
TRAFFIC_MBUF_256 : 8190
TRAFFIC_MBUF_512 : 8190
TRAFFIC_MBUF_1024 : 8190
TRAFFIC_MBUF_2048 : 32760
TRAFFIC_MBUF_4096 : 128
TRAFFIC_MBUF_9K : 512
MBUF_DP_FLOWS : 524288
MBUF_GLOBAL_FLOWS : 5120
master thread : 0
rx thread : 1
dual_if : 0
socket : 0
[ 2 3 4 5 6 ]
CTimerWheelYamlInfo does not exist
flags : 8010f00
write_file : 0
verbose : 7
realtime : 1
flip : 0
cores : 1
single core : 0
flow-flip : 0
no clean close : 0
zmq_publish : 1
vlan mode : 0
client_cfg : 0
mbuf_cache_disable : 0
cfg file :
mac file :
out file :
client cfg file :
duration : 0
factor : 1
mbuf_factor : 1
latency : 0 pkt/sec
zmq_port : 4500
telnet_port : 4501
expected_ports : 2
tw_bucket_usec : 20.000000 usec
tw_buckets : 1024 usec
tw_levels : 3 usec
port : 0 dst:00:00:00:00:00:00 src:00:00:00:00:00:00
port : 1 dst:00:00:00:00:00:00 src:00:00:00:00:00:00
port : 2 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 3 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 4 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 5 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 6 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 7 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 8 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 9 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 10 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 11 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 12 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 13 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 14 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
port : 15 dst:00:00:00:01:00:00 src:00:00:00:00:00:00
Total Memory :
MBUF_64 : 81900
MBUF_128 : 40950
MBUF_256 : 16380
MBUF_512 : 16380
MBUF_1024 : 16380
MBUF_2048 : 36855
MBUF_4096 : 1024
MBUF_DP_FLOWS : 524288
MBUF_GLOBAL_FLOWS : 5120
get_each_core_dp_flows : 524288
Total memory : 248.40 Mbytes
core_mask 7
sockets : 0
active sockets : 1
ports_sockets : 1
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
phy | virt
2 1
DPDK args
xx -c 0x7 -n 4 --log-level 8 --master-lcore 0 -w 0000:00:04.0 -w 0000:00:05.0 --legacy-mem
EAL: Detected 8 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: No free hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clock cycles !
EAL: PCI device 0000:00:04.0 on NUMA socket -1
EAL: Invalid NUMA socket, default to 0
EAL: probe driver: 1af4:1000 net_virtio
EAL: PCI device 0000:00:05.0 on NUMA socket -1
EAL: Invalid NUMA socket, default to 0
EAL: probe driver: 1af4:1000 net_virtio
input : [00:04.0, 00:05.0]
dpdk : [0000:00:04.0, 0000:00:05.0]
pci_scan : [0000:00:04.0, 0000:00:05.0]
map : [ 0, 1]
TRex port mapping
-----------------
TRex vport: 0 dpdk_rte_eth: 0
TRex vport: 1 dpdk_rte_eth: 1
set driver name net_virtio
driver capability :
Number of ports found: 2


if_index : 0
driver name : net_virtio
min_rx_bufsize : 64
max_rx_pktlen : 9728
max_rx_queues : 2
max_tx_queues : 2
max_mac_addrs : 64
rx_offload_capa : 0x1a1d
tx_offload_capa : 0x8001
rss reta_size : 0
flow_type_rss : 0x0
zmq publisher at: tcp://*:4500
port 0 desc: Virtio network device
port 1 desc: Virtio network device
wait 1 sec .
port : 0
------------
link : link : Link Up - speed 10000 Mbps - full-duplex
promiscuous : 0
port : 1
------------
link : link : Link Up - speed 10000 Mbps - full-duplex
promiscuous : 0
number of ports : 2
max cores for 2 ports : 1
max queue per port : 3
-------------------------------
RX core uses TX queue number 0 on all ports
core, c-port, c-queue, s-port, s-queue, lat-queue
------------------------------------------
1 0 0 1 0 0
-------------------------------
base stack ctor
Legacy stack ctor
add port node
add node
Run pending tasks for ticket 0
Running in FG
Legacy node ctor
base stack ctor
Legacy stack ctor
add port node
add node
Run pending tasks for ticket 0
Running in FG
Legacy node ctor
TX grat ARP on port 0 - ip: 1.1.1.1 mac: de:ad:ba:be:11:22
TX grat ARP on port 1 - ip: 2.2.2.2 mac: de:ad:ba:be:33:44
TX ARP request on port 0 - ip: 2.2.2.2 mac: Unknown

+---------+---------------+----------+
00:00:00,000,000 ETHER
|0 |ff|ff|ff|ff|ff|ff|de|ad|ba|be|11|22|08|06|00|01|08|00|06|04|00|01|de|ad|ba|be|11|22|01|01|01|01|01|03|05|07|09|00|02|02|02|02|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|
TX ARP request on port 1 - ip: 1.1.1.1 mac: Unknown

+---------+---------------+----------+
00:00:00,000,000 ETHER
|0 |ff|ff|ff|ff|ff|ff|de|ad|ba|be|33|44|08|06|00|01|08|00|06|04|00|01|de|ad|ba|be|33|44|02|02|02|02|01|03|05|07|09|01|01|01|01|01|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|
RX-gen on port 0 queue 0

+---------+---------------+----------+
00:00:00,000,000 ETHER
|0 |ff|ff|ff|ff|ff|ff|de|ad|ba|be|33|44|08|06|00|01|08|00|06|04|00|01|de|ad|ba|be|33|44|02|02|02|02|01|03|05|07|09|00|02|02|02|02|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|
RX grat ARP on port 0 queue 0 sip:2.2.2.2 tip:2.2.2.2 vlan:0

+---------+---------------+----------+
00:00:00,000,000 ETHER
|0 |ff|ff|ff|ff|ff|ff|de|ad|ba|be|33|44|08|06|00|01|08|00|06|04|00|01|de|ad|ba|be|33|44|02|02|02|02|01|03|05|07|09|00|02|02|02|02|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|
RX-gen on port 0 queue 0

+---------+---------------+----------+
00:00:00,000,000 ETHER
|0 |ff|ff|ff|ff|ff|ff|de|ad|ba|be|33|44|08|06|00|01|08|00|06|04|00|01|de|ad|ba|be|33|44|02|02|02|02|01|03|05|07|09|01|01|01|01|01|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|
RX ARP request on port 0 queue 0 sip:2.2.2.2 tip:1.1.1.1 vlan:0

+---------+---------------+----------+
00:00:00,000,000 ETHER
|0 |ff|ff|ff|ff|ff|ff|de|ad|ba|be|33|44|08|06|00|01|08|00|06|04|00|01|de|ad|ba|be|33|44|02|02|02|02|01|03|05|07|09|01|01|01|01|01|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|
RX-gen on port 1 queue 0

+---------+---------------+----------+
00:00:00,000,000 ETHER
|0 |ff|ff|ff|ff|ff|ff|de|ad|ba|be|11|22|08|06|00|01|08|00|06|04|00|01|de|ad|ba|be|11|22|01|01|01|01|01|03|05|07|09|00|01|01|01|01|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|
RX grat ARP on port 1 queue 0 sip:1.1.1.1 tip:1.1.1.1 vlan:0

+---------+---------------+----------+
00:00:00,000,000 ETHER
|0 |ff|ff|ff|ff|ff|ff|de|ad|ba|be|11|22|08|06|00|01|08|00|06|04|00|01|de|ad|ba|be|11|22|01|01|01|01|01|03|05|07|09|00|01|01|01|01|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|
RX-gen on port 1 queue 0

+---------+---------------+----------+
00:00:00,000,000 ETHER
|0 |ff|ff|ff|ff|ff|ff|de|ad|ba|be|11|22|08|06|00|01|08|00|06|04|00|01|de|ad|ba|be|11|22|01|01|01|01|01|03|05|07|09|00|02|02|02|02|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|
RX ARP request on port 1 queue 0 sip:1.1.1.1 tip:2.2.2.2 vlan:0

+---------+---------------+----------+
00:00:00,000,000 ETHER
|0 |ff|ff|ff|ff|ff|ff|de|ad|ba|be|11|22|08|06|00|01|08|00|06|04|00|01|de|ad|ba|be|11|22|01|01|01|01|01|03|05|07|09|00|02|02|02|02|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|00|
*******Pretest after resolving ********
Pre test info start ===================
Port 0:
Port connected in loopback
Sources:
ip: 1.1.1.1 mac: de:ad:ba:be:11:22
Destinations:
ip: 2.2.2.2 mac: de:ad:ba:be:33:44
Port 1:
Port connected in loopback
Sources:
ip: 2.2.2.2 mac: de:ad:ba:be:33:44
Destinations:
ip: 1.1.1.1 mac: de:ad:ba:be:11:22
Pre test info end ===================
Pre test statistics for port 0
opackets : 2
obytes : 128
ipackets : 2
ibytes : 8
m_tx_arp : 2
m_rx_arp : 2
Pre test statistics for port 1
opackets : 2
obytes : 128
ipackets : 2
ibytes : 8
m_tx_arp : 2
m_rx_arp : 2
conf ip4
conf dst
set dst valid
set is loop
Run pending tasks for ticket 0
Running in FG
another cfg
Legacy stack: conf IPv4 internal
conf dst internal
conf dst valid internal
conf loop internal
conf ip4
conf dst
set dst valid
set is loop
Run pending tasks for ticket 0
Running in FG
another cfg
Legacy stack: conf IPv4 internal
conf dst internal
conf dst valid internal
conf loop internal


-Per port stats table
ports | 0 | 1
-----------------------------------------------------------------------------------------

opackets | 0 | 0
obytes | 0 | 0
ipackets | 0 | 0
ibytes | 0 | 0


ierrors | 0 | 0
oerrors | 0 | 0

Tx Bw | 0.00 bps | 0.00 bps

-Global stats enabled
Cpu Utilization : 0.0 %
...


trex>stats -x
Xstats

Name: | Port 0: | Port 1:
-------------------------------+-----------------+----------------

rx_good_packets | 44 | 44
tx_good_packets | 44 | 44
tx_good_bytes | 2640 | 2640
rx_q0packets | 44 | 44
tx_q0packets | 44 | 44
tx_q0bytes | 2640 | 2640
rx_q0_good_packets | 44 | 44
tx_q0_good_packets | 44 | 44
tx_q0_good_bytes | 2640 | 2640
tx_q0_undersize_packets | 44 | 44

hanoh haim

unread,
Oct 30, 2018, 10:34:06 AM10/30/18
to gpano...@gmail.com, TRex Traffic Generator
It seems your virtio driver think it small packet and does not count it.
Could you try with bigger packets?

Hanoh 

--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To post to this group, send email to trex...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

gpano...@gmail.com

unread,
Oct 30, 2018, 11:01:23 AM10/30/18
to TRex Traffic Generator
Thank you for your reply! The same behavior persists whether I use a 150B or 1000B payload (modified 10*'x' to e.g. 150*'x' in udp_1pkt_simple.py).

The screen capture below is from the 150B payload, where the outgoing packets have a 196B size, while the incoming still 4B.

-Per port stats table
ports | 0 | 1
-----------------------------------------------------------------------------------------

opackets | 8 | 8
obytes | 1568 | 1568
ipackets | 8 | 8
ibytes | 32 | 32


ierrors | 0 | 0
oerrors | 0 | 0
Tx Bw | 0.00 bps | 0.00 bps

In the capture monitor console, I can normally see all 150 'x's on the RX ports.

How is it possible that the virtio driver gets confused about the received packets size, and TRex capturing feature not? Shouldn't capturing happen right after the packets have been received by the driver?

Thanks,
Georgia

hanoh haim

unread,
Oct 30, 2018, 11:11:07 AM10/30/18
to gpano...@gmail.com, TRex Traffic Generator
It seems as an Rx counters driver issue.
You should ask this in DPDK forum (virtio driver issue)


Thanks,
Hanoh

--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To post to this group, send email to trex...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

gpano...@gmail.com

unread,
Oct 30, 2018, 11:16:43 AM10/30/18
to TRex Traffic Generator
Thank you for all your effort! We will contact with DPDK forum.

Best regards,
Georgia

Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
0 new messages