Fix local destination address resolution with VRF
cover Fix local destination address resolution with VRF
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.
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(-)
Signature · 1 line
2.21.3
PATCH 1/4 RDMA/core: Squash a single user static function
From: Parav Pandit <[email protected]>
In order to reduce dependencies in IFF_LOOPBACK in route and neighbour resolution steps, squash the static function to its single caller and simplify the code. No functional change.
--- drivers/infiniband/core/addr.c | 49 ++++++++++++++-------------------- 1 file changed, 20 insertions(+), 29 deletions(-)
drivers/infiniband/core/addr.c +20 -29
@@ -465,34 +465,6 @@ static int addr_resolve_neigh(const struct dst_entry *dst,return ret; } -static int copy_src_l2_addr (struct rdma_dev_addr *dev_addr, -const struct sockaddr *dst_in, -const struct dst_entry *dst, -const struct net_device *ndev) -{ -int ret =0 ; - -if (dst->dev->flags &IFF_LOOPBACK ) - ret =rdma_translate_ip (dst_in, dev_addr); -else -rdma_copy_src_l2_addr (dev_addr, dst->dev); - -/* -* If there's a gateway and type of device not ARPHRD_INFINIBAND, -* we're definitely in RoCE v2 (as RoCE v1 isn't routable) set the -* network type accordingly. -*/ -if (has_gateway (dst, dst_in->sa_family) && - ndev->type !=ARPHRD_INFINIBAND ) - dev_addr->network = dst_in->sa_family ==AF_INET ? -RDMA_NETWORK_IPV4 : -RDMA_NETWORK_IPV6 ; -else - dev_addr->network =RDMA_NETWORK_IB ; - -return ret; -} - static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, unsigned int *ndev_flags, const struct sockaddr *dst_in,
@@ -503,6 +475,7 @@ static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, *ndev_flags = ndev->flags;/* A physical device must be the RDMA device to use */ if (ndev->flags &IFF_LOOPBACK ) { +int ret;/* * RDMA (IB/RoCE, iWarp) doesn't run on lo interface or * loopback IP address. So if route is resolved to loopback
@@ -512,9 +485,27 @@ static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, ndev =rdma_find_ndev_for_src_ip_rcu (dev_net (ndev), dst_in);if (IS_ERR (ndev))return -ENODEV ; + ret =rdma_translate_ip (dst_in, dev_addr); +if (ret) +return ret; + }else { +rdma_copy_src_l2_addr (dev_addr, dst->dev); } -return copy_src_l2_addr (dev_addr, dst_in, dst, ndev); +/* +* If there's a gateway and type of device not ARPHRD_INFINIBAND, +* we're definitely in RoCE v2 (as RoCE v1 isn't routable) set the +* network type accordingly. +*/ +if (has_gateway (dst, dst_in->sa_family) && + ndev->type !=ARPHRD_INFINIBAND ) + dev_addr->network = dst_in->sa_family ==AF_INET ? +RDMA_NETWORK_IPV4 : +RDMA_NETWORK_IPV6 ; +else + dev_addr->network =RDMA_NETWORK_IB ; + +return 0 ; }static int set_addr_netns_by_gid_rcu (struct rdma_dev_addr *addr)
Signature · 1 line
2.21.3
Re: [PATCH 1/4] RDMA/core: Squash a single user static function
Quoted 6 lines · Edward Srouji
From: Parav Pandit <[email protected]>
In order to reduce dependencies in
IFF_LOOPBACKin route and neighbour resolution steps, squash the static function to its single caller and simplify the code. No functional change.
It needs more explanation why it is true. Before this change, we set dev_addr->network to some value and returned error. That error propagated upto process_one_req(), which handles only some errors and ignores rest.
So now, we continue to handle REQ without proper req->addr->network.
Thanks
Quoted 88 lines
Signed-off-by Parav Pandit <[email protected]>Reviewed-by Vlad Dumitrescu <[email protected]>Signed-off-by Edward Srouji <[email protected]>--- drivers/infiniband/core/addr.c | 49 ++++++++++++++-------------------- 1 file changed, 20 insertions(+), 29 deletions(-)drivers/infiniband/core/addr.c +20
-29@@ -465,34 +465,6 @@ static int addr_resolve_neigh(const struct dst_entry *dst,return ret; } -static int copy_src_l2_addr (struct rdma_dev_addr *dev_addr, -const struct sockaddr *dst_in, -const struct dst_entry *dst, -const struct net_device *ndev) -{ -int ret =0 ; - -if (dst->dev->flags &IFF_LOOPBACK ) - ret =rdma_translate_ip (dst_in, dev_addr); -else -rdma_copy_src_l2_addr (dev_addr, dst->dev); - -/* -* If there's a gateway and type of device not ARPHRD_INFINIBAND, -* we're definitely in RoCE v2 (as RoCE v1 isn't routable) set the -* network type accordingly. -*/ -if (has_gateway (dst, dst_in->sa_family) && - ndev->type !=ARPHRD_INFINIBAND ) - dev_addr->network = dst_in->sa_family ==AF_INET ? -RDMA_NETWORK_IPV4 : -RDMA_NETWORK_IPV6 ; -else - dev_addr->network =RDMA_NETWORK_IB ; - -return ret; -} - static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, unsigned int *ndev_flags, const struct sockaddr *dst_in,@@ -503,6 +475,7 @@ static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, *ndev_flags = ndev->flags;/* A physical device must be the RDMA device to use */ if (ndev->flags &IFF_LOOPBACK ) { +int ret;/* * RDMA (IB/RoCE, iWarp) doesn't run on lo interface or * loopback IP address. So if route is resolved to loopback @@ -512,9 +485,27 @@ static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, ndev =rdma_find_ndev_for_src_ip_rcu (dev_net (ndev), dst_in);if (IS_ERR (ndev))return -ENODEV ; + ret =rdma_translate_ip (dst_in, dev_addr); +if (ret) +return ret; + }else { +rdma_copy_src_l2_addr (dev_addr, dst->dev); } -return copy_src_l2_addr (dev_addr, dst_in, dst, ndev); +/* +* If there's a gateway and type of device not ARPHRD_INFINIBAND, +* we're definitely in RoCE v2 (as RoCE v1 isn't routable) set the +* network type accordingly. +*/ +if (has_gateway (dst, dst_in->sa_family) && + ndev->type !=ARPHRD_INFINIBAND ) + dev_addr->network = dst_in->sa_family ==AF_INET ? +RDMA_NETWORK_IPV4 : +RDMA_NETWORK_IPV6 ; +else + dev_addr->network =RDMA_NETWORK_IB ; + +return 0 ; }static int set_addr_netns_by_gid_rcu (struct rdma_dev_addr *addr)Signature · 1 line
2.21.3
RE: [PATCH 1/4] RDMA/core: Squash a single user static function
Quoted 5 lines
From: Leon Romanovsky <[email protected]>
Sent: 10 September 2025 01:48 PM
Quoted 8 lines
Quoted 5 lines · Edward Srouji
From: Parav Pandit <[email protected]>
In order to reduce dependencies in
IFF_LOOPBACKin route and neighbour resolution steps, squash the static function to its single caller and simplify the code. No functional change.It needs more explanation why it is true.
After second look at the code, it is not true.
It is not true for the case when dev->flags has IFF_LOOPBACK and translate_ip() failed. In existing code, when translate_ip() fails, code still sets dev_addr->network. dev_addr->network is not referred if the process_one_req() has error.
Quoted 7 lines
Before this change, we set dev_addr-
Quoted 1 line
network to some value and returned error.
That error propagated upto
process_one_req(), which handles only some errors and ignores rest.So now, we continue to handle REQ without proper
req->addr->network.
Not exactly. When error is returned by the code addr->network is not filled up, which is correct thing to do.
So at best, commit message should be updated to remove "No functional change".
Will send v1.
Quoted 97 lines
Thanks
drivers/infiniband/core/addr.c static int addr_resolve_neigh(const struct dst_entry
Quoted 15 lines
Signed-off-by Parav Pandit <[email protected]>Reviewed-by Vlad Dumitrescu <[email protected]>Signed-off-by Edward Srouji <[email protected]>--- drivers/infiniband/core/addr.c | 49 ++++++++++++++-------------------- 1 file changed, 20 insertions(+), 29 deletions(-)(quoted diff) +0
-0
b/drivers/infiniband/core/addr.cindexbe0743dac3ff..594e7ee335f7100644drivers/infiniband/core/addr.c +0
-0@@ -465,34 +465,6 @@ static int addr_resolve_neigh(const struct dst_entry*dst,
drivers/infiniband/core/addr.c static int rdma_set_src_addr_rcu(struct
Quoted 35 lines
drivers/infiniband/core/addr.c +0
-28return ret; } -static int copy_src_l2_addr (struct rdma_dev_addr *dev_addr, -const struct sockaddr *dst_in, -const struct dst_entry *dst, -const struct net_device *ndev) -{ -int ret =0 ; - -if (dst->dev->flags &IFF_LOOPBACK ) - ret =rdma_translate_ip (dst_in, dev_addr); -else -rdma_copy_src_l2_addr (dev_addr, dst->dev); - -/* -* If there's a gateway and type of device not ARPHRD_INFINIBAND, -* we're definitely in RoCE v2 (as RoCE v1 isn't routable) set the -* network type accordingly. -*/ -if (has_gateway (dst, dst_in->sa_family) && - ndev->type !=ARPHRD_INFINIBAND ) - dev_addr->network = dst_in->sa_family ==AF_INET ? -RDMA_NETWORK_IPV4 : -RDMA_NETWORK_IPV6 ; -else - dev_addr->network =RDMA_NETWORK_IB ; - -return ret; -} - static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, unsigned int *ndev_flags, const struct sockaddr *dst_in,@@ -503,6 +475,7 @@ static int rdma_set_src_addr_rcu(struct
rdma_dev_addr*dev_addr,drivers/infiniband/core/addr.c static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, · line 481
Quoted 7 lines
drivers/infiniband/core/addr.c +1
-0*ndev_flags = ndev->flags;/* A physical device must be the RDMA device to use */ if (ndev->flags &IFF_LOOPBACK ) { +int ret;/* * RDMA (IB/RoCE, iWarp) doesn't run on lo interface or * loopback IP address. So if route is resolved to loopback @@
Quoted 1 line
-512,9 +485,27 @@ static int rdma_set_src_addr_rcu(struct
rdma_dev_addr
*dev_addr,Quoted 1 line
ndev = rdma_find_ndev_for_src_ip_rcu(dev_net(ndev),
dst_in);Quoted 31 lines
drivers/infiniband/core/addr.c +19
-2if (IS_ERR (ndev))return -ENODEV ; + ret =rdma_translate_ip (dst_in, dev_addr); +if (ret) +return ret; + }else { +rdma_copy_src_l2_addr (dev_addr, dst->dev); } -return copy_src_l2_addr (dev_addr, dst_in, dst, ndev); +/* +* If there's a gateway and type of device not ARPHRD_INFINIBAND, +* we're definitely in RoCE v2 (as RoCE v1 isn't routable) set the +* network type accordingly. +*/ +if (has_gateway (dst, dst_in->sa_family) && + ndev->type !=ARPHRD_INFINIBAND ) + dev_addr->network = dst_in->sa_family ==AF_INET ? +RDMA_NETWORK_IPV4 : +RDMA_NETWORK_IPV6 ; +else + dev_addr->network =RDMA_NETWORK_IB ; + +return 0 ; }static int set_addr_netns_by_gid_rcu (struct rdma_dev_addr *addr) --2.21.3
Re: [PATCH 1/4] RDMA/core: Squash a single user static function
Quoted 23 lines · Parav Pandit
Quoted 5 lines
From: Leon Romanovsky <[email protected]>
Sent: 10 September 2025 01:48 PMQuoted 8 lines
Quoted 5 lines · Edward Srouji
From: Parav Pandit <[email protected]>
In order to reduce dependencies in
IFF_LOOPBACKin route and neighbour resolution steps, squash the static function to its single caller and simplify the code. No functional change.It needs more explanation why it is true.
After second look at the code, it is not true.
It is not true for the case whendev->flagshasIFF_LOOPBACKandtranslate_ip()failed. In existing code, whentranslate_ip()fails, code still setsdev_addr->network.dev_addr->networkis not referred if theprocess_one_req()has error.Quoted 5 lines
Before this change, we set dev_addr-
Quoted 1 line
network to some value and returned error.
That error propagated upto
process_one_req(), which handles only some errors and ignores rest.
Quoted 7 lines
Quoted 2 lines
So now, we continue to handle REQ without proper
req->addr->network.Not exactly. When error is returned by the code
addr->networkis not filled up, which is correct thing to do.So at best, commit message should be updated to remove "No functional change".
Will send v1.
Parav,
Please setup your e-mail client, your reply is mixed with mine and repeats it.
Thanks
Quoted 98 lines
Quoted 98 lines
Thanks
drivers/infiniband/core/addr.c static int addr_resolve_neigh(const struct dst_entry
Quoted 15 lines
Signed-off-by Parav Pandit <[email protected]>Reviewed-by Vlad Dumitrescu <[email protected]>Signed-off-by Edward Srouji <[email protected]>--- drivers/infiniband/core/addr.c | 49 ++++++++++++++-------------------- 1 file changed, 20 insertions(+), 29 deletions(-)(quoted diff) +0
-0
b/drivers/infiniband/core/addr.cindexbe0743dac3ff..594e7ee335f7100644drivers/infiniband/core/addr.c +0
-0@@ -465,34 +465,6 @@ static int addr_resolve_neigh(const struct dst_entry*dst,
drivers/infiniband/core/addr.c static int rdma_set_src_addr_rcu(struct
Quoted 35 lines
drivers/infiniband/core/addr.c +0
-28return ret; } -static int copy_src_l2_addr (struct rdma_dev_addr *dev_addr, -const struct sockaddr *dst_in, -const struct dst_entry *dst, -const struct net_device *ndev) -{ -int ret =0 ; - -if (dst->dev->flags &IFF_LOOPBACK ) - ret =rdma_translate_ip (dst_in, dev_addr); -else -rdma_copy_src_l2_addr (dev_addr, dst->dev); - -/* -* If there's a gateway and type of device not ARPHRD_INFINIBAND, -* we're definitely in RoCE v2 (as RoCE v1 isn't routable) set the -* network type accordingly. -*/ -if (has_gateway (dst, dst_in->sa_family) && - ndev->type !=ARPHRD_INFINIBAND ) - dev_addr->network = dst_in->sa_family ==AF_INET ? -RDMA_NETWORK_IPV4 : -RDMA_NETWORK_IPV6 ; -else - dev_addr->network =RDMA_NETWORK_IB ; - -return ret; -} - static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, unsigned int *ndev_flags, const struct sockaddr *dst_in,@@ -503,6 +475,7 @@ static int rdma_set_src_addr_rcu(struct
rdma_dev_addr*dev_addr,drivers/infiniband/core/addr.c static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, · line 481
Quoted 7 lines
drivers/infiniband/core/addr.c +1
-0*ndev_flags = ndev->flags;/* A physical device must be the RDMA device to use */ if (ndev->flags &IFF_LOOPBACK ) { +int ret;/* * RDMA (IB/RoCE, iWarp) doesn't run on lo interface or * loopback IP address. So if route is resolved to loopback @@
Quoted 1 line
-512,9 +485,27 @@ static int rdma_set_src_addr_rcu(struct
rdma_dev_addr
*dev_addr,Quoted 1 line
ndev = rdma_find_ndev_for_src_ip_rcu(dev_net(ndev),
dst_in);Quoted 31 lines
drivers/infiniband/core/addr.c +19
-2if (IS_ERR (ndev))return -ENODEV ; + ret =rdma_translate_ip (dst_in, dev_addr); +if (ret) +return ret; + }else { +rdma_copy_src_l2_addr (dev_addr, dst->dev); } -return copy_src_l2_addr (dev_addr, dst_in, dst, ndev); +/* +* If there's a gateway and type of device not ARPHRD_INFINIBAND, +* we're definitely in RoCE v2 (as RoCE v1 isn't routable) set the +* network type accordingly. +*/ +if (has_gateway (dst, dst_in->sa_family) && + ndev->type !=ARPHRD_INFINIBAND ) + dev_addr->network = dst_in->sa_family ==AF_INET ? +RDMA_NETWORK_IPV4 : +RDMA_NETWORK_IPV6 ; +else + dev_addr->network =RDMA_NETWORK_IB ; + +return 0 ; }static int set_addr_netns_by_gid_rcu (struct rdma_dev_addr *addr) --2.21.3
PATCH 2/4 RDMA/core: Resolve MAC of next-hop device without ARP support
In reply to Edward SroujiFrom: Parav Pandit <[email protected]>
Currently, if the next-hop netdevice does not support ARP resolution, the destination MAC address is silently set to zero without reporting an error. This leads to incorrect behavior and may result in packet transmission failures.
Fix this by deferring MAC resolution to the IP stack via neighbour lookup, allowing proper resolution or error reporting as appropriate.
--- drivers/infiniband/core/addr.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-)
drivers/infiniband/core/addr.c +3 -7
@@ -454,14 +454,10 @@ static int addr_resolve_neigh(const struct dst_entry *dst, {int ret =0 ; -if (ndev_flags &IFF_LOOPBACK ) { +if (ndev_flags &IFF_LOOPBACK )memcpy (addr->dst_dev_addr, addr->src_dev_addr,MAX_ADDR_LEN ); - }else { -if (!(ndev_flags &IFF_NOARP )) { -/* If the device doesn't do ARP internally */ - ret =fetch_ha (dst, addr, dst_in, seq); - } - } +else + ret =fetch_ha (dst, addr, dst_in, seq);return ret; }
Signature · 1 line
2.21.3
Re: [PATCH 2/4] RDMA/core: Resolve MAC of next-hop device without ARP support
Quoted 5 lines · Edward Srouji
From: Parav Pandit <[email protected]>
Currently, if the next-hop netdevice does not support ARP resolution, the destination MAC address is silently set to zero without reporting an error.
Not an expert here, but from my understanding this is right behavior. IFF_NOARP means "leave" MAC address as is (zero).
Quoted 4 lines
This leads to incorrect behavior and may result in packet transmission failures.
Fix this by deferring MAC resolution to the IP stack via neighbour lookup, allowing proper resolution or error reporting as appropriate.
What is the difference here? For IPv4, neighbour lookup is ARP, no?
Quoted 34 lines
Fixes 7025fcd36bd6 ("IB: address translation to map IP toIB addresses (GIDs)")Signed-off-by Parav Pandit <[email protected]>Reviewed-by Vlad Dumitrescu <[email protected]>Signed-off-by Edward Srouji <[email protected]>--- drivers/infiniband/core/addr.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-)drivers/infiniband/core/addr.c +3
-7@@ -454,14 +454,10 @@ static int addr_resolve_neigh(const struct dst_entry *dst, {int ret =0 ; -if (ndev_flags &IFF_LOOPBACK ) { +if (ndev_flags &IFF_LOOPBACK )memcpy (addr->dst_dev_addr, addr->src_dev_addr,MAX_ADDR_LEN ); - }else { -if (!(ndev_flags &IFF_NOARP )) { -/* If the device doesn't do ARP internally */ - ret =fetch_ha (dst, addr, dst_in, seq); - } - } +else + ret =fetch_ha (dst, addr, dst_in, seq);return ret; }Signature · 1 line
2.21.3
RE: [PATCH 2/4] RDMA/core: Resolve MAC of next-hop device without ARP support
Quoted 5 lines
From: Leon Romanovsky <[email protected]>
Sent: 10 September 2025 02:02 PMOn Sun, Sep 07, 2025 at 07:08:31PM +0300, Edward Srouji wrote:
Quoted 9 lines
Quoted 5 lines
From: Parav Pandit <[email protected]>
Currently, if the next-hop netdevice does not support ARP resolution, the destination MAC address is silently set to zero without reporting an error.
Not an expert here, but from my understanding this is right behavior.
IFF_NOARPmeans "leave" MAC address as is (zero).
Not really.
In the example of the VRF, the device does not resolve the ARP itself, but it's the enslaved device which resolves the neighbour. Some ip vlan l2 devices do not do arp internally but depends on the bridge/stack to resolve.
Quoted 7 lines
Quoted 1 line
This leads to incorrect behavior and may result in packet transmission
failures.
Quoted 3 lines
Fix this by deferring MAC resolution to the IP stack via neighbour lookup, allowing proper resolution or error reporting as appropriate.
What is the difference here? For IPv4, neighbour lookup is ARP, no?
It is but it is not the only way. A device may not do ARP by itself but it relies on the rest of the stack like vrf or ip vlan mode to resolve. A user may also set manual entry without explicit ARP.
Quoted 38 lines
Quoted 17 lines
Fixes 7025fcd36bd6 ("IB: address translation to map IP toIB addresses(GIDs)")
Signed-off-by Parav Pandit <[email protected]>Reviewed-by Vlad Dumitrescu <[email protected]>Signed-off-by Edward Srouji <[email protected]>--- drivers/infiniband/core/addr.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-)(quoted diff) +0
-0
b/drivers/infiniband/core/addr.cindex594e7ee335f7..ca86c482662f100644drivers/infiniband/core/addr.c static int addr_resolve_neigh(const struct · line 458
Quoted 6 lines
drivers/infiniband/core/addr.c +1
-1@@ -454,14 +454,10 @@ static int addr_resolve_neigh(const struct dst_entry *dst, { int ret = 0; -if (ndev_flags &IFF_LOOPBACK ) { + if (ndev_flags & IFF_LOOPBACK) memcpy(addr->dst_dev_addr, addr->src_dev_addr,
MAX_ADDR_LEN);Quoted 14 lines
drivers/infiniband/core/addr.c +2
-7- }else { -if (!(ndev_flags &IFF_NOARP )) { -/* If the device doesn't do ARP internally */ - ret =fetch_ha (dst, addr, dst_in, seq); - } - } +else + ret =fetch_ha (dst, addr, dst_in, seq);return ret; } --2.21.3
Re: [PATCH 2/4] RDMA/core: Resolve MAC of next-hop device without ARP support
Quoted 9 lines · Parav Pandit
Quoted 7 lines
Quoted 1 line
This leads to incorrect behavior and may result in packet transmission
failures.
Quoted 3 lines
Fix this by deferring MAC resolution to the IP stack via neighbour lookup, allowing proper resolution or error reporting as appropriate.
What is the difference here? For IPv4, neighbour lookup is ARP, no?
It is but it is not the only way. A device may not do ARP by itself but it relies on the rest of the stack like vrf or ip vlan mode to resolve. A user may also set manual entry without explicit ARP.
I think it was just a mistake to use NOARP this way in RDMA, I looked in the git history and there was no justification. That or it was right in the 2.x days and netdev moved on to the current schem.
I expect to just call the neighbor functions and if they can't work for some reason they should fail?
Jason
Re: [PATCH 2/4] RDMA/core: Resolve MAC of next-hop device without ARP support
Quoted 8 lines · Jason Gunthorpe
Quoted 7 lines · Parav Pandit
Quoted 5 lines
Quoted 1 line
This leads to incorrect behavior and may result in packet transmission
failures.
Quoted 2 lines
Fix this by deferring MAC resolution to the IP stack via neighbour lookup, allowing proper resolution or error reporting as appropriate.
What is the difference here? For IPv4, neighbour lookup is ARP, no?
It is but it is not the only way. A device may not do ARP by itself but it relies on the rest of the stack like vrf or ip vlan mode to resolve. A user may also set manual entry without explicit ARP.
Quoted 8 lines
I think it was just a mistake to use NOARP this way in RDMA, I looked in the git history and there was no justification. That or it was right in the 2.x days and netdev moved on to the current schem.
I expect to just call the neighbor functions and if they can't work for some reason they should fail?
Jason
Right. This is the patch does, to rely on the neighbour functions to resolve without depending on the NOARP.
PATCH 3/4 RDMA/core: Use route entry flag to decide on loopback traffic
In reply to Edward SroujiFrom: Parav Pandit <[email protected]>
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.
--- drivers/infiniband/core/addr.c | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-)
drivers/infiniband/core/addr.c +21 -13
@@ -446,31 +446,40 @@ static int addr6_resolve(struct sockaddr *src_sock, }#endif +static bool is_dst_local (const struct dst_entry *dst) +{ +if (dst->ops->family ==AF_INET ) +return !!(dst_rtable (dst)->rt_type &RTN_LOCAL ); +else if (dst->ops->family ==AF_INET6 ) +return !!(dst_rt6_info (dst)->rt6i_flags &RTF_LOCAL ); +else +return false; +} +static int addr_resolve_neigh (const struct dst_entry *dst,const struct sockaddr *dst_in,struct rdma_dev_addr *addr, -unsigned int ndev_flags,u32 seq) { -int ret =0 ; - -if (ndev_flags &IFF_LOOPBACK ) +if (is_dst_local (dst)) { +/* When the destination is local entry, source and destination +* are same. Skip the neighbour lookup. +*/ memcpy (addr->dst_dev_addr, addr->src_dev_addr,MAX_ADDR_LEN ); -else - ret =fetch_ha (dst, addr, dst_in, seq); -return ret; +return 0 ; + } + +return fetch_ha (dst, addr, dst_in, seq); }static int rdma_set_src_addr_rcu (struct rdma_dev_addr *dev_addr, -unsigned int *ndev_flags,const struct sockaddr *dst_in,const struct dst_entry *dst) {struct net_device *ndev =READ_ONCE (dst->dev); - *ndev_flags = ndev->flags;/* A physical device must be the RDMA device to use */ -if (ndev->flags &IFF_LOOPBACK ) { +if (is_dst_local (dst)) {int ret;/* * RDMA (IB/RoCE, iWarp) doesn't run on lo interface or
@@ -538,7 +547,6 @@ static int addr_resolve(struct sockaddr *src_in, u32 seq) {struct dst_entry *dst =NULL ; -unsigned int ndev_flags =0 ;struct rtable *rt =NULL ;int ret;
@@ -575,7 +583,7 @@ static int addr_resolve(struct sockaddr *src_in,rcu_read_unlock (); goto done; } - ret =rdma_set_src_addr_rcu (addr, &ndev_flags, dst_in, dst); + ret =rdma_set_src_addr_rcu (addr, dst_in, dst);rcu_read_unlock ();/*
@@ -583,7 +591,7 @@ static int addr_resolve(struct sockaddr *src_in,* only if src addr translation didn't fail. */ if (!ret && resolve_neigh) - ret =addr_resolve_neigh (dst, dst_in, addr, ndev_flags, seq); + ret =addr_resolve_neigh (dst, dst_in, addr, seq);if (src_in->sa_family ==AF_INET )ip_rt_put (rt);
Signature · 1 line
2.21.3
PATCH 4/4 IB/ipoib: Ignore L3 master device
In reply to Edward SroujiFrom: Vlad Dumitrescu <[email protected]>
Currently, all master upper netdevices (e.g., bond, VRF) are treated equally.
When a VRF netdevice is used over an IPoIB netdevice, the expected netdev resolution is on the lower IPoIB device which has the IP address assigned to it and not the VRF device.
The rdma_cm module (CMA) tries to match incoming requests to a particular netdevice. When successful, it also validates that the return path points to the same device by performing a routing table lookup. Currently, the former would resolve to the VRF netdevice, while the latter to the correct lower IPoIB netdevice, leading to failure in rdma_cm.
Improve this by ignoring the VRF master netdevice, if it exists, and instead return the lower IPoIB device.
--- drivers/infiniband/ulp/ipoib/ipoib_main.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-)
drivers/infiniband/ulp/ipoib/ipoib_main.c +11 -10
@@ -351,26 +351,27 @@ static bool ipoib_is_dev_match_addr_rcu(const struct sockaddr *addr, }/* -* Find the master net_device on top of the given net_device. +* Find the L2 master net_device on top of the given net_device. * @dev: base IPoIB net_device * -* Returns the master net_device with a reference held, or the same net_device -* if no master exists. +* Returns the L2 master net_device with reference held if the L2 master +* exists (such as bond netdevice), or returns same netdev with reference +* held when master does not exist or when L3 master (such as VRF netdev). */ static struct net_device *ipoib_get_master_net_dev (struct net_device *dev) {struct net_device *master;rcu_read_lock (); + master =netdev_master_upper_dev_get_rcu (dev); +if (!master ||netif_is_l3_master (master)) + master = dev; +dev_hold (master);rcu_read_unlock (); -if (master) -return master; - -dev_hold (dev); -return dev; +return master; }struct ipoib_walk_data {
@@ -522,7 +523,7 @@ static struct net_device *ipoib_get_net_dev_by_params(if (ret)return NULL ; -/* See if we can find a unique device matching the L2 parameters */ +/* See if we can find a unique device matching the pkey and GID */ matches =__ipoib_get_net_dev_by_params (dev_list, port, pkey_index, gid,NULL , &net_dev);
@@ -535,7 +536,7 @@ static struct net_device *ipoib_get_net_dev_by_params(dev_put (net_dev); -/* Couldn't find a unique device with L2 parameters only. Use L3 +/* Couldn't find a unique device with pkey and GID only. Use L3 * address to uniquely match the net device */ matches =__ipoib_get_net_dev_by_params (dev_list, port, pkey_index, gid, addr, &net_dev);
Signature · 1 line
2.21.3
cover Fix local destination address resolution with VRF
In reply to Edward SroujiFrom 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/[email protected]/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(-)
Signature · 1 line
2.21.3
PATCH 1/4 RDMA/core: Squash a single user static function
From: Parav Pandit <[email protected]>
To reduce dependencies in IFF_LOOPBACK in route and neighbour resolution steps, squash the static function to its single caller and simplify the code.
Until now, network field was set even when neighbour resolution failed. With this change, dev_addr output fields are valid only when resolution is successful.
--- drivers/infiniband/core/addr.c | 49 ++++++++++++++-------------------- 1 file changed, 20 insertions(+), 29 deletions(-)
drivers/infiniband/core/addr.c +20 -29
@@ -465,34 +465,6 @@ static int addr_resolve_neigh(const struct dst_entry *dst,return ret; } -static int copy_src_l2_addr (struct rdma_dev_addr *dev_addr, -const struct sockaddr *dst_in, -const struct dst_entry *dst, -const struct net_device *ndev) -{ -int ret =0 ; - -if (dst->dev->flags &IFF_LOOPBACK ) - ret =rdma_translate_ip (dst_in, dev_addr); -else -rdma_copy_src_l2_addr (dev_addr, dst->dev); - -/* -* If there's a gateway and type of device not ARPHRD_INFINIBAND, -* we're definitely in RoCE v2 (as RoCE v1 isn't routable) set the -* network type accordingly. -*/ -if (has_gateway (dst, dst_in->sa_family) && - ndev->type !=ARPHRD_INFINIBAND ) - dev_addr->network = dst_in->sa_family ==AF_INET ? -RDMA_NETWORK_IPV4 : -RDMA_NETWORK_IPV6 ; -else - dev_addr->network =RDMA_NETWORK_IB ; - -return ret; -} - static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, unsigned int *ndev_flags, const struct sockaddr *dst_in,
@@ -503,6 +475,7 @@ static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, *ndev_flags = ndev->flags;/* A physical device must be the RDMA device to use */ if (ndev->flags &IFF_LOOPBACK ) { +int ret;/* * RDMA (IB/RoCE, iWarp) doesn't run on lo interface or * loopback IP address. So if route is resolved to loopback
@@ -512,9 +485,27 @@ static int rdma_set_src_addr_rcu(struct rdma_dev_addr *dev_addr, ndev =rdma_find_ndev_for_src_ip_rcu (dev_net (ndev), dst_in);if (IS_ERR (ndev))return -ENODEV ; + ret =rdma_translate_ip (dst_in, dev_addr); +if (ret) +return ret; + }else { +rdma_copy_src_l2_addr (dev_addr, dst->dev); } -return copy_src_l2_addr (dev_addr, dst_in, dst, ndev); +/* +* If there's a gateway and type of device not ARPHRD_INFINIBAND, +* we're definitely in RoCE v2 (as RoCE v1 isn't routable) set the +* network type accordingly. +*/ +if (has_gateway (dst, dst_in->sa_family) && + ndev->type !=ARPHRD_INFINIBAND ) + dev_addr->network = dst_in->sa_family ==AF_INET ? +RDMA_NETWORK_IPV4 : +RDMA_NETWORK_IPV6 ; +else + dev_addr->network =RDMA_NETWORK_IB ; + +return 0 ; }static int set_addr_netns_by_gid_rcu (struct rdma_dev_addr *addr)
Signature · 1 line
2.21.3
PATCH 2/4 RDMA/core: Resolve MAC of next-hop device without ARP support
In reply to Edward SroujiFrom: Parav Pandit <[email protected]>
Currently, if the next-hop netdevice does not support ARP resolution, the destination MAC address is silently set to zero without reporting an error. This leads to incorrect behavior and may result in packet transmission failures.
Fix this by deferring MAC resolution to the IP stack via neighbour lookup, allowing proper resolution or error reporting as appropriate.
--- drivers/infiniband/core/addr.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-)
drivers/infiniband/core/addr.c +3 -7
@@ -454,14 +454,10 @@ static int addr_resolve_neigh(const struct dst_entry *dst, {int ret =0 ; -if (ndev_flags &IFF_LOOPBACK ) { +if (ndev_flags &IFF_LOOPBACK )memcpy (addr->dst_dev_addr, addr->src_dev_addr,MAX_ADDR_LEN ); - }else { -if (!(ndev_flags &IFF_NOARP )) { -/* If the device doesn't do ARP internally */ - ret =fetch_ha (dst, addr, dst_in, seq); - } - } +else + ret =fetch_ha (dst, addr, dst_in, seq);return ret; }
Signature · 1 line
2.21.3
PATCH 3/4 RDMA/core: Use route entry flag to decide on loopback traffic
In reply to Edward SroujiFrom: Parav Pandit <[email protected]>
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.
--- drivers/infiniband/core/addr.c | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-)
drivers/infiniband/core/addr.c +21 -13
@@ -446,31 +446,40 @@ static int addr6_resolve(struct sockaddr *src_sock, }#endif +static bool is_dst_local (const struct dst_entry *dst) +{ +if (dst->ops->family ==AF_INET ) +return !!(dst_rtable (dst)->rt_type &RTN_LOCAL ); +else if (dst->ops->family ==AF_INET6 ) +return !!(dst_rt6_info (dst)->rt6i_flags &RTF_LOCAL ); +else +return false; +} +static int addr_resolve_neigh (const struct dst_entry *dst,const struct sockaddr *dst_in,struct rdma_dev_addr *addr, -unsigned int ndev_flags,u32 seq) { -int ret =0 ; - -if (ndev_flags &IFF_LOOPBACK ) +if (is_dst_local (dst)) { +/* When the destination is local entry, source and destination +* are same. Skip the neighbour lookup. +*/ memcpy (addr->dst_dev_addr, addr->src_dev_addr,MAX_ADDR_LEN ); -else - ret =fetch_ha (dst, addr, dst_in, seq); -return ret; +return 0 ; + } + +return fetch_ha (dst, addr, dst_in, seq); }static int rdma_set_src_addr_rcu (struct rdma_dev_addr *dev_addr, -unsigned int *ndev_flags,const struct sockaddr *dst_in,const struct dst_entry *dst) {struct net_device *ndev =READ_ONCE (dst->dev); - *ndev_flags = ndev->flags;/* A physical device must be the RDMA device to use */ -if (ndev->flags &IFF_LOOPBACK ) { +if (is_dst_local (dst)) {int ret;/* * RDMA (IB/RoCE, iWarp) doesn't run on lo interface or
@@ -538,7 +547,6 @@ static int addr_resolve(struct sockaddr *src_in, u32 seq) {struct dst_entry *dst =NULL ; -unsigned int ndev_flags =0 ;struct rtable *rt =NULL ;int ret;
@@ -575,7 +583,7 @@ static int addr_resolve(struct sockaddr *src_in,rcu_read_unlock (); goto done; } - ret =rdma_set_src_addr_rcu (addr, &ndev_flags, dst_in, dst); + ret =rdma_set_src_addr_rcu (addr, dst_in, dst);rcu_read_unlock ();/*
@@ -583,7 +591,7 @@ static int addr_resolve(struct sockaddr *src_in,* only if src addr translation didn't fail. */ if (!ret && resolve_neigh) - ret =addr_resolve_neigh (dst, dst_in, addr, ndev_flags, seq); + ret =addr_resolve_neigh (dst, dst_in, addr, seq);if (src_in->sa_family ==AF_INET )ip_rt_put (rt);
Signature · 1 line
2.21.3
PATCH 4/4 IB/ipoib: Ignore L3 master device
In reply to Edward SroujiFrom: Vlad Dumitrescu <[email protected]>
Currently, all master upper netdevices (e.g., bond, VRF) are treated equally.
When a VRF netdevice is used over an IPoIB netdevice, the expected netdev resolution is on the lower IPoIB device which has the IP address assigned to it and not the VRF device.
The rdma_cm module (CMA) tries to match incoming requests to a particular netdevice. When successful, it also validates that the return path points to the same device by performing a routing table lookup. Currently, the former would resolve to the VRF netdevice, while the latter to the correct lower IPoIB netdevice, leading to failure in rdma_cm.
Improve this by ignoring the VRF master netdevice, if it exists, and instead return the lower IPoIB device.
--- drivers/infiniband/ulp/ipoib/ipoib_main.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-)
drivers/infiniband/ulp/ipoib/ipoib_main.c +11 -10
@@ -351,26 +351,27 @@ static bool ipoib_is_dev_match_addr_rcu(const struct sockaddr *addr, }/* -* Find the master net_device on top of the given net_device. +* Find the L2 master net_device on top of the given net_device. * @dev: base IPoIB net_device * -* Returns the master net_device with a reference held, or the same net_device -* if no master exists. +* Returns the L2 master net_device with reference held if the L2 master +* exists (such as bond netdevice), or returns same netdev with reference +* held when master does not exist or when L3 master (such as VRF netdev). */ static struct net_device *ipoib_get_master_net_dev (struct net_device *dev) {struct net_device *master;rcu_read_lock (); + master =netdev_master_upper_dev_get_rcu (dev); +if (!master ||netif_is_l3_master (master)) + master = dev; +dev_hold (master);rcu_read_unlock (); -if (master) -return master; - -dev_hold (dev); -return dev; +return master; }struct ipoib_walk_data {
@@ -522,7 +523,7 @@ static struct net_device *ipoib_get_net_dev_by_params(if (ret)return NULL ; -/* See if we can find a unique device matching the L2 parameters */ +/* See if we can find a unique device matching the pkey and GID */ matches =__ipoib_get_net_dev_by_params (dev_list, port, pkey_index, gid,NULL , &net_dev);
@@ -535,7 +536,7 @@ static struct net_device *ipoib_get_net_dev_by_params(dev_put (net_dev); -/* Couldn't find a unique device with L2 parameters only. Use L3 +/* Couldn't find a unique device with pkey and GID only. Use L3 * address to uniquely match the net device */ matches =__ipoib_get_net_dev_by_params (dev_list, port, pkey_index, gid, addr, &net_dev);
Signature · 1 line
2.21.3
Quoted 43 lines · Edward Srouji
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 andib_write_bwtimes 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 interfacesParav.
---
Changelog:
v0 -> v1:
- Addressed comments from Leon
- Updated commit message to reflect thatdev_addrfields are invalid in case of failure in PATCH 1/4
- Removed incorrect commit log about 'no functional change' in PATCH 1/4v0: https://lore-kernel.gnuweeb.org/lkml/[email protected]/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
Quoted 6 lines
Vlad Dumitrescu (1):
IB/ipoib: Ignore L3 master devicedrivers/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
Quoted 4 lines
Signature · 2 lines
-- 2.21.3