netdev - Re: [bpf-next PATCH v4 0/7] Series short description

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 for Android: free password hash cracker in your pocket

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

Message-ID: <a117ca44-e64e-57f1-b255-077a396bccb5@iogearbox.net>
Date:   Wed, 24 Jan 2018 11:00:28 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     John Fastabend <john.fastabend@...il.com>, borkmann@...earbox.net,
        kafai@...com, ast@...nel.org
Cc:     netdev@...r.kernel.org, brouer@...hat.com
Subject: Re: [bpf-next PATCH v4 0/7] Series short description

On 01/22/2018 07:35 PM, John Fastabend wrote:
> The sockmap sample is pretty simple at the moment. All it does is open
> a few sockets attach BPF programs/sockmaps and sends a few packets.

Btw, the subject from cover letter says 'Series short description'.

> However, for testing and debugging I wanted to have more control over
> the sendmsg format and data than provided by tools like iperf3/netperf,
> etc. The reason is for testing BPF programs and stream parser it is
> helpful to be able submit multiple sendmsg calls with different msg
> layouts. For example lots of 1B iovs or a single large MB of data, etc.
> 
> Additionally, my current test setup requires an entire orchestration
> layer (cilium) to run. As well as lighttpd and http traffic generators
> or for kafka testing brokers and clients. This makes it a bit more
> difficult when doing performance optimizations to incrementally test
> small changes and come up with performance delta's and perf numbers.
> 
> By adding a few more options and an additional few tests the sockmap
> sample program can show a more complete example and do some of the
> above. Because the sample program is self contained it doesn't require
> additional infrastructure to run either.
> 
> This series, although still fairly crude, does provide some nice
> additions. They are
> 
>   - a new sendmsg tests with a sender and recv threads
>   - a new base tests so we can get metrics/data without BPF
>   - multiple GBps of throughput on base and sendmsg tests
>   - automatically set rlimit and common variables
> 
> That said the UI is still primitive, more features could be added,
> more tests might be useful, the reporting is bare bones, etc. But,
> IMO lets push this now rather than sit on it for weeks until I get
> time to do the above improvements. Additional patches can address
> the other limitations/issues. Another thing I am considering is
> moving this into selftests, after a few more fixes so we avoid
> false failures, so that we get more sockmap testing.
> 
> v2: removed bogus file added by patch 3/7
> v3: 1/7 replace goto out with returns, remove sighandler update,
>     2/7 free iov in error cases
>     3/7 fix bogus makefile change, bail out early on errors
> v4: add Martin's "nits" and ACKs along with fixes to 2/7 iov free
>     also pointed out by Martin.
> 
> Thanks Daniel and Martin for the reviews!
> 
> ---
> 
> John Fastabend (7):
>       bpf: refactor sockmap sample program update for arg parsing
>       bpf: add sendmsg option for testing BPF programs
>       bpf: sockmap sample, use fork() for send and recv
>       bpf: sockmap sample, report bytes/sec
>       bpf: sockmap sample add base test without any BPF for comparison
>       bpf: sockmap put client sockets in blocking mode
>       bpf: sockmap set rlimit
> 
> 
>  samples/sockmap/sockmap_user.c |  392 +++++++++++++++++++++++++++++++++++-----
>  1 file changed, 340 insertions(+), 52 deletions(-)

Series applied to bpf-next, thanks John!