From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id BC6B0C450 for ; Thu, 18 Jun 2015 05:08:56 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 17 Jun 2015 20:08:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,636,1427785200"; d="scan'208";a="510124532" Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103]) by FMSMGA003.fm.intel.com with ESMTP; 17 Jun 2015 20:08:54 -0700 Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 18 Jun 2015 11:08:32 +0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 18 Jun 2015 11:08:32 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.246]) by shsmsx102.ccr.corp.intel.com ([169.254.2.165]) with mapi id 14.03.0224.002; Thu, 18 Jun 2015 11:08:30 +0800 From: "Xie, Huawei" To: Pavel Boldin Thread-Topic: [dpdk-dev] [PATCH v4 1/5] vhost: eventfd_link: moving ioctl to a function Thread-Index: AQHQqXQNyamJGGGM8Ue5vFWUvRqr3g== Date: Thu, 18 Jun 2015 03:08:30 +0000 Message-ID: References: <1427123731-15654-1-git-send-email-pboldin@mirantis.com> <1427994080-10163-1-git-send-email-pboldin@mirantis.com> <1427994080-10163-2-git-send-email-pboldin@mirantis.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v4 1/5] vhost: eventfd_link: moving ioctl to a function 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: Thu, 18 Jun 2015 03:08:58 -0000 Two opens here, the trivial one is i think it is not good practice to=0A= explicitly inline non performance critical functions in c file, even if=0A= it will be done by compiler anyway.=0A= The critical one i have concern is whether it will introduce=0A= inconsistency if we call fd_install on a fd that is just closed by=0A= sys_close, because that fd will be set to next-to-be-allocated fd. I=0A= prefer to keep the original logic in patch 4/5 if we are not clear.=0A= =0A= As we actually don't need to use the eventfd that is allocated in user=0A= space at all, future patch would be: directly allocate a new fd in the=0A= kernel and call fd_install on it.=0A=