From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id B1D44C3CA for ; Mon, 3 Aug 2015 12:00:00 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 03 Aug 2015 02:59:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,600,1432623600"; d="scan'208";a="776663792" Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103]) by orsmga002.jf.intel.com with ESMTP; 03 Aug 2015 02:59:56 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 3 Aug 2015 17:59:54 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.126]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.38]) with mapi id 14.03.0224.002; Mon, 3 Aug 2015 17:59:53 +0800 From: "Liang, Cunming" To: "Liang, Cunming" , "Ananyev, Konstantin" , Zoltan Kiss , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v1] ixgbe: remove vector pmd burst size restriction Thread-Index: AQHQzb/jeorioZ4AXUGu3RBLDHAXhZ36CMvA Date: Mon, 3 Aug 2015 09:59:52 +0000 Message-ID: References: <1438330669-25942-1-git-send-email-cunming.liang@intel.com> <55BB47FB.3000409@linaro.org> <2601191342CEEE43887BDE71AB97725836A6B79C@irsmsx105.ger.corp.intel.com> In-Reply-To: Accept-Language: zh-CN, 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 Subject: Re: [dpdk-dev] [PATCH v1] ixgbe: remove vector pmd burst size restriction 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: Mon, 03 Aug 2015 10:00:01 -0000 Hi, [...] > > Another thing, that I just thought about: > > Right now we invoke ixgbe_rxq_rearm() only at the start of > > _recv_raw_pkts_vec(). > > Before it was ok, as _recv_raw_pkts_vec() would never try to read more = then > 32 > > RXDs. > > But what would happen if nb_pkts > rxq->nb_desc and rxq->rxrearm_nb =3D= =3D 0? > > I suppose, _recv_raw_pkts_vec() can wrpa around RXD ring and 'receive' > same > > packet twice? > > So we probably better still limit nb_pkts <=3D 32 at _recv_raw_pkts_vec= (). >=20 > The _recv_raw_pkts_vec() won't wrap around RXD ring. When it reaches the = last > one, the DD bit of padding desc. always 0. > So in the case nb_pkts > rxq->nb_desc, the '_recv_raw_pkts_vec()' can onl= y get > no more than 'rxq->nb_desc' packets. >=20 I think the violation is true when rx_id in some middle position of desc_ri= ng, and nb_pkts > rxq->nb_desc. The DD checking may exceed the boundary (access the entry whose DD is set a= nd waiting for rearm). So I agree to keep the max burst size as 32. /Steve