diff options
author | Parav Pandit <parav@nvidia.com> | 2025-09-16 14:11:02 +0300 |
---|---|---|
committer | Leon Romanovsky <leon@kernel.org> | 2025-09-18 05:20:35 -0400 |
commit | c31e4038c97f355967bf906c0b6914edb4f20d75 (patch) | |
tree | 6f962cb2be69b86b501cbde4689643980ef3ff56 /drivers/infiniband/hw/ionic/ionic_controlpath.c | |
parent | 200651b9b8aadfbbec852f0e5d042d9abe75e2ab (diff) |
RDMA/core: Use route entry flag to decide on loopback traffic
addr_resolve() considers a destination to be local if the next-hop
device of the resolved route for the destination is the loopback
netdevice.
This fails when the source and destination IP addresses belong to
a netdev enslaved to a VRF netdev. In this case the next-hop device
is the VRF itself:
$ ip link add name myvrf up type vrf table 100
$ ip link set ens2f0np0 master myvrf up
$ ip addr add 192.168.1.1/24 dev ens2f0np0
$ ip route get 192.168.1.1 oif myvrf
local 192.168.1.1 dev myvrf table 100 src 192.168.1.1 uid 0
cache <local>
This results in packets being generated with an incorrect destination
MAC of the VRF netdevice and ib_write_bw failing with timeout.
Solve this by determining if a destination is local or not based on
the resolved route's type rather than based on its next-hop netdevice
loopback flag.
This enables to resolve loopback traffic with and without VRF
configurations in a uniform way.
Signed-off-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Vlad Dumitrescu <vdumitrescu@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20250916111103.84069-4-edwards@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Diffstat (limited to 'drivers/infiniband/hw/ionic/ionic_controlpath.c')
0 files changed, 0 insertions, 0 deletions