From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by dpdk.org (Postfix) with ESMTP id 374C42E8A for ; Mon, 11 Apr 2016 13:21:03 +0200 (CEST) X-AuditID: c1b4fb30-f79246d00000788a-64-570b889e590b Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5D.BB.30858.E988B075; Mon, 11 Apr 2016 13:21:02 +0200 (CEST) Received: from [147.214.49.111] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.248.2; Mon, 11 Apr 2016 13:21:01 +0200 To: Christian Ehrhardt References: <1458292380-9258-1-git-send-email-patrik.r.andersson@ericsson.com> <570379F9.6020306@ericsson.com> <570B3ECE.3050905@ericsson.com> CC: "Xie, Huawei" , Daniele Di Proietto , "dev@dpdk.org" , Thomas Monjalon , "Ananyev, Konstantin" , Yuanhan Liu From: Patrik Andersson R Organization: Ericsson AB Message-ID: <570B889E.7050405@ericsson.com> Date: Mon, 11 Apr 2016 13:21:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7hO68Du5wgx+rjS3mrt7AbvHu03Ym i5fd99gt2meeZbJ4/2cRi8WXTdPZLK5PuMDqwO5xsf8Oo8eshl42j18LlrJ6LN7zkslj3slA j3fz37IFsEVx2aSk5mSWpRbp2yVwZbzetpatYL9oxc27X9gaGLfxdzFyckgImEi8f72DFcIW k7hwbz1bFyMXh5DAEUaJ5dcusEI4axgl5i5/z9jFyMEhLOAl8eqiMUiDiIClxLcTW5kharYw Szw5PpURxGEW6GSSaFi2jgWkik3ASmLetmVMIDa/gKTEhobdzCA2r4C2xJYTtxhBbBYBVYl/ f8+A1YgKREg8mXuSEaJGUOLkzCdgczgFAiW+da8CizMLWEjMnH8eypaX2P52DthMIQEdiVdn 3rJNYBSahaR9FpKWWUhaFjAyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIjJGDW34b7GB8 +dzxEKMAB6MSD68CK3e4EGtiWXFl7iFGCQ5mJRHejFagEG9KYmVValF+fFFpTmrxIUZpDhYl cd7syH9hQgLpiSWp2ampBalFMFkmDk6pBkbvCpP9Vu+NzQqs5LPZL3ZcbVixcN78SrbkrY0e c3mvrrHnfMzGM/0Sz7/qeVvufWIQsqv5yBWwa150d3Vy/xtWdbcjp99LeW958uG6xKP4ugvz RI+uzOVfu9Jyc+GF/MNJHTy3em+kOjpWCM01jb6m6Nn623RnJRNvpdtx2+0TFJIirjH6Jyqx FGckGmoxFxUnAgDcaQvGjQIAAA== Subject: Re: [dpdk-dev] [RFC] vhost user: add error handling for fd > 1023 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: Mon, 11 Apr 2016 11:21:03 -0000 Yes, that is correct. Closing the socket on failure needs to be added. Regards, Patrik On 04/11/2016 11:34 AM, Christian Ehrhardt wrote: > I like the approach as well to go for the fix for robustness first. > > I was accidentally able to find another testcase to hit the same root > cause. > Adding guests with 15 vhost_user based NICs each while having rxq for > openvswitch-dpdk set to 4 and multiqueue for the guest devices at 4 > already breaks when adding the thirds such guests. > That is way earlier than I would have expected the fd's to be > exhausted but still the same root cause, so just another test for the > same. > > In prep to the wider check to the patch a minor review question from me: > On the section of rte_vhost_driver_register that now detects if there > were issues we might want to close the socketfd as well when bailing out. > Otherwise we would just have another source of fd leaks or would that > be reused later on even now that we have freed vserver-path and > vserver itself? > > ret = fdset_add(&g_vhost_server.fdset, vserver->listenfd, > vserver_new_vq_conn, NULL, vserver); > if (ret < 0) { > pthread_mutex_unlock(&g_vhost_server.server_mutex); > RTE_LOG(ERR, VHOST_CONFIG, > "failed to add listen fd %d to vhost server fdset\n", > vserver->listenfd); > free(vserver->path); > + close(vserver->listenfd); > free(vserver); > return -1; > } > > > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd > > On Mon, Apr 11, 2016 at 8:06 AM, Patrik Andersson R > > wrote: > > I fully agree with this course of action. > > Thank you, > > Patrik > > > > On 04/08/2016 08:47 AM, Xie, Huawei wrote: > > On 4/7/2016 10:52 PM, Christian Ehrhardt wrote: > > I totally agree to that there is no deterministic rule > what to expect. > The only rule is that #fd certainly always is > > #vhost_user devices. > In various setup variants I've crossed fd 1024 anywhere > between 475 > and 970 vhost_user ports. > > Once the discussion continues and we have an updates > version of the > patch with some more agreement I hope I can help to test it. > > Thanks. Let us first temporarily fix this problem for > robustness, then > we consider whether upgrade to (e)poll. > Will check the patch in detail later. Basically it should work > but need > check whether we need extra fixes elsewhere. > > >