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: <CACKFLi=m1jKw18p7QnZ3FV1Bg+5quQ8pt3gEYrZfmaS8+8Ptiw@mail.gmail.com>
Date: Tue, 9 Apr 2024 16:48:38 -0700
From: Michael Chan <michael.chan@...adcom.com>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com, 
	kuba@...nel.org, pabeni@...hat.com, pavan.chebbi@...adcom.com, 
	andrew.gospodarek@...adcom.com, Vikas Gupta <vikas.gupta@...adcom.com>
Subject: Re: [PATCH net-next 5/7] bnxt_en: Change MSIX/NQs allocation policy

On Tue, Apr 9, 2024 at 4:40 PM Jacob Keller <jacob.e.keller@...el.com> wrote:
>
>
>
> On 4/9/2024 2:54 PM, Michael Chan wrote:
> > From: Vikas Gupta <vikas.gupta@...adcom.com>
> >
> > The existing scheme sets aside a number of MSIX/NQs for the RoCE
> > driver whether the RoCE driver is registered or not.  This scheme
> > is not flexible and limits the resources available for the L2 rings
> > if RoCE is never used.
> >
> > Modify the scheme so that the RoCE MSIX/NQs can be used by the L2
> > driver if they are not used for RoCE.  The MSIX/NQs are now
> > represented by 3 fields.  bp->ulp_num_msix_want contains the
> > desired default value, edev->ulp_num_msix_vec contains the
> > available value (but not necessarily in use), and
> > ulp_tbl->msix_requested contains the actual value in use by RoCE.
> >
> > The L2 driver can dip into edev->ulp_num_msix_vec if necessary.
> >
> > We need to add rtnl_lock() back in bnxt_register_dev() and
> > bnxt_unregister_dev() to synchronize the MSIX usage between L2 and
> > RoCE.
> >
> > Reviewed-by: Andy Gospodarek <andrew.gospodarek@...adcom.com>
> > Signed-off-by: Vikas Gupta <vikas.gupta@...adcom.com>
> > Signed-off-by: Michael Chan <michael.chan@...adcom.com>
> > ---
>
> Whats the behavior if the L2 driver dips into this pool and then RoCE is
> enabled later?

Thanks for the review.  If the user increases the L2 rings or enables
XDP which will cause the driver to allocate a new set of XDP TX rings,
it can now use the RoCE MSIX if needed and if they are not in use.

>
> I guess RoCE would fail to get the resources it needs, but then system
> administrator could re-configure the L2 device to use fewer resources?

If the above simply reduces the RoCE MSIX, the RoCE driver can still
operate with fewer MSIX.  If the above has reduced the MSIX below the
minimum required for RoCE, then RoCE will fail to initialize.  At that
point, the user can reduce the L2 rings and reload the RoCE driver.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ