Hi Rumen, hi David,
(please avoid top-posting)
On 6/9/21 11:56 PM, Rumen Telbizov wrote:
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.
I agree with David here that performance of the helper is paramount.
As a side-note, we should probably add a build_bug_on() to ensure that
the size of struct bpf_fib_lookup will stay at 64b / one cacheline.
That said, given h_vlan_proto/h_vlan_TCI are both output parameters,
maybe we could just union the two fields with a __u32 mark extension
that we then transfer into the flowi{4,6}?
Thanks,
Daniel
On Wed, Jun 9, 2021 at 11:30 AM Rumen Telbizov
<rumen.telbizov@xxxxxxxxxxxxxxxxx> 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 <dsahern@xxxxxxxxx> wrote:
On 6/8/21 4:59 PM, Rumen Telbizov wrote:
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.
