For more info see commit cd7921f ("bpf: implement time source switch
and use it in CT") for more information wrt ktime vs jiffies. Given the CT
maps have been switched, we also should do it for NAT to allow for potential
created time correlation of entries.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

If there is no entry in the affinity map, then it's pointless to fetch
bpf_mono_now() and prep the match key. Only go for it when really needed.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

The only thing that lb4_update_affinity_by_netns() is doing for existing
entries is updating the last_used timestamp, nothing else. So lets not
hit the BPF map update spinlock from all CPUs. Instead use a READ_ONCE()/
WRITE_ONCE() scheme and update the timestamp at the time we do the lookup
where we have the val already.

Only call the lb4_update_affinity_by_netns() update when the
backend_from_affinity is false which indicates that a backend was just
newly selected.

The lb4_update_affinity_by_netns() is addressed separately to ease review.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Do the same conversion as done in the DSR case also for SNAT NodePort
which similarly helps to improve the performance by avoiding the fib
lookup in the kernel. Improving by similar numbers as with DSR case.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Enforce retiring of neigh cache entries either on update or deletion of
new nodes. This will enforce the datapath to re-cache the neigh entry
from the fib. This is needed in order to not leave stale entries around.
Only do this when we have acceleration enabled right now since this is
equivalent to what the datapath does as well. We might later extend this
for tc as well.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

So far eth_store_{s,d}addr() had to fall back to byte-by-byte copies of
src/dst mac addresses from stack into XDP buffer since the case of
fib_lookup is special in that fib_params.{s,d}mac would cause unaligned
access on the BPF stack access when used with our optimized memcpy. For
the neigh table cases we do not have this issue and can therefore reduce
the number of insns needed by using word and half-word wide copies.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

We only ever need to track neigh entries of clients in case of SNAT
when the reply comes back to us or in the case where its local to the
node. For DSR and Hyrbid (DSR for TCP) we don't need to track them
here since the node only ever sees to original requests which improves
scalability for new client mappings as tracking can be avoided altogether.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>