From Parav:

Presently, address resolve routines consider a destination to be local
if the next-hop device of the resolved route for the destination is the 
loopback netdevice. While this works for simple configurations, it fails
when the source and destination IP addresses belong to an enslaved
netdevice of a VRF.
In that case the next-hop device is the VRF itself, so packets are 
generated with an incorrect destination MAC on the VRF netdevice and 
ib_write_bw times out.

This patch series fixes that by determining whether a destination is
local based on the resolved route's type rather than on the next-hop
netdevice's loopback flag.
That approach resolves loopback traffic consistently both with and 
without VRF configurations.

This series contains 4 patches:
  1/4: refactor address resolution code for reuse by subsequent patches
  2/4: resolve destination MAC via IP stack
  3/4: use route table entry instead of netdev loopback flag
  4/4: fix netdev lookup for IPoIB interfaces

Parav.

---

Changelog:
v0 -> v1:
- Addressed comments from Leon
- Updated commit message to reflect that dev_addr fields are invalid in
  case of failure in PATCH 1/4
- Removed incorrect commit log about 'no functional change' in PATCH 1/4

v0: https://lore-kernel.gnuweeb.org/lkml/20250907160833.56589-5-edwards@nvidia.com/T/

---

Parav Pandit (3):
  RDMA/core: Squash a single user static function
  RDMA/core: Resolve MAC of next-hop device without ARP support
  RDMA/core: Use route entry flag to decide on loopback traffic

Vlad Dumitrescu (1):
  IB/ipoib: Ignore L3 master device

 drivers/infiniband/core/addr.c            | 83 +++++++++++------------
 drivers/infiniband/ulp/ipoib/ipoib_main.c | 21 +++---
 2 files changed, 50 insertions(+), 54 deletions(-)

-- 
2.21.3

On Tue, Sep 16, 2025 at 02:10:59PM +0300, Edward Srouji wrote:
> From Parav:
> 
> Presently, address resolve routines consider a destination to be local
> if the next-hop device of the resolved route for the destination is the 
> loopback netdevice. While this works for simple configurations, it fails
> when the source and destination IP addresses belong to an enslaved
> netdevice of a VRF.
> In that case the next-hop device is the VRF itself, so packets are 
> generated with an incorrect destination MAC on the VRF netdevice and 
> ib_write_bw times out.
> 
> This patch series fixes that by determining whether a destination is
> local based on the resolved route's type rather than on the next-hop
> netdevice's loopback flag.
> That approach resolves loopback traffic consistently both with and 
> without VRF configurations.
> 
> This series contains 4 patches:
>   1/4: refactor address resolution code for reuse by subsequent patches
>   2/4: resolve destination MAC via IP stack
>   3/4: use route table entry instead of netdev loopback flag
>   4/4: fix netdev lookup for IPoIB interfaces
> 
> Parav.
> 
> ---
> 
> Changelog:
> v0 -> v1:
> - Addressed comments from Leon
> - Updated commit message to reflect that dev_addr fields are invalid in
>   case of failure in PATCH 1/4
> - Removed incorrect commit log about 'no functional change' in PATCH 1/4
> 
> v0: https://lore-kernel.gnuweeb.org/lkml/20250907160833.56589-5-edwards@nvidia.com/T/
> 
> ---
> 
> Parav Pandit (3):
>   RDMA/core: Squash a single user static function
>   RDMA/core: Resolve MAC of next-hop device without ARP support
>   RDMA/core: Use route entry flag to decide on loopback traffic
> 
> Vlad Dumitrescu (1):
>   IB/ipoib: Ignore L3 master device
> 
>  drivers/infiniband/core/addr.c            | 83 +++++++++++------------
>  drivers/infiniband/ulp/ipoib/ipoib_main.c | 21 +++---
>  2 files changed, 50 insertions(+), 54 deletions(-)

I applied this series, but please never send series as reply-to. It
broke all flows: b4 automatic apply script, patchworks and "Thanks you .."
email.

Thanks

> 
> -- 
> 2.21.3
>