Sending bufs with 'MSG_ZEROCOPY' flag and 'SO_ZEROCOPY' option in kernel 4.14 behaves worse than non_zerocpy

Question

I have a try on zero_copy of kernel 4.14, follow is the details about zero_copy in kernel 4.14.

[1] (https://netdevconf.org/2.1/papers/netdev.pdf)

And I test it in squid which is a cache proxy.My code is a little diffrent with above. I use epoll to handle zerocopy and copy disk file to send to the client. When the socket is writable, I use function as follow

send(fd, buf, sz, MSG_ZEROCOPY); //sz=16KB, 32KB

Also I handle EPOLLERR as follow to free the buf allocated.

recvmsg(fd, &msg, MSG_ERRQUEUE)

But I found that the fd is often waked up with EPOLLERR, SO I call recvmsg after every send calls or else the cpu runs very high. Then I use curl to make requests to the squid proxy which has caches for the request.

foreach -c 400 -w 4 'curl -o /dev/null -s -w "%{time_connect} %{time_total} %{speed_download}\n" http://160MB.html -x 192.168.1.20:3128 -H "Pragma: "'

But the result shows that non_zero_copy code is more quickly. And the cpu hot functions distributes as follow:

non_zero_copy: %Cpu1  : 21.9 us, 77.1 sy,  0.0 ni,  0.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.3 st 

   32.52%  [kernel]             [k] copy_user_enhanced_fast_string
   8.73%  libc-2.17.so         [.] __memcpy_ssse3_back
   6.36%  [kernel]             [k] iowrite16
   3.97%  [kernel]             [k] do_syscall_64
   3.60%  [kernel]             [k] _raw_spin_unlock_irqrestore
   3.25%  libc-2.17.so         [.] __memset_sse2
   2.74%  [kernel]             [k] find_get_entry
   2.03%  libpthread-2.17.so   [.] pthread_cond_wait@@GLIBC_2.3.2
   1.66%  [kernel]             [k] tcp_sendmsg_locked
   1.44%  [kernel]             [k] generic_file_read_iter
   0.84%  [kernel]             [k] finish_task_switch
   0.80%  libc-2.17.so         [.] epoll_ctl
   0.78%  [kernel]             [k] __fget
   0.78%  [kernel]             [k] get_page_from_freelist
   0.77%  [kernel]             [k] sock_poll
   0.71%  [kernel]             [k] skb_release_data
   0.69%  libpthread-2.17.so   [.] __pthread_disable_asynccancel
   0.64%  [kernel]             [k] sys_epoll_ctl
   0.62%  [kernel]             [k] __audit_syscall_exit

zero_copy: %Cpu1  : 35.8 us, 63.9 sy,  0.0 ni,  0.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

   9.41%  [kernel]             [k] do_syscall_64
   8.57%  [kernel]             [k] copy_user_enhanced_fast_string
   7.79%  [kernel]             [k] _raw_spin_unlock_irqrestore
   7.55%  libc-2.17.so         [.] 0x00000000000f7d13
   6.70%  [kernel]             [k] ep_send_events_proc
   5.11%  [vdso]               [.] __vdso_gettimeofday
   4.73%  libc-2.17.so         [.] __memset_sse2
   4.16%  [kernel]             [k] pvclock_clocksource_read
   3.66%  libc-2.17.so         [.] __memcpy_ssse3_back
   2.02%  [kernel]             [k] tcp_poll
   1.95%  [kernel]             [k] iowrite16
   1.93%  squid                [.] comm_select
   1.73%  [kernel]             [k] find_get_entry
   1.57%  [kernel]             [k] sock_poll
   1.54%  [kernel]             [k] __fget
   1.53%  [kernel]             [k] select_estimate_accuracy
   1.41%  squid                [.] getCurrentTime
   0.86%  [kernel]             [k] ktime_get_ts64
   0.84%  [kernel]             [k] ep_poll
   0.83%  [kernel]             [k] ep_scan_ready_list.isra.13
   0.81%  libpthread-2.17.so   [.] pthread_cond_wait@@GLIBC_2.3.2
   0.73%  [kernel]             [k] fput
   0.71%  [kernel]             [k] __audit_syscall_entry
   0.71%  [kernel]             [k] __audit_syscall_exit
   0.70%  [kernel]             [k] mutex_lock
   0.66%  [kernel]             [k] _raw_spin_lock_irqsave
   0.59%  libc-2.17.so         [.] __libc_disable_asynccancel
   0.57%  squid                [.] statHistCount

Does anyone have the same test with me? And why my test is not same with the result of the article in pdf above.

Hi can you please elaborate the steps followed by you to test MSG_ZERO copy.., im trying to test the same, i'm getting an error as given below exec of "./msg_zerocopy" failed: No such file or directory [1]+ Exit 1 ip netns exec cli "${BIN}" "-${IP}" -i p4p4 -t 2 -C 2 -S "${SADDR}" -D "${DADDR}" ${ARGS} -r "${RXMODE}" — SudipM, Sep 04 '18 at 07:47
I don't test msg_zerocopy in the kernel's example, but use the functions at squid source code — zengxiaobai2, Nov 28 '19 at 07:42

score 3 · Answer 1 · 2018-04-18T13:31:54.900

3

Are you trying zerocopy over loopback or real network card? Be sure to check Documentation/networking/msg_zerocopy.rst first

Loopback

Data sent to local sockets can be queued indefinitely if the receive process does not read its socket. Unbound notification latency is not acceptable. For this reason all packets generated with MSG_ZEROCOPY that are looped to a local socket will incur a deferred copy. This includes looping onto packet sockets (e.g., tcpdump) and tun devices.

Also, looking at the implementation, it seems that your network card must have enabled tx-scatter-gather-fraglist. Check it in ethtool -k.

   zc = sk->sk_route_caps & NETIF_F_SG;
    if (!zc)
      uarg->zerocopy = 0; 

enum {
  NETIF_F_SG_BIT,     /* Scatter/gather IO. */

edited Apr 18 '18 at 13:31

answered Apr 18 '18 at 13:23

thanks ,you are right . I test in a virtual machine,when i move test to a real machine, i can get correct result. And also the function stack is associated with ”zero_copy“ ，but in virtual machine the function stack is not associated with "zero_copy" – zengxiaobai2 Jun 30 '18 at 01:43
I test request from 192.168.1.70 to 192.168.1.20 ,the two virtual machine is on a same real machine. but the option tx-scatter-gather-fraglist is off (fixed) – zengxiaobai2 Jun 30 '18 at 13:57

score 0 · Answer 2 · answered Jun 30 '18 at 14:06

I modify nothing just move tests from virtual machine to real machine: the function __zerocopy_sg_from_iter which never occured in the virtual machine but in the real machine.

ZERO_COPY: (in real machine)
%Cpu1  : 17.8 us, 34.9 sy,  0.0 ni, 47.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
13903 squid     20   0  147236  45196   5860 R  52.2  0.1   0:15.65 squid  

  18.42%  libc-2.17.so         [.] __memcpy_ssse3_back
  17.32%  [kernel]             [k] copy_user_generic_string
   2.79%  [kernel]             [k] syscall_return_via_sysret
   2.09%  [unknown]            [k] 0xfffffe800003201e
   1.91%  [kernel]             [k] gup_pgd_range
   1.21%  [kernel]             [k] generic_file_read_iter
   1.20%  [kernel]             [k] _raw_spin_lock
   1.05%  [kernel]             [k] sock_poll
   1.04%  [kernel]             [k] sys_epoll_ctl
   1.02%  [kernel]             [k] __schedule
   0.97%  [kernel]             [k] __audit_syscall_entry
   0.93%  [kernel]             [k] __zerocopy_sg_from_iter

and i make a comparisonwith NO_ZEROCOPY in real machine
%Cpu1  : 11.4 us, 46.8 sy,  0.0 ni, 41.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st                                                                                                                 
13988 squid     20   0  115948  15228   5784 R  57.5  0.0   0:31.99 squid
   33.27%  [kernel]             [k] copy_user_generic_string
   9.62%  libc-2.17.so         [.] __memcpy_ssse3_back
   2.34%  [kernel]             [k] syscall_return_via_sysret
   1.80%  [unknown]            [k] 0xfffffe800003201e
   1.35%  [kernel]             [k] tcp_sendmsg_locked
   1.18%  [kernel]             [k] generic_file_read_iter 
    NO_ZEROCOPY    ZERO_COPY
cpu 62.9           53.6
cpu 53.6           43.3
cpu 46.8           34.9

Sending bufs with 'MSG_ZEROCOPY' flag and 'SO_ZEROCOPY' option in kernel 4.14 behaves worse than non_zerocpy

2 Answers2

Loopback