From: Leon Romanovsky <leon@kernel.org>
To: Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: andrew.gospodarek@broadcom.com, davem@davemloft.net,
edumazet@google.com, jgg@ziepe.ca, kuba@kernel.org,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
michael.chan@broadcom.com, netdev@vger.kernel.org,
pabeni@redhat.com, selvin.xavier@broadcom.com
Subject: Re: [PATCH v4 0/6] Add Auxiliary driver support
Date: Wed, 23 Nov 2022 08:58:53 +0200 [thread overview]
Message-ID: <Y33ErZHAsX76y34Z@unreal> (raw)
In-Reply-To: <CACZ4nhsv4zyzANrGh90WGKORz0Su=i7+Jmsk6nWoOq4or7Y0=Q@mail.gmail.com>
On Tue, Nov 22, 2022 at 07:02:45AM -0800, Ajit Khaparde wrote:
> On Wed, Nov 16, 2022 at 5:22 AM Leon Romanovsky <leon@kernel.org> wrote:
> >
> ::snip::
> > > > All PCI management logic and interfaces are needed to be inside eth part
> > > > of your driver and only that part should implement SR-IOV config. Once
> > > > user enabled SR-IOV, the PCI driver should create auxiliary devices for
> > > > each VF. These device will have RDMA capabilities and it will trigger RDMA
> > > > driver to bind to them.
> > > I agree and once the PF creates the auxiliary devices for the VF, the RoCE
> > > Vf indeed get probed and created. But the twist in bnxt_en/bnxt_re
> > > design is that
> > > the RoCE driver is responsible for making adjustments to the RoCE resources.
> >
> > You can still do these adjustments by checking type of function that
> > called to RDMA .probe. PCI core exposes some functions to help distinguish between
> > PF and VFs.
> >
> > >
> > > So once the VF's are created and the bnxt_en driver enables SRIOV adjusts the
> > > NIC resources for the VF, and such, it tries to call into the bnxt_re
> > > driver for the
> > > same purpose.
> >
> > If I read code correctly, all these resources are for one PCI function.
> >
> > Something like this:
> >
> > bnxt_re_probe()
> > {
> > ...
> > if (is_virtfn(p))
> > bnxt_re_sriov_config(p);
> > ...
> > }
> I understand what you are suggesting.
> But what I want is a way to do this in the context of the PF
> preferably before the VFs are probed.
I don't understand the last sentence. You call to this sriov_config in
bnxt_re driver without any protection from VFs being probed,
> So we are trying to call the
> bnxt_re_sriov_config in the context of handling the PF's
> sriov_configure implementation. Having the ulp_ops is allowing us to
> avoid resource wastage and assumptions in the bnxt_re driver.
To which resource wastage are you referring?
There are no differences if same limits will be in bnxt_en driver when
RDMA bnxt device is created or in bnxt_re which will be called once RDMA
device is created.
Thanks
>
> ::snip::
next prev parent reply other threads:[~2022-11-23 6:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 18:42 [PATCH v4 0/6] Add Auxiliary driver support Ajit Khaparde
2022-11-09 18:42 ` [PATCH v4 1/6] bnxt_en: Add auxiliary " Ajit Khaparde
2022-11-09 18:42 ` [PATCH v4 2/6] RDMA/bnxt_re: Use auxiliary driver interface Ajit Khaparde
2022-11-09 18:42 ` [PATCH v4 3/6] bnxt_en: Remove usage of ulp_id Ajit Khaparde
2022-11-09 18:42 ` [PATCH v4 4/6] bnxt_en: Use direct API instead of indirection Ajit Khaparde
2022-11-09 18:42 ` [PATCH v4 5/6] bnxt_en: Use auxiliary bus calls over proprietary calls Ajit Khaparde
2022-11-09 18:42 ` [PATCH v4 6/6] bnxt_en: Remove struct bnxt access from RoCE driver Ajit Khaparde
2022-11-10 10:53 ` [PATCH v4 0/6] Add Auxiliary driver support Leon Romanovsky
2022-11-15 0:47 ` Ajit Khaparde
2022-11-16 13:22 ` Leon Romanovsky
2022-11-22 15:02 ` Ajit Khaparde
2022-11-23 6:58 ` Leon Romanovsky [this message]
2022-11-29 2:01 ` Ajit Khaparde
2022-11-29 9:13 ` Leon Romanovsky
2022-12-07 17:49 ` Ajit Khaparde
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=Y33ErZHAsX76y34Z@unreal \
--to=leon@kernel.org \
--cc=ajit.khaparde@broadcom.com \
--cc=andrew.gospodarek@broadcom.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jgg@ziepe.ca \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 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).