On 02-Apr-19 21:29, Leon Romanovsky wrote: > On Mon, Apr 01, 2019 at 05:19:30PM +0300, Gal Pressman wrote: >> On 01-Apr-19 16:35, Leon Romanovsky wrote: >>> On Mon, Apr 01, 2019 at 03:07:09PM +0300, Gal Pressman wrote: >>>> On 01-Apr-19 11:47, Leon Romanovsky wrote: >>>>> From: Mark Zhang <markz@xxxxxxxxxxxx> >>>>> >>>>> In auto mode all QPs belong to one category are bind automatically to >>>>> a single counter set. Currently only "qp type" is supported. >>>>> >>>>> In this mode the qp counter is set in RST2INIT modification, and when >>>>> a qp is destroyed the counter is unbound. >>>> >>>> This seems like a strange lifetime choice, why set it on RST2INIT and not on >>>> creation? Isn't that very tied to mlx5 implementation? >>> >>> It is our attempt to delay depletion of HW objects (counters). They are >>> limited in number and change RST2INIT means that this QP was enabled. >> >> We can leave it to the individual driver to decide when to do the actual hw >> allocation, it's better than the core forcing all drivers to do it on QP >> modification. > > Other drivers cal allocate counter whenever they want, in RST2INIT they > actually connected. The bind (on the software level) should happen when the object (QP) is allocated, if mlx5 driver wants to do the hardware bind on RST2INIT that can be solved inside the driver. Mark that the QP has a counter bind on create and delay the operation to mlx5_ib_modify_qp. Don't make the core force it for everyone.
