28 Sep
2015
28 Sep
'15
2:58 p.m.
On Fri, Sep 25, 2015 at 09:13:01AM +0200, Harald Welte wrote:
Hi all,
it seems like there is some work in the kernel network stack to have a
generic multiplexor/demultiplexor for protocols that implement
message-based semantics over TCP:
http://thread.gmane.org/gmane.linux.network/378365
They don't implement a specific messaging protocol, but the userspace
program can BPF to let the kernel muxer know how to find the length
of the message.
This seems like conceptually it is suitable for actually implementing an
IPA multiplex inside the kernel and then get e.g. Abis OML and RSL on
different sockets.
Interesting, as my recent patch submission does some effort to multiplex
the SGSN<->MAP IPA wire to GSUP and the new OAP. The difference between
the two is visible from the proto_ext byte, easy to filter on.
So IIUC with (e)BPF in the kernel, we can load two eBPF programs on an IPA
socket and somehow get two separate sockets(?) to read from, where each
will yield only those IPA packets that match the respective proto_ext.
There is also the connection housekeeping (IPA ping/pong and so on), which
is independent of the IPA proto payload. Could be a third eBPF program &
socket (or the like) ... ? Interesting in the sense: "You want another
proto on your IPA wire? just open another BPF without changing the current
IPA code."
But so far it sounds like the BPF can only examine and maybe drop packets
on a single socket and not yet mux towards multiple readers (we can add a
BPF sockopt on one socket, not get N sockets, AFAICT).
And, when muxing is already working in internal code, replacing that with
BPF is just more work, of course.
But will keep in mind for the future, I guess :)
~Neels