From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m13-4.163.com (m13-4.163.com [220.181.13.4]) by dpdk.org (Postfix) with ESMTP id C8D1A9247 for ; Thu, 22 Oct 2015 04:15:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=sukQN 0TJAlu8XtGQfcxIHqx+XbqUjGWtUAQEb8Q0SG8=; b=cypIfHK5ZdONmtqCZLjDf Z1INq4IhVgHPMc+teGqK4f//aRS+2diwPb7TlXrhRzWoqoxmzPeI6vSdetK70JeX ziyF1vB4wCK2mHMTTzLwR/Jt6fbEZocx9xg4h9V+rcYBFvT6zsiiYHe7BtHPQl+d +jX7NYm+aBSthecNcCY47E= Received: from mablexidana$163.com ( [182.92.253.20] ) by ajax-webmail-wmsvr4 (Coremail) ; Thu, 22 Oct 2015 10:15:16 +0800 (CST) X-Originating-IP: [182.92.253.20] Date: Thu, 22 Oct 2015 10:15:16 +0800 (CST) From: mablexidana To: "Bruce Richardson" X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20150911(74783.7961) Copyright (c) 2002-2015 www.mailtech.cn 163com In-Reply-To: <20151021110749.GD16140@bricha3-MOBL3> References: <5e5d9466.100a4.15089d2018f.Coremail.mablexidana@163.com> <20151021110749.GD16140@bricha3-MOBL3> X-CM-CTRLDATA: iWJiy2Zvb3Rlcl9odG09NzU4ODo1Ng== MIME-Version: 1.0 Message-ID: <313921ca.4b27.1508d543038.Coremail.mablexidana@163.com> X-CM-TRANSID: BMGowAA3PwO1RihWYVuMAA--.288W X-CM-SenderInfo: xpdezvp0lgt0rd6rljoofrz/1tbiIAybsFWBSBQJtgABsx X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] fix lpm bugs 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, 22 Oct 2015 02:15:24 -0000 aGk6CiAgICBGaXhlczogMjVlNGY1MTVmZTYzICgiZml4IGxwbSBidWdzIikKCgoKCiAgIHRoZSBy YW5kb20gdGVzdCBvZiBscG0gLCBtdWx0aXBsZSBkZWxldGUgYW5kIGFkZCBpcCBhZGRyZXNzLCBp dCBkbyBub3QgcmVjb3ZlciB0aGUgbGFzdCByaWdodCBpcCBhZGRyZXNzLgogIGVnMTogCiAgIGFk ZCBhIGxvdCBvZiByb3V0ZXM6CiBydWxlIGlkIDogMSwgaXAgOiAxNi4zMi4wLjAvMTksIG5leHRf aG9wIDogNjIsIApydWxlIGlkIDogMiwgaXAgOiAxNi4zMi4yOC4wLzIyLCBuZXh0X2hvcCA6IDk3 LApydWxlIGlkIDogIDI4LCBpcDoxNi4zMi4wLjAvMjEsIG5leHRfaG9wIDozNgouLi4uLgp3aGVu IHlvdSBkZWxldGUgcnVsZSBpZCAzLCB0aGVuIGxvb2t1cCAxNi4zMi4wLjE1MCwgdGhlIHJldHVy biBpcyAxNi4zMi4yOC4wLzIyLGJ1dCBub3QgMTYuMzIuMC4wLzE5LiB0aGlzIGlzIGJlY2F1c2Ug aW4gZGVsZXRlX2RlcHRoX3NtYWxsIGZ1bmN0aW9uLCB3aGVuIGxwbS0+dGJsMjRbaV0uZXh0X2Vu dHJ5ID09IDAgYW5kIGxwbS0+dGJsMjRbaV0uZGVwdGggPiBkZXB0aCwgaXQgd2lsbCBydW4gaW50 byB0aGUgIHRibDggcHJvY2Vzcy50aGVuIHRoZSBuZXh0X2hvcCB3aWxsIGJlIGRvaW5nIGFzIHRi bDhfZ2luZGV4LCBhbmQgdGhlIGxwbS0+dGJsOFtqXSBkYXRhIGlzIGJlaW5nIHdyb25nIHByb2Nl c3NlZC4KZml4OiArIGVsc2UgaWYgKGxwbS0+dGJsMjRbaV0uZXh0X2VudHJ5ID09IDEpIHsKCgpl ZzI6CndoZW4gYWRkICxkZWxldGUgYW5kIGFkZCBhZ2FpbiwgaXQgd2lsbCBhbHNvIGhhcyBwcm9i bGVtLgppbiBkZWxldGVfZGVwdGhfc21hbGwgZnVuY3Rpb24sIHRoZSB2YWxpZF9ncm91cCBvZiBu ZXcgc3RydWN0IHJ0ZV9scG1fdGJsOF9lbnRyeSBpcyBJTlZBTElELCBzbyB3aGVuIHByb2Nlc3Mg IGxwbS0+dGJsOFtqXSA9IG5ld190Ymw4X2VudHJ5LCB0aGUgdmFsaWRfZ3JvdXAgaXMgY292ZXJl ZC4gYW5kIHdoZW4ganVzdCBhZGQgYSByb3V0ZSBkZXB0aCA+IDI0LCAgYW5kICBhbGxvYyBhIHRi bDggaW5kZXgsIHRoZW4gdGhlIHRibDhfYWxsb2Mgd2lsbCByZXR1cm4gaXQgYXMgbmV3IGluZGV4 LCB0aGVuIHRoZSBkYXRhIGlzIGJlaW5nIHdyb25nIHJld3JpdGUuCmZpeDorIC52YWxpZF9ncm91 cCA9IFZBTElELAoKCgoKdGhhbmtzLiAgICBJIHdpbGwgcHJvdmlkZSB0aGUgdGVzdGluZyBwcm9n cmFtIGxhdGVyIC4KCgoKCnJlZ2FyZHMKCgp5dWVyeGluCiAgIAoKCgoKCgoKCgoKCgoKQXQgMjAx NS0xMC0yMSAxOTowNzo0OSwgIkJydWNlIFJpY2hhcmRzb24iIDxicnVjZS5yaWNoYXJkc29uQGlu dGVsLmNvbT4gd3JvdGU6Cj5PbiBXZWQsIE9jdCAyMSwgMjAxNSBhdCAwNTo1NDoxM1BNICswODAw LCBtYWJsZXhpZGFuYSB3cm90ZToKPj4gaGk6Cj4+ICAgICBXZSB0ZXN0IHNvbWUgbHBtIGNhc2Vz IGFuZCBmaW5kIHNvbWUgYnVncywgYmVsb3cgaXMgaG93IHRvIGZpeCBpdC4gdGhhbmtzIDopCj4K PkhpLAo+Cj50aGFua3MgZm9yIHRoZSBwYXRjaC4gQ291bGQgeW91IHBlcmhhcHMgcHJvdmlkZSBh IGRlc2NyaXB0aW9uIG9mIGhvdyB0byByZXByb2R1Y2UKPnRoZSBidWcgKG9yIGJ1Z3MgeW91IGFy ZSBmaXhpbmcpLCBzbyB0aGF0IHdlIGNhbiByZXByb2R1Y2UgdGhlbSBhbmQgdmVyaWZ5IHRoZQo+ Zml4LiAoQSB1bml0IHRlc3QgYWRkZWQgdG8gdGhlIGV4aXN0aW5nIGxwbSB1bml0IHRlc3RzIGZv ciB0aGlzIHdvdWxkIGJlIHRoZSAKPmJlc3Qgc29sdXRpb24uKQo+Rm9yIHRoZSBwYXRjaCBpdHNl bGYsIHRoZSBjb21taXQgbWVzc2FnZSBzaG91bGQgYWxzbyBkZXNjcmliZSB0aGUgYnVnLCBhbmQK PmhvdyB0aGUgcGF0Y2ggZml4ZXMgaXQuIEl0J3MgYWxzbyBnb29kIHRvIGluY2x1ZGUgYSBvbmUt bGluZSAiRml4ZXM6IiBsaW5lCj5pbiB0aGUgY29tbWVudCAtIGdlbmVyYXRlZCBieSB1c2luZyB0 aGUgZ2l0IGFsaWFzICJmaXhsaW5lIiBhZGRlZCBhczoKPglmaXhsaW5lID0gbG9nIC0xIC0tYWJi cmV2PTEyIC0tZm9ybWF0PSdGaXhlczogJWggKFwiJXNcIiknCj4KPlJlZ2FyZHMsCj4vQnJ1Y2UK Pgo+PiAtLS0KPj4gIGxpYi9saWJydGVfbHBtL3J0ZV9scG0uYyB8IDUgKysrLS0KPj4gIDEgZmls ZSBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCj4+IAo+PiAKPj4gZGlm ZiAtLWdpdCBhL2xpYi9saWJydGVfbHBtL3J0ZV9scG0uYyBiL2xpYi9saWJydGVfbHBtL3J0ZV9s cG0uYwo+PiBpbmRleCAxNjNiYTNjLi5iNTE5OWZmIDEwMDY0NAo+PiAtLS0gYS9saWIvbGlicnRl X2xwbS9ydGVfbHBtLmMKPj4gKysrIGIvbGliL2xpYnJ0ZV9scG0vcnRlX2xwbS5jCj4+IEBAIC03 MzUsNyArNzM1LDcgQEAgZGVsZXRlX2RlcHRoX3NtYWxsKHN0cnVjdCBydGVfbHBtICpscG0sIHVp bnQzMl90IGlwX21hc2tlZCwKPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGxwbS0+dGJsMjRbaV0uZGVwdGggPD0gZGVwdGggKSB7Cj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgbHBtLT50YmwyNFtpXS52YWxpZCA9IElOVkFMSUQ7Cj4+ICAgICAgICAg ICAgICAgICAgICAgICAgIH0KPj4gLSAgICAgICAgICAgICAgICAgICAgICAgZWxzZSB7Cj4+ICsg ICAgICAgICAgICAgICAgICAgICAgIGVsc2UgaWYgKGxwbS0+dGJsMjRbaV0uZXh0X2VudHJ5ID09 IDEpewo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8qCj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICogSWYgVEJMMjQgZW50cnkgaXMgZXh0ZW5kZWQsIHRoZW4g dGhlcmUgaGFzCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogdG8gYmUgYSBy dWxlIHdpdGggZGVwdGggPj0gMjUgaW4gdGhlCj4+IEBAIC03NzAsNiArNzcwLDcgQEAgZGVsZXRl X2RlcHRoX3NtYWxsKHN0cnVjdCBydGVfbHBtICpscG0sIHVpbnQzMl90IGlwX21hc2tlZCwKPj4g Cj4+IAo+PiAgICAgICAgICAgICAgICAgc3RydWN0IHJ0ZV9scG1fdGJsOF9lbnRyeSBuZXdfdGJs OF9lbnRyeSA9IHsKPj4gICAgICAgICAgICAgICAgICAgICAgICAgLnZhbGlkID0gVkFMSUQsCj4+ ICsgICAgICAgICAgICAgICAgICAgICAgIC52YWxpZF9ncm91cCA9IFZBTElELAo+PiAgICAgICAg ICAgICAgICAgICAgICAgICAuZGVwdGggPSBzdWJfcnVsZV9kZXB0aCwKPj4gICAgICAgICAgICAg ICAgICAgICAgICAgLm5leHRfaG9wID0gbHBtLT5ydWxlc190YmwKPj4gICAgICAgICAgICAgICAg ICAgICAgICAgW3N1Yl9ydWxlX2luZGV4XS5uZXh0X2hvcCwKPj4gQEAgLTc4MSw3ICs3ODIsNyBA QCBkZWxldGVfZGVwdGhfc21hbGwoc3RydWN0IHJ0ZV9scG0gKmxwbSwgdWludDMyX3QgaXBfbWFz a2VkLAo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbHBtLT50Ymwy NFtpXS5kZXB0aCA8PSBkZXB0aCApIHsKPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBscG0tPnRibDI0W2ldID0gbmV3X3RibDI0X2VudHJ5Owo+PiAgICAgICAgICAgICAgICAgICAg ICAgICB9Cj4+IC0gICAgICAgICAgICAgICAgICAgICAgIGVsc2Ugewo+PiArICAgICAgICAgICAg ICAgICAgICAgICBlbHNlICBpZiAobHBtLT50YmwyNFtpXS5leHRfZW50cnkgPT0gMSkgewo+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8qCj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICogSWYgVEJMMjQgZW50cnkgaXMgZXh0ZW5kZWQsIHRoZW4gdGhlcmUgaGFz Cj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogdG8gYmUgYSBydWxlIHdpdGgg ZGVwdGggPj0gMjUgaW4gdGhlCj4+IC0tCj4+IDEuOC41LjIgKEFwcGxlIEdpdC00OCkK >From jianfeng.tan@intel.com Thu Oct 22 04:27:30 2015 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 99FC19366 for ; Thu, 22 Oct 2015 04:27:29 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 21 Oct 2015 19:27:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,180,1444719600"; d="scan'208";a="832644136" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga002.fm.intel.com with ESMTP; 21 Oct 2015 19:27:28 -0700 Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 21 Oct 2015 19:27:28 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx101.amr.corp.intel.com (10.18.124.199) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 21 Oct 2015 19:27:27 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.204]) by shsmsx102.ccr.corp.intel.com ([169.254.2.253]) with mapi id 14.03.0248.002; Thu, 22 Oct 2015 10:27:26 +0800 From: "Tan, Jianfeng" To: "Xie, Huawei" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v3 6/7] virtio: simple tx routine Thread-Index: AQHRC0yAsp8O5rChIkaCHhgF+xmUEp52yXfA Date: Thu, 22 Oct 2015 02:27:25 +0000 Message-ID: References: <1443537953-23917-1-git-send-email-huawei.xie@intel.com> <1445355007-4613-1-git-send-email-huawei.xie@intel.com> <1445355007-4613-7-git-send-email-huawei.xie@intel.com> In-Reply-To: <1445355007-4613-7-git-send-email-huawei.xie@intel.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 Subject: Re: [dpdk-dev] [PATCH v3 6/7] virtio: simple tx routine 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, 22 Oct 2015 02:27:30 -0000 On 10/22/2015 10:26 AM, Jianfeng wrote:=20 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Huawei Xie > Sent: Tuesday, October 20, 2015 11:30 PM > To: dev@dpdk.org > Subject: [dpdk-dev] [PATCH v3 6/7] virtio: simple tx routine >=20 > Changes in v3: > - Remove return at the end of void function > - Remove always_inline attribute for virtio_xmit_cleanup >=20 > bulk free of mbufs when clean used ring. > shift operation of idx could be saved if vq_free_cnt means free slots rat= her > than free descriptors. >=20 > TODO: rearrange vq data structure, pack the stats var together so that we > could use one vec instruction to update all of them. >=20 > Signed-off-by: Huawei Xie > --- > drivers/net/virtio/virtio_ethdev.h | 3 ++ > drivers/net/virtio/virtio_rxtx_simple.c | 93 > +++++++++++++++++++++++++++++++++ > 2 files changed, 96 insertions(+) >=20 > diff --git a/drivers/net/virtio/virtio_ethdev.h > b/drivers/net/virtio/virtio_ethdev.h > index d7797ab..ae2d47d 100644 > --- a/drivers/net/virtio/virtio_ethdev.h > +++ b/drivers/net/virtio/virtio_ethdev.h > @@ -111,6 +111,9 @@ uint16_t virtio_xmit_pkts(void *tx_queue, struct > rte_mbuf **tx_pkts, uint16_t virtio_recv_pkts_vec(void *rx_queue, struct > rte_mbuf **rx_pkts, > uint16_t nb_pkts); >=20 > +uint16_t virtio_xmit_pkts_simple(void *tx_queue, struct rte_mbuf > **tx_pkts, > + uint16_t nb_pkts); > + > /* > * The VIRTIO_NET_F_GUEST_TSO[46] features permit the host to send us > * frames larger than 1514 bytes. We do not yet support software LRO dif= f -- > git a/drivers/net/virtio/virtio_rxtx_simple.c > b/drivers/net/virtio/virtio_rxtx_simple.c > index ef17562..a53d462 100644 > --- a/drivers/net/virtio/virtio_rxtx_simple.c > +++ b/drivers/net/virtio/virtio_rxtx_simple.c > @@ -288,6 +288,99 @@ virtio_recv_pkts_vec(void *rx_queue, struct > rte_mbuf **rx_pkts, > return nb_pkts_received; > } >=20 > +#define VIRTIO_TX_FREE_THRESH 32 > +#define VIRTIO_TX_MAX_FREE_BUF_SZ 32 > +#define VIRTIO_TX_FREE_NR 32 > +/* TODO: vq->tx_free_cnt could mean num of free slots so we could avoid > +shift */ static inline void virtio_xmit_cleanup(struct virtqueue *vq) { > + uint16_t i, desc_idx; > + int nb_free =3D 0; > + struct rte_mbuf *m, *free[VIRTIO_TX_MAX_FREE_BUF_SZ]; > + > + desc_idx =3D (uint16_t)(vq->vq_used_cons_idx & > + ((vq->vq_nentries >> 1) - 1)); > + free[0] =3D (struct rte_mbuf *)vq->vq_descx[desc_idx++].cookie; > + nb_free =3D 1; > + > + for (i =3D 1; i < VIRTIO_TX_FREE_NR; i++) { > + m =3D (struct rte_mbuf *)vq->vq_descx[desc_idx++].cookie; > + if (likely(m->pool =3D=3D free[0]->pool)) > + free[nb_free++] =3D m; > + else { > + rte_mempool_put_bulk(free[0]->pool, (void **)free, > + nb_free); > + free[0] =3D m; > + nb_free =3D 1; > + } > + } > + > + rte_mempool_put_bulk(free[0]->pool, (void **)free, nb_free); > + vq->vq_used_cons_idx +=3D VIRTIO_TX_FREE_NR; > + vq->vq_free_cnt +=3D (VIRTIO_TX_FREE_NR << 1); } > + > +uint16_t > +virtio_xmit_pkts_simple(void *tx_queue, struct rte_mbuf **tx_pkts, > + uint16_t nb_pkts) > +{ > + struct virtqueue *txvq =3D tx_queue; > + uint16_t nb_used; > + uint16_t desc_idx; > + struct vring_desc *start_dp; > + uint16_t nb_tail, nb_commit; > + int i; > + uint16_t desc_idx_max =3D (txvq->vq_nentries >> 1) - 1; > + > + nb_used =3D VIRTQUEUE_NUSED(txvq); > + rte_compiler_barrier(); > + > + nb_commit =3D nb_pkts =3D RTE_MIN((txvq->vq_free_cnt >> 1), > nb_pkts); Here if nb_commit is zero, how about return 0 immediately? > + desc_idx =3D (uint16_t) (txvq->vq_avail_idx & desc_idx_max); > + start_dp =3D txvq->vq_ring.desc; > + nb_tail =3D (uint16_t) (desc_idx_max + 1 - desc_idx); > + > + if (nb_used >=3D VIRTIO_TX_FREE_THRESH) > + virtio_xmit_cleanup(tx_queue); If this cleanup should be put before vq_free_cnt is referenced? It's becaus= e it may free some descs to vq_free_cnt. > + > + if (nb_commit >=3D nb_tail) { > + for (i =3D 0; i < nb_tail; i++) > + txvq->vq_descx[desc_idx + i].cookie =3D tx_pkts[i]; > + for (i =3D 0; i < nb_tail; i++) { > + start_dp[desc_idx].addr =3D > + RTE_MBUF_DATA_DMA_ADDR(*tx_pkts); > + start_dp[desc_idx].len =3D (*tx_pkts)->pkt_len; > + tx_pkts++; > + desc_idx++; > + } > + nb_commit -=3D nb_tail; > + desc_idx =3D 0; > + } > + for (i =3D 0; i < nb_commit; i++) > + txvq->vq_descx[desc_idx + i].cookie =3D tx_pkts[i]; > + for (i =3D 0; i < nb_commit; i++) { > + start_dp[desc_idx].addr =3D > RTE_MBUF_DATA_DMA_ADDR(*tx_pkts); > + start_dp[desc_idx].len =3D (*tx_pkts)->pkt_len; > + tx_pkts++; > + desc_idx++; > + } > + > + rte_compiler_barrier(); > + > + txvq->vq_free_cnt -=3D (uint16_t)(nb_pkts << 1); > + txvq->vq_avail_idx +=3D nb_pkts; > + txvq->vq_ring.avail->idx =3D txvq->vq_avail_idx; > + txvq->packets +=3D nb_pkts; > + > + if (likely(nb_pkts)) { > + if (unlikely(virtqueue_kick_prepare(txvq))) > + virtqueue_notify(txvq); > + } > + > + return nb_pkts; > +} > + > int __attribute__((cold)) > virtio_rxq_vec_setup(struct virtqueue *rxq) { > -- > 1.8.1.4