On Wed, Nov 16, 2022 at 5:22 AM Leon Romanovsky <leon@xxxxxxxxxx> 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. 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.
::snip::
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
