[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6d589863-1eba-46dc-a9ff-905d5380cd53@linux.dev>
Date: Thu, 6 Mar 2025 11:24:08 +0100
From: Zhu Yanjun <yanjun.zhu@...ux.dev>
To: Stephen Rothwell <sfr@...b.auug.org.au>,
Doug Ledford <dledford@...hat.com>, Jason Gunthorpe <jgg@...lanox.com>
Cc: Leon Romanovsky <leon@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the rdma tree with the rdma-fixes
tree
Hi, Stephen
I am the author of the commit 8ce2eb9dfac8 ("RDMA/rxe: Fix the failure
of ibv_query_device() and ibv_query_device_ex() tests").
My replies are inline. Thanks a lot.
"
diff --cc drivers/infiniband/sw/rxe/rxe.c
index e27478fe9456,4e56a371deb5..000000000000
--- a/drivers/infiniband/sw/rxe/rxe.c
+++ b/drivers/infiniband/sw/rxe/rxe.c
@@@ -72,10 -71,45 +69,39 @@@ static void rxe_init_device_param(struc
rxe->attr.max_pkeys = RXE_MAX_PKEYS;
rxe->attr.local_ca_ack_delay = RXE_LOCAL_CA_ACK_DELAY;
- ndev = rxe_ib_device_get_netdev(&rxe->ib_dev);
- if (!ndev)
- return;
-
+ if (ndev->addr_len) {
+ memcpy(rxe->raw_gid, ndev->dev_addr,
+ min_t(unsigned int, ndev->addr_len, ETH_ALEN));
+ } else {
+ /*
+ * This device does not have a HW address, but
+ * connection mangagement requires a unique gid.
+ */
+ eth_random_addr(rxe->raw_gid);
+ }
+
addrconf_addr_eui48((unsigned char *)&rxe->attr.sys_image_guid,
- ndev->dev_addr);
+ rxe->raw_gid);
- dev_put(ndev);
-
------The above snippet is fine with me.
rxe->max_ucontext = RXE_MAX_UCONTEXT;
+
+ if (IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING)) {
+ rxe->attr.kernel_cap_flags |= IBK_ON_DEMAND_PAGING;
+
+ /* IB_ODP_SUPPORT_IMPLICIT is not supported right now. */
+ rxe->attr.odp_caps.general_caps |= IB_ODP_SUPPORT;
+
+ rxe->attr.odp_caps.per_transport_caps.ud_odp_caps |=
IB_ODP_SUPPORT_SEND;
+ rxe->attr.odp_caps.per_transport_caps.ud_odp_caps |=
IB_ODP_SUPPORT_RECV;
+ rxe->attr.odp_caps.per_transport_caps.ud_odp_caps |=
IB_ODP_SUPPORT_SRQ_RECV;
+
+ rxe->attr.odp_caps.per_transport_caps.rc_odp_caps |=
IB_ODP_SUPPORT_SEND;
+ rxe->attr.odp_caps.per_transport_caps.rc_odp_caps |=
IB_ODP_SUPPORT_RECV;
+ rxe->attr.odp_caps.per_transport_caps.rc_odp_caps |=
IB_ODP_SUPPORT_WRITE;
+ rxe->attr.odp_caps.per_transport_caps.rc_odp_caps |=
IB_ODP_SUPPORT_READ;
+ rxe->attr.odp_caps.per_transport_caps.rc_odp_caps |=
IB_ODP_SUPPORT_ATOMIC;
+ rxe->attr.odp_caps.per_transport_caps.rc_odp_caps |=
IB_ODP_SUPPORT_SRQ_RECV;
+ }
}
---------The above snippet is from on_demand paging commits. I do not
why it is involved in this commit.
---------It should appear in on_demand_paging patchset.
/* initialize port attributes */
@@@ -107,13 -141,18 +133,13 @@@ static void rxe_init_port_param(struct
/* initialize port state, note IB convention that HCA ports are always
* numbered from 1
*/
-static void rxe_init_ports(struct rxe_dev *rxe)
+static void rxe_init_ports(struct rxe_dev *rxe, struct net_device *ndev)
----------In this snippet, the variable "struct net_device *ndev" is not
used in the function rxe_init_ports, it should be removed.
----------Thanks a lot.
Zhu Yanjun
{
struct rxe_port *port = &rxe->port;
- struct net_device *ndev;
rxe_init_port_param(port);
- ndev = rxe_ib_device_get_netdev(&rxe->ib_dev);
- if (!ndev)
- return;
addrconf_addr_eui48((unsigned char *)&port->port_guid,
- ndev->dev_addr);
+ rxe->raw_gid);
- dev_put(ndev);
spin_lock_init(&port->port_lock);
}
"
On 06.03.25 02:37, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> drivers/infiniband/sw/rxe/rxe.c
>
> between commit:
>
> 8ce2eb9dfac8 ("RDMA/rxe: Fix the failure of ibv_query_device() and ibv_query_device_ex() tests")
>
> from the rdma-fixes tree and commit:
>
> d34d0bdb500e ("RDMA/rxe: Replace netdev dev addr with raw_gid")
>
> from the rdma tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
--
Best Regards,
Yanjun.Zhu
Powered by blists - more mailing lists