netdev - Re: [bpf-next PATCH 2/2] samples/bpf: xdp_redirect

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] [day] [month] [year] [list]

Message-ID: <20180809223619.27ac88fa@redhat.com>
Date:   Thu, 9 Aug 2018 22:36:19 +0200
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     netdev@...r.kernel.org, Daniel Borkmann <borkmann@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        jhsiao@...hat.com, brouer@...hat.com
Subject: Re: [bpf-next PATCH 2/2] samples/bpf: xdp_redirect_cpu load balance
 like Suricata

On Thu, 9 Aug 2018 22:15:22 +0200
Daniel Borkmann <daniel@...earbox.net> wrote:

> On 08/09/2018 03:26 PM, Jesper Dangaard Brouer wrote:
> > This implement XDP CPU redirection load-balancing across available
> > CPUs, based on the hashing IP-pairs + L4-protocol.  This equivalent to
> > xdp-cpu-redirect feature in Suricata, which is inspired by the
> > Suricata 'ippair' hashing code.
> > 
> > An important property is that the hashing is flow symmetric, meaning
> > that if the source and destination gets swapped then the selected CPU
> > will remain the same.  This is helps locality by placing both directions
> > of a flows on the same CPU, in a forwarding/routing scenario.
> > 
> > The hashing INITVAL (15485863 the 10^6th prime number) was fairly
> > arbitrary choosen, but experiments with kernel tree pktgen scripts
> > (pktgen_sample04_many_flows.sh +pktgen_sample05_flow_per_thread.sh)
> > showed this improved the distribution.
> > 
> > This patch also change the default loaded XDP program to be this
> > load-balancer.  As based on different user feedback, this seems to be
> > the expected behavior of the sample xdp_redirect_cpu.
> > 
> > Link: https://github.com/OISF/suricata/commit/796ec08dd7a63
> > Signed-off-by: Jesper Dangaard Brouer <brouer@...hat.com>
> > ---
> >  samples/bpf/xdp_redirect_cpu_kern.c |  103 +++++++++++++++++++++++++++++++++++
> >  samples/bpf/xdp_redirect_cpu_user.c |    4 +
> >  2 files changed, 105 insertions(+), 2 deletions(-)
> > 
> > diff --git a/samples/bpf/xdp_redirect_cpu_kern.c b/samples/bpf/xdp_redirect_cpu_kern.c
> > index 0cc3d71057f0..a306d1c75622 100644
> > --- a/samples/bpf/xdp_redirect_cpu_kern.c
> > +++ b/samples/bpf/xdp_redirect_cpu_kern.c
> > @@ -13,6 +13,7 @@
> >  
> >  #include <uapi/linux/bpf.h>
> >  #include "bpf_helpers.h"
> > +#include "hash_func01.h"
> >  
> >  #define MAX_CPUS 64 /* WARNING - sync with _user.c */  
> 
> Hmm, this doesn't apply cleanly. I have the following in bpf-next:
> 
> #define MAX_CPUS 12 /* WARNING - sync with _user.c */
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/samples/bpf/xdp_redirect_cpu_kern.c#n17
> 
> Rebase issue? Please respin, thanks.

Ah, this is due to the teardown-fixes patchset for "bpf" git-tree,
which you just applied, which changed MAX_CPUS to 64 (so, QA can use
the reproducer).

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer