From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) by dpdk.org (Postfix) with ESMTP id 61685293C for ; Wed, 20 Apr 2016 08:19:09 +0200 (CEST) Received: by mail-qk0-f179.google.com with SMTP id n63so11570738qkf.0 for ; Tue, 19 Apr 2016 23:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MVVJqyHWxK653s2BMrCf7y5pdrRFrLE/hsdO0Ffylm8=; b=DzhzkAryABCN6QdvLmbDQXiJrQ00/4Nt+caaZC12RkgPOsdDXHXQGbH8/u957WHnNj wEF7Gf5POebnozSkPVegCHkPT0AWb1U6xqMyp+yggTmHbSSNHz3GCvLuF8vo8kKXETIB +OpKJDmX0YGFSe93MGySMq2/kVWMz8fOKmJdzA/7MgWzytcTa1Vug3f8OzH66jZgH410 ni2WhaWWw5dCz92ngPZItyCSUHRJMfQiTQ1+7rXvQ9G0iPpo5WiSair0Br1e2aOBCh+G i2LozmN2Lc3c9tg9FjXCwHYEWqU71RYc6ZebRqZNaHHmukZPSH1p5HRwtGcJhxCRexj7 8YaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MVVJqyHWxK653s2BMrCf7y5pdrRFrLE/hsdO0Ffylm8=; b=Br/k/LTEkwtf4UFul4Z1MiClf1dSLPp/xH3xlZh8kyLfV91qCt62Gz/P2aevJT4Vll dK5gjMrcl1n0T199aX6JnkTA2EQxlWKGMjzQtqlFJtT1R4H2MzFJuczTb7a5/68G5hLg RIT1Ri+3ZXx9qG5S7UT6u28qPOZeJBfj8ZGIiWQqT1eKiK857bZ2Kf1fRNbfaHJshu/D LITkAvHms0u7Ge3gY/6sK5DftCihnva9fUGezWxXnWQgsGeqCN0c52Wdyl7KmDHUaawQ Hy4xjY8rNkJ6kfEtNMuN0Q8f0t6+IIz6I/EaAK6F5fRmw4Xqv22h+ow3dCcFS2klUAhp JDRg== X-Gm-Message-State: AOPr4FWjX2SE7prC9pJ9T+BwcurGe15FOIPIaakx9hA3uDx+9UbhV/jztvKHAcKCITP7Ol5yvbWAEOHm1BKrh3qL X-Received: by 10.55.23.196 with SMTP id 65mr8990574qkx.101.1461133148698; Tue, 19 Apr 2016 23:19:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.212.91 with HTTP; Tue, 19 Apr 2016 23:18:49 -0700 (PDT) In-Reply-To: <20160420050445.GB5872@yliu-dev.sh.intel.com> References: <20160418174650.GD2576@yliu-dev.sh.intel.com> <20160418181422.GE2576@yliu-dev.sh.intel.com> <20160420050445.GB5872@yliu-dev.sh.intel.com> From: Christian Ehrhardt Date: Wed, 20 Apr 2016 08:18:49 +0200 Message-ID: To: Yuanhan Liu Cc: dev , Daniele Di Proietto Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Memory leak when adding/removing vhost_user ports X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 06:19:09 -0000 On Wed, Apr 20, 2016 at 7:04 AM, Yuanhan Liu wrote: > On Tue, Apr 19, 2016 at 06:33:50PM +0200, Christian Ehrhardt wrote: > [...] > > With that applied one (and only one) of my two guests looses > connectivity after > > removing the ports the first time. > > Yeah, that's should be because I invoked the "->destroy_device()" > callback. > Shouldn't that not only destroy the particular vhost_user device I remove? See below for some better details on the test to clarify that. BTW, I'm curious how do you do the test? I saw you added 256 ports, but > with 2 guests only? So, 254 of them are idle, just for testing the > memory leak bug? > Maybe I should describe it better: 1. Spawn some vhost-user ports (40 in my case) 2. Spawn a pair of guests that connect via four of those ports per guest 3. Guests only intialize one of that vhost_user based NICs 4. check connectivity between guests via the vhost_user based connection (working at this stage) LOOP 5-7: 5. add ports 41-512 6. remove ports 41-512 7. check connectivity between guests via the vhost_user based connection So the vhost_user ports the guests are using are never deleted. Only some extra (not even used) ports are added&removed in the loop to search for potential leaks over a longer lifetime of an openvswitch-dpdk based solution.