netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Wenjia Zhang <wenjia@linux.ibm.com>
Cc: Wen Gu <guwen@linux.alibaba.com>,
	"D. Wythe" <alibuda@linux.alibaba.com>,
	Tony Lu <tonylu@linux.alibaba.com>,
	David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
	linux-s390@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
	Jan Karcher <jaka@linux.ibm.com>,
	Gerd Bayer <gbayer@linux.ibm.com>,
	Alexandra Winter <wintera@linux.ibm.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	Nils Hoppmann <niho@linux.ibm.com>,
	Niklas Schnell <schnelle@linux.ibm.com>,
	Thorsten Winkler <twinkler@linux.ibm.com>,
	Karsten Graul <kgraul@linux.ibm.com>,
	Stefan Raspl <raspl@linux.ibm.com>, Aswin K <aswin@linux.ibm.com>
Subject: Re: [PATCH net] net/smc: Fix lookup of netdev by using ib_device_get_netdev()
Date: Tue, 5 Nov 2024 15:39:55 +0200	[thread overview]
Message-ID: <20241105133955.GF311159@unreal> (raw)
In-Reply-To: <e88d6049-6be1-4967-b88d-94d437900c3d@linux.ibm.com>

On Tue, Nov 05, 2024 at 01:30:24PM +0100, Wenjia Zhang wrote:
> 
> 
> On 05.11.24 12:23, Leon Romanovsky wrote:
> > On Tue, Nov 05, 2024 at 10:50:45AM +0100, Wenjia Zhang wrote:
> > > 
> > > 
> > > On 27.10.24 21:18, Leon Romanovsky wrote:
> > > > On Fri, Oct 25, 2024 at 09:23:55AM +0200, Wenjia Zhang wrote:
> > > > > Commit c2261dd76b54 ("RDMA/device: Add ib_device_set_netdev() as an
> > > > > alternative to get_netdev") introduced an API ib_device_get_netdev.
> > > > > The SMC-R variant of the SMC protocol continued to use the old API
> > > > > ib_device_ops.get_netdev() to lookup netdev.
> > > > 
> > > > I would say that calls to ibdev ops from ULPs was never been right
> > > > thing to do. The ib_device_set_netdev() was introduced for the drivers.
> > > > 
> > > > So the whole commit message is not accurate and better to be rewritten.
> > > > 
> > > > > As this commit 8d159eb2117b
> > > > > ("RDMA/mlx5: Use IB set_netdev and get_netdev functions") removed the
> > > > > get_netdev callback from mlx5_ib_dev_common_roce_ops, calling
> > > > > ib_device_ops.get_netdev didn't work any more at least by using a mlx5
> > > > > device driver.
> > > > 
> > > > It is not a correct statement too. All modern drivers (for last 5 years)
> > > > don't have that .get_netdev() ops, so it is not mlx5 specific, but another
> > > > justification to say that SMC-R was doing it wrong.
> > > > 
> > > > > Thus, using ib_device_set_netdev() now became mandatory.
> > > > 
> > > > ib_device_set_netdev() is mandatory for the drivers, it is nothing to do
> > > > with ULPs.
> > > > 
> > > > > 
> > > > > Replace ib_device_ops.get_netdev() with ib_device_get_netdev().
> > > > 
> > > > It is too late for me to do proper review for today, but I would say
> > > > that it is worth to pay attention to multiple dev_put() calls in the
> > > > functions around the ib_device_get_netdev().
> > > > 
> > > > > 
> > > > > Fixes: 54903572c23c ("net/smc: allow pnetid-less configuration")
> > > > > Fixes: 8d159eb2117b ("RDMA/mlx5: Use IB set_netdev and get_netdev functions")
> > > > 
> > > > It is not related to this change Fixes line.
> > > > 
> > > 
> > > Hi Leon,
> > > 
> > > Thank you for the review! I agree that SMC could do better. However, we
> > > should fix it and give enough information and reference on the changes,
> > > since the code has already existed and didn't work with the old way.
> > 
> > The code which you change worked by chance and was wrong from day one.
> > 
> > > I can rewrite the commit message.
> > > 
> > > What about:
> > > "
> > > The SMC-R variant of the SMC protocol still called
> > > ib_device_ops.get_netdev() to lookup netdev. As we used mlx5 device driver
> > > to run SMC-R, it failed to find a device, because in mlx5_ib the internal
> > > net device management for retrieving net devices was replaced by a common
> > > interface ib_device_get_netdev() in commit 8d159eb2117b ("RDMA/mlx5: Use IB
> > > set_netdev and get_netdev functions"). Thus, replace
> > > ib_device_ops.get_netdev() with ib_device_get_netdev() in SMC.
> > > "
> > 
> >   The SMC-R variant of the SMC protocol used direct call to ib_device_ops.get_netdev()
> >   function to lookup netdev. Such direct accesses are not correct for any
> >   usage outside of RDMA core code.
> > 
> Is such an absolute statement documented somewhere? If not, I don't think
> it's convenient that I use it. Maybe you guys as RDMA core maintainer can,
> not I.

You can too as it is very clear. All functions which can be used have
EXPORT_SYMBOL near them, ops.get_netdev() has nothing like that.

> >   RDMA subsystem provides ib_device_get_netdev() function that works on
> >   all RDMA drivers returns valid netdev with proper locking an reference
> >   counting. The commit 8d159eb2117b ("RDMA/mlx5: Use IB set_netdev and get_netdev
> >   functions") exposed that SMC-R didn't use that function.
> > 
> >   So update the SMC-R to use proper API,
> > 
> > Thanks
> > 
> mhhh, I'd like to stick to my version, which sounds more neutral IMO. I
> think the purpose is the same.

I don't want to argue about the words, my point is that get_netdev() was
never been the right interface.

Thanks

> 
> Thanks,
> Wenjia

  reply	other threads:[~2024-11-05 13:40 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25  7:23 [PATCH net] net/smc: Fix lookup of netdev by using ib_device_get_netdev() Wenjia Zhang
2024-10-25  8:57 ` Halil Pasic
2024-10-25 14:01 ` Simon Horman
2024-10-26  0:42 ` Dust Li
2024-10-27 11:18 ` Wen Gu
2024-10-27 19:28 ` Zhu Yanjun
2024-10-27 20:18 ` Leon Romanovsky
2024-10-27 20:30   ` Leon Romanovsky
2024-11-05  9:50   ` Wenjia Zhang
2024-11-05 11:23     ` Leon Romanovsky
2024-11-05 12:30       ` Wenjia Zhang
2024-11-05 13:39         ` Leon Romanovsky [this message]
2024-11-05 14:14           ` Wenjia Zhang
2024-11-06  9:24       ` Halil Pasic
2024-11-06 13:59         ` Leon Romanovsky
2024-11-07 11:47           ` Halil Pasic
2024-11-07 12:08             ` Leon Romanovsky
2024-11-07 11:56           ` Halil Pasic
2024-11-07 12:13             ` Leon Romanovsky
2024-11-07 23:40             ` Namjae Jeon
2024-11-08 17:59               ` Leon Romanovsky
2024-11-09  5:32                 ` Namjae Jeon
2024-10-29  8:43 ` D. Wythe
2024-10-31 10:01 ` Paolo Abeni
2024-11-05  9:53   ` Wenjia Zhang

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=20241105133955.GF311159@unreal \
    --to=leon@kernel.org \
    --cc=alibuda@linux.alibaba.com \
    --cc=aswin@linux.ibm.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gbayer@linux.ibm.com \
    --cc=guwen@linux.alibaba.com \
    --cc=hca@linux.ibm.com \
    --cc=jaka@linux.ibm.com \
    --cc=kgraul@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=niho@linux.ibm.com \
    --cc=pabeni@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=raspl@linux.ibm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=tonylu@linux.alibaba.com \
    --cc=twinkler@linux.ibm.com \
    --cc=wenjia@linux.ibm.com \
    --cc=wintera@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).