From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4DA10A00BE; Tue, 28 Apr 2020 02:44:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EBA4A1D505; Tue, 28 Apr 2020 02:44:08 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 38C851D483 for ; Tue, 28 Apr 2020 02:44:07 +0200 (CEST) IronPort-SDR: tvN3QfdRTwzpEKvYklpkCkd7oBifgp5FRT8QLwnW745blNhBsLsBL3AqQSCyHtR2uwHAUbqDN5 4F7Jdu2gaIbQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2020 17:44:06 -0700 IronPort-SDR: WjKBZxz4k4rfv+e+Bdb6TD264vAF9AmTuSYWQZbbpak5IYMET3Lwi8W7z0+8uwbcMH33+du+A8 T/6ktDZZ5hdA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,325,1583222400"; d="scan'208";a="275663942" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga002.jf.intel.com with ESMTP; 27 Apr 2020 17:44:05 -0700 Received: from fmsmsx163.amr.corp.intel.com (10.18.125.72) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 27 Apr 2020 17:44:05 -0700 Received: from shsmsx105.ccr.corp.intel.com (10.239.4.158) by fmsmsx163.amr.corp.intel.com (10.18.125.72) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 27 Apr 2020 17:44:05 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.146]) by SHSMSX105.ccr.corp.intel.com ([169.254.11.213]) with mapi id 14.03.0439.000; Tue, 28 Apr 2020 08:44:03 +0800 From: "Liu, Yong" To: Maxime Coquelin , "Ye, Xiaolong" , "Wang, Zhihong" CC: "dev@dpdk.org" Thread-Topic: [PATCH v2 2/2] vhost: cache gpa to hpa translation Thread-Index: AQHWB/Ux3HhOESg2LUy+M7Zh4d4Ys6iMSkoAgAGQCxA= Date: Tue, 28 Apr 2020 00:44:02 +0000 Message-ID: <86228AFD5BCD8E4EBFD2B90117B5E81E63546B77@SHSMSX103.ccr.corp.intel.com> References: <20200316153353.112897-1-yong.liu@intel.com> <20200401145011.67357-1-yong.liu@intel.com> <20200401145011.67357-2-yong.liu@intel.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 2/2] vhost: cache gpa to hpa translation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Maxime Coquelin > Sent: Monday, April 27, 2020 4:45 PM > To: Liu, Yong ; Ye, Xiaolong ; > Wang, Zhihong > Cc: dev@dpdk.org > Subject: Re: [PATCH v2 2/2] vhost: cache gpa to hpa translation >=20 > Hi Marvin, >=20 > On 4/1/20 4:50 PM, Marvin Liu wrote: > > If Tx zero copy enabled, gpa to hpa mapping table is updated one by > > one. This will harm performance when guest memory backend using 2M > > hugepages. Now add cached mapping table which will sorted by using > > sequence. Address translation will first check cached mapping table, > > then check unsorted mapping table if no match found. > > > > Signed-off-by: Marvin Liu > > >=20 > I don't like the approach, as I think it could have nasty effects. > For example, the system is loaded normally and let's say 25% of the > pages are used. Then we have a small spike, and buffers that were never > used start to be used, it will cause writing new entries into the cache > in the hot path when it is already overloaded. Wouldn't it increase the > number of packets dropped? >=20 > At set_mem_table time, instead of adding the guest pages unsorted, maybe > better to add them sorted there. Then you can use a better algorithm > than linear searching (O(n)), like binary search (O(log n)). >=20 Maxime, Thanks for input. Previous sorted way is according using sequence, it may c= ause more packets drop if accessing pages sequence varied a lot. Based on current dpdk and virtio-net implementation, it is unlikely to be h= appened. Anyway, it is not the best choice. I will use binary search replace current cache solution. Regards, Marvin > Thanks, > Maxime >=20