Hi Marcin, On 5/6/19 3:31 PM, Emeric Brun wrote: > Hi Marcin, > > On 5/6/19 3:15 PM, Marcin Deranek wrote: >> Hi Emeric, >> >> On 5/3/19 5:54 PM, Emeric Brun wrote: >>> Hi Marcin, >>> >>> On 5/3/19 4:56 PM, Marcin Deranek wrote: >>>> Hi Emeric, >>>> >>>> On 5/3/19 4:50 PM, Emeric Brun wrote: >>>> >>>>> I've a testing platform here but I don't use the usdm_drv but the >>>>> qat_contig_mem and I don't reproduce this issue (I'm using QAT 1.5, as >>>>> the doc says to use with my chip) . >>>> >>>> I see. I use qat 1.7 and qat-engine 0.5.40. >>>> >>>>> Anyway, could you re-compile a haproxy's binary if I provide you a >>>>> testing patch? >>>> >>>> Sure, that should not be a problem. >>> >>> The patch in attachment. >> >> As I use HAProxy 1.8 I had to adjust the patch (see attachment for end >> result). Unfortunately after applying the patch there is no change in >> behavior: we still leak /dev/usdm_drv descriptors and have "stuck" HAProxy >> instances after reload.. >> Regards, > > > Ok, the patch adds a ENGINE_finish() call before the reload. I was supposing > that the ENGINE_finish would perform the close of the fd because on the > application side there is no different way to interact with the engine. > > Unfortunately, this is not the case. So I will ask to the intel guys what we > supposed to do to close this fd.
I've just written to my contact at intel. Just for note: I'm using hardware supported with QAT 1.5 in this version tu usdm_drv was not present and I use the other option qat_contig_mem which seems to not cause such fd leak. Perhaps to switch to this one would be a work-around if you want to continue to perform test waiting for intel's guy reply. R, Emeric
