From: Leon Romanovsky <leon@kernel.org>
To: Edward Srouji <edwards@nvidia.com>
Cc: jgg@ziepe.ca, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, parav@nvidia.com,
cratiu@nvidia.com, vdumitrescu@nvidia.com, kuba@kernel.org,
tariqt@nvidia.com, mbloch@nvidia.com, gal@nvidia.com
Subject: Re: [PATCH 1/4] RDMA/core: Squash a single user static function
Date: Wed, 10 Sep 2025 11:17:35 +0300 [thread overview]
Message-ID: <20250910081735.GJ341237@unreal> (raw)
In-Reply-To: <20250907160833.56589-2-edwards@nvidia.com>
On Sun, Sep 07, 2025 at 07:08:30PM +0300, Edward Srouji wrote:
> From: Parav Pandit <parav@nvidia.com>
>
> 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.
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
>
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> Reviewed-by: Vlad Dumitrescu <vdumitrescu@nvidia.com>
> Signed-off-by: Edward Srouji <edwards@nvidia.com>
> ---
> drivers/infiniband/core/addr.c | 49 ++++++++++++++--------------------
> 1 file changed, 20 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
> index be0743dac3ff..594e7ee335f7 100644
> --- a/drivers/infiniband/core/addr.c
> +++ b/drivers/infiniband/core/addr.c
> @@ -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)
> --
> 2.21.3
>
>
next prev parent reply other threads:[~2025-09-10 8:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-07 16:08 [PATCH 0/4] Fix local destination address resolution with VRF Edward Srouji
2025-09-07 16:08 ` [PATCH 1/4] RDMA/core: Squash a single user static function Edward Srouji
2025-09-10 8:17 ` Leon Romanovsky [this message]
2025-09-10 10:51 ` Parav Pandit
2025-09-10 12:21 ` Leon Romanovsky
2025-09-07 16:08 ` [PATCH 2/4] RDMA/core: Resolve MAC of next-hop device without ARP support Edward Srouji
2025-09-10 8:32 ` Leon Romanovsky
2025-09-10 10:55 ` Parav Pandit
2025-09-15 16:30 ` Jason Gunthorpe
2025-09-15 17:16 ` Parav Pandit
2025-09-07 16:08 ` [PATCH 3/4] RDMA/core: Use route entry flag to decide on loopback traffic Edward Srouji
2025-09-07 16:08 ` [PATCH 4/4] IB/ipoib: Ignore L3 master device Edward Srouji
2025-09-16 11:10 ` [PATCH v1 0/4] Fix local destination address resolution with VRF Edward Srouji
2025-09-16 11:11 ` [PATCH v1 1/4] RDMA/core: Squash a single user static function Edward Srouji
2025-09-16 11:11 ` [PATCH v1 2/4] RDMA/core: Resolve MAC of next-hop device without ARP support Edward Srouji
2025-09-16 11:11 ` [PATCH v1 3/4] RDMA/core: Use route entry flag to decide on loopback traffic Edward Srouji
2025-09-16 11:11 ` [PATCH v1 4/4] IB/ipoib: Ignore L3 master device Edward Srouji
2025-09-18 9:24 ` [PATCH v1 0/4] Fix local destination address resolution with VRF Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250910081735.GJ341237@unreal \
--to=leon@kernel.org \
--cc=cratiu@nvidia.com \
--cc=edwards@nvidia.com \
--cc=gal@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=parav@nvidia.com \
--cc=tariqt@nvidia.com \
--cc=vdumitrescu@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.