How easy is it to extend the XDP/eBPF program with a new input
parameter?

I see the need for providing the input "source-port" to the eBPF
program. E.g. needed when implementing a basic learning bridge
(basically a map of <src-mac,src-port>). The concepts of "ports" are
not-defined-yet, thus, this change need to be part of a later
patchset.

Maybe this "source-port-id" can instead be stored as part of the eBPF
program structure? (as it is likely known at registration time)


Reminder: XDP patchset I'm referring to is avail here[1]:
[1] https://git.kernel.org/cgit/linux/kernel/git/ast/bpf.git/?h=xdp

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

On Wed, Jul 06, 2016 at 05:21:53PM +0200, Jesper Dangaard Brouer wrote:

How easy is it to extend the XDP/eBPF program with a new input
parameter?

trivial. do git blame include/uapi/linux/bpf.h
and see commits for struct __sk_buff
We've been adding input md fields non stop without breaking existing programs.
Same thing will be happening with 'struct xdp_md', but hopefully
not that extent. We might need only few extra fields.

I see the need for providing the input "source-port" to the eBPF
program. E.g. needed when implementing a basic learning bridge
(basically a map of <src-mac,src-port>). The concepts of "ports" are
not-defined-yet, thus, this change need to be part of a later
patchset.

correct. the definition of 'port' would be needed.
It will come together with support for multi-port tx.

Maybe this "source-port-id" can instead be stored as part of the eBPF
program structure? (as it is likely known at registration time)

that's also possible, but probably harder to use from program pov.