netdev - Re: [RFC PATCH 3/4] udp: implement GRO plain UDP sockets.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 17 Sep 2018 12:06:06 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>,
        Willem de Bruijn <willemb@...gle.com>,
        Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [RFC PATCH 3/4] udp: implement GRO plain UDP sockets.

Hi,

On Fri, 2018-09-14 at 09:48 -0700, Eric Dumazet wrote:
> Are you sure the data is actually fully copied to user space ?
> 
> tools/testing/selftests/net/udpgso_bench_rx.c
> 
> uses :
> 
> static char rbuf[ETH_DATA_LEN];
>    /* MSG_TRUNC will make return value full datagram length */
>    ret = recv(fd, rbuf, len, MSG_TRUNC | MSG_DONTWAIT);
> 
> So you need to change this program.

Thank for the feedback.

You are right, I need to update udpgso_bench_rx. Making it
unconditionally read up to 64K bytes, I measure:

Before:
udp rx:    962 MB/s   685339 calls/s

After:
udp rx:   1344 MB/s    22812 calls/s

Top perf offenders for udpgso_bench_rx:
  31.83%  [kernel]         [k] copy_user_enhanced_fast_string
   8.90%  [kernel]         [k] skb_release_data
   7.97%  [kernel]         [k] free_pcppages_bulk
   6.82%  [kernel]         [k] copy_page_to_iter
   3.41%  [kernel]         [k] skb_copy_datagram_iter
   2.01%  [kernel]         [k] free_unref_page
   1.92%  [kernel]         [k] __entry_SYSCALL_64_trampoline

Trivial note: with this even UDP sockets would benefit from remote skb
freeing, as the cost of skb_release_data is relevant for the GSO
packets.

> Also, GRO reception would mean that userspace can retrieve,
> not only full bytes of X datagrams, but also the gso_size (or length of individual datagrams)
> 
> You can not know the size of the packets in advance, the sender will decide.

Thanks for pointing that out. I guess that implementing something like
cmsg(UDP_SEGMENT) as Willem suggests in in 8/8 patch would do, right?

I can have a look at that _if_ there is interest in this approch,

Cheers,

Paolo