Giter Site home page Giter Site logo

mellanox / libvma Goto Github PK

View Code? Open in Web Editor NEW
552.0 53.0 149.0 13.59 MB

Linux user space library for network socket acceleration based on RDMA compatible network adaptors

Home Page: https://www.mellanox.com/products/software/accelerator-software/vma?mtag=vma

License: Other

Python 1.18% Shell 3.36% C 19.87% C++ 74.06% Yacc 0.28% Lex 0.09% Makefile 0.36% M4 0.79%

libvma's Introduction

GitHub version Coverity Scan Build Status

Introduction

NVIDIA Messaging Accelerator (VMA) boosts performance for message-based and streaming applications such as those found in financial services market data environments and Web2.0 clusters. It allows application written over standard socket API to run over Ethernet and/or Infiniband from user-space with full network stack bypass.

The VMA architecture page includes additional information.

Download

Get all download and installation information here.
or some quick instruction in order to build VMA from source.

Technical Support

Have a question? please open a github issue or contact [email protected].

Additional Information

  • Refer to the libvma README
  • Messaging Accelerator VMA page
  • Check out the rest of the Wiki pages in this project

libvma's People

Contributors

alexandergrissik avatar alexbriskin avatar alexvm avatar aod314 avatar ashanably avatar avnerbh avatar awik84 avatar bhatnagarsid avatar daniellibenson avatar dinal avatar haron avatar honggang-li avatar iftahl avatar igor-ivanov avatar ilansmith avatar jdrouhard avatar liranoz12 avatar mike-dubman avatar mohammadqurt avatar nirwolfer avatar nkilim avatar ophirmunk avatar orkmellanox avatar pasis avatar rafiw avatar rosenbaumalex avatar rostiksh avatar serglelv avatar vasily-v-ryabov avatar vialogi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

libvma's Issues

Support for 802.3ad bonding mode

What need is this feature going to satisfy?
1. support for 802.3ad bonding mode

What is the expected output? What do you have currently? Any workaround?
Currently active-backup mode only is availaible with fail_over_mac=1

Please use labels and text to provide additional information.


Original issue reported on code.google.com by [email protected] on 13 Aug 2014 at 2:31

Please explain VMA error

What steps will reproduce the problem?
1. run a ping


What is the expected output? What do you see instead?

VMA ERROR  : rfs[0x7fe18ff494c0]:186:create_ibv_flow() Create of QP flow ID 
failed with flow dst:172.17.38.36:60005, src:205.209.217.135:1025, protocol:UDP


What version of the product are you using? On what operating system?

Linux aurarb01 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013 x86_64 
x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux Server release 6.5 (Santiago)
VMA 6.5.9

Please provide any additional information below.

[denis@aurarb01 ~]$ sudo LD_PRELOAD=libvma.so ping 205.209.217.135
 VMA INFO   : ---------------------------------------------------------------------------
 VMA INFO   : VMA_VERSION: 6.5.9-0 Release built on 2013-12-23-16:14:27
 VMA INFO   : Cmd Line: ping 205.209.217.135
 VMA INFO   : Log Level                      3                          [VMA_TRACELEVEL]
 VMA INFO   : ---------------------------------------------------------------------------
mlx4: prefer_bf=1
mlx4: prefer_bf=1
 VMA ERROR  : rfs[0x7fe18ff494c0]:186:create_ibv_flow() Create of QP flow ID failed with flow dst:172.17.38.36:60005, src:205.209.217.135:1025, protocol:UDP
PING 205.209.217.135 (205.209.217.135) 56(84) bytes of data.
64 bytes from 205.209.217.135: icmp_seq=1 ttl=60 time=0.086 ms
64 bytes from 205.209.217.135: icmp_seq=2 ttl=60 time=0.049 ms
64 bytes from 205.209.217.135: icmp_seq=3 ttl=60 time=0.038 ms
64 bytes from 205.209.217.135: icmp_seq=4 ttl=60 time=0.042 ms
64 bytes from 205.209.217.135: icmp_seq=5 ttl=60 time=0.038 ms



Original issue reported on code.google.com by [email protected] on 10 Apr 2014 at 4:23

libvma dont work with teamd daemon in centos 7

subj.

VMA ERROR : utils:243:priv_read_file() ERROR while opening file /sys/class/net/team1/device/resource (errno 2 No such file or directory)
VMA ERROR : utils:484:get_ipv4_from_ifname() Failed getting ipv4 from interface 'eth0' (errno=99 Cannot assign requested address)
VMA WARNING: rtm:143:rt_mgr_update_source_ip() could not figure out source ip for rtv = dst: 169.254.0.0 netmask: 255.255.0.0 dev: eth0 table :main scope 253 type 1 index 2
VMA ERROR : utils:484:get_ipv4_from_ifname() Failed getting ipv4 from interface 'team1' (errno=99 Cannot assign requested address)
VMA WARNING: rtm:143:rt_mgr_update_source_ip() could not figure out source ip for rtv = dst: 169.254.0.0 netmask: 255.255.0.0 dev: team1 table :main scope 253 type 1 index 6
VMA ERROR : utils:484:get_ipv4_from_ifname() Failed getting ipv4 from interface 'eth0' (errno=99 Cannot assign requested address)
VMA WARNING: rtm:206:rt_mgr_update_source_ip() could not figure out source ip for rtv = dst: 169.254.0.0 netmask: 255.255.0.0 dev: eth0 table :main scope 253 type 1 index 2
VMA ERROR : utils:484:get_ipv4_from_ifname() Failed getting ipv4 from interface 'team1' (errno=99 Cannot assign requested address)
VMA WARNING: rtm:206:rt_mgr_update_source_ip() could not figure out source ip for rtv = dst: 169.254.0.0 netmask: 255.255.0.0 dev: team1 table :main scope 253 type 1 index 6
VMA PANIC : ring_simple[0x1399df0]:144:create_resources() p_ring_info.p_ib_ctx = NULL. It can be related to wrong bonding configuration
terminate called without an active exception
Aborted

Blocked bs Non-blocked sockers

As far as I understand if I see in vma_stats
"UDP, Non-blocked, MC Loop Enabled , MC IF = [172.17.38.36]"

It means the socket is in "Non-blocked" mode and therefore RX_POLL does not 
apply and there is little performance improvement via VMA, nothing is done on 
RX path. Is it correct? "Blocked" is mandatory to achieve decent results?

Original issue reported on code.google.com by [email protected] on 28 Apr 2014 at 4:02

VMA ring allocation problem

Hello team.

I have some issue with VMA VMA_RING_ALLOCATION_LOGIC_RX=30.
My application is a client application, which listens to UDP multicast. If I use VMA_RING_ALLOCATION_LOGIC_RX=30 I have some measurable decrease in latency, but on the other side my application starts to lose packets.

I managed to fix it in 2 ways: 1. pin my application to 1 core. 2. Set VMA_RING_MIGRATION_RATIO_RX = -1. I have noticed that the application loses packets when the most loaded CPU core changes on another one. And I guess the packets loss during RING migration.

Is it the correct behavior of VMA or not?

Add receive software packet timestampping support

These patches update libvma to support software receive packet timestampping, 
with SO_TIMESTAMP, SO_TIMESTAMPNS, and SO_TIMESTAMPING.

Additionally I'll mention that I really would like to have hardware packet 
timestamps but it is my understanding that the infrastructure to get and 
synchronize the hardware timestamps with the system time is still in 
development.

Original issue reported on code.google.com by [email protected] on 29 Jan 2014 at 7:32

Attachments:

VMA defaults to huge pages on Redhat 7.1 which results in the failure of memory registration

On RH7.1 VMA works with VMA_MEM_ALLOC_TYPE=1 when configured with a large number of hugepages. But when we do not set this value we get:

VMA WARNING: ib_ctx_collection89:mem_reg_on_all_devices() Failure in mem_reg: addr=0x2aaaab200000, length=372800063, mr_pos=0, mr_array[mr_pos]=0, dev=0x74a540, ibv_dev=mlx4_0
VMA WARNING: bpool[0x754840]:269:register_memory() Failed registering memory, This might happen due to low MTT entries. Please refer to README.txt for more info

settings:

[mlx4_core]$ cd parameters
[parameters]$ ls -l
total 0
-rw-r--r-- 1 root root 4096 Aug 6 13:00 block_loopback
-rw-r--r-- 1 root root 4096 Aug 6 13:00 debug_level
-r--r--r-- 1 root root 4096 Aug 6 13:00 enable_64b_cqe_eqe
-r--r--r-- 1 root root 4096 Aug 6 13:00 enable_qos
-rw-r--r-- 1 root root 4096 Aug 6 13:00 internal_err_reset
-r--r--r-- 1 root root 4096 Aug 6 13:00 log_mtts_per_seg
-r--r--r-- 1 root root 4096 Aug 6 13:00 log_num_mac
-r--r--r-- 1 root root 4096 Aug 6 10:38 log_num_mgm_entry_size
-r--r--r-- 1 root root 4096 Aug 6 13:00 log_num_vlan
-r--r--r-- 1 root root 4096 Aug 6 13:00 msi_x
-r--r--r-- 1 root root 4096 Aug 6 13:00 num_vfs
-r--r--r-- 1 root root 4096 Aug 6 13:00 port_type_array
-r--r--r-- 1 root root 4096 Aug 6 13:00 probe_vf
-r--r--r-- 1 root root 4096 Aug 6 13:00 use_prio
[parameters]$ cat *
1
0
Y
N
1
7
7
-1
0
1

,0,0

,N

Silence ofed_info: command not found error

Now that flow steering is making its way into upstream you won't need to have 
OFED and thus won't have ofed_info.

 VMA INFO   : ---------------------------------------------------------------------------
 VMA INFO   : VMA_VERSION: 6.6.0-0 Development Snapshot built on Feb 12 2014 09:17:53
 VMA INFO   : Cmd Line: netperf --help
 VMA INFO   : Current Time: Fri Mar  7 14:39:13 2014
 VMA INFO   : Pid: 30353
sh: ofed_info: command not found
 VMA INFO   : OFED Version: ๏ฟฝ VMA INFO   : Architecture: x86_64
 VMA INFO   : Node: berbox2
 VMA INFO   : ---------------------------------------------------------------------------
 VMA INFO   : Log Level                      3                          [VMA_TRACELEVEL]
 VMA INFO   : ---------------------------------------------------------------------------

I've attached a patch that simply sends stderr to /dev/null to swallow the 
"command not found" error.  There are probably a number of other solutions to 
this problem, but this is the quick easy one.

Original issue reported on code.google.com by [email protected] on 7 Mar 2014 at 10:10

Attachments:

epoll_wait causes high CPU usage

Hi,

This issue has been puzzled me for a while.
Every time using libvma, the CPU usage becomes high when client doing disconnect and reconnect.
I checked gstack, seems epoll_wait becomes nonblock and keeps looping.

When not using libvma, TCP's recv seems not having such issue.

Configurable message/packet number limits

Background - after Knight Capital 
http://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stock_trading_disruption 
software related trading loss of $400+ million incured in minutes a lot of 
people have concerns about out of control trading algorithms. Even ~500 packet 
a second sent by out of control algorithm could create losses in tens of 
millions before human operator would even notice.

Of course libvma is by no means proper place to put real risk management and 
it'd be just one of the measures / lines of defence between trading algorithm 
and the exchange. Idea is to limit number of packets sent, it's the most 
damaging scenario - infinite loop in application sending orders. Of course the 
application layer would do all possible to prevent it but any additional layer 
would help.

Other network layers can provide some protection features (through QoS) but 
switches and OFED are MB/s oriented not packet/s oriented typically. Linux 
kernel has "tc" (traffic control) but I'm sure it'd incur very much latency and 
VMA can't be used. 

From technical perspective I see it as a counter(s) per application / remote 
destination configured in VMA conf . Once certain threshold value exceeded 
socket needs to be closed.

1. total number of packets (application would typically write entire trading 
order at once so number of socket write calls is okay) since some point (socket 
open or midnight local time) allowed, once limit exceeded please close the 
socket.
2. even better would be a limit on messages per unit of time, this value could 
be computed for example as exponential moving average (similar to Linux load 
average) per application and network destination.
3. this could impact latency somewhat but we could count a certain pattern in 
outgoing application flow i.e. "8=FIX.4.2" and count these instead of number of 
socket writes

Features 2, 3 are great to have but at least 1 would be of great help.
This patch could be in long term a marketing advantage of Mellanox.

Best
Denis

Original issue reported on code.google.com by [email protected] on 30 Mar 2014 at 10:26

VMA PANIC when IPv6 is disabled

What steps will reproduce the problem?
1. Disable IPv6 kernel module, by adding "install ipv6 /bin/true" to modprobe 
configuration.
2. Install MLNX_OFED and libvma
3. Run an App with LD_PRELOAD=libvma.so (e.g. netcat or telnet)

What is the expected output? What do you see instead?
Expected: app to work
Output: VMA_PANIC because /dev/infiniband/rdma_cm cannot be found

What version of the product are you using? On what operating system?
libvma 6.4.11;
MLNX_OFED 2.0-3.0.0-rhel6_4-x86-64
Scientific linux 6.4 (Carbon) - kernel 2.6.32-358.23.2.el6.x86_64

Please provide any additional information below.

OFED module RDMA-CM fails to load After installation, 

# service openibd restart
Unloading HCA driver:                                      [  OK  ]
Loading HCA driver and Access Layer:                       [FAILED]

Please open an issue in the http://bugs.openfabrics.org and attach 
/tmp/ib_debug_info.log

Original issue reported on code.google.com by [email protected] on 5 Nov 2013 at 2:09

Attachments:

Support IPv6 (AF_INET6(10))

What need is this feature going to satisfy?
1. open socket(type = AF_INET6(10)) 
2. use IPv6 addressing to: bind(), connect(), sendto(), ...
3.

What is the expected output? What do you have currently? Any workaround?
Provide IPv6 support for recv and send of offloaded traffic via VMA


Please use labels and text to provide additional information.
See more info in http://man7.org/linux/man-pages/man7/ipv6.7.html

Original issue reported on code.google.com by [email protected] on 19 Aug 2014 at 8:58

Data loss seen with libvma API - data returned by vma_packet->iovec is less than the value returned by recvfrom_copy

Hi,

Iโ€™ve written a client server program using libvma.so. We are seeing data loss when data transferred using recvfrom_zcopy libvma API.

Explanation:

client_vma code
Client program which accepts, server IP address, port, buffer size, number of buffers and interval between buffers sent (in micro secs).

$ ./client_vma
usage ./client_vma <hostname> <port> <bufsize> <bufcount> <sleepinmicro>

Example: Following client will connect to server 19.1.1.0:9000 and will send buffers of size 4096 to server 100 times with time interval of 10 micro seconds.
    ./client_vma โ€œ19.1.1.0โ€ 9000 4096 100 10

server_svm code
Server program which accepts IP address and port. Internally it uses recvfrom_zcopy() API of libvma whenever it receives data event. Server calculates the total amount of data received from the client and prints it.

Amount of data received are calculated in 2 ways:

  1. Data length based on return value
    return value from recvfrom_zcopy is the total data len represented by iovec segments in vma_packets
  2. Data length based on iovec
    For each received vma_packet Iterate through iovec and calculate total length of data by adding up all iov[i].io_len

Both of the above value expected to be same. But based on experiment in our lab, we found that, some times the recvfrom_zopy returns correct number data bytes, but corresponding vma_packets has iovec with less number of data bytes.

<Server_vma>
$ export VMA_MTU=9000; export LD_PRELOAD=/usr/lib64/libvma.so; ./server_vma 192.168.1.1 8000
 VMA INFO: ---------------------------------------------------------------------------
 VMA INFO: VMA_VERSION: 7.0.14-0 Release built on Jan 28 2016 20:41:00
 VMA INFO: Cmd Line: ./server_vma 192.168.1.1 8000
 VMA INFO: OFED Version: MLNX_OFED_LINUX-3.2-1.0.1.1:
 VMA INFO: Log Level                      INFO                       [VMA_TRACELEVEL]
 VMA INFO: Rx Mem Bufs                    500000                     [VMA_RX_BUFS]
 VMA INFO: Select Poll (usec)             -1                         [VMA_SELECT_POLL]
 VMA INFO: CQ Interrupts Moderation       Disabled                   [VMA_CQ_MODERATION_ENABLE]
 VMA INFO: CQ Adaptive Moderation         Disabled                   [VMA_CQ_AIM_INTERVAL_MSEC]
 VMA INFO: MTU                            9000                       [VMA_MTU]
 VMA INFO: ---------------------------------------------------------------------------
 VMA WARNING: ndv104:configure() Mismatch between interface eth1 MTU=1500 and VMA_MTU=9000. Make sure VMA_MTU and all offloaded interfaces MTUs match.
Accepted connection on descriptor 23 (host=192.168.1.2, port=47401)
Total Data Recieved [socketfd: 23]: Based on iovec: 2920 bytes,  Based on return value: 2920 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 4380 bytes,  Based on return value: 4380 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 7300 bytes,  Based on return value: 7300 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 8760 bytes,  Based on return value: 8760 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 13140 bytes,  Based on return value: 13140 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 14600 bytes,  Based on return value: 14600 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 21900 bytes,  Based on return value: 21900 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 23360 bytes,  Based on return value: 23360 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 32120 bytes,  Based on return value: 32120 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 33580 bytes,  Based on return value: 33580 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 43800 bytes,  Based on return value: 43800 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 45260 bytes,  Based on return value: 45260 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 52560 bytes,  Based on return value: 52560 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 56940 bytes,  Based on return value: 56940 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 58400 bytes,  Based on return value: 58400 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 67160 bytes,  Based on return value: 67160 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 71540 bytes,  Based on return value: 71540 bytes
Total Data Recieved [socketfd: 23]: Based on iovec: 73000 bytes,  Based on return value: 73000 bytes
**## ERROR: Datalen from vma_packet's iovec: 6161 != Return value from recvfrom_zcopy: 8920 !!!**
Total Data Recieved [socketfd: 23]: Based on iovec: 79161 bytes,  Based on return value: 81920 bytes
</Server>

Above text prefixed with "##ERROR" is printed only if the data length returned by recvfrom_zopy does not match the data provided by corresponding vma_packets.

<Client_vma>
$ export LD_PRELOAD=/usr/lib64/libvma.so; ./client_vma 192.168.1.1 8000 4096 20  10
 VMA INFO: ---------------------------------------------------------------------------
 VMA INFO: VMA_VERSION: 7.0.14-0 Release built on Jan 28 2016 20:41:00
 VMA INFO: Cmd Line: ./client_vma 192.168.1.1 8000 4096 20 10
 VMA INFO: OFED Version: MLNX_OFED_LINUX-3.2-1.0.1.1:
 VMA INFO: Log Level                      INFO                       [VMA_TRACELEVEL]
 VMA INFO: ---------------------------------------------------------------------------
Buf[0] sent (Total data sent: 4096)
Buf[1] sent (Total data sent: 8192)
Buf[2] sent (Total data sent: 12288)
Buf[3] sent (Total data sent: 16384)
Buf[4] sent (Total data sent: 20480)
Buf[5] sent (Total data sent: 24576)
Buf[6] sent (Total data sent: 28672)
Buf[7] sent (Total data sent: 32768)
Buf[8] sent (Total data sent: 36864)
Buf[9] sent (Total data sent: 40960)
Buf[10] sent (Total data sent: 45056)
Buf[11] sent (Total data sent: 49152)
Buf[12] sent (Total data sent: 53248)
Buf[13] sent (Total data sent: 57344)
Buf[14] sent (Total data sent: 61440)
Buf[15] sent (Total data sent: 65536)
Buf[16] sent (Total data sent: 69632)
Buf[17] sent (Total data sent: 73728)
Buf[18] sent (Total data sent: 77824)
Buf[19] sent (Total data sent: 81920)
**##Overall Total data sent = 81920 bytes**

wakeup: Add return_from_sleep() method

wakeup::remove_wakeup_fd() both decremented m_is_sleeping and removed
the wakeup fd from the epoll list.  In the vast majority of cases there
is no wakeup fd present which causes all blocking epoll_wait calls to
perform an unnecessary epoll_ctl() systemcall.

This change adds a return_from_sleep() method which handles the
decrementing of m_is_sleeping and moves the remove_wakeup_fd() call to
only happen when there is a wakeup fd present in the events returned by
epoll_wait().

This change additionally makes a small optimization to
epoll_wait_call::_wait() by using a for loop and not copying struct
epoll_event to shrink the array.

On my hardware this increases a netperf UDP_RR test with VMA_RX_POLL=0
and VMA_SELECT_POLL=0 from 89948 transactions per second to 94307
transactions per second.

Original issue reported on code.google.com by [email protected] on 31 Jan 2014 at 11:25

Attachments:

recvfrom_zcopy in epoll_wait loop

In epoll_wait loop with multiple FDs registered should I call recvfrom_zcopy 
once only?

Otherwise if there is a continuous stream of UDP packets incoming it always 
returns recvfrom_zcopy > 0 and I never get any chance to get to the other FD.

See attached file stest.c - line #91. Is it correct (provides optimal 
performance) to attempt to receive only once?

Thanks

Original issue reported on code.google.com by [email protected] on 13 Jul 2014 at 10:07

Attachments:

vma 7.0.11 build errors

I am experiencing issues trying to build vma 7.0.11 from source over OFED 3.1_1.0.3 on CentOS 6.7.

Here is the build log:

log.txt

Broken cubic implementation

Hi,

I'm wondering whether this implementation of cubic has been used extensively? There seems to be an obvious problem in this code.

In cubic_record_rtt(), t_srtt_ticks is supposed to be a "smoothed round-trip time" but you use 'pcb->rttest', which is a timestamp taken upon sending a TCP segment (in tcp_out.c) to be used later (upon getting a corresponding ACK) to measure RTT.

With the current code, what will happen is that as tcp_ticks is growing over time, so the values of pcb->rttest are, and so cubic_data->mean_rtt_ticks becomes bigger and bigger, resulting in setting very big cwnd values (but it will outperform Linux ;-)).

I guess what should be used is something like this:

diff --git a/src/vma/lwip/cc_cubic.c b/src/vma/lwip/cc_cubic.c
index 4c78b7c..85e3a57 100644
--- a/src/vma/lwip/cc_cubic.c
+++ b/src/vma/lwip/cc_cubic.c
@@ -328,7 +328,7 @@ cubic_record_rtt(struct tcp_pcb *pcb)
    /* Ignore srtt until a min number of samples have been taken. */
    if (pcb->t_rttupdated >= CUBIC_MIN_RTT_SAMPLES) {

-       t_srtt_ticks = pcb->rttest;
+       t_srtt_ticks = pcb->sa >> 3;

        /*
         * Record the current SRTT as our minrtt if it's the smallest

--Dmitry

VMA not sending via Ethernet on RH7,1

We run a test program that works fine with the kernel stack

VMA INFO : ---------------------------------------------------------------------------
VMA INFO : VMA_VERSION: 7.0.4-0 Release built on 2015-07-09-03:08:51
VMA INFO : Cmd Line: strace -o log ./OrderEntry T_JT009A1 azsxdc1234 7.40.28.11 21024 1
VMA INFO : OFED Version: โ–’โ–’โ–’โ–’ VMA INFO : Log Level 3 [VMA_TRACELEVEL]
VMA INFO : CQ Interrupts Moderation Disabled [VMA_CQ_MODERATION_ENABLE]
VMA INFO : CQ Adaptive Moderation Disabled [VMA_CQ_AIM_INTERVAL_MSEC]
VMA INFO : Mem Allocate type 1 (Contig Pages) [VMA_MEM_ALLOC_TYPE]
VMA INFO : ---------------------------------------------------------------------------
VMA INFO : ---------------------------------------------------------------------------
VMA INFO : VMA_VERSION: 7.0.4-0 Release built on 2015-07-09-03:08:51
VMA INFO : Cmd Line: ./OrderEntry T_JT009A1 azsxdc1234 7.40.28.11 21024 1
VMA INFO : OFED Version: Pโ–’โ–’โ–’ VMA INFO : Log Level 3 [VMA_TRACELEVEL]
VMA INFO : CQ Interrupts Moderation Disabled [VMA_CQ_MODERATION_ENABLE]
VMA INFO : CQ Adaptive Moderation Disabled [VMA_CQ_AIM_INTERVAL_MSEC]
VMA INFO : Mem Allocate type 1 (Contig Pages) [VMA_MEM_ALLOC_TYPE]
VMA INFO : ---------------------------------------------------------------------------

strace output

select(23, [], [], NULL, {0, 0}) = 0 (Timeout)
select(23, [], [], NULL, {0, 0}) = 0 (Timeout)
select(23, [], [], NULL, {0, 0}) = 0 (Timeout)
select(23, [], [], NULL, {0, 0}) = 0 (Timeout)
select(23, [], [], NULL, {0, 0}) = 0 (Timeout)
select(23, [], [], NULL, {0, 0}) = 0 (Timeout)
select(23, [], [], NULL, {0, 0}) = 0 (Timeout)
select(23, [], [], NULL, {0, 0}) = 0 (Timeout)
select(23, [], [], NULL, {0, 0}) = 0 (Timeout)
select(23, [14], [], NULL, {14, 899448}) = 1 (in [14], left {14, 899446})
epoll_wait(14, {{EPOLLIN, {u32=0, u64=0}}}, 16, 0) = 1
epoll_ctl(14, EPOLL_CTL_DEL, 15, NULL) = 0
select(23, [14], [], NULL, {14, 899400}) = 0 (Timeout)
fcntl(22, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(22, F_SETFL, O_RDWR|O_NONBLOCK) = 0
times({tms_utime=6, tms_stime=26, tms_cutime=0, tms_cstime=0}) = 437715486
write(30, "0", 1) = 1
epoll_ctl(7, EPOLL_CTL_ADD, 5, {EPOLLIN, {u32=5, u64=7953746620024094725}}) = 0
close(22) = 0
futex(0x7ffff652a190, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "terminate called after throwing "..., 48) = 48
write(2, "std::runtime_error", 18) = 18

libvma crushes on vlan (on bond) interfaces

i got mlnx0+mlnx1=bond0 active-backup
and I got bond0.77 vlan interface.
centos 7.1

error:

VMA ERROR : utils:238:priv_read_file() ERROR while opening file /sys/class/net/vlan77/device/resource (errno 2 No such file or directory)
VMA PANIC : ring[0x14229e0]:199:create_resources() ibv_create_comp_channel for rx failed. p_rx_comp_event_channel = (nil) (errno=9 Bad file descriptor)

here is cannot be this file, cause interface is virtual, so why it try it to find?

libvma got errors with no ip interfaces

ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether d8:50:e6:c2:80:b0 txqueuelen 1000 (Ethernet)
RX packets 33780 bytes 12221293 (11.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 27684 bytes 2319239 (2.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18 memory 0xfb700000-fb720000

ifconfig bond0
bond0: flags=5122<BROADCAST,MASTER,MULTICAST> mtu 1500
ether 9a:f8:31:a3:e0:bf txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

VMA ERROR : utils:484:get_ipv4_from_ifname() Failed getting ipv4 from interface 'eth0' (errno=99 Cannot assign requested address)
VMA WARNING: rtm:143:rt_mgr_update_source_ip() could not figure out source ip for rtv = dst: 169.254.0.0 netmask: 255.255.0.0 dev: eth0 table :main scope 253 type 1 index 2
VMA ERROR : utils:484:get_ipv4_from_ifname() Failed getting ipv4 from interface 'bond1' (errno=99 Cannot assign requested address)
VMA WARNING: rtm:143:rt_mgr_update_source_ip() could not figure out source ip for rtv = dst: 169.254.0.0 netmask: 255.255.0.0 dev: bond1 table :main scope 253 type 1 index 14
VMA ERROR : utils:484:get_ipv4_from_ifname() Failed getting ipv4 from interface 'eth0' (errno=99 Cannot assign requested address)
VMA WARNING: rtm:206:rt_mgr_update_source_ip() could not figure out source ip for rtv = dst: 169.254.0.0 netmask: 255.255.0.0 dev: eth0 table :main scope 253 type 1 index 2
VMA ERROR : utils:484:get_ipv4_from_ifname() Failed getting ipv4 from interface 'bond1' (errno=99 Cannot assign requested address)
VMA WARNING: rtm:206:rt_mgr_update_source_ip() could not figure out source ip for rtv = dst: 169.254.0.0 netmask: 255.255.0.0 dev: bond1 table :main scope 253 type 1 index 14

Data loss seen with libvma API - callback API vma_recv_callback_t

Data loss seen with libvma callback API: vma_recv_callback_t

I've written client & server program which uses libvma APIs.

Client code: Connects to servers by opening socket using server IP and port number. Sends data over the socket. To use libvma.so did LD_PRELOAD of libvma.so library

Server Code: Server initializes vma_api and registers callback server_vma_recv_callback, which counts number of bytes recieved in by iovecs & prints them in total with the packet id. And also prints total data recieved till now from the client. Then returns VMA_PACKET_RECV.

Callback: Recieved VMA packet 0x7f5787df1a98 containing data of length: 1460, Total data recieved until now: 23360

Packets are zero copied using recvfrom_zcopy whenever epool data event is raised for the packet. It also prints the packet ID and length of the data vma packet points to (using iovec).

recvfrom_zcopy: Packet_id: 0x7f5787df0d78 datalen: 2920

Following are the Server logs.

$ export VMA_MTU=9000; export LD_PRELOAD=/usr/lib64/libvma.so; ./server_vma_cb 192.168.1.1 8000
 VMA INFO: ---------------------------------------------------------------------------
 VMA INFO: VMA_VERSION: 7.0.14-0 Release built on Jan 28 2016 20:41:00
 VMA INFO: Cmd Line: ./server_vma_cb 192.168.1.1 8000
 VMA INFO: OFED Version: MLNX_OFED_LINUX-3.2-1.0.1.1:
 VMA INFO: Log Level                      INFO                       [VMA_TRACELEVEL]
 VMA INFO: MTU                            9000                       [VMA_MTU]
 VMA INFO: ---------------------------------------------------------------------------
 VMA WARNING: ndv104:configure() Mismatch between interface eth1 MTU=1500 and VMA_MTU=9000. Make sure VMA_MTU and all offloaded interfaces MTUs match.
Accepted connection on descriptor 23 (host=192.168.1.2, port=51494)
callback registered
Callback: Recieved VMA packet 0x7f5787df0a30 containing data of length: 2920, Total data recieved until now: 2920
recvfrom_zcopy: Packet_id: 0x7f5787df0a30 datalen: 2920
Callback: Recieved VMA packet 0x7f5787df0c60 containing data of length: 1460, Total data recieved until now: 4380
recvfrom_zcopy: Packet_id: 0x7f5787df0c60 datalen: 1460
Callback: Recieved VMA packet 0x7f5787df0d78 containing data of length: 2920, Total data recieved until now: 7300
recvfrom_zcopy: Packet_id: 0x7f5787df0d78 datalen: 2920
Callback: Recieved VMA packet 0x7f5787df0fa8 containing data of length: 1460, Total data recieved until now: 8760
recvfrom_zcopy: Packet_id: 0x7f5787df0fa8 datalen: 1460
Callback: Recieved VMA packet 0x7f5787df10c0 containing data of length: 4380, Total data recieved until now: 13140
recvfrom_zcopy: Packet_id: 0x7f5787df10c0 datalen: 4380
Callback: Recieved VMA packet 0x7f5787df1408 containing data of length: 1460, Total data recieved until now: 14600
recvfrom_zcopy: Packet_id: 0x7f5787df1408 datalen: 1460
Callback: Recieved VMA packet 0x7f5787df1520 containing data of length: 7300, Total data recieved until now: 21900
recvfrom_zcopy: Packet_id: 0x7f5787df1520 datalen: 7300
Callback: Recieved VMA packet 0x7f5787df1a98 containing data of length: 1460, Total data recieved until now: 23360
recvfrom_zcopy: Packet_id: 0x7f5787df1a98 datalen: 1460
Callback: Recieved VMA packet 0x7f5787df1bb0 containing data of length: 8760, Total data recieved until now: 32120
recvfrom_zcopy: Packet_id: 0x7f5787df1bb0 datalen: 8760
Callback: Recieved VMA packet 0x7f5787df2240 containing data of length: 1460, Total data recieved until now: 33580
recvfrom_zcopy: Packet_id: 0x7f5787df2240 datalen: 1460
Callback: Recieved VMA packet 0x7f5787df2358 containing data of length: 7300, Total data recieved until now: 40880
recvfrom_zcopy: Packet_id: 0x7f5787df2358 datalen: 4461
recvfrom_zcopy: Packet_id: 0x7f5787df28d0 datalen: 4541

Client logs:

dce@alba154232:~/vikram$ export LD_PRELOAD=/usr/lib64/libvma.so; ./client_vma 192.168.1.1 8000 4096 10 100
 VMA INFO: ---------------------------------------------------------------------------
 VMA INFO: VMA_VERSION: 7.0.14-0 Release built on Jan 28 2016 20:41:00
 VMA INFO: Cmd Line: ./client_vma 192.168.1.1 8000 4096 10 100
 VMA INFO: OFED Version: MLNX_OFED_LINUX-3.2-1.0.1.1:
 VMA INFO: Log Level                      INFO                       [VMA_TRACELEVEL]
 VMA INFO: ---------------------------------------------------------------------------
Buf[0] sent (Total data sent: 4096)
Buf[1] sent (Total data sent: 8192)
Buf[2] sent (Total data sent: 12288)
Buf[3] sent (Total data sent: 16384)
Buf[4] sent (Total data sent: 20480)
Buf[5] sent (Total data sent: 24576)
Buf[6] sent (Total data sent: 28672)
Buf[7] sent (Total data sent: 32768)
Buf[8] sent (Total data sent: 36864)
Buf[9] sent (Total data sent: 40960)
##Overall Total data sent = 40960 bytes

Issue:

  • Total data sent by client is 40960 bytes, while server received less than this i.e. 40880 bytes. So it looks to be data loss. You can also look at the code attached, to see if anything missing w.r.t API usage.
  • From the logs you can see that, for the last packet the amount of data reported by the server_vma_recv_callback and recvfrom_zcopy are different for same packet. And also for packet (0x7f5787df2358) callback is not invoked but recvfrom_zopy event recieved.
Callback: Recieved VMA packet 0x7f5787df2358 containing data of length: 7300, Total data recieved until now: 40880
recvfrom_zcopy: Packet_id: 0x7f5787df2358 datalen: 4461

We are blocked on this, so an early resolution to this would be very helpful.

libvma seemingly enabled only on IB connections not RoCE. feature or misconfiguration?

hi all,
I think the subject says it all, but to clarify, we have a setup with 2 RoCE + 2 IB connections per node. We tried to use libvma (both preloaded and using the extra API) on the system, but it would fail everytime it tried to register the rdma devices when we used only the RoCE connections, it did however seemed to be enabled when the IB ports were connected as well. Please confirm if this is the case as it was a bit unclear in both the library documentation and the VMA user guide on Mellanox's site. However, even if it appeared to be enabled, we still have problems using it successfully and we can't get either the tests nor our own application -using VMA extra API- work.

net_device_table_mgr: Remove unnecessary epoll_wait

After epolling the global ring epoll fd and handling any ready CQ
channels the code does a second zero timeout epoll_wait() on the global
ring epoll fd.  This second epoll_wait() must be unnecessary since both
the return of epoll_wait() and the returned epoll_event array which is
stored on the stack are ignored.  Additionally to my knowledge there are
no secondary side effects by calling epoll_wait() so the comment
implying this is to "clear the nested set fd" must be erroneous or the
code must not be doing what the author intended.

Results of a blocking udp_lat test with and without this change:

Without change
$ VMA_SELECT_POLL=0 VMA_RX_POLL=0 LD_PRELOAD=libvma.so udp_lat -c -t 10 -f 
udp_lat_ips -F epoll
7.138 usec

Removing extra epoll_wait()
$ VMA_SELECT_POLL=0 VMA_RX_POLL=0 LD_PRELOAD=libvma.so udp_lat -c -t 10 -f 
udp_lat_ips -F epoll
6.827 usec

Original issue reported on code.google.com by [email protected] on 4 Feb 2014 at 6:08

Attachments:

VMA panic with iperf and Ethernet

Running iperf between two hosts via Ethernet:

VMA PANIC : qpm[0x643be0]:556:prepare_ibv_qp() failed to modify QP from ERR to INIT state (ret = -3)

VMA defaults to huge pages on Redhat 7.1 which results in the failure of memory registration

On RH7.1 VMA works with VMA_MEM_ALLOC_TYPE=1 when configured with a large number of hugepages. But when we do not set this value we get:

VMA WARNING: ib_ctx_collection89:mem_reg_on_all_devices() Failure in mem_reg: addr=0x2aaaab200000, length=372800063, mr_pos=0, mr_array[mr_pos]=0, dev=0x74a540, ibv_dev=mlx4_0
VMA WARNING: bpool[0x754840]:269:register_memory() Failed registering memory, This might happen due to low MTT entries. Please refer to README.txt for more info

settings:

[mlx4_core]$ cd parameters
[parameters]$ ls -l
total 0
-rw-r--r-- 1 root root 4096 Aug 6 13:00 block_loopback
-rw-r--r-- 1 root root 4096 Aug 6 13:00 debug_level
-r--r--r-- 1 root root 4096 Aug 6 13:00 enable_64b_cqe_eqe
-r--r--r-- 1 root root 4096 Aug 6 13:00 enable_qos
-rw-r--r-- 1 root root 4096 Aug 6 13:00 internal_err_reset
-r--r--r-- 1 root root 4096 Aug 6 13:00 log_mtts_per_seg
-r--r--r-- 1 root root 4096 Aug 6 13:00 log_num_mac
-r--r--r-- 1 root root 4096 Aug 6 10:38 log_num_mgm_entry_size
-r--r--r-- 1 root root 4096 Aug 6 13:00 log_num_vlan
-r--r--r-- 1 root root 4096 Aug 6 13:00 msi_x
-r--r--r-- 1 root root 4096 Aug 6 13:00 num_vfs
-r--r--r-- 1 root root 4096 Aug 6 13:00 port_type_array
-r--r--r-- 1 root root 4096 Aug 6 13:00 probe_vf
-r--r--r-- 1 root root 4096 Aug 6 13:00 use_prio
[parameters]$ cat *
1
0
Y
N
1
7
7
-1
0
1

,0,0

,N

Delete rx channel from global fd collection

Previously rx channel fds were never explicitly removed from the global
fd collection, and the m_p_n_rx_channel_fds member was leaked.  Since
the rx channel fds were never removed, a subsequent call to
add_cq_channel_fd() with a new fd that happens to match an old no longer
existing rx channel fd, would trigger the removal of the fd from the
global collection and would not add the new fd.

This removes the rx channel fd from the global fd collection as the
completion channels are destroyed, and frees the m_p_n_rx_channel_fds
member so that it is not leaked.

Original issue reported on code.google.com by [email protected] on 17 Jan 2014 at 6:40

Attachments:

Support for connectX4

It seems that connectx4 / mlx5 /libmlx5 is not supported for the inbox (upstream) driver and not working on Redhat 7.X. Can that be fixed?

VMA does not honor multiple routing tables with policy-based routing

What steps will reproduce the problem?
1. Given two local interfaces, mlx0 and mlx1, give them IP addresses in the 
same subnet.
2. Set up the proper routing tables and rules.
3. Write a simple test application; create a TCP socket, bind() it to a 
specific local IP address and try to connect() to an external IP like 8.8.8.8. 
Doing this without loading VMA succeeds. Once you try this with VMA it fails 
finding the gateway for that particular interface and is not able to connect, 
giving errors about not being able to find the destination gateway and 
subsequently saying it can't lookup the neigh for the destination. For the 
record, this fails with SO_BINDTODEVICE as well.

An example of the whole process:

sysctl net.ipv4.conf.all.arp_ignore=1
sysctl net.ipv4.conf.all.arp_announce=2

ip link set dev mlx0 up
ip link set dev mlx1 up

ip addr add dev mlx0 10.0.0.201/24 brd +
ip addr add dev mlx1 10.0.0.202/24 brd +

ip route add 10.0.0.0/24 dev mlx0 proto kernel scope link src 10.0.0.201 table 
10
ip route add 10.0.0.0/24 dev mlx1 proto kernel scope link src 10.0.0.202 table 
20

ip route add default via 10.0.0.254 dev mlx0 table 10
ip route add default via 10.0.0.254 dev mlx1 table 20

ip rule add from 10.0.0.201 pri 10000 lookup 10
ip rule add from 10.0.0.202 pri 10000 lookup 20

What is the expected output? What do you see instead?
The expected output is that VMA will lookup the proper route using the routing 
rules and the proper table (lookup rule for src ip 10.0.0.202 for example, see 
it resides in routing table 20, lookup routing table 20 and find the default gw 
there). Instead, VMA fails to find the proper route because it only looks at 
the main routing table and does not consider routing rules at all.

What version of the product are you using? On what operating system?
libvma v6.6.0, Debian with kernel 3.12-rt

Please provide any additional information below.


Original issue reported on code.google.com by [email protected] on 16 Jun 2014 at 11:12

libnl issues on Redhat 7.0

Runnig libvma triggers a bug in libnl that seems to indicate that an invalid module tried to register itself with libnl.

LD_PRELOAD=/usr/local/lib/libvma.so lldiag-0.15/mcast
mcast: route/tc.c:973: rtnl_tc_register: Assertion `0' failed.

VMA_RX_POLL=-1 VMA_SELECT_POLL=-1 with thread affinity

What steps will reproduce the problem?
1. I've three TCP sessions, each one have own receiving thread (non-blocking)
2. Each receiving thread have affinity set to the same CPU (i.e. all have 
cpumask = 3 for example)
3. VMA_RX_POLL=-1 VMA_SELECT_POLL=-1
4. Application is on SCHED_FIFO

What is the expected output? What do you see instead?

Seems like everything hangs. If I leave only VMA_RX_POLL=-1 then it might 
occasionally (very rarely) hang as well.

Is it possible to selectively apply different VMA_RX/SELECT_POLL to UDP and TCP?

What version of the product are you using? On what operating system?

VMA 6.6.4 OFED 2.2 RHEL 6.5

Original issue reported on code.google.com by [email protected] on 8 Jul 2014 at 1:46

pimreg interface with VMA_TRACELEVEL=debug (or higher) causes segmentation fault

My environment:

  • Ubuntu 14.04
  • linux kernel 4.2
  • OFED version: MLNX_OFED_LINUX-3.2-1.0.1.1
  • VMA version: 7.0.14-0 (from OFED package)

pimd daemon (https://github.com/troglobit/pimd) creates pimreg interface.
When it's exists in the system VMA executed with VMA_TRACELEVEL >= debug crashes with segmentation fault.

Example with usage of libvma/tests/functionality/getsockname_test.c

Without VMA

# ./getsockname_test
Listening on port 47129
^C
#

With VMA, trace level default

# LD_PRELOAD=libvma.so ./getsockname_test
VMA INFO: ---------------------------------------------------------------------------
VMA INFO: VMA_VERSION: 7.0.14-0 Release built on Jan 28 2016 20:41:00
VMA INFO: Cmd Line: ./getsockname_test
VMA INFO: OFED Version: MLNX_OFED_LINUX-3.2-1.0.1.1:
VMA INFO: Log Level INFO
[VMA_TRACELEVEL]
VMA INFO: ---------------------------------------------------------------------------
Listening on port 58619
^C
#

With VMA, trace level debug

# LD_PRELOAD=libvma.so VMA_TRACELEVEL=debug ./getsockname_test
Pid: 24364 Tid: 24364 VMA INFO:
---------------------------------------------------------------------------
Pid: 24364 Tid: 24364 VMA INFO: VMA_VERSION: 7.0.14-0 Release built
on Jan 28 2016 20:41:00
Pid: 24364 Tid: 24364 VMA INFO: Cmd Line: ./getsockname_test
Pid: 24364 Tid: 24364 VMA DEBUG: Current Time: Sat Feb 20 18:11:09 2016
Pid: 24364 Tid: 24364 VMA DEBUG: Pid: 24364
Pid: 24364 Tid: 24364 VMA INFO: OFED Version: MLNX_OFED_LINUX-3.2-1.0.1.1:
Pid: 24364 Tid: 24364 VMA DEBUG: System: 4.2.0-27-lowlatency
Pid: 24364 Tid: 24364 VMA DEBUG: Architecture: x86_64
Pid: 24364 Tid: 24364 VMA DEBUG: Node: srv1
Pid: 24364 Tid: 24364 VMA DEBUG:
---------------------------------------------------------------------------
Pid: 24364 Tid: 24364 VMA INFO: Log Level DEBUG
[VMA_TRACELEVEL]
Pid: 24364 Tid: 24364 VMA INFO: Log Details 2
[VMA_LOG_DETAILS]
Pid: 24364 Tid: 24364 VMA DETAILS: Log Colors
Enabled [VMA_LOG_COLORS]
Pid: 24364 Tid: 24364 VMA DETAILS: Log File
[VMA_LOG_FILE]
Pid: 24364 Tid: 24364 VMA DETAILS: Stats File
[VMA_STATS_FILE]
Pid: 24364 Tid: 24364 VMA DETAILS: Stats shared memory directory
/tmp/ [VMA_STATS_SHMEM_DIR]
Pid: 24364 Tid: 24364 VMA DETAILS: Stats FD Num (max) 100
[VMA_STATS_FD_NUM]
Pid: 24364 Tid: 24364 VMA DETAILS: Conf File
/etc/libvma.conf [VMA_CONFIG_FILE]
Pid: 24364 Tid: 24364 VMA DETAILS: Application ID
VMA_DEFAULT_APPLICATION_ID [VMA_APPLICATION_ID]
Pid: 24364 Tid: 24364 VMA DETAILS: Polling CPU idle usage
Disabled [VMA_CPU_USAGE_STATS]
Pid: 24364 Tid: 24364 VMA DETAILS: SigIntr Ctrl-C Handle
Disabled [VMA_HANDLE_SIGINTR]
Pid: 24364 Tid: 24364 VMA DETAILS: SegFault Backtrace
Disabled [VMA_HANDLE_SIGSEGV]
Pid: 24364 Tid: 24364 VMA DETAILS: Ring allocation logic TX 0
(Ring per interface) [VMA_RING_ALLOCATION_LOGIC_TX]
Pid: 24364 Tid: 24364 VMA DETAILS: Ring allocation logic RX 0
(Ring per interface) [VMA_RING_ALLOCATION_LOGIC_RX]
Pid: 24364 Tid: 24364 VMA DETAILS: Ring migration ratio TX 100
[VMA_RING_MIGRATION_RATIO_TX]
Pid: 24364 Tid: 24364 VMA DETAILS: Ring migration ratio RX 100
[VMA_RING_MIGRATION_RATIO_RX]
Pid: 24364 Tid: 24364 VMA DETAILS: Ring limit per interface 0
(no limit) [VMA_RING_LIMIT_PER_INTERFACE]
Pid: 24364 Tid: 24364 VMA DETAILS: TCP max syn rate 0
(no limit) [VMA_TCP_MAX_SYN_RATE]
Pid: 24364 Tid: 24364 VMA DETAILS: Tx Mem Segs TCP
1000000 [VMA_TX_SEGS_TCP]
Pid: 24364 Tid: 24364 VMA DETAILS: Tx Mem Bufs
200000 [VMA_TX_BUFS]
Pid: 24364 Tid: 24364 VMA DETAILS: Tx QP WRE
3000 [VMA_TX_WRE]
Pid: 24364 Tid: 24364 VMA DETAILS: Tx Max QP INLINE 220
[VMA_TX_MAX_INLINE]
Pid: 24364 Tid: 24364 VMA DETAILS: Tx MC Loopback
Enabled [VMA_TX_MC_LOOPBACK]
Pid: 24364 Tid: 24364 VMA DETAILS: Tx non-blocked eagains
Disabled [VMA_TX_NONBLOCKED_EAGAINS]
Pid: 24364 Tid: 24364 VMA DETAILS: Tx Prefetch Bytes 256
[VMA_TX_PREFETCH_BYTES]
Pid: 24364 Tid: 24364 VMA DETAILS: Rx Mem Bufs
200000 [VMA_RX_BUFS]
Pid: 24364 Tid: 24364 VMA DETAILS: Rx QP WRE
16000 [VMA_RX_WRE]
Pid: 24364 Tid: 24364 VMA DETAILS: Rx QP WRE BATCHING 64
[VMA_RX_WRE_BATCHING]
Pid: 24364 Tid: 24364 VMA DETAILS: Rx Byte Min Limit
65536 [VMA_RX_BYTES_MIN]
Pid: 24364 Tid: 24364 VMA DETAILS: Rx Poll Loops
100000 [VMA_RX_POLL]
Pid: 24364 Tid: 24364 VMA DETAILS: Rx Poll Init Loops 0
[VMA_RX_POLL_INIT]
Pid: 24364 Tid: 24364 VMA DETAILS: Rx UDP Poll OS Ratio 100
[VMA_RX_UDP_POLL_OS_RATIO]
Pid: 24364 Tid: 24364 VMA DETAILS: Rx UDP HW TS Conversion 3
[VMA_RX_UDP_HW_TS_CONVERSION]
Pid: 24364 Tid: 24364 VMA DETAILS: Rx Poll Yield
Disabled [VMA_RX_POLL_YIELD]
Pid: 24364 Tid: 24364 VMA DETAILS: Rx Prefetch Bytes 256
[VMA_RX_PREFETCH_BYTES]
Pid: 24364 Tid: 24364 VMA DETAILS: Rx Prefetch Bytes Before Poll 0
[VMA_RX_PREFETCH_BYTES_BEFORE_POLL]
Pid: 24364 Tid: 24364 VMA DETAILS: Rx CQ Drain Rate
Disabled [VMA_RX_CQ_DRAIN_RATE_NSEC]
Pid: 24364 Tid: 24364 VMA DETAILS: GRO max streams 32
[VMA_GRO_STREAMS_MAX]
Pid: 24364 Tid: 24364 VMA DETAILS: TCP 3T rules
Disabled [VMA_TCP_3T_RULES]
Pid: 24364 Tid: 24364 VMA DETAILS: ETH MC L2 only rules
Disabled [VMA_ETH_MC_L2_ONLY_RULES]
Pid: 24364 Tid: 24364 VMA DETAILS: Select Poll (usec)
100000 [VMA_SELECT_POLL]
Pid: 24364 Tid: 24364 VMA DETAILS: Select Poll OS Force
Disabled [VMA_SELECT_POLL_OS_FORCE]
Pid: 24364 Tid: 24364 VMA DETAILS: Select Poll OS Ratio 10
[VMA_SELECT_POLL_OS_RATIO]
Pid: 24364 Tid: 24364 VMA DETAILS: Select Skip OS 4
[VMA_SELECT_SKIP_OS]
Pid: 24364 Tid: 24364 VMA DETAILS: CQ Drain Interval (msec) 10
[VMA_PROGRESS_ENGINE_INTERVAL]
Pid: 24364 Tid: 24364 VMA DETAILS: CQ Drain WCE (max)
10000 [VMA_PROGRESS_ENGINE_WCE_MAX]
Pid: 24364 Tid: 24364 VMA DETAILS: CQ Interrupts Moderation
Enabled [VMA_CQ_MODERATION_ENABLE]
Pid: 24364 Tid: 24364 VMA DETAILS: CQ Moderation Count 48
[VMA_CQ_MODERATION_COUNT]
Pid: 24364 Tid: 24364 VMA DETAILS: CQ Moderation Period (usec) 50
[VMA_CQ_MODERATION_PERIOD_USEC]
Pid: 24364 Tid: 24364 VMA DETAILS: CQ AIM Max Count 560
[VMA_CQ_AIM_MAX_COUNT]
Pid: 24364 Tid: 24364 VMA DETAILS: CQ AIM Max Period (usec) 250
[VMA_CQ_AIM_MAX_PERIOD_USEC]
Pid: 24364 Tid: 24364 VMA DETAILS: CQ AIM Interval (msec) 250
[VMA_CQ_AIM_INTERVAL_MSEC]
Pid: 24364 Tid: 24364 VMA DETAILS: CQ AIM Interrupts Rate (per sec)
5000 [VMA_CQ_AIM_INTERRUPTS_RATE_PER_SEC]
Pid: 24364 Tid: 24364 VMA DETAILS: CQ Poll Batch (max) 16
[VMA_CQ_POLL_BATCH_MAX]
Pid: 24364 Tid: 24364 VMA DETAILS: CQ Keeps QP Full
Enabled [VMA_CQ_KEEP_QP_FULL]
Pid: 24364 Tid: 24364 VMA DETAILS: QP Compensation Level 256
[VMA_QP_COMPENSATION_LEVEL]
Pid: 24364 Tid: 24364 VMA DETAILS: Offloaded Sockets
Enabled [VMA_OFFLOADED_SOCKETS]
Pid: 24364 Tid: 24364 VMA DETAILS: Timer Resolution (msec) 10
[VMA_TIMER_RESOLUTION_MSEC]
Pid: 24364 Tid: 24364 VMA DETAILS: TCP Timer Resolution (msec) 100
[VMA_TCP_TIMER_RESOLUTION_MSEC]
Pid: 24364 Tid: 24364 VMA DETAILS: TCP control thread 0
(Disabled) [VMA_TCP_CTL_THREAD]
Pid: 24364 Tid: 24364 VMA DETAILS: TCP timestamp option 0
[VMA_TCP_TIMESTAMP_OPTION]
Pid: 24364 Tid: 24364 VMA DETAILS: Exception handling mode
-1(just log debug message) [VMA_EXCEPTION_HANDLING]
Pid: 24364 Tid: 24364 VMA DETAILS: Avoid sys-calls on tcp fd
Disabled [VMA_AVOID_SYS_CALLS_ON_TCP_FD]
Pid: 24364 Tid: 24364 VMA DETAILS: Delay after join (msec) 0
[VMA_WAIT_AFTER_JOIN_MSEC]
Pid: 24364 Tid: 24364 VMA DETAILS: Internal Thread Affinity -1
[VMA_INTERNAL_THREAD_AFFINITY]
Pid: 24364 Tid: 24364 VMA DETAILS: Internal Thread Cpuset
[VMA_INTERNAL_THREAD_CPUSET]
Pid: 24364 Tid: 24364 VMA DETAILS: Internal Thread Arm CQ
Disabled [VMA_INTERNAL_THREAD_ARM_CQ]
Pid: 24364 Tid: 24364 VMA DETAILS: Thread mode
Multi spin lock [VMA_THREAD_MODE]
Pid: 24364 Tid: 24364 VMA DETAILS: Buffer batching mode 1
(Batch and reclaim buffers) [VMA_BUFFER_BATCHING_MODE]
Pid: 24364 Tid: 24364 VMA DETAILS: Mem Allocate type 1
(Contig Pages) [VMA_MEM_ALLOC_TYPE]
Pid: 24364 Tid: 24364 VMA DETAILS: Num of UC ARPs 3
[VMA_NEIGH_UC_ARP_QUATA]
Pid: 24364 Tid: 24364 VMA DETAILS: UC ARP delay (msec)
10000 [VMA_NEIGH_UC_ARP_DELAY_MSEC]
Pid: 24364 Tid: 24364 VMA DETAILS: Num of neigh restart retries 1
[VMA_NEIGH_NUM_ERR_RETRIES]
Pid: 24364 Tid: 24364 VMA DETAILS: IPOIB support
Enabled [VMA_IPOIB]
Pid: 24364 Tid: 24364 VMA DETAILS: BF (Blue Flame)
Enabled [VMA_BF]
Pid: 24364 Tid: 24364 VMA DETAILS: fork() support
Enabled [VMA_FORK]
Pid: 24364 Tid: 24364 VMA DETAILS: close on dup2()
Enabled [VMA_CLOSE_ON_DUP2]
Pid: 24364 Tid: 24364 VMA DETAILS: MTU 0
(follow actual MTU) [VMA_MTU]
Pid: 24364 Tid: 24364 VMA DETAILS: MSS 0
(follow VMA_MTU) [VMA_MSS]
Pid: 24364 Tid: 24364 VMA DETAILS: TCP CC Algorithm 0
(LWIP) [VMA_TCP_CC_ALGO]
Pid: 24364 Tid: 24364 VMA DETAILS: Suppress IGMP ver. warning
Disabled [VMA_SUPPRESS_IGMP_WARNING]
Pid: 24364 Tid: 24364 VMA INFO:
---------------------------------------------------------------------------
Pid: 24364 Tid: 24364 VMA WARNING:
*************************************************************
Pid: 24364 Tid: 24364 VMA WARNING: * VMA is currently configured with
high log level *
Pid: 24364 Tid: 24364 VMA WARNING: * Application performance will
decrease in this log level! *
Pid: 24364 Tid: 24364 VMA WARNING: * This log level is recommended
for debugging purposes only *
Pid: 24364 Tid: 24364 VMA WARNING:
*************************************************************
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/sys/module/mlx4_core/parameters/log_num_mgm_entry_size,
flags=0, mode=0x2) = 3
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: close(fd=3)
Pid: 24364 Tid: 24364 VMA DEBUG: sock_redirect_main()
Pid: 24364 Tid: 24364 VMA DEBUG: ibv_fork_init() succeeded, fork()
may be used safely!!
Pid: 24364 Tid: 24364 VMA DEBUG: wakeup_pipe[epfd=0]:48:wakeup_pipe()
created wakeup pipe [RD=3, WR=4]
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/tmp//vmastat.24364, flags=0x42, mode=0x1f6) = 6
Pid: 24364 Tid: 24364 VMA DEBUG: vma_shmem_stats_open: file
'/tmp//vmastat.24364' fd 6 shared memory at 0x7fd2e7610000 with 100
max blocks
Pid: 24364 Tid: 24364 VMA DEBUG: evh:59:register_timer_event() timer
handler '0x106b9d0' registered PERIODIC timer for 10 msec (user data:
0)
Pid: 24364 Tid: 24364 VMA DEBUG: evh:314:start_thread() VMA Internal
thread affinity not set.
Pid: 24364 Tid: 24364 VMA DEBUG: evh:335:start_thread() Started event
handler thread
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: do_wakeup()
Pid: 24364 Tid: 24369 VMA DEBUG: evh:251:event_handler_thread()
Entering internal thread, id = 140543770318592
Pid: 24364 Tid: 24364 VMA DEBUG: nl_wrapper:122:netlink_wrapper()
---> netlink_route_listener CTOR
Pid: 24364 Tid: 24364 VMA DEBUG: nl_wrapper:126:netlink_wrapper()
<--- netlink_route_listener CTOR
Pid: 24364 Tid: 24369 VMA DEBUG: ENTER: remove_wakeup_fd()
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/sys/class/misc/rdma_cm/abi_version, flags=0,
mode=0x106bdb0) = 7
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: close(fd=7)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/sys/class/infiniband_verbs/abi_version, flags=0,
mode=0x106bdb0) = 7
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: close(fd=7)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/sys/class/infiniband_verbs/uverbs0/ibdev, flags=0,
mode=0x1073e70) = 8
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: close(fd=8)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/sys/class/infiniband_verbs/uverbs0/abi_version, flags=0,
mode=0x1073e70) = 8
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: close(fd=8)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/sys/class/infiniband_verbs/uverbs0/device/vendor, flags=0,
mode=0x106d120) = 7
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: close(fd=7)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/sys/class/infiniband_verbs/uverbs0/device/device, flags=0,
mode=0x106d190) = 7
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: close(fd=7)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/sys/class/infiniband/mlx4_0/node_type, flags=0,
mode=0x106d1d0) = 7
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: close(fd=7)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/sys/class/infiniband/mlx4_0/node_guid, flags=0,
mode=0x106d1d0) = 7
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: close(fd=7)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/dev/infiniband/rdma_cm, flags=0x80002, mode=0x106d8d0) = 7
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: close(fd=7)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/sys/class/infiniband/mlx4_0/node_guid, flags=0,
mode=0x1073e40) = 7
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: close(fd=7)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/dev/infiniband/uverbs0, flags=0x2, mode=0x106d1d0) = 7
Pid: 24364 Tid: 24364 VMA DEBUG:
ib_ctx_time_converter::get_devices_convertor_status : Checking RX UDP
HW time stamp status for all devices [1], ibv_context_list = 0x1072af0
Pid: 24364 Tid: 24364 VMA DEBUG:
ib_ctx_collection[0x106bc90]:77:map_ib_devices() TS converter status
was set to 3
Pid: 24364 Tid: 24364 VMA DEBUG:
ib_ctx_collection[0x106bc90]:79:map_ib_devices() Mapping 1 ibv devices
Pid: 24364 Tid: 24364 VMA DEBUG: evh:59:register_timer_event() timer
handler '0x1072d58' registered ONE SHOT timer for 1000 msec (user
data: 0)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: do_wakeup()
Pid: 24364 Tid: 24364 VMA DEBUG: evh:59:register_timer_event() timer
handler '0x1072d58' registered PERIODIC timer for 10000 msec (user
data: 0)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: do_wakeup()
Pid: 24364 Tid: 24369 VMA DEBUG: ENTER: remove_wakeup_fd()
Pid: 24364 Tid: 24364 VMA DEBUG:
ib_ctx_handler[0x1072b10]:67:ib_ctx_handler() ibv device 'mlx4_0'
[0x106d3b0] has 2 ports. Vendor Part Id: 4099, FW Ver: 2.36.5000,
max_qp_wr=16351, hca_core_clock (per sec)=258000000
Pid: 24364 Tid: 24364 VMA DEBUG:
ib_ctx_handler[0x1072b10]:136:set_dev_configuration() Setting
configuration for the MLX card mlx4_0
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: do_wakeup()
Pid: 24364 Tid: 24369 VMA DEBUG:
evh:448:priv_prepare_ibverbs_async_event_queue()
Pid: 24364 Tid: 24369 VMA DEBUG: utils:241:set_fd_block_mode() fd[8]:
setting to non-blocking mode (0)
Pid: 24364 Tid: 24369 VMA DEBUG:
evh:468:priv_prepare_ibverbs_async_event_queue() Emptied 0 Events
Pid: 24364 Tid: 24369 VMA DEBUG:
evh:488:priv_register_ibverbs_events() 8 added to event_handler_map_t!
Pid: 24364 Tid: 24369 VMA DEBUG: ENTER: remove_wakeup_fd()
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER:
open(file=/dev/infiniband/rdma_cm, flags=0x80002, mode=0x1072af0) = 9
Pid: 24364 Tid: 24364 VMA DEBUG: ntm:51:neigh_table_mgr() Creation of
neigh_cma_event_channel on fd=9
Pid: 24364 Tid: 24364 VMA DEBUG: evh:59:register_timer_event() timer
handler '0x1072e98' registered PERIODIC timer for 100000 msec (user
data: 0)
Pid: 24364 Tid: 24364 VMA DEBUG: ENTER: do_wakeup()
Pid: 24364 Tid: 24369 VMA DEBUG: ENTER: remove_wakeup_fd()
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:143:map_net_devices() Checking if can offload on
interface 'lo' (addr=1.0.0.0, flags=10049)
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:150:map_net_devices() Blocking offload: Interface
('lo') is not of type AF_INET
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:143:map_net_devices() Checking if can offload on
interface 'eth2' (addr=2.0.0.0, flags=1002)
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:150:map_net_devices() Blocking offload: Interface
('eth2') is not of type AF_INET
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:143:map_net_devices() Checking if can offload on
interface 'eth3' (addr=3.0.0.0, flags=1002)
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:150:map_net_devices() Blocking offload: Interface
('eth3') is not of type AF_INET
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:143:map_net_devices() Checking if can offload on
interface 'eth0' (addr=4.0.0.0, flags=11043)
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:150:map_net_devices() Blocking offload: Interface
('eth0') is not of type AF_INET
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:143:map_net_devices() Checking if can offload on
interface 'eth1' (addr=5.0.0.0, flags=1002)
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:150:map_net_devices() Blocking offload: Interface
('eth1') is not of type AF_INET
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:143:map_net_devices() Checking if can offload on
interface 'eth6' (addr=6.0.0.0, flags=1003)
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:150:map_net_devices() Blocking offload: Interface
('eth6') is not of type AF_INET
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:143:map_net_devices() Checking if can offload on
interface 'eth8' (addr=7.0.0.0, flags=11043)
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:150:map_net_devices() Blocking offload: Interface
('eth8') is not of type AF_INET
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:143:map_net_devices() Checking if can offload on
interface 'eth8.302' (addr=8.0.0.0, flags=11043)
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:150:map_net_devices() Blocking offload: Interface
('eth8.302') is not of type AF_INET
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:143:map_net_devices() Checking if can offload on
interface 'eth8.388' (addr=9.0.0.0, flags=11043)
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:150:map_net_devices() Blocking offload: Interface
('eth8.388') is not of type AF_INET
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:143:map_net_devices() Checking if can offload on
interface 'eth8.389' (addr=10.0.0.0, flags=11043)
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:150:map_net_devices() Blocking offload: Interface
('eth8.389') is not of type AF_INET
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:143:map_net_devices() Checking if can offload on
interface 'docker0' (addr=11.0.0.0, flags=1003)
Pid: 24364 Tid: 24364 VMA DEBUG:
ndtm[0x1072f70]:150:map_net_devices() Blocking offload: Interface
('docker0') is not of type AF_INET
Segmentation fault (core dumped)

Steps to reproduce:

  • install pimd and start it, so pimreg interface is bring up
  • run any code working with sockets as LD_PRELOAD=libvma.so VMA_TRACELVEL=debug ./cmd

pimreg interface:

pimreg    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          UP RUNNING NOARP  MTU:1472  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

More details in dev list - https://groups.google.com/forum/#!topic/libvma-dev/xU5F_Cyjz9E

RDMAV_HUGEPAGES_SAFE set after ibv_fork_init()

Commit 0f4c81655332f94313020e667158bc56b983a4b4 "issue: 365538 Loading VMA with 
Redis server give a seg-fault" has moved setting RDMAV_HUGEPAGES_SAFE=1 to 
do_global_ctors() which occurs after ibv_fork_init() has run in main_init().  
This causes ibv_reg_mr() to fail when running with Huge Pages.

# LD_PRELOAD=/usr/lib64/libvma.so.6.5.9 ./timestamping eth4 SO_TIMESTAMPNS 
SOF_TIMESTAMPING_RX_SOFTWARE SOF_TIMESTAMPING_SOFTWARE
 VMA INFO   : ---------------------------------------------------------------------------
 VMA INFO   : VMA_VERSION: 6.5.9-0 Development Snapshot built on Jan 29 2014 14:06:15
 VMA INFO   : Cmd Line: ./timestamping eth4 SO_TIMESTAMPNS SOF_TIMESTAMPING_RX_SOFTWARE SOF_TIMESTAMPING_SOFTWARE
 VMA INFO   : Current Time: Wed Jan 29 14:06:36 2014
 VMA INFO   : Pid: 29456
sh: ofed_info: command not found
 VMA INFO   : OFED Version: ๏ฟฝ VMA INFO   : Architecture: x86_64
 VMA INFO   : Node: berbox13
 VMA INFO   : ---------------------------------------------------------------------------
 VMA INFO   : Log Level                      3                          [VMA_TRACELEVEL]
 VMA INFO   : ---------------------------------------------------------------------------
calling ibv_fork_init()
Setting RDMAV_HUGEPAGES_SAFE
 VMA WARNING: ib_ctx_collection88:mem_reg_on_all_devices() Failure in mem_reg: addr=0x2aaaaac00000, length=361600063, mr_pos=0, mr_array[mr_pos]=0, dev=0x700080, ibv_dev=mlx4_0
 VMA WARNING: bpool[0x702f40]:247:register_memory() Failed registering memory, This might happen due to low MTT entries. Please refer to README.txt for more info

Original issue reported on code.google.com by [email protected] on 29 Jan 2014 at 8:32

Please advise on optimal UDP/TCP traffic distribution

Dear Or,

Would be very grateful if you could advise on what'd be optional. I've two MLNX 
cards and four 10GB lines to the switch.

I need to receive a lot of multicast data combined to logical channels. Most of 
the data in a channel is incremental A multicast group and B MC group (there 
could be ~100-10000 msgs/sec).

Then I need to send short TCP packet or series of TCP packets (0.5-10 msgs/sec).

The question is - should I stream all the multicast data RX through one MLNX 
card and do TCP TX through another or it's better to consume A multicast group 
on one MLNX card and B multicast on another card?

Target latencies ~3-10usec.

Does it even matter to the hardware/firmware/software - the separation of 
traffic I'm talking about? Or any combination of routing would yield pretty 
much the same performance?

Thx
Denis

Original issue reported on code.google.com by [email protected] on 28 Apr 2014 at 8:31

Ceph with libvma crashed in both V6.9.1 and tag 7.0.5

Hi,

I tried to use libvma in my Ceph cluster recently. However, I met same crash in version 6.9.1(installed via RPM) and 7.0.5(installed from src with debug enabled). The core trace is pasted below. Cloud some one help to look at this issue? Thanks very much!

  (gdb) bt
#0  0x00007f4c566cf65b in raise () from /lib64/libpthread.so.0
#1  0x00000000009bd1c4 in ?? ()
#2  <signal handler called>
#3  0x00007f4c52c88d71 in ?? () from /usr/lib64/libmlx4-rdmav2.so
#4  0x00007f4c5536612f in ibv_create_cq () from /usr/lib64/libibverbs.so.1
#5  0x00007f4c5762ed08 in cq_mgr::cq_mgr (this=0x3819340, p_ring=0x15358000, p_ib_ctx_handler=0x373a200, cq_size=3000, p_comp_event_channel=0x94639f0, is_rx=false) at dev/cq_mgr.cpp:69
#6  0x00007f4c57633090 in qp_mgr::configure (this=0x37fb000, p_rx_comp_event_channel=0x94639e0) at dev/qp_mgr.cpp:104
#7  0x00007f4c5763cbae in qp_mgr_eth::qp_mgr_eth (this=0x37fb000, p_ring=0x15358000, p_context=0x373a200, port_num=1 '\001', p_rx_comp_event_channel=0x94639e0, tx_num_wr=3000,
    vlan=101) at ../../src/vma/dev/qp_mgr.h:162
#8  0x00007f4c576365af in ring_eth::create_qp_mgr (this=0x15358000, key=..., p_rx_comp_event_channel=0x94639e0) at dev/ring.cpp:70
#9  0x00007f4c57637790 in ring::create_resources (this=0x15358000, p_ring_info=0x7f4c1d2ded60, active=0) at dev/ring.cpp:209
#10 0x00007f4c57652b5c in ring_eth::ring_eth (this=0x15358000, local_if=168758798, p_ring_info=0x7f4c1d2ded60, count=1, active=0, vlan=101) at ../../src/vma/dev/ring.h:382
#11 0x00007f4c57651abd in net_device_val_eth::create_ring (this=0x37a85a0) at dev/net_device_val.cpp:500
#12 0x00007f4c57650168 in net_device_val::reserve_ring (this=0x37a85a0, key=0) at dev/net_device_val.cpp:267
#13 0x00007f4c576ac9b5 in dst_entry::resolve_ring (this=0x36fad00) at proto/dst_entry.cpp:242
#14 0x00007f4c576ad896 in dst_entry::prepare_to_send (this=0x36fad00, skip_rules=false) at proto/dst_entry.cpp:482
#15 0x00007f4c576d70b9 in sockinfo_tcp::connect (this=0x6283f00, __to=0x6310310, __tolen=16) at sock/sockinfo_tcp.cpp:1631
#16 0x00007f4c576efb0c in connect (__fd=66, __to=0x6310310, __tolen=16) at sock/sock-redirect.cpp:569
#17 0x0000000000b4f037 in Pipe::connect() ()
#18 0x0000000000b53743 in Pipe::writer() ()
#19 0x0000000000b5f16d in Pipe::Writer::entry() ()
#20 0x00007f4c566c7a51 in start_thread () from /lib64/libpthread.so.0
#21 0x00007f4c556579ad in clone () from /lib64/libc.so.6
(gdb) f 5
#5  0x00007f4c5762ed08 in cq_mgr::cq_mgr (this=0x3819340, p_ring=0x15358000, p_ib_ctx_handler=0x373a200, cq_size=3000, p_comp_event_channel=0x94639f0, is_rx=false) at dev/cq_mgr.cpp:69
69              m_p_ibv_cq = ibv_create_cq(m_p_ib_ctx_handler->get_ibv_context(), cq_size, (void*)this, m_comp_event_channel, 0);
(gdb) p *this
$3 = {m_p_ring = 0x15358000, m_p_ib_ctx_handler = 0x373a200, m_b_is_rx = false, m_b_is_rx_csum_on = false, m_comp_event_channel = 0x94639f0, m_p_ibv_cq = 0x0,
  m_b_notification_armed = false, m_b_was_drained = false, m_n_wce_counter = 0, m_qp_rec = {qp = 0x0, debth = 0}, m_p_next_rx_desc_poll = 0x0, m_rx_queue = {m_list = {head = {
        next = 0x3819388, prev = 0x3819388}, obj_ptr = 0x0}, m_size = 0}, m_rx_pool = {m_list = {head = {next = 0x38193a8, prev = 0x38193a8}, obj_ptr = 0x0}, m_size = 0},
  m_n_out_of_free_bufs_warning = 0, m_p_cq_stat = 0x0, m_cq_stat_static = {n_rx_pkt_drop = 0, n_rx_sw_queue_len = 0, n_rx_drained_at_once_max = 0, n_buffer_pool_len = 0,
    buffer_miss_rate = 0}, m_cq_id = 5, m_n_cq_poll_sn = 0, m_transport_type = VMA_TRANSPORT_ETH, m_sz_transport_header = 0, m_buffer_miss_count = 0, m_buffer_total_count = 0,
  m_buffer_prev_id = 0, static m_n_cq_id_counter = {counter = 6}, static m_n_global_sn = 0}
(gdb) p m_comp_event_channel
$4 = (ibv_comp_channel *) 0x94639f0
(gdb) p *m_comp_event_channel
$5 = {context = 0x3828218, fd = 69, refcnt = 0}
(gdb) p *p_ib_ctx_handler
$6 = {<event_handler_ibverbs> = {_vptr.event_handler_ibverbs = 0x7f4c5797ee90}, m_p_ibv_context = 0x3828218, m_ibv_port_attr = {state = IBV_PORT_ACTIVE, max_mtu = IBV_MTU_4096,
    active_mtu = IBV_MTU_1024, gid_tbl_len = 128, port_cap_flags = 201392128, max_msg_sz = 1073741824, bad_pkey_cntr = 0, qkey_viol_cntr = 0, pkey_tbl_len = 1, lid = 0, sm_lid = 0,
    lmc = 0 '\000', max_vl_num = 2 '\002', sm_sl = 0 '\000', subnet_timeout = 0 '\000', init_type_reply = 0 '\000', active_width = 2 '\002', active_speed = 4 '\004',
    phys_state = 5 '\005', link_layer = 2 '\002', reserved = 0 '\000'}, m_p_ibv_device = 0x37d8300, m_ibv_device_attr = {fw_ver = "2.34.5000", '\000' <repeats 54 times>,
    node_guid = 6942324114412346852, sys_image_guid = 6942324114412346852, max_mr_size = 18446744073709551615, page_size_cap = 4294966784, vendor_id = 713, vendor_part_id = 4103,
    hw_ver = 0, max_qp = 392632, max_qp_wr = 16351, reserved = 6069350, max_sge = 32, max_sge_rd = 0, max_cq = 65408, max_cqe = 4194303, max_mr = 524032, max_pd = 32764,
    max_qp_rd_atom = 16, max_ee_rd_atom = 0, max_res_rd_atom = 6282112, max_qp_init_rd_atom = 128, max_ee_init_rd_atom = 0, exp_atomic_cap = IBV_EXP_ATOMIC_HCA, max_ee = 0,
    max_rdd = 0, max_mw = 0, max_raw_ipv6_qp = 0, max_raw_ethy_qp = 0, max_mcast_grp = 131072, max_mcast_qp_attach = 244, max_total_mcast_qp_attach = 31981568, max_ah = 2147483647,
    max_fmr = 0, max_map_per_fmr = 8191, max_srq = 65472, max_srq_wr = 16383, max_srq_sge = 31, max_pkeys = 128, local_ca_ack_delay = 15 '\017', phys_port_cnt = 2 '\002',
    comp_mask = 9, calc_cap = {data_types = 7, data_sizes = 1, int_ops = 29, uint_ops = 29, fp_ops = 29}, timestamp_mask = 0, hca_core_clock = 0,
    exp_device_cap_flags = 8152104758268435558, max_dc_req_rd_atom = 0, max_dc_res_rd_atom = 0, inline_recv_sz = 0, max_rss_tbl_sz = 0, ext_atom = {log_atomic_arg_sizes = 0,
      max_fa_bit_boundary = 0, log_max_atomic_inline = 0}, umr_caps = {max_klm_list_size = 0, max_send_wqe_inline_klms = 0, max_umr_recursion_depth = 0, max_umr_stride_dimension = 0},
    odp_caps = {general_odp_caps = 0, per_transport_caps = {rc_odp_caps = 0, uc_odp_caps = 0, ud_odp_caps = 0, dc_odp_caps = 0, xrc_odp_caps = 0, raw_eth_odp_caps = 0}}, max_dct = 0,
    max_ctx_res_domain = 0}, m_p_ibv_pd = 0x36b6100, m_channel = 0, m_removed = false, m_conf_attr_rx_num_wre = 16000, m_conf_attr_tx_num_post_send_notify = 64,
  m_conf_attr_tx_max_inline = 220, m_conf_attr_tx_num_wre = 3000}
(gdb) p *p_ring
$7 = {<mem_buf_desc_owner> = {_vptr.mem_buf_desc_owner = 0x7f4c5797ea70}, m_p_ring_stat = 0x0, m_local_if = 168758798, m_transport_type = VMA_TRANSPORT_ETH, m_n_num_resources = 1,
  m_ring_resources_map = std::tr1::unordered_map with 0 elements,
  m_ring_active_resource = {<std::tr1::__detail::_Hashtable_iterator_base<std::pair<ring_resource_definition const, ring_resources_info_t>, false>> = {_M_cur_node = 0x1000,
      _M_cur_bucket = 0x1523d758}, <No data fields>}, m_rx_channel_fd_to_ring_resources_map = std::tr1::unordered_map with 0 elements,
  m_l2_mc_ip_attach_map = std::tr1::unordered_map with 0 elements, m_tcp_dst_port_attach_map = std::tr1::unordered_map with 0 elements, m_p_tx_comp_event_channel = 0x94639f0,
  m_flow_tcp_map = {_vptr.hash_map = 0x7f4c5797eb10, m_hash_table = {0x0 <repeats 4096 times>}, m_last = 0x0}, m_flow_udp_mc_map = {_vptr.hash_map = 0x7f4c5797eaf0, m_hash_table = {
      0x0 <repeats 4096 times>}, m_last = 0x0}, m_flow_udp_uc_map = {_vptr.hash_map = 0x7f4c5797ead0, m_hash_table = {0x0 <repeats 4096 times>}, m_last = 0x0},
  m_lock_ring_rx = {<lock_mutex> = {<lock_base> = {_vptr.lock_base = 0x7f4c5797eb70, m_lock_name = 0x7f4c577198ab "ring:lock_rx"}, m_lock = {__data = {__lock = 0, __count = 0,
          __owner = 0, __nusers = 0, __kind = 1, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 16 times>, "\001", '\000' <repeats 22 times>,
        __align = 0}}, <No data fields>}, m_lock_ring_tx = {<lock_mutex> = {<lock_base> = {_vptr.lock_base = 0x7f4c5797eb70, m_lock_name = 0x7f4c577198b8 "ring:lock_tx"}, m_lock = {
        __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 1, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
        __size = '\000' <repeats 16 times>, "\001", '\000' <repeats 22 times>, __align = 0}}, <No data fields>}, m_lock_ring_tx_buf_wait = {<lock_base> = {
      _vptr.lock_base = 0x7f4c5797ebb0, m_lock_name = 0x7f4c577198c5 "ring:lock_tx_buf_wait"}, m_lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0,
        __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}, m_p_n_rx_channel_fds = 0x11410f60, m_tx_pool = {m_list = {head = {
        next = 0x153701d8, prev = 0x153701d8}, obj_ptr = 0x0}, m_size = 0}, m_tx_num_bufs = 0, m_tx_num_wr = 3000, m_tx_num_wr_free = 3000,
  m_b_qp_tx_first_flushed_completion_handled = false, m_missing_buf_ref_count = 0, m_cq_moderation_info = {period = 0, count = 0, packets = 0, bytes = 0, prev_packets = 0,
    prev_bytes = 0, missed_rounds = 0}, m_tx_lkey = 0, m_partition = 101, m_gro_mgr = {_vptr.gro_mgr = 0x7f4c5797e970, m_n_flow_max = 32, m_n_buf_max = 32, m_n_flow_count = 0,
    m_p_rfs_arr = 0x36f2500}, m_ring_stat_static = {n_rx_pkt_count = 0, n_rx_byte_count = 0, n_rx_interrupt_requests = 0, n_rx_interrupt_received = 0, n_rx_cq_moderation_count = 0,
    n_rx_cq_moderation_period = 0, n_tx_retransmits = 0}}

Support AF_PACKET(17)

What need is this feature going to satisfy?
1. open socket(type = AF_PACKET(17)) 
2.
3.

What is the expected output? What do you have currently? Any workaround?
Expected: VMA to offload the traffic. 
Receive and send all raw packet's via VMA offloaded interface


Please use labels and text to provide additional information.
See more info in http://man7.org/linux/man-pages/man7/packet.7.html


Original issue reported on code.google.com by [email protected] on 19 Aug 2014 at 8:54

802.3ad bonding mode issue

Greetings.
CentOS 6.7. ConnectX-3 EN. OFED 3.2-2.0.0.0
I am running sockperf tcp/ip ping-pong test.
Trying to use vma with vlan over 802.3ad bonded interfaces.
It works when server and client are connected directly with two cables (both are ConnectX-3 Pro)
It fails when server (vlan over bond)<-> router 802.3ad configured<-> internet <-> client. This works on kernel stack, hence net config is fine.

sockperf: Warmup stage (sending a few dummy messages)...
sockperf: Starting test...
sockperf: Test end (interrupted by timer)
sockperf: Test ended
sockperf: No messages were received from the server. Is the server down?

I have written the test ping-pong app much similar to sockperf. From its log it is clear that tcp connection is being established, but no message can pass to server.

here are the logs with VMA_TRACELEVEL=4

vmalog_failed_802.3ad_vlan_ping-pong.txt
vmalog_failed_802.3ad_vlan_sockperf.txt

Is this a bug or i'm doing something wrong?

Network is configured in /etc/sysconfig/network-scripts. Not manually

Turning off the 802.3ad (keep vlan over eth0) on the server makes it work

802.3ad bonding mode support

As of VMA 6.6.4, the only bonding supported is the Active/Passive mode, and only with fail_over_mac=1
Is 802.3ad bonding mode support planned? If not, is there any way for us to influence some how and add it to enhancements plan?

Test throughput on a dual-port 10Gbps card in "loopback" mode

Greetings.
Is there a way on Linux to test throughput on a dual-port 10Gbps ConnectX3-EN Pro card in "loopback" mode, that is, one port plugged directly into the other. With VMA enabled on each port of course?

We have several of these cards installed in servers that are deployed in the data-centre. But I never had an opportunity to get two servers for the test at once. I have one now and would like to preform such test, if possible

VMA crashes when TCP connection is closed by peer

I have experienced a crash when TCP connections are terminated by peer (a Windows box).
Whenever, client (a Window box) closes a TCP connection, the server (running with socket offload) generates the following vma errors and crashes after few mins:

VMA ERROR : vma_list_t.push_front() - buff is already a member in a list.

I am using:
firmware version 2.34.5000
MLNX_OFED version 3.0-2.0.1
VMA version 7.0.4

Besides, seems when in the socket offload mode, the TCP call accept() will not return even after shutdown() and closesocket() the server socket.

Jni

Is there a way to disable TCP delayed ACK in libvma

Hi,
I have experienced the situation that libvma delayed TCP ack by around 200ms.
I have switch the TCP CC Algorithm to CUBIC but still got the same delay.
I am wondering if there is a way to disable TCP delay?

Thanks

Running ping with libvma using dns name resolving does not work.

When I run the command ping with the libvma option with a hostname, result comes back with unknown hostname while the host is resolvable.

Running the ping command IP based, no problems.

Can libvma handle DNS resolution with HW offload or do you always have to use the OS redirect for this?

gdb core dumps when LD_PRELOAD set to libvma.so library

Hi,

I have written code to use libvma. To debug my code, I'm trying to use gdb. But gdb core dumps when libvma.so is LD_PRELOADED. See following logs for details.

If LD_PROLOAD is unset, then gdb works fine. How to run gdb when LD_PRELOAD is set to libvma? Why is it dumping core in gdb?

$ cat /etc/issue
**Ubuntu 14.04.3 LTS \n \l**

$ gdb --version
**GNU gdb (GDB) 7.10**
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".

$ export LD_PRELOAD=/usr/lib64/libvma.so
$ gdb ./client_vma
 VMA INFO   : ---------------------------------------------------------------------------
 VMA INFO   : VMA_VERSION: 7.0.7-0 Release built on 2015-09-08-13:24:18
 VMA INFO   : Cmd Line: gdb ./client_vma
 VMA INFO   : OFED Version: MLNX_OFED_LINUX-3.1-1.0.3:
 VMA INFO   : Log Level                      3                          [VMA_TRACELEVEL]
 VMA INFO   : ---------------------------------------------------------------------------
**Segmentation fault (core dumped)**

$ gdb -c ./core /usr/local/bin/gdb
GNU gdb (GDB) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/gdb...done.
[New LWP 129298]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `gdb ./client_vma'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fe0c2f8a8dd in getenv () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt**
#0  0x00007fe0c2f8a8dd in getenv () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fe0c2f80681 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00000000004ee458 in _initialize_charset () at charset.c:1050
#3  0x00000000006567fa in initialize_all_files () at init.c:205
#4  0x000000000061c225 in gdb_init (argv0=<optimized out>) at top.c:2011
#5  0x000000000054ed7d in captured_main (data=data@entry=0x7fffb2f0ac00) at main.c:863
#6  0x000000000054ba7d in catch_errors (func=func@entry=0x54eac0 <captured_main>, func_args=func_args@entry=0x7fffb2f0ac00, errstring=errstring@entry=0x7422a2 "",
    mask=mask@entry=RETURN_MASK_ALL) at exceptions.c:240
#7  0x000000000054f9ab in gdb_main (args=args@entry=0x7fffb2f0ac00) at main.c:1165
#8  0x0000000000407425 in main (argc=<optimized out>, argv=<optimized out>) at gdb.c:32**

vlogger: pass buffer as string in fprintf


The buf may contain special characters like '%' which may be interpreted
by fprintf.  As an example this can occur when the command run under
VMA has arguments that are escaped for example:

LD_PRELOAD=libvma.so /bin/echo 
"ts_keywords=type:tr_delay%20host:foo%20venue:isld%20source:nasdaq"

Always pass the buffer as a string.

Original issue reported on code.google.com by [email protected] on 3 Jan 2014 at 11:52

Attachments:

VMA ERROR when running on alias to VLAN interface

What steps will reproduce the problem?
1. bring up VLAN interface (e.g. eth0.10) with IP (e.g. 192.168.1.100)
2. bring up alias on previously created VLAN (e.g. eth0.10:2) with IP (e.g. 
192.168.1.200)
3. run application with VMA (e.g. LD_PRELOAD=libvma.so iperf -u -c 192.168.1.1)

> What is the expected output?

 VMA INFO   : ---------------------------------------------------------------------------
 VMA INFO   : VMA_VERSION: 6.7.2-0 Release built on 2014-08-21-15:28:25
 VMA INFO   : Cmd Line: iperf -u -c 192.168.1.1
 VMA INFO   : OFED Version: MLNX_OFED_LINUX-2.3-1.0.1:
 VMA INFO   : Log Level                      3                          [VMA_TRACELEVEL]
 VMA INFO   : ---------------------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.1.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 4.00 MByte (default)

> What do you see instead?

 VMA INFO   : ---------------------------------------------------------------------------
 VMA INFO   : VMA_VERSION: 6.7.2-0 Release built on 2014-08-21-15:28:25
 VMA INFO   : Cmd Line: iperf -u -c 192.168.1.1
 VMA INFO   : OFED Version: MLNX_OFED_LINUX-2.3-1.0.1:
 VMA INFO   : Log Level                      3                          [VMA_TRACELEVEL]
 VMA INFO   : ---------------------------------------------------------------------------
 VMA ERROR  : utils:229:priv_read_file() ERROR while opening file /sys/class/net/eth0.10/device/resource
------------------------------------------------------------
Client connecting to 192.168.1.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 4.00 MByte (default)


> What version of the product are you using? On what operating system?
MLNX_OFED_LINUX-2.3-1.0.1-ubuntu12.04-x86_64
Ubuntu 12.04 amd64
Kernel 3.13.0-36-generic


> Please provide any additional information below.
If bind software to aliased address it crashed:

 VMA ERROR  : utils:229:priv_read_file() ERROR while opening file /sys/class/net/eth0.10/device/resource
 VMA PANIC  : ring[0x7f8c68040630]:170:create_resources() ibv_create_comp_channel for tx failed. m_p_tx_comp_event_channel = (nil) (errno=9 Bad file descriptor)

Original issue reported on code.google.com by [email protected] on 8 Oct 2014 at 6:54

Data loss seen with code using boost::asio when libvma.so is LD_PRELOADed

I've written client server code, which uses boost::asio. I wanted to check performance number by LD_PRELOADing the server & client binaries. But seeing data loss.

Following are the sample programs written:

  • client_rawio - client program which accepts buffersize, buffercount and internval between which buffer to be sent as input argements. Sends specified number of buffers of specified size to server with each buffer having following header information:
    • pid of client process
    • sequence no
    • length of data in buffer after subtracting header
      On standard output it prints sequence number as shown below:
Buf[4] sent (Total data sent: 4096)

where [4] represents buffer sequence number.

(Source files: client_rawio.cpp)

  • server - server program, which uses boost::asio to bind and listen on socket using io_service. It uses boost::asio::socket::async_read_some() API to read the data from the client and prints the buffer header information to ensure whether data is being read properly or not as shown below:
boost::async_read_some: Bytes read in buffer: 4096      <<< reported by boost::asio
Recieved buffer( pid: 8266 seqno: 0 data_length: 4084 total_length: 4096 total_buffer_data_till_now: 4096) 

As shown above it also prints total buffer data till now received from the client.

(Source files: server.cpp, connection_manager.cpp, connection.cpp)

Issue not seen when libvma.so is not LD_PRELOADed

Run server and client without libvma.so exported

Server logs:

$ ./server
Usage: server <hostip> <portno> <bufsize>

$ ./server 192.168.1.1 8000 4096
Buffer Size expected : 4096
Connection created
start the read operation
boost::async_read_some: Bytes read in buffer: 4096
Recieved buffer( pid: 8266 seqno: 0 data_length: 4084 total_length: 4096 total_buffer_data_till_now: 4096)
boost::async_read_some: Bytes read in buffer: 4096
Recieved buffer( pid: 8266 seqno: 1 data_length: 4084 total_length: 4096 total_buffer_data_till_now: 8192)
boost::async_read_some: Bytes read in buffer: 4096
Recieved buffer( pid: 8266 seqno: 2 data_length: 4084 total_length: 4096 total_buffer_data_till_now: 12288)
boost::async_read_some: Bytes read in buffer: 4096
Recieved buffer( pid: 8266 seqno: 3 data_length: 4084 total_length: 4096 total_buffer_data_till_now: 16384)
boost::async_read_some: Bytes read in buffer: 4096
Recieved buffer( pid: 8266 seqno: 4 data_length: 4084 total_length: 4096 total_buffer_data_till_now: 20480)
boost::async_read_some: Bytes read in buffer: 4096
Recieved buffer( pid: 8266 seqno: 5 data_length: 4084 total_length: 4096 total_buffer_data_till_now: 24576)
boost::async_read_some: Bytes read in buffer: 4096
Recieved buffer( pid: 8266 seqno: 6 data_length: 4084 total_length: 4096 total_buffer_data_till_now: 28672)
boost::async_read_some: Bytes read in buffer: 4096
Recieved buffer( pid: 8266 seqno: 7 data_length: 4084 total_length: 4096 total_buffer_data_till_now: 32768)
boost::async_read_some: Bytes read in buffer: 4096
Recieved buffer( pid: 8266 seqno: 8 data_length: 4084 total_length: 4096 total_buffer_data_till_now: 36864)
boost::async_read_some: Bytes read in buffer: 4096
Recieved buffer( pid: 8266 seqno: 9 data_length: 4084 total_length: 4096 total_buffer_data_till_now: 40960)
Operation aborted

Client logs:

$ ./client_rawio 
usage ./client_rawio <hostname> <port> <bufsize> <bufcount> <sleepinmicro>

$ ./client_rawio 192.168.1.1 8000 4096 10 1
Client Started
Address resolved
Buf[0] sent (Total data sent: 4096)
Buf[1] sent (Total data sent: 8192)
Buf[2] sent (Total data sent: 12288)
Buf[3] sent (Total data sent: 16384)
Buf[4] sent (Total data sent: 20480)
Buf[5] sent (Total data sent: 24576)
Buf[6] sent (Total data sent: 28672)
Buf[7] sent (Total data sent: 32768)
Buf[8] sent (Total data sent: 36864)
Buf[9] sent (Total data sent: 40960)
##Overall Total data sent = 40960bytes 
Client aborted

Issue (Data loss) seen when libvma.so is LD_PRELOADed

When LD_PRELOAD of libvma.so is not performed, no data loss seen with boost APIs.
Run server and client with libvma.so exported

start server as shown below:

$ export LD_PRELOAD=/usr/lib64/libvma.so; ./server 192.168.1.1 8000 4096
 VMA INFO: ---------------------------------------------------------------------------
  VMA INFO: VMA_VERSION: 7.0.14-0 Release built on Jan 28 2016 20:41:00
   VMA INFO: Cmd Line: ./server 192.168.1.1 8000 4096
    VMA INFO: OFED Version: MLNX_OFED_LINUX-3.2-1.0.1.1:
     VMA INFO: Log Level                      INFO                       [VMA_TRACELEVEL]
      VMA INFO: ---------------------------------------------------------------------------
      Buffer Size expected : 4096
      Connection created
      start the read operation
      boost::async_read_some: Bytes read in buffer: 2920
      Recieved buffer( pid: 8269 seqno: 0 data_length: 4084 total_length: 4096 total_buffer_data_till_now: 4096)
      boost::async_read_some: Bytes read in buffer: 1460
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4108)
      boost::async_read_some: Bytes read in buffer: 2920
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4120)
      boost::async_read_some: Bytes read in buffer: 1460
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4132)
      boost::async_read_some: Bytes read in buffer: 4096
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4144)
      boost::async_read_some: Bytes read in buffer: 284
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4156)
      boost::async_read_some: Bytes read in buffer: 1460
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4168)
      boost::async_read_some: Bytes read in buffer: 4096
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4180)
      boost::async_read_some: Bytes read in buffer: 3204
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4192)
      boost::async_read_some: Bytes read in buffer: 1460
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4204)
      boost::async_read_some: Bytes read in buffer: 4096
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4216)
      boost::async_read_some: Bytes read in buffer: 4096
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4228)
      boost::async_read_some: Bytes read in buffer: 568
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4240)
      boost::async_read_some: Bytes read in buffer: 1460
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4252)
      boost::async_read_some: Bytes read in buffer: 4096
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4264)
      boost::async_read_some: Bytes read in buffer: 3284
      Recieved buffer( pid: 0 seqno: 0 data_length: 0 total_length: 12 total_buffer_data_till_now: 4276)
      Operation aborted

Client logs:

$ export LD_PRELOAD=/usr/lib64/libvma.so; ./client_vma 192.168.1.1 8000 4096 10 1
 VMA INFO: ---------------------------------------------------------------------------
  VMA INFO: VMA_VERSION: 7.0.14-0 Release built on Jan 28 2016 20:41:00
   VMA INFO: Cmd Line: ./client_vma 192.168.1.1 8000 4096 10 1
    VMA INFO: OFED Version: MLNX_OFED_LINUX-3.2-1.0.1.1:
     VMA INFO: Log Level                      INFO                       [VMA_TRACELEVEL]
      VMA INFO: ---------------------------------------------------------------------------
      Buf[0] sent (Total data sent: 4096)
      Buf[1] sent (Total data sent: 8192)
      Buf[2] sent (Total data sent: 12288)
      Buf[3] sent (Total data sent: 16384)
      Buf[4] sent (Total data sent: 20480)
      Buf[5] sent (Total data sent: 24576)
      Buf[6] sent (Total data sent: 28672)
      Buf[7] sent (Total data sent: 32768)
      Buf[8] sent (Total data sent: 36864)
      Buf[9] sent (Total data sent: 40960)
      ##Overall Total data sent = 40960 bytes

Above in client logs total bytes sent is 40960 bytes while server received only 4276 bytes (see total_buffer_data_till_now value in server log). Thus header information is wrong (pid and seqno are shown as 0).

So Whenever LD_PRELOAD of libvma.so is done while running client & server, data loss is seen with boost APIs.

Source code:

libvma-boost.tar.gz

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.