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 DF190A00C2; Fri, 24 Apr 2020 15:40:53 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B09741C2F9; Fri, 24 Apr 2020 15:40:52 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id F0AEA1C22D for ; Fri, 24 Apr 2020 15:40:50 +0200 (CEST) IronPort-SDR: tYQfyEovk5/H4fPljdfWeA9tP4/D3jyUqXdtQJDFUra+XTPjjX7kQ6326r8XgksfolH5oHnJI7 9r8BURMONvBQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Apr 2020 06:40:49 -0700 IronPort-SDR: FIflkyQ6LRwwArkrwZEpiTKPVVVeTcr0ADXUzhQ9aiO+0Hw31v2cKYx2Ze0betwn7H/GuDKcFh kBzcN/MxaWDA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,311,1583222400"; d="scan'208";a="335347646" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga001.jf.intel.com with ESMTP; 24 Apr 2020 06:40:49 -0700 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 24 Apr 2020 06:40:42 -0700 Received: from shsmsx108.ccr.corp.intel.com (10.239.4.97) by FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 24 Apr 2020 06:40:41 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.146]) by SHSMSX108.ccr.corp.intel.com ([169.254.8.7]) with mapi id 14.03.0439.000; Fri, 24 Apr 2020 21:40:39 +0800 From: "Liu, Yong" To: Maxime Coquelin , "Ye, Xiaolong" , "Wang, Zhihong" CC: "dev@dpdk.org" , "Van Haaren, Harry" Thread-Topic: [PATCH v9 5/9] net/virtio: add vectorized packed ring Rx path Thread-Index: AQHWGdqj9niUthnVgU+NhrCwmxjwpaiHo6OAgACYrYD//4PHAIAAhlPQ Date: Fri, 24 Apr 2020 13:40:38 +0000 Message-ID: <86228AFD5BCD8E4EBFD2B90117B5E81E635432C6@SHSMSX103.ccr.corp.intel.com> References: <20200313174230.74661-1-yong.liu@intel.com> <20200424092445.44693-1-yong.liu@intel.com> <20200424092445.44693-6-yong.liu@intel.com> <8d024d70-21b2-19cb-ee72-0bd036f0816f@redhat.com> <86228AFD5BCD8E4EBFD2B90117B5E81E63543212@SHSMSX103.ccr.corp.intel.com> <67a4586c-bbf4-8472-60bc-aef6af583573@redhat.com> In-Reply-To: <67a4586c-bbf4-8472-60bc-aef6af583573@redhat.com> 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 v9 5/9] net/virtio: add vectorized packed ring Rx path 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: Friday, April 24, 2020 9:34 PM > To: Liu, Yong ; Ye, Xiaolong ; > Wang, Zhihong > Cc: dev@dpdk.org; Van Haaren, Harry > Subject: Re: [PATCH v9 5/9] net/virtio: add vectorized packed ring Rx pat= h >=20 >=20 >=20 > On 4/24/20 3:12 PM, Liu, Yong wrote: > >> IIUC, the only difference with the non-vectorized version is the GSO > >> support removed here. > >> gso_type being in the same cacheline as flags in virtio_net_hdr, I don= 't > >> think checking the performance gain is worth the added maintainance > >> effort due to code duplication. > >> > >> Please prove I'm wrong, otherwise please move virtio_rx_offload() in a > >> header and use it here. Alternative if it really imapcts performance i= s > >> to put all the shared code in a dedicated function that can be re-used > >> by both implementations. > >> > > Maxime, > > It won't be much performance difference between non-vectorized and > vectorized. > > The reason to add special vectorized version is for skipping the handli= ng of > garbage GSO packets. > > As all descs have been handled in batch, it is needed to revert when fo= und > garbage packets. > > That will introduce complicated logic in vectorized path. >=20 =09 Dequeue function will call virtio_discard_rxbuf when found gso info in hdr = is invalid. IMHO, there's no need to check gso info when GSO not negotiated. There's an alternative way is that use single function handle GSO packets b= ut its performance will be worse than normal function. if ((hdr->gso_type & VIRTIO_NET_HDR_GSO_ECN) || (hdr->gso_size =3D=3D 0)) { return -EINVAL; } >=20 > What do you mean by garbage packet? > Is it really good to just ignore such issues? >=20 > Thanks, > Maxime >=20 > > Regards, > > Marvin > >