From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0086.outbound.protection.outlook.com [104.47.2.86]) by dpdk.org (Postfix) with ESMTP id 6E5E8FFA for ; Tue, 12 Sep 2017 01:28:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k/Jo3ovXTTF+rz3CrVUBelEpf9VZY6RbVJ9EiA2AEnY=; b=cGnuFZAeC7oIA8hrOEXLkDlNtrhYI7DYhOrKZwlBmMXYzbDXD8/HuulZ1AnEToRQRGNiZgHp45o+ByVDWaDREEsTLAN69JBvWxfS9EsbfB3s+mZhzoEzYu1jSyxX2aM7ykGaR8PPqg/VaUG2ZTeXDxlLwHdDuEKuuwC7MVqvVNo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; Received: from yongseok-MBP.local (209.116.155.178) by HE1PR0501MB2044.eurprd05.prod.outlook.com (2603:10a6:3:35::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12; Mon, 11 Sep 2017 23:28:20 +0000 Date: Mon, 11 Sep 2017 16:28:07 -0700 From: Yongseok Koh To: =?iso-8859-1?Q?N=E9lio?= Laranjeiro Cc: adrien.mazarguil@6wind.com, dev@dpdk.org Message-ID: <20170911232806.GC1922@yongseok-MBP.local> References: <20170825184023.31692-1-yskoh@mellanox.com> <20170825184023.31692-2-yskoh@mellanox.com> <20170904123703.tcygmgk5jarhhksy@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170904123703.tcygmgk5jarhhksy@localhost> User-Agent: Mutt/1.7.2 (2016-11-26) X-Originating-IP: [209.116.155.178] X-ClientProxiedBy: MWHPR10CA0010.namprd10.prod.outlook.com (2603:10b6:301::20) To HE1PR0501MB2044.eurprd05.prod.outlook.com (2603:10a6:3:35::22) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6ffd052c-a1b4-4ee6-0062-08d4f96ccaa2 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0501MB2044; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0501MB2044; 3:ycL6lNalx7No55nT9zx5TcsooOiX0lh7w/oDlXRlK7AEW25ej2Dpr8uH2hM4rRxDYv0s2BLN1fZkuFdIynHgJyAL2oHz5VhfrKao85zU7brcxZXp9c0JCvtz+HbtRFLL4wDvCnHo6zyKCBHjommp0pQKLJ1TbaIuYaBOB0gf4QtK5DXn6Rk+czTGSraTc89S257zbMFT5vVU69VKzFTtafDUtiSlAX+TOhD0ID5kBOBoSRi4eIvuGyo1llGnYKI+; 25:8JYwOVuEl+IF5MhEVn2nDGceFEDVSM9xYxUI6G/ZN4xgaHZ70rvjt9g8SyrePLk8CHd04Ov/MWZs7V7oGBeL2Znd0VVW7/mDXgYdn9wST6PuQwcobF75sLxoyPWIXzLe3X+GI4n6h4jNMICnjCaXFRKvmZq0IhMOx+1p540VEQrjLGWnkSNLN6HxOzEAp8vMieUZEHKiX4KHLpE/WTnDYuox35RZBWi/21tFqZtjnFIaDGI+vcbpeuysvCM6R5a7jFmm2smCk/Bv3GvmKytNdqv5/J1vA/eJMJVEZCVVQPb1eXWrQLm95z6is6aYgRRHSmKb6pnMA91DCeqSET7h+g==; 31:BaDgjK+l4b9/vK4IzCrBMF/kfcdtxmxBNFWTKZqtNMTxu27yUkkyRzYHxqv4CmUiUJoCSZXTd5g5MiZX2iJIdLOBbeCXRgsbGzkHLFFIPOMY+nuCbCj+5YWRKN/sJlqYALPpy61uaLznO7wxNApAveR0iXnQG3Z/HEX/Ij8rn78cGJtvFhsM0iMC80MEjR0Zpp1P3ytcGAgnf6GPV5Vhyy0tL55nfxiqIKFovA/nLHc= X-MS-TrafficTypeDiagnostic: HE1PR0501MB2044: X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; HE1PR0501MB2044; 20:oiwHYzDo3yZi2dGzdl6dRPi8+GO1yitpo3QEZZoaBvIgfm6dPsJ9VOyYi1coa/OLy0dFeYl/Nsx7YfGxBgu0tS2gZIevbgi1Inpz4HXLn92PWyvu5Vx5upz63MvD+jLNhLqubAbxDQmDT1qxE6dGngfJQ3KnVt0VorTBP2AsE9or3HFjRI+hVSfkwAlipnKqNLHZkydAk/WQWYEzEB6WPDcPDA18tUxOJD5ipkg2GziiJgLwymlBv5k5nzcQSDyMnl5R+4OrYGfGTsC2Uwe42DACWuOAd9oCa6TaCRzwQVjkooIYOvDXJgJWzIwdrrwWeS1j7lPVdV179klPnu2e2md+c5ptaDH8gY0OeV3F2bLXrWqb5yGyYUK7alFpM59Mjf/g28YCXZQJGn8VSZ00L8eIwzU5Jvm/1UGOYDd4R7SfHfa4w0sPVkf74F/nxR4CmTelVeNGmYexzwXuKRESS5axbeM8edOngnh/QliFbjPDPkZ8/906rKzR0HgRgDYw; 4:RvGL/Y3DP0YsoIf/FPDpN+Qhsx5BraLsTdg9eHGYh4AEtBeeq9KK3vTfXmM9b9nt8wWPon3uyNSV8+kAYyoi2oLwx+HJy4gw9/bjSeN3ERqsLaOCiDxes0AE5NzjxlUBMgMborZSTGpJxmXvrnUmB90JZmaYtuqFYpPdjkRuk6qKgfbsJx9/qCn79Bf4Y9RbTnTvaf+fT8zwTdbgAwGovd4sB/31+z0IKPRqX4zL7Yut7Fnfw8dSDptzA1llyXkWFBpdSYUAZ8PMdwqSwsbTbCTMr6ZJF8fUKICwi1iXjsQ= X-Exchange-Antispam-Report-Test: UriScan:(788757137089); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0501MB2044; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0501MB2044; X-Forefront-PRVS: 04270EF89C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(7370300001)(4630300001)(6009001)(39860400002)(189002)(199003)(24454002)(66066001)(97736004)(47776003)(478600001)(6666003)(83506001)(4001350100001)(2870700001)(9686003)(33656002)(23756003)(305945005)(55016002)(106356001)(86362001)(2906002)(189998001)(53936002)(229853002)(110136004)(7736002)(98436002)(81166006)(6506006)(50466002)(54356999)(8676002)(105586002)(81156014)(50986999)(76176999)(6246003)(68736007)(42186005)(1076002)(2950100002)(101416001)(6116002)(6916009)(25786009)(5660300001)(7350300001)(4326008)(3846002)(316002)(18370500001)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0501MB2044; H:yongseok-MBP.local; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0501MB2044; 23:iqvqdSnZOxXLk5nIULnbxpkRmkpLfl9a0fD1T?= =?iso-8859-1?Q?SG2U3vwF2mxrX/rV69rlPWGKRp1tIUos/s2nV0amgEpAq4EIc4bscAj2UT?= =?iso-8859-1?Q?3CWuo6/FYdd6qkxOKUdCEi1+uq/naGvR1MHpDnnGkR7gFppWYwA0uTxCtv?= =?iso-8859-1?Q?bVFYbcH8uirhM4n4YQJPHuXQ9KhzSZi823YKj2vlASSdubOapK3RJGm76y?= =?iso-8859-1?Q?niUyG+IQSkp1mF5qy2hwIUbBdtDQdyHizikSzwd3e+qGDn6q5zHAH8KLbm?= =?iso-8859-1?Q?34iZ5Fje1c5hqcKcz+L5WCsnp4sdFy1l4eG1sh6d1rcZ86YcMvJWPDdxdT?= =?iso-8859-1?Q?GeX6IsFtii38NxJIWhSvjo70KzH0GYI9HrpJIoIr2xabEBy1Xko7KijAZd?= =?iso-8859-1?Q?9oMK57oB5HRd2FJ4JrEBtv+xV2aJGZF3KGMaN46mw2P++yPQxVJuS5WUBj?= =?iso-8859-1?Q?IXEdZX7TT5ouf+HQzXey48as7aX3lNe5LFZbb5y/xT931IYlb826VQ2mkv?= =?iso-8859-1?Q?VNpLgffrbK9s/HXimoR9SThgqytgh9R13ONcsWsEVf8GrTpBKnpgkAcuPb?= =?iso-8859-1?Q?uq9ebDVrlLipMJ12NuRxdD4DDAosjz/E9z5+rNVKT/v6ixeV1tO9QrVoDf?= =?iso-8859-1?Q?3FNMbnqD/R78O2vIQpCenQN4c/EHGFecjjDXlGfiKJ80/+A3UHgHj9FTjo?= =?iso-8859-1?Q?8dhxUt8N9/6wRVBhSNgB7o7dSIBFWrcjFjmCWQbnwadFZyh0+bZmz0OQvJ?= =?iso-8859-1?Q?/bz9xDcMSrH/o1Wi6v28AJmWnpuGFYkSzEAPX5PSA7AuQVdc4MUTcyN4DW?= =?iso-8859-1?Q?bzf7fu/GL7XXzxbQAwtZyTrlopwr+vdk885dpfHT8CPZxY8j8fU84jLhj1?= =?iso-8859-1?Q?lsfV+w7z2w1A053FLXIJVNRj2so8LFc8gGMdPo/5raC2dRLtEzzdvhvk3V?= =?iso-8859-1?Q?XTQzFV9ed/q59GD9JFRNORfOUCR/xiyT27S9/LfMrxm9Y3v7uurSTei2Zf?= =?iso-8859-1?Q?Fi9Nw1Vflrzd6yG6WNk32eojnj3zWdgtJ2lWXAYgz3EFBpYlEVTcXy/r/a?= =?iso-8859-1?Q?LvZfofmXsYz+coQfXwpEbNcVcqfRuLnO/umKeoUoFKWnULFZae7oKPvoYx?= =?iso-8859-1?Q?wVDe2rt8OUUhInzL3aaMFzw5lTpbBUAjsi6FOMxxoZXba9o7cnbE28wzPV?= =?iso-8859-1?Q?lM78ywBUsHlNWY1Ir28ZAuU9BJLLXuRtZ/6B+iV1hsov7ROGWSA0RoRk/l?= =?iso-8859-1?Q?/eMIr77GrXxo04WruDa04LRDeWhDaIA0k7XhDwjTyyhDa6beK7I2VbfNX7?= =?iso-8859-1?Q?S49kSweDuLjQGt5f790WvkIFfVI5FocHkvAl+1oMrRV6OlQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0501MB2044; 6:t+xX6CcW4IUAe8xqJzbqSzGEGWjE6QdPVqIZ/pT6ruuE1AOzBuYlC6GJMEm9E+r/sPTudtsuP33Wxf3KuOzJ6yintWAVCl8fLTikK9aQeIddWCuv5y92kypEdlcfrdo11yxyM8MhIS/fA+3Swp48BjH6QG8a1+OYmTRIWaVejfyYjGsR+rrb3V4MNgKga2hcSEM2WeE3yvuEPu8/XdREetdeeeuw+ZVry9X3am7QA7r7gTYRZo0qG+qaOUa5YOLSsUyeWmRA7OFLE9w+zd3f2gwndMvWe0Oq1HuLBVrTvOpxdzt0P57rN/2yVOQgxd8w/xzQpQzKwy8CRxfib6OBZg==; 5:Jd2fXE7KiJpdlaYYw1ZRPfjhCfyR1B0YE2OVWN/lfR7egTCjcQjB74q0UpXUeKqPqmOqY7H1CdVuvpR4biB2SxbOLn4ozZR0dYJ5LR/vQXyiWufloGlBan3/4i29O0avyDw3JY++CQsd8FO4/3uMXjovnqvsTOfgrQ4JMaOhhww=; 24:l8MiRFWbJyirqMioBrsp2zUDheOTnhKeehG1SvY+eZySK+GiSchS0SFxR2RYEAedOidB/iZvrfFuflX7KfvLo4515Crq8cijdZQYbD14E0M=; 7:Xt3J95XnKHvG/WZswvltFfouQf1vBhW+weaD+Eh384m6nwqW+Pb2KZeZIZnTMcHwzsVN7DskFC70Z28RhAyquaL0j2g3DTePJm0iHSReaI/tvQJ1TLXX6d32rwaa8Wg4VTQYkmB0xhaCsAueCn+keOROb7Ci8VRb05oqqdbM1ORf3IVncycvzZR8jl3FOAEU8keV5WHDN73XPuGcqkyLO3MPqp4aJmdWpSfkRMtxQKs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2017 23:28:20.7480 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0501MB2044 Subject: Re: [dpdk-dev] [RFC PATCH 1/1] net/mlx5: add vectorized Rx/Tx burst for ARM 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: , X-List-Received-Date: Mon, 11 Sep 2017 23:28:24 -0000 Hi Nelio, Sorry for delayed reply. I was on vacation for a week. On Mon, Sep 04, 2017 at 02:37:05PM +0200, Nélio Laranjeiro wrote: > Hi Yongseok, > > Some questions/comments below, > > On Fri, Aug 25, 2017 at 11:40:23AM -0700, Yongseok Koh wrote: > > New Rx/Tx burst functions are added using NEON vector instructions for ARM > > CPU. > > > > Signed-off-by: Yongseok Koh [...] > > @@ -1542,7 +1542,7 @@ priv_select_rx_function(struct priv *priv) > > if (priv_check_vec_rx_support(priv) > 0) { > > priv_prep_vec_rx_function(priv); > > priv->dev->rx_pkt_burst = mlx5_rx_burst_vec; > > - DEBUG("selected RX vectorized function"); > > + WARN("selected RX vectorized function"); > > This should remain in DEBUG level. My bad, that was just for debugging purpose while I was testing the code. Will change it back when I send out a patchset for integration. > > } else { > > priv->dev->rx_pkt_burst = mlx5_rx_burst; > > } > > diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h > > index 608072f7e..01e95b466 100644 > > --- a/drivers/net/mlx5/mlx5_prm.h > > +++ b/drivers/net/mlx5/mlx5_prm.h > > @@ -224,6 +224,20 @@ struct mlx5_mpw { > > }; > > > > /* CQ element structure - should be equal to the cache line size */ > > +#if 0 > > +struct mlx5_cqe { // 16B > > + uint16_t hdr_type_etc; > > + uint8_t pkt_info; > > + uint8_t sop_drop_qpn; /* flow_tag */ > > + uint16_t byte_cnt; > > + uint16_t vlan_info; > > + uint32_t rx_hash_res; > > + uint8_t timestamp; > > + uint8_t wqe_counter; > > + uint8_t rsvd4; > > + uint8_t op_own; > > +}; > > Seems this structure will never be used due to the #if 0. This code was just for SW emulation to emulate the result of 16B CQE size. I should've trimmed all the debugging/testing code before I sent out this RFC. [...] > > @@ -1064,6 +1119,10 @@ rxq_ctrl_setup(struct rte_eth_dev *dev, struct rxq_ctrl *rxq_ctrl, > > (void *)dev, strerror(ret)); > > goto error; > > } > > +#ifdef SW_EMULATION > > + rxq_cqe_comp_en = priv->cqe_comp; > > + emulate_rxq_cqe_setup(&tmpl); > > +#endif > > /* Reuse buffers from original queue if possible. */ > > if (rxq_ctrl->rxq.elts_n) { > > assert(1 << rxq_ctrl->rxq.elts_n == desc); > > @@ -1092,7 +1151,9 @@ rxq_ctrl_setup(struct rte_eth_dev *dev, struct rxq_ctrl *rxq_ctrl, > > /* Update doorbell counter. */ > > rxq_ctrl->rxq.rq_ci = desc >> rxq_ctrl->rxq.sges_n; > > rte_wmb(); > > +#ifndef SW_EMULATION > > *rxq_ctrl->rxq.rq_db = htonl(rxq_ctrl->rxq.rq_ci); > > +#endif > > DEBUG("%p: rxq updated with %p", (void *)rxq_ctrl, (void *)&tmpl); > > assert(ret == 0); > > return 0; > > What is the purpose of this SW_EMULATION? That's to emulate packet Rx without getting device involved. And it was to optimize cycle budget from pure SW perspective. This will get removed in a formal patch. Please understand that it is RFC code. > > diff --git a/drivers/net/mlx5/mlx5_rxtx.h b/drivers/net/mlx5/mlx5_rxtx.h > > index 7de1d1086..6aae00b77 100644 > > --- a/drivers/net/mlx5/mlx5_rxtx.h > > +++ b/drivers/net/mlx5/mlx5_rxtx.h > > @@ -602,11 +602,12 @@ mlx5_tx_dbrec(struct txq *txq, volatile struct mlx5_wqe *wqe) > > uint64_t *dst = (uint64_t *)((uintptr_t)txq->bf_reg); > > volatile uint64_t *src = ((volatile uint64_t *)wqe); > > > > - rte_wmb(); > > + rte_compiler_barrier(); > > *txq->qp_db = htonl(txq->wqe_ci); > > /* Ensure ordering between DB record and BF copy. */ > > rte_wmb(); > > *dst = *src; > > + rte_wmb(); > > } > > Is this better to have the rte_compiler_barrier() instead of the rte_io_wmb()? You are right. I'm also aware of Shahaf's patch - "net/mlx5: replace memory barrier type". This code block was to include Shahaf's patch for testing and I've already included Shahaf's final patch. As his patch's been merged, will remove this hunk in a formal patch. [...] > > +/* Verbs header. */ > > +/* ISO C doesn't support unnamed structs/unions, disabling -pedantic. */ > > +#ifdef PEDANTIC > > +#pragma GCC diagnostic ignored "-Wpedantic" > > +#endif > > +#include > > +#include > > +#include > > +#ifdef PEDANTIC > > +#pragma GCC diagnostic error "-Wpedantic" > > +#endif > > Should this patch be included before the upstream re-work? No, after the rework. Will change it properly then. [...] > > + vst1q_u8(dseg, desc); > > +#ifdef MLX5_PMD_SOFT_COUNTERS > > + tx_byte += DATA_LEN(pkt); > > +#endif > > + } > > +#ifdef MLX5_PMD_SOFT_COUNTERS > > + txq->stats.obytes += tx_byte; > > +#endif > > +} > > + > > +#if 0 > > #if 0? > > It does not help to read an RFC with embed code blocks not even compiled. Right. That was my mistake in rushing to meet the submission deadline. Sorry for the mess. Now, I've completed porting the commented part and I'll be able to send out a formal patchset soon. [...] > > + __asm__ volatile ( > > + /* A.1 load mCQEs into a 128bit register. */ > > + "ld1 {v16.16b - v17.16b}, [%[mcq]]\n\t" > > + /* B.1 store rearm data to mbuf. */ > > + "st1 {%[rearm].2d}, [%[e0]]\n\t" > > + "add %[e0], %[e0], #16\n\t" > > + "st1 {%[rearm].2d}, [%[e1]]\n\t" > > + "add %[e1], %[e1], #16\n\t" > > + /* C.1 combine data from mCQEs with rx_descriptor_fields1. */ > > + "tbl v18.16b, {v16.16b}, %[mcqe_shuf_m1].16b\n\t" > > + "tbl v19.16b, {v16.16b}, %[mcqe_shuf_m2].16b\n\t" > > + "sub v18.8h, v18.8h, %[crc_adj].8h\n\t" > > + "sub v19.8h, v19.8h, %[crc_adj].8h\n\t" > > + "orr v18.16b, v18.16b, %[rxdf].16b\n\t" > > + "orr v19.16b, v19.16b, %[rxdf].16b\n\t" > > + /* D.1 store rx_descriptor_fields1. */ > > + "st1 {v18.2d}, [%[e0]]\n\t" > > + "st1 {v19.2d}, [%[e1]]\n\t" > > + /* B.1 store rearm data to mbuf. */ > > + "st1 {%[rearm].2d}, [%[e2]]\n\t" > > + "add %[e2], %[e2], #16\n\t" > > + "st1 {%[rearm].2d}, [%[e3]]\n\t" > > + "add %[e3], %[e3], #16\n\t" > > + /* C.1 combine data from mCQEs with rx_descriptor_fields1. */ > > + "tbl v18.16b, {v17.16b}, %[mcqe_shuf_m1].16b\n\t" > > + "tbl v19.16b, {v17.16b}, %[mcqe_shuf_m2].16b\n\t" > > + "sub v18.8h, v18.8h, %[crc_adj].8h\n\t" > > + "sub v19.8h, v19.8h, %[crc_adj].8h\n\t" > > + "orr v18.16b, v18.16b, %[rxdf].16b\n\t" > > + "orr v19.16b, v19.16b, %[rxdf].16b\n\t" > > + /* D.1 store rx_descriptor_fields1. */ > > + "st1 {v18.2d}, [%[e2]]\n\t" > > + "st1 {v19.2d}, [%[e3]]\n\t" > > +#ifdef MLX5_PMD_SOFT_COUNTERS > > + "tbl %[byte_cnt].8b, {v16.16b - v17.16b}, %[len_shuf_m].8b\n\t" > > +#endif > > + :[byte_cnt]"=&w"(byte_cnt) > > + :[mcq]"r"(p), [rxdf]"w"(rxdf), [rearm]"w"(rearm), > > + [e3]"r"(e3), [e2]"r"(e2), [e1]"r"(e1), [e0]"r"(e0), > > + [mcqe_shuf_m1]"w"(mcqe_shuf_m1), > > + [mcqe_shuf_m2]"w"(mcqe_shuf_m2), > > + [crc_adj]"w"(crc_adj), [len_shuf_m]"w"(len_shuf_m) > > + :"memory", "v16", "v17", "v18", "v19"); > > Is not there a better way instead of writing all those assembly instructions, > maybe by using a set of macros? [...] > It follows the same algorithm as for x86 side, unless the fact you seem to > need a lot of assembly instruction due to the missing instrasics I suppose. Yes, the main reason for this inline assembly was due to lack of load instrinsics - vld1q_u64_x3() and inefficiency of a shuffle intrinsic vqtbl3q_u8() in the gcc-5.4.0-6ubuntu1~16.04.4. I'm quite sure that using vld1q_u64_x3() is more efficient than three vld1q_u64() although vld1q_u64_x3() internally executes 3 micro-ops in NEON. This is used to load the first three 16byte blocks from a CQE. And in vqtbl3q_u8() of arm_neon.h, it uses a redundant load instruction to load data into 3 consecutive SIMD registers. This caused hotspots in perf-annotate. > Do you already have some good feedbacks in performance? Currently, I'm seeing 45% improvement comparing with regular rx/tx_burst in case of single core. Also, when I firstly wrote the code, I could get ~20% benefit by removing the hottest instructions with inline assembly. I also concerned about difficulty for maintenance and code reading, so I tried to minimize the assembly part as much as possible and it is limited to fetching/manipulating CQE data on Rx, which is most critical in performance. Thanks, Yongseok