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