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 0607C8D89 for ; Tue, 27 Oct 2015 03:38:28 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 26 Oct 2015 19:38:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,202,1444719600"; d="scan'208";a="820123473" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga001.fm.intel.com with ESMTP; 26 Oct 2015 19:38:27 -0700 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 26 Oct 2015 19:38:27 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 26 Oct 2015 19:38:27 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.96]) by shsmsx102.ccr.corp.intel.com ([169.254.2.253]) with mapi id 14.03.0248.002; Tue, 27 Oct 2015 10:38:25 +0800 From: "Xie, Huawei" To: Stephen Hemminger Thread-Topic: [dpdk-dev] [PATCH v2 0/5] virtio: Tx performance improvements Thread-Index: AdEMtczKGoGnSN25SBqgZMNDMzsH2Q== Date: Tue, 27 Oct 2015 02:38:24 +0000 Message-ID: References: <1445231772-17467-1-git-send-email-stephen@networkplumber.org> <1536056.KWEakoJpBK@xps13> <20151022090459.68015713@xeon-e3> <20151027085212.24ce7e5e@samsung9> 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 v2 0/5] virtio: Tx performance improvements 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: Tue, 27 Oct 2015 02:38:29 -0000 On 10/27/2015 10:23 AM, Stephen Hemminger wrote:=0A= > You need to use the extended mergeable rx buffer format.=0A= > It is a virtio spec requirement, look at Linux virtio network driver=0A= > or ask the virtio maintainers for Linux=0A= > if you need more clarification.=0A= Yes, it is spec requirement as far as we know though num_buffers might=0A= not be used.=0A= So far not a big deal for us. Let us get clarification from mst later.=0A= >=0A= > On Tue, Oct 27, 2015 at 10:56 AM, Xie, Huawei > wrote:=0A= >=0A= > On 10/27/2015 7:52 AM, Stephen Hemminger wrote:=0A= > > On Fri, 23 Oct 2015 09:00:38 +0000=0A= > > "Xie, Huawei" > wrote:=0A= > >=0A= > >>>> Why use merge-able rx header here in the tx region?=0A= > >>> If mergeable rx is negotiated then the header must be used for=0A= > >>> both Tx and Rx. I chose to allocate the largest possible header= =0A= > >>> needed, rather than having to deal with variable size data=0A= > structure.=0A= > >> Our original code is also using merge-able header for TX=0A= > descriptor if=0A= > >> this negotiated.=0A= > >> I checked the virtio spec, all of the merge-able header is about= =0A= > >> receiving buffers, which is expected. That is why i feel weird=0A= > here.=0A= > >> Maybe not a big deal?=0A= > > Since num_buffers is only in merge-able header, the negotiation=0A= > is implied=0A= > > to be symmetric.=0A= > >=0A= > Can we come to the conclusion that in tx case, we use merge-able=0A= > header=0A= > though number_buffers is not used at all?=0A= > > Reading 0.95 spec=0A= > >=0A= > > Under "Packet Transmission"=0A= > > 3. If the driver negotatied the VIRTIO_NET_F_MGR_RXBUF feature=0A= > > the num_buffers field is set to zero.=0A= > >=0A= > >=0A= >=0A= >=0A= =0A=