From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pboldin@mirantis.com>
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45])
 by dpdk.org (Postfix) with ESMTP id C7E795A65
 for <dev@dpdk.org>; Sat, 11 Jul 2015 17:08:23 +0200 (CEST)
Received: by wgmn9 with SMTP id n9so15436553wgm.0
 for <dev@dpdk.org>; Sat, 11 Jul 2015 08:08:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mirantis.com; s=google;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=a+h+BbL6W90TfPanhFKqblYhuq/BW0outKmYkYGbgfM=;
 b=g5iap7yOQ2uQnBCw7ChrRoihKz/yeJN0vqzDqMLjBt0FvWOoy9YFzopMyYc6i3heqD
 c/B3xsqHvJp1h73FyDP7fkopEL6o0SyVelTOfpf833fSxf7h3NibGxe3zOtE4zPyd0Or
 cEDkdL4ChsTSpSbiO9Pl6uV1maaw7HvCZ+miE=
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:date
 :message-id:subject:from:to:cc:content-type;
 bh=a+h+BbL6W90TfPanhFKqblYhuq/BW0outKmYkYGbgfM=;
 b=HHk/MQRdNsXT8VBmlORpPysbsYcvLOc9Z8b+TDYkURHb0Zag8yhcEchaoklfT3kITg
 gJ0eKKotaOtmY62lrrEvqPx90YiaeiFSLCcGpSBIfB5fBAbG+dWIYnnYU0BRi6n6GTs9
 FmvXpJlrqghPZhQZLhxLI5bEwefG+ZFaE62F/b4uV5v2MhLNXwpk0okH/IRYK27j3FNw
 QWjDL3SNJxOIdkYWfDNoAg6wTd7jRdGrFWn0R5ne7Ilav4jTc2bJOk02jlrpi91OyXMG
 ZU0JHDvnj+swEso58MVFqXG0+N4ARjHtUPga+Hej+BDZsicxW0RrggUKBx8ru4vp6OMk
 VGrA==
X-Gm-Message-State: ALoCoQlFZf31eWQ+96Vy4C8BUNxJjAI5mtIyyRdvKgfR22i+NNIxIQIRYgV7m+LOotMMJ0bAhKVM
MIME-Version: 1.0
X-Received: by 10.180.23.33 with SMTP id j1mr7107636wif.44.1436627303588; Sat,
 11 Jul 2015 08:08:23 -0700 (PDT)
Received: by 10.194.64.102 with HTTP; Sat, 11 Jul 2015 08:08:23 -0700 (PDT)
In-Reply-To: <C37D651A908B024F974696C65296B57B0F56C759@SHSMSX101.ccr.corp.intel.com>
References: <1427994080-10163-1-git-send-email-pboldin@mirantis.com>
 <1429184910-30186-5-git-send-email-pboldin@mirantis.com>
 <C37D651A908B024F974696C65296B57B0F476567@SHSMSX101.ccr.corp.intel.com>
 <1665929.SfCu3BinAE@xps13>
 <C37D651A908B024F974696C65296B57B0F56C326@SHSMSX101.ccr.corp.intel.com>
 <CACf4_B_2M-Nc76kTDwxySgjS3LzYgJVLFz0GgNcWEpz-96WipQ@mail.gmail.com>
 <C37D651A908B024F974696C65296B57B0F56C759@SHSMSX101.ccr.corp.intel.com>
Date: Sat, 11 Jul 2015 18:08:23 +0300
Message-ID: <CACf4_B_rbJutj+F6xqsGOx2EFs8GYYhQxrWSoWqF9077Up=Wxg@mail.gmail.com>
From: Pavel Boldin <pboldin@mirantis.com>
To: "Xie, Huawei" <huawei.xie@intel.com>
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Cc: "dev@dpdk.org" <dev@dpdk.org>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jul 2015 15:08:24 -0000

Xie, All,

Please find my comments intermixed below.

On Fri, Jul 10, 2015 at 6:42 PM, Xie, Huawei <huawei.xie@intel.com> wrote:

> Don't know why previous mail get messed.
>
> 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.
>

That is what applications do when call `close' libc function -- the freed
FD is ready to be allocated again and it is OK for applications to reuse
FDs.


>
> 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])
>

Well, this requires changes from the user-space side so I prefer not to do
it by myself at the moment, because I'm no expert in DPDK. I can provide
with the updated patches though but I will require a lab to check that it
works indeed.

No comments below this line.

Pavel


>
> /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 <huawei.xie@intel.com<mailto:
> huawei.xie@intel.com>> 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.
>
> >
> >
>
>
>
>