Re: bpf_fib_lookup support for firewall mark

List,

For what it's worth I patched the structure locally by introducing a
new __u32 mark field
to the structure and adding the proper assignment of the field in
filter.c. Recompiled without any issues.
With that patch a bpf lookup matches ip rule that contains fwmark.

Still interested to know how much of a performance penalty adding an 4
bytes to the
structure brings. I'd certainly vote for adding at least the firewall
mark to the set of fields used in the lookup.

Cheers

On Wed, Jun 9, 2021 at 11:30 AM Rumen Telbizov
[off-list ref] wrote:

Hi David,

Thanks for the quick response. I appreciate it.
A couple of quick follow up questions:
1. Do you have any performance data that would indicate how much of a
performance drop adding an extra 4 or 8 bytes to the structure would
cause?
2. If I patch locally the structure in libc and the kernel by adding
an extra _u32 mark member is there anything that such a modification
would break?

Regards,
Rumen Telbizov


On Tue, Jun 8, 2021 at 6:21 PM David Ahern [off-list ref] wrote:

quoted

On 6/8/21 4:59 PM, Rumen Telbizov wrote:

quoted

Dear BPF list,

I am new to eBPF so go easy on me.
It seems to me that currently eBPF has no support for route table
lookups including firewall marks. The bpf_fib_lookup structure itself
has no mark field as per
https://elixir.bootlin.com/linux/v5.10.28/source/include/uapi/linux/bpf.h#L4864

Additionally bpf_fib_lookup() function does not incorporate the
firewall mark in its route lookup. It explicitly sets it to 0 as per
https://elixir.bootlin.com/linux/v5.10.28/source/net/core/filter.c#L5329
along with other fields which are used during the regular routing
policy database lookup.

Thus lookups from within eBPF and outside of it result in different
outcomes if there are rules directing traffic based on fwmark.
Can you please advise what the rationale for this is or if there
anything that I might be missing.

Let me know if I can provide any further information.

The API (struct bpf_fib_lookup) is constrained to 64B for performance.
It is not possible to support all of the policy routing options that
Linux has in 64B. Choices had to be made.