Date:	Fri, 19 Dec 2014 18:49:06 -0800
From:	Andy Zhou <azhou@...ira.com>
To:	"dev@...nvswitch.com" <dev@...nvswitch.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: OVS + BPF, make sense?

Hi, OVS and netdev developers:

On 12/17/2014,  Alexei Starovoiov and a few of the OVS developers
(Joe, Andy, Jesse, Pravin and Justin) got together to discuss possible
ways for OVS to harness the power BPF in recent Linux kernels.  During
the meeting, we feel that the content of the discussion may be of
interest to many OVS and Linux kernel developers, it should be a good
idea to post the meeting minutes.

The meeting minutes can be found below.  I cross post them to both
ovs-dev and netdev mailing list.  Apologises if you receive this email
twice.

We don't have a concrete plan at this point on how BPF can be applied.
However we are interested in exploring further and exchange ideas with
the developer communities.   We can
probably meet again early 2015 if there is sufficient interest in this topic.

Regards,
Andy


BPF current status:
===========================
* Linux kernel up-streaming on going, currently focus on tracing.
Other enhancements
planed, for example, JIT opcode obfuscation, as a security enhancements.

* First set of LLVM upstreaming should land in Q1'15.  More
enhancements will follow.

* GCC backend is possible, but not planed at this time.

* New features planed: per-cpu data structures, streaming interfaces
reusing trace buffer infrasturucture.


Possible use cases of BPF in OVS Linux kernel datapath
===========================================
1. Using BPF to implement a single action:

     It may make sense for OVS to have its own program type. However,
     bpf_register_prog_type() API currently is not exported.  This
means the program type and related helper function can not be provided
by the OVS kernel module, but has be be up-streamed into the kernel
core.  This may affect how OVS kernel module can provide backward
compatibility.  Alexei explained the this is mainly driven by the
concerns of the
complexity related to tracking module load/unload while BPF program
are running, and
the concern of possible side-stepping of GPL.

    BPF action may need to access kernel data structures, such as skb,
in kernel version agnostic ways.  Alexei is aware of this requirement,
and is considering multiple potential solutions  A) bpf helper
functions, b) using pseudo skb, c) ask kernel about offsets for each
interested data field...  This is work in progress.



2. Using BPF to implement the entire action list:

    This is a bigger task than 1, but can bring more benefits of BPF
to OVS. Current ovs action list are sequentially executed. BPF
provides if-then-else and other types of control capabilities to
'upgrade' action list to a true program.

    Those BPF programs needs to be generated at run time by OVS users
space. Alexei thinks this may not be hard within the scope of current
OVS actions. Jesse suggested to reference libpcap style of program generation.


3. Using BPF to implement ovs flow extract

    Flow extract functions are sweet spots for applying BPF. BPF can
be the backend of current OpenFlow match parser, or even the back end
of a more flexible parser such as P4.


4. Using BPF to implement overall OVS kernel module functionality

   Alexei likes this approach the most. The potential benefits are:

   a) flexible parser and flow data structure
   b) user space and kernel data structures are always in-sync, thus
removing the complexity of version compatibility handling and error
checking.
   c) possible higher performance than current kernel module, with
JITed BPF code.
   d) The helper functions can be more easily planned out. This can be
important in case dynamic helper function registration is not
possible.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists