All of lore.kernel.org
 help / color / mirror / Atom feed
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::



  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 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.