From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id D3E5CC3AA for ; Fri, 10 Jul 2015 17:50:24 +0200 (CEST) Received: by wgxm20 with SMTP id m20so69482571wgx.3 for ; Fri, 10 Jul 2015 08:50:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=8cGz23NepAike/HUrJHXOmVCol88wkGeza/R/Ht4OWc=; b=ZxTp+AvBh6PV68Xq171FDa6PxUaAP9kf3kaTPhNM2Eluuwxh4WTFWhKGBapzk38HWr bQsWUWANavXWp9LqVsN7GySma0HjkA7jmlj0ZnNRGRX95x0TbpBo5m0Ll51dj6e+n97K UpegPXETf39addKoxp1znTR+6yhnkWwhzeRY/2IZG2nI4tkYEGhxjedvtQJQoqkA7Fh4 ZtTpjyI29LZWb0D9jttU1DbKdMSboWpMypfWpVBuBAzN+iFl4lFoWWD8ftDKdI/Wevy9 SiUumW/sdq1RPHE7uwT43nvoZp9BeUdr/g77vqtiVDjBsfA5DOplUBayaEID2TqL/0vW N5YA== X-Gm-Message-State: ALoCoQkiijLy7I6rTDVkXv2yRIVn68pFNGxWO+WO6INZbMxFX72UB6aWmHpZAzVDYTwMpWiGN3LN X-Received: by 10.180.38.107 with SMTP id f11mr7104685wik.48.1436543424692; Fri, 10 Jul 2015 08:50:24 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id be9sm14172018wjb.26.2015.07.10.08.50.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jul 2015 08:50:23 -0700 (PDT) From: Thomas Monjalon To: "Xie, Huawei" Date: Fri, 10 Jul 2015 17:49:07 +0200 Message-ID: <7112583.u7L3bAyaN6@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: References: <1427994080-10163-1-git-send-email-pboldin@mirantis.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org, Pavel Boldin Subject: Re: [dpdk-dev] [PATCH v5 4/5] vhost: eventfd_link: replace copy-pasted sys_close 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: Fri, 10 Jul 2015 15:50:25 -0000 2015-07-10 15:42, Xie, Huawei: > Don't know why previous mail get messed. Same problem with this one. It's maybe because you send HTML mail which is wrongly translated in plain text. > On 7/10/2015 10:50 PM, Pavel Boldin wrote: > Xie, > > Regarding the patches: > 1. The replaced code in fourth patch is checked to be a copy-paste of the `sys_close` syscall. > > sys_close does extra cleanup than the replaced coe. My concern is, for example, sys_close will mark the fd as next-to-be-allocated fd. Will there be issue when we allocate a new fd, because it will be allocated starting from the value of next-to-be-allocted-fd? I think kernel willn't blindly use that value, but not sure. > > 2. It is not uncommon for the applications to close FD making it allocated for a different file. In our particular case the file is closed in the *source* process and *added* to a target process, so matching fds should not be the problem. > > Yes, that is exactly what the old code does. > 3. There is an implementation of the exact same thing in the SCM_RIGHTS [1] that can be used as the reference code. > > I did a rough check. Maybe i miss something. I see it calls fd_install on a newly allocated fd. That is exactly what i want to replace the current code with. > Currently we allcoate eventfd in user space and install a new file onto it through fd_install. Actually we don't need to allocate the eventfd in user space at all, what we should do is allocate a new fd in kernel, and install the file onto it. > > new_fd = get_unused_fd_flags(...) > fd_install(new_fd, get_file(fp[i]) > > /huawei > > [1] https://github.com/torvalds/linux/blob/master/net/core/scm.c#L248 > > Pavel > > On Fri, Jul 10, 2015 at 5:27 PM, Xie, Huawei > wrote: > On 6/17/2015 11:24 PM, Thomas Monjalon wrote: > > 2015-05-07 06:54, Xie, Huawei: > >> On 4/16/2015 7:48 PM, Pavel Boldin wrote: > >>> + /* Closing the source_fd */ > >>> + ret = sys_close(eventfd_copy.source_fd); > >> Pavel: > >> Here we close the fd and re-install a new file on this fd later. > >> sys_close does all cleanup. > >> But, for instance, if we allocate new fd later, normally it will reuse > >> the just freed fds by sys_close, is there issue here? > > Pavel, Huawei, > > Could we come to a conclusion on this patch series please? > For the previous 3 patches, i am OK except that i don't think inline is > needed explicitly for non-performance critical function. > For this patch, didn't check the fs code. > > > > > > > >