On Mon, Apr 22, 2019 at 09:38:37PM +0800, oulijun wrote: > ??? 2019/4/22 20:22, Leon Romanovsky ??????: > > On Fri, Apr 19, 2019 at 03:46:32PM +0800, oulijun wrote: > >> ??? 2019/4/16 20:16, Leon Romanovsky ??????: > >>> On Sat, Apr 13, 2019 at 07:29:01PM +0800, Lijun Ou wrote: > >>>> To avoid resource unreleased while ULP aborted abnormally, > >>>> the hardware adds the capability of restoring the resource > >>>> while removing module, this patch enables this capability. > >>> Can anyone help me to understand what does it mean? > >>> How can ULP "abort" without releasing resources? > >>> > >>> Thanks > >> Maybe the commit description is not correct enough. > >> > >> The entire PATCH is to solve the following scenarios. When a function is abnormal, the hardware > >> > >> need to release the relatived hardware reource and the entire release process is the same as the flr process. > >> > >> It uses the firmware to reslove. The hw design adds a firmware cmd to clear the hardware state and judge > >> > >> the resource of hardware have freed. > >> > >> As a result, the driver need to implement this cmd. > > You explained what you are doing, but not why are you doing. > Hi, Leon > if carried out unload operation When rdma app running, the hardware is too late to release and remain in hardware. It is responsibility of disassociate flow to clean such mess and various unwind flows. > Under these circumstances, it maybe happen error if loaded hns driver and run app again. In order to reslove it, > the hardware adds a function clear function to stop this function and clear the residual hardware resources in the function. First, your initialization flow should do it always, second you need to find the root cause of resource leakage in case of application was aborted. > > Thanks. > Lijun Ou > > Thanks > > > >> Thanks > >> > >> Lijun Ou > >> > >> > > . > > > >
