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.

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