mbox series

[for-next,V2,0/3] RDMA/bnxt_re: driver update

Message ID 1544608584-30998-1-git-send-email-selvin.xavier@broadcom.com (mailing list archive)
Headers show
Series RDMA/bnxt_re: driver update | expand

Message

Selvin Xavier Dec. 12, 2018, 9:56 a.m. UTC
This is the bnxt_re driver update for next feature
cycle. This series includes changes to support bigger MR
and increasing the Control path command Queue depth. Also
a patch to query the HW interface version for driver/fw
compatibility check is included.

Changelog:
v1 -> v2:
 	- Dropped the refactor patch which involve the usage of rtnl_lock.
          This will be reworked based on the comments from Jason and will be
          pushed as a separate series.
        - Changed some of the macro definitions to inline functions

Devesh Sharma (1):
  RDMA/bnxt_re: Increase depth of control path command queue

Selvin Xavier (1):
  RDMA/bnxt_re: bnxt_re: Query HWRM Interface version from FW

Somnath Kotur (1):
  RDMA/bnxt_re: Increase memory registration size of a single MR

 drivers/infiniband/hw/bnxt_re/bnxt_re.h    |  3 ++
 drivers/infiniband/hw/bnxt_re/ib_verbs.c   | 24 +++++-------
 drivers/infiniband/hw/bnxt_re/main.c       | 32 ++++++++++++++++
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.c | 34 +++++++++++------
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.h | 59 +++++++++++++++++++++++-------
 drivers/infiniband/hw/bnxt_re/qplib_res.c  | 54 +++++++++++++++++++++++----
 drivers/infiniband/hw/bnxt_re/qplib_res.h  |  5 ++-
 drivers/infiniband/hw/bnxt_re/qplib_sp.c   |  8 ++--
 8 files changed, 165 insertions(+), 54 deletions(-)

Comments

Jason Gunthorpe Dec. 19, 2018, 11:42 p.m. UTC | #1
On Wed, Dec 12, 2018 at 01:56:21AM -0800, Selvin Xavier wrote:

> Devesh Sharma (1):
>   RDMA/bnxt_re: Increase depth of control path command queue
> 
> Selvin Xavier (1):
>   RDMA/bnxt_re: bnxt_re: Query HWRM Interface version from FW

I applied these two patches to for-next, thanks.
 
> Somnath Kotur (1):
>   RDMA/bnxt_re: Increase memory registration size of a single MR

I still don't like this one. Please work with Shiraz on his series:

https://patchwork.kernel.org/project/linux-rdma/list/?series=33335&state=*

Such that the core can tell the driver how many pages required and
provide the needed multi-page size aggragetion API and so forth.

vmallocing another buffer when the core code already alloced a buffer
just to count the pages is really ugly.

That should allow this driver to make use of all its HW capability.

Jason