From: Leon Romanovsky <leon@kernel.org>
To: Selvin Xavier <selvin.xavier@broadcom.com>
Cc: Michael Chan <michael.chan@broadcom.com>,
jgg@ziepe.ca, linux-rdma@vger.kernel.org,
andrew.gospodarek@broadcom.com,
kalesh-anakkur.purayil@broadcom.com
Subject: Re: [rdma-next 5/5] RDMA/bnxt_re: Add new function to setup NQs
Date: Tue, 12 Nov 2024 12:34:29 +0200 [thread overview]
Message-ID: <20241112103429.GK71181@unreal> (raw)
In-Reply-To: <CA+sbYW2BAUXLyk0Fa_hmXoQ1e7Ocmj-jw41JNBmjJQupimaD8Q@mail.gmail.com>
On Tue, Nov 12, 2024 at 02:55:12PM +0530, Selvin Xavier wrote:
> +Michael Chan
>
> On Tue, Nov 12, 2024 at 1:47 PM Leon Romanovsky <leon@kernel.org> wrote:
> >
> > On Fri, Nov 08, 2024 at 12:42:39AM -0800, Selvin Xavier wrote:
> > > From: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
> > >
> > > Move the logic to setup and enable NQs to a new function.
> > > Similarly moved the NQ cleanup logic to a common function.
> > > Introdued a flag to keep track of NQ allocation status
> > > and added sanity checks inside bnxt_re_stop_irq() and
> > > bnxt_re_start_irq() to avoid possible race conditions.
> > >
> > > Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
> > > Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
> > > ---
> > > drivers/infiniband/hw/bnxt_re/bnxt_re.h | 2 +
> > > drivers/infiniband/hw/bnxt_re/main.c | 204 +++++++++++++++++++-------------
> > > 2 files changed, 123 insertions(+), 83 deletions(-)
> >
> > <...>
> >
> > >
> > > + rtnl_lock();
> > > + if (test_and_clear_bit(BNXT_RE_FLAG_SETUP_NQ, &rdev->flags))
> > > + bnxt_re_clean_nqs(rdev);
> > > + rtnl_unlock();
> >
> > <...>
> >
> > > + rtnl_lock();
> > > bnxt_qplib_free_ctx(&rdev->qplib_res, &rdev->qplib_ctx);
> > > bnxt_qplib_disable_rcfw_channel(&rdev->rcfw);
> > > type = bnxt_qplib_get_ring_type(rdev->chip_ctx);
> > > bnxt_re_net_ring_free(rdev, rdev->rcfw.creq.ring_id, type);
> > > + rtnl_unlock();
> >
> > Please don't add rtnl_lock() to drivers in RDMA subsystem. BNXT driver
> > is managed through netdev and it is there all proper locking should be
> > done.
> The main reason for bnxt_re to take the rtnl is because of the MSIx
> resource configuration.
> This is because the NIC driver is dynamically modifying the MSIx table
> when the number
> of ring change or ndo->open/close is invoked. So we stop and restart
> the interrupts of RoCE also with rtnl held.
rtnl_lock is a big kernel lock, which blocks almost everything in the netdev.
In your case, you are changing one device configuration and should use
your per-device locks. Even in the system with more than one BNXT device,
the MSI-X on one device will influence other "innocent" devices.
> >
> > Please work to remove existing rtnl_lock() from bnxt_re_update_en_info_rdev() too.
> > IMHO that lock is not needed after your driver conversion to auxbus.
> This check is also to synchronize between the irq_stop and restart
> implementation between
> bnxt_en and bnxt_re driver and roce driver unload.
>
> We will review this locking and see if we can handle it. But it is a
> major design change in both L2
> and roce drivers.
You are adding new rtnl_lock and not moving it from one place to
another, so this redesign should be done together with this new
feature.
Thanks
> >
> > Thanks
next prev parent reply other threads:[~2024-11-12 10:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 8:42 [rdma-next 0/5] RDMA/bnxt_re: Refactor Notification queue allocation Selvin Xavier
2024-11-08 8:42 ` [rdma-next 1/5] RDMA/bnxt_re: Fail probe early when not enough MSI-x vectors are reserved Selvin Xavier
2024-11-08 8:42 ` [rdma-next 2/5] RDMA/bnxt_re: Refactor NQ allocation Selvin Xavier
2024-11-08 8:42 ` [rdma-next 3/5] RDMA/bnxt_re: Refurbish CQ to NQ hash calculation Selvin Xavier
2024-11-08 8:42 ` [rdma-next 4/5] RDMA/bnxt_re: Cache MSIx info to a local structure Selvin Xavier
2024-11-08 8:42 ` [rdma-next 5/5] RDMA/bnxt_re: Add new function to setup NQs Selvin Xavier
2024-11-12 8:17 ` Leon Romanovsky
2024-11-12 9:25 ` Selvin Xavier
2024-11-12 10:34 ` Leon Romanovsky [this message]
2024-11-13 5:44 ` Selvin Xavier
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=20241112103429.GK71181@unreal \
--to=leon@kernel.org \
--cc=andrew.gospodarek@broadcom.com \
--cc=jgg@ziepe.ca \
--cc=kalesh-anakkur.purayil@broadcom.com \
--cc=linux-rdma@vger.kernel.org \
--cc=michael.chan@broadcom.com \
--cc=selvin.xavier@broadcom.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.