netdev - Re: [PATCH v4 0/6] Add Auxiliary driver support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACZ4nhsv4zyzANrGh90WGKORz0Su=i7+Jmsk6nWoOq4or7Y0=Q@mail.gmail.com>
Date:   Tue, 22 Nov 2022 07:02:45 -0800
From:   Ajit Khaparde <ajit.khaparde@...adcom.com>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     andrew.gospodarek@...adcom.com, davem@...emloft.net,
        edumazet@...gle.com, jgg@...pe.ca, kuba@...nel.org,
        linux-kernel@...r.kernel.org, linux-rdma@...r.kernel.org,
        michael.chan@...adcom.com, netdev@...r.kernel.org,
        pabeni@...hat.com, selvin.xavier@...adcom.com
Subject: Re: [PATCH v4 0/6] Add Auxiliary driver support

On Wed, Nov 16, 2022 at 5:22 AM Leon Romanovsky <leon@...nel.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. 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::

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4218 bytes)