[{"id":1810669,"web_url":"http://patchwork.ozlabs.org/comment/1810669/","msgid":"","list_archive_url":null,"date":"2017-11-27T14:47:23","subject":"Re: [ovs-dev] [PATCH v4 0/2] vHost Dequeue Zero Copy","submitter":{"id":68449,"url":"http://patchwork.ozlabs.org/api/people/68449/","name":"Jan Scheurich","email":"jan.scheurich@ericsson.com"},"content":"Hi Ciara,\n\n> Thanks for your feedback. The limitation is only placed on phy port queues on the VP (vhost -> phy) path. VV path and PV path are not\n> affected.\n\nYes, you are right. VM to VM traffic is copied on transmit to the second VM.\n\n> > I would much rather put a requirement on tenants that their virtio drivers\n> > need to allocate enough virtio packet buffers if they want their VM to use\n> > zero-copy vhostuser ports. Or is the critical resource owned and managed by\n> > Qemu and we'd need a patch on Qemu to overcome this limit?\n\nCan you comment on that? Can a user also reduce the problem by configuring\na) a larger virtio Tx queue size (up to 1K) in Qemu, or\nb) a larger mempool for packets in Tx direction inside the guest (driver?) \n\n> >\n> > And what about increased packet drop risk due to shortened tx queues?\n> \n> I guess this could be an issue. If I had some data to back this up I would include it in the documentation and mention the risk.\n> If the risk is unacceptable to the user they may choose to not enable the feature. It's disabled by default so shouldn't introduce an issue for\n> the standard case.\n\nYes, but it would be good to understand the potential drawback for a better judgement of the trade-off between better raw throughput and higher loss risk.\n\nRegards, Jan","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ericsson.onmicrosoft.com\n\theader.i=@ericsson.onmicrosoft.com header.b=\"Uf8AUcEy\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=jan.scheurich@ericsson.com; "],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ylqQg5jXrz9sP9\n\tfor ;\n\tTue, 28 Nov 2017 01:47:39 +1100 (AEDT)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 2530CC84;\n\tMon, 27 Nov 2017 14:47:29 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 8B61EBCF\n\tfor ; Mon, 27 Nov 2017 14:47:27 +0000 (UTC)","from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id B8DCD47E\n\tfor ; Mon, 27 Nov 2017 14:47:26 +0000 (UTC)","from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63])\n\tby sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id\n\tEB.4B.09556.C752C1A5; Mon, 27 Nov 2017 15:47:25 +0100 (CET)","from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145)\n\tby oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server\n\t(TLS) id 14.3.352.0; Mon, 27 Nov 2017 15:47:24 +0100","from VI1PR0702MB3839.eurprd07.prod.outlook.com (52.134.7.160) by\n\tVI1PR0702MB3837.eurprd07.prod.outlook.com (52.134.1.148) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.282.3; Mon, 27 Nov 2017 14:47:23 +0000","from VI1PR0702MB3839.eurprd07.prod.outlook.com\n\t([fe80::15be:fedb:29bc:caf0]) by\n\tVI1PR0702MB3839.eurprd07.prod.outlook.com\n\t([fe80::15be:fedb:29bc:caf0%13]) with mapi id 15.20.0282.002;\n\tMon, 27 Nov 2017 14:47:23 +0000"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-AuditID":"c1b4fb30-a25ff70000002554-59-5a1c257c233d","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ericsson.onmicrosoft.com; s=selector1-ericsson-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=cyly8CNHxKedmy46YrUpByHyygy4C3Q+NGLj2M90oPI=;\n\tb=Uf8AUcEyEKmoag1vb/9dET3N2Kr/jqzmPPd8pER+mDsN+sEGaA1Sy2v5Cl8ONNJk6/F2ThttyF3Iw5+fnjS1Zv95zwfETlhpJCJPiw8lb4+DldbZFab+9YXH337T0AuvVRopnakmUSTRHsiK3Tb28xehECScO9Jk+Vy7Z5STk04=","From":"Jan Scheurich ","To":"\"Loftus, Ciara\" ","Thread-Topic":"[PATCH v4 0/2] vHost Dequeue Zero Copy","Thread-Index":"AQHTU7xEYscyPuEyjk6oBeAJ+eEbc6MjUD6AgAAzchCABOrtgIAABU7Q","Date":"Mon, 27 Nov 2017 14:47:23 +0000","Message-ID":"","References":"<1509614611-4233-1-git-send-email-ciara.loftus@intel.com>\n\t\n\t\n\t<74F120C019F4A64C9B78E802F6AD4CC278E47FBA@IRSMSX106.ger.corp.intel.com>","In-Reply-To":"<74F120C019F4A64C9B78E802F6AD4CC278E47FBA@IRSMSX106.ger.corp.intel.com>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","authentication-results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ericsson.onmicrosoft.com\n\theader.i=@ericsson.onmicrosoft.com header.b=\"Uf8AUcEy\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=jan.scheurich@ericsson.com; "],"x-originating-ip":"[129.192.10.2]","x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; VI1PR0702MB3837;\n\t6:8MNluDv50tcWWuD+p7OHZ4/IVEt5cKU5/PHgPb0OdnoWtmB/QRcckuM5MNUxguVKzzdxzvnkwC45Uy/AsCLLVQaH+Rm91XwATAgc+5+fG6vRiRe4DTMBH1ZhMH1e9MwpvqfRuToZbnzk3YzyeeIqV5XK8hDhKBubqkYzD4W7XeZbJf5nh0JxavECX12WoQjVwjEwxGnT9Msy1NPafSgfgO2XyWt2zY6RJnL3FbkJRbDMS1LL+5ImgUs2ub8O1mICMqecd7AJPQGiPPgtuLHL787Gz4kcwpwUsTDqd97CDUbLz48Q+2+0KszrFhZbXp9sRTpGrLPkoNT2UxJcInimehh15wqfr3HEmlGCtu5OLFo=;\n\t5:Nf+ZvORCuY8fR0u9fg30e0yQl1WD9TyDCpwr/6UzkuNPAzIYdiMMvFwYoCmMmzOtrBZLmEcpJXZoirJc6ZivCLrN/53ETXsAx5Gh8C+vwXIVJpK0hJy6kuFSvukaMX3PhKsoazHGJJUI1hWTp57yDY1YAUvDnkDEeXNsoYV9G8k=;\n\t24:OqhNqVZeL8powAN31cUtkawobn+qcRT+5qWrEAxd0fNCFSPo4PHotDkHgEevivtGE0e8NvbLnV8h2FyOpVtbvnI3N89biJ7vlbMTFVbKPMg=;\n\t7:Q7q+/X/UNqxeCZYcSehk+O8X4m3wZsEYYO6mF4pfxPWlGKv5ZejY3G+8Helo5vJqsifEOxLwPXs1wPHQkhMDGW9bySRcRJtEJ7XUZr7nOPB5WvC5BjFC6UBL2GMayY20noplim3f5n3Uuux4AXqx2hepUQCAMeKrIRQHsfamvaDgrEvF0TDR9GgBtvUcom993EXjTQr7+eA779/8/+KvFWLn0qi9ETgLm++AOfywXpQOK+GaKzASjLoP6uY1ihSo","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"c15d25aa-aaea-4f1f-d041-08d535a5c4d9","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603199);\n\tSRVR:VI1PR0702MB3837; ","x-ms-traffictypediagnostic":"VI1PR0702MB3837:","x-microsoft-antispam-prvs":"","x-exchange-antispam-report-test":"UriScan:(17755550239193);","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231022)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(6072148)(201708071742011);\n\tSRVR:VI1PR0702MB3837; BCL:0; PCL:0;\n\tRULEID:(100000803101)(100110400095); SRVR:VI1PR0702MB3837; ","x-forefront-prvs":"0504F29D72","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(366004)(346002)(376002)(39860400002)(189002)(199003)(8936002)(6916009)(68736007)(5660300001)(2950100002)(54906003)(2900100001)(8676002)(81156014)(81166006)(305945005)(7736002)(106356001)(6116002)(102836003)(316002)(33656002)(55016002)(99286004)(93886005)(6246003)(50986999)(76176999)(54356999)(74316002)(53936002)(3846002)(101416001)(9686003)(7696005)(25786009)(105586002)(97736004)(66066001)(4326008)(478600001)(229853002)(189998001)(5250100002)(2906002)(3280700002)(86362001)(6506006)(6436002)(14454004)(3660700001);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0702MB3837;\n\tH:VI1PR0702MB3839.eurprd07.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; MX:1; A:1; LANG:en; ","received-spf":"None (protection.outlook.com: ericsson.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","MIME-Version":"1.0","X-MS-Exchange-CrossTenant-Network-Message-Id":"c15d25aa-aaea-4f1f-d041-08d535a5c4d9","X-MS-Exchange-CrossTenant-originalarrivaltime":"27 Nov 2017 14:47:23.0184\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"92e84ceb-fbfd-47ab-be52-080c6b87953f","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"VI1PR0702MB3837","X-OriginatorOrg":"ericsson.com","X-Brightmail-Tracker":"H4sIAAAAAAAAA02SbUhTYRTHee692+5Gt27Ll5POyoEfEp2mhiOkNCTmhyDMNEalSy+6ppts\n\taqkIIkVty1KydCYo27Qw8zXRdEKtYm7RC70gRkiiqfuQoF9cVJrbs6Bv/3P+v/OcFx6aFJt4\n\tEbRaW8HptapSKV9EWc6OHYuvi5EoE7vmkPzqbQspf/XaQcqH5t/w0kmFzeElFEuzW+gUoRSl\n\tFXGl6ipOn3C0QFQyYlvll7ftvNLQ+I2oRyuMCQlpYFPg0b0OngmJaDH7AkHHjbcEDqYRWD9N\n\t8/wUxTaSsG7XY6ONgAe+uwgHywjcw62UCdE0n02E+5Pp/oIQNg7+rHkDxSSbB46mp4Rf72GT\n\twffYLsBMCjRd36KwPgEetwPhZjGwYjWTfs2wBTAyNxwcb5CAgYa+wENCNgd6G/sDEGLDYMOD\n\t8yQbDl8WOwm8Gwt2xzsS61DwLmzyMH8ejHdmeDh/AAbXPBTWUfCh0xxYDNiXAuho2RJgQwaj\n\tzT8Q1ifh2uozEkM9CG6Z14JQHCxNDQYhHXz2eYNTHAGfvUuAC+wkuD03+diQgMv4kWpCsvb/\n\tJm/fviTJHoSBiQScjoYW87ygPXCN3eC2LFJdiOpFoQbOcLGsOClJxunVhQaDTivTchXDaPuH\n\tPH/yK3EceZcznIilkXQHcylaohTzVFWG6jInApqUhjBR85FKMVOkqq7h9Lp8fWUpZ3CiSJqS\n\thjPuLEYpZotVFZyG48o5/T+XoIUR9ah7YCJZKq/a+7WwVmNXZHe3jjprNZkHvMb0urz+Zast\n\tIoe/L/dcyNT390PWZC4tNbUmf2xhlskc/9nWM+s6Y7mcrXBVyhjPrqywevXMVKs0tjlWHG6d\n\tvpArzudspyW/hev7dSsbpsO24xmOzdR4o0azUdCn2XhYViJ3TS4IpJShRHUoltQbVH8B4QtA\n\tBh0DAAA=","X-Spam-Status":"No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,\n\tDKIM_VALID,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"dev@openvswitch.org\" ","Subject":"Re: [ovs-dev] [PATCH v4 0/2] vHost Dequeue Zero Copy","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1811527,"web_url":"http://patchwork.ozlabs.org/comment/1811527/","msgid":"<74F120C019F4A64C9B78E802F6AD4CC278E49280@IRSMSX106.ger.corp.intel.com>","list_archive_url":null,"date":"2017-11-28T15:37:47","subject":"Re: [ovs-dev] [PATCH v4 0/2] vHost Dequeue Zero Copy","submitter":{"id":67255,"url":"http://patchwork.ozlabs.org/api/people/67255/","name":"Ciara Loftus","email":"ciara.loftus@intel.com"},"content":"> \r\n> Hi Ciara,\r\n> \r\n> > Thanks for your feedback. The limitation is only placed on phy port queues\r\n> on the VP (vhost -> phy) path. VV path and PV path are not\r\n> > affected.\r\n> \r\n> Yes, you are right. VM to VM traffic is copied on transmit to the second VM.\r\n> \r\n> > > I would much rather put a requirement on tenants that their virtio drivers\r\n> > > need to allocate enough virtio packet buffers if they want their VM to use\r\n> > > zero-copy vhostuser ports. Or is the critical resource owned and\r\n> managed by\r\n> > > Qemu and we'd need a patch on Qemu to overcome this limit?\r\n> \r\n> Can you comment on that? Can a user also reduce the problem by\r\n> configuring\r\n> a) a larger virtio Tx queue size (up to 1K) in Qemu, or\r\n\r\nIs this possible right now without modifying QEMU src? I think the size is hardcoded to 256 at the moment although it may become configurable in the future. If/when it does, we can test and update the docs if it does solve the problem. I don’t think we should suggest modifying the QEMU src as a workaround now.\r\n\r\n> b) a larger mempool for packets in Tx direction inside the guest (driver?)\r\n\r\nUsing the DPDK driver in the guest & generating traffic via testpmd I modified the number of descriptors given to the virtio device from 512 (default) to 2048 & 4096 but it didn't resolve the issue unfortunately.\r\n\r\n> \r\n> > >\r\n> > > And what about increased packet drop risk due to shortened tx queues?\r\n> >\r\n> > I guess this could be an issue. If I had some data to back this up I would\r\n> include it in the documentation and mention the risk.\r\n> > If the risk is unacceptable to the user they may choose to not enable the\r\n> feature. It's disabled by default so shouldn't introduce an issue for\r\n> > the standard case.\r\n> \r\n> Yes, but it would be good to understand the potential drawback for a better\r\n> judgement of the trade-off between better raw throughput and higher loss\r\n> risk.\r\n\r\nI ran RFC2544 0% packet loss tests for ZC on & off (64B PVP) and observed the following:\r\n\r\nMax rate (Mpps) with 0% loss\r\nZC Off 2599518\r\nZC On 1678758\r\n\r\nAs you suspected, there is a trade-off. I can mention this in the docs.\r\n\r\nThanks,\r\nCiara\r\n\r\n> \r\n> Regards, Jan","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ymSVC3PWvz9t2Z\n\tfor ;\n\tWed, 29 Nov 2017 02:37:55 +1100 (AEDT)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id A9891C01;\n\tTue, 28 Nov 2017 15:37:52 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 3044FBAD\n\tfor ; Tue, 28 Nov 2017 15:37:51 +0000 (UTC)","from mga01.intel.com (mga01.intel.com [192.55.52.88])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id BF57B4FE\n\tfor ; Tue, 28 Nov 2017 15:37:50 +0000 (UTC)","from orsmga003.jf.intel.com ([10.7.209.27])\n\tby fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t28 Nov 2017 07:37:50 -0800","from irsmsx102.ger.corp.intel.com ([163.33.3.155])\n\tby orsmga003.jf.intel.com with ESMTP; 28 Nov 2017 07:37:49 -0800","from irsmsx112.ger.corp.intel.com (10.108.20.5) by\n\tIRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Tue, 28 Nov 2017 15:37:48 +0000","from irsmsx106.ger.corp.intel.com ([169.254.8.36]) by\n\tirsmsx112.ger.corp.intel.com ([169.254.1.12]) with mapi id\n\t14.03.0319.002; Tue, 28 Nov 2017 15:37:48 +0000"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.44,468,1505804400\"; d=\"scan'208\";a=\"7217841\"","From":"\"Loftus, Ciara\" ","To":"Jan Scheurich ","Thread-Topic":"[PATCH v4 0/2] vHost Dequeue Zero Copy","Thread-Index":"AQHTU7xSICO74TbUe0u9Wj/fY6jtaKMjUD6AgAA2+wCABOSAIIAAChKAgAFguOA=","Date":"Tue, 28 Nov 2017 15:37:47 +0000","Message-ID":"<74F120C019F4A64C9B78E802F6AD4CC278E49280@IRSMSX106.ger.corp.intel.com>","References":"<1509614611-4233-1-git-send-email-ciara.loftus@intel.com>\n\t\n\t\n\t<74F120C019F4A64C9B78E802F6AD4CC278E47FBA@IRSMSX106.ger.corp.intel.com>\n\t","In-Reply-To":"","Accept-Language":"en-GB, en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjVlZmZjZTMtMzYwNy00MDEwLWFkNTItNzY4NDE4YjIwMzI2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Ikp6d1BKRTUzYzk0bjBacHVJV1IxeU9hUmhTZkhTaFNLKzl0akRHeklDWEE9In0=","x-ctpclassification":"CTP_IC","dlp-product":"dlpe-windows","dlp-version":"11.0.0.116","dlp-reaction":"no-action","x-originating-ip":"[163.33.239.182]","MIME-Version":"1.0","X-Spam-Status":"No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, \n\tT_RP_MATCHES_RCVD autolearn=ham version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"dev@openvswitch.org\" ","Subject":"Re: [ovs-dev] [PATCH v4 0/2] vHost Dequeue Zero Copy","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1811656,"web_url":"http://patchwork.ozlabs.org/comment/1811656/","msgid":"","list_archive_url":null,"date":"2017-11-28T17:04:15","subject":"Re: [ovs-dev] [PATCH v4 0/2] vHost Dequeue Zero Copy","submitter":{"id":68449,"url":"http://patchwork.ozlabs.org/api/people/68449/","name":"Jan Scheurich","email":"jan.scheurich@ericsson.com"},"content":"> > Can you comment on that? Can a user also reduce the problem by\r\n> > configuring\r\n> > a) a larger virtio Tx queue size (up to 1K) in Qemu, or\r\n> \r\n> Is this possible right now without modifying QEMU src? I think the size is hardcoded to 256 at the moment although it may become\r\n> configurable in the future. If/when it does, we can test and update the docs if it does solve the problem. I don’t think we should suggest\r\n> modifying the QEMU src as a workaround now.\r\n\r\nThe possibility to configure the tx queue size has been upstreamed in Qemu 2.10:\r\n\r\ncommit 9b02e1618cf26aa52cf786f215d757506dda14f8\r\nAuthor: Wei Wang \r\nDate: Wed Jun 28 10:37:59 2017 +0800\r\n\r\n virtio-net: enable configurable tx queue size\r\n\r\n This patch enables the virtio-net tx queue size to be configurable\r\n between 256 (the default queue size) and 1024 by the user when the\r\n vhost-user backend is used....\r\n\r\nSo you should be able to test larger tx queue sizes with Qemu 2.10.\r\n\r\n> \r\n> > b) a larger mempool for packets in Tx direction inside the guest (driver?)\r\n> \r\n> Using the DPDK driver in the guest & generating traffic via testpmd I modified the number of descriptors given to the virtio device from\r\n> 512 (default) to 2048 & 4096 but it didn't resolve the issue unfortunately.\r\n\r\nI re-read the virtio 1.0 spec and it states that the total number of virtio descriptors per virtqueue equals the size of the virtqueue. Descriptors just point to guest mbufs. The mempool the guest driver uses for mbufs is irrelevant. OVS as virtio device needs to return the virtio descriptors to the guest driver. That means the virtio queue size sets the limit on the packets in flight in OVS and physical NICs.\r\n\r\nI would like to add a statement in the documentation that explains this dependency between Qemu Tx queue size and maximum physical NIC Tx queue size when using the vhost zero copy feature on a port.\r\n\r\n> > > > And what about increased packet drop risk due to shortened tx queues?\r\n> > >\r\n> > > I guess this could be an issue. If I had some data to back this up I would\r\n> > include it in the documentation and mention the risk.\r\n> > > If the risk is unacceptable to the user they may choose to not enable the\r\n> > feature. It's disabled by default so shouldn't introduce an issue for\r\n> > > the standard case.\r\n> >\r\n> > Yes, but it would be good to understand the potential drawback for a better\r\n> > judgement of the trade-off between better raw throughput and higher loss\r\n> > risk.\r\n> \r\n> I ran RFC2544 0% packet loss tests for ZC on & off (64B PVP) and observed the following:\r\n> \r\n> Max rate (Mpps) with 0% loss\r\n> ZC Off 2599518\r\n> ZC On 1678758\r\n> \r\n> As you suspected, there is a trade-off. I can mention this in the docs.\r\n\r\nThat degradation looks severe.\r\nIt would be cool if you could re-run the test with a 1K queue size configured in Qemu 2.10 and NIC\r\n\r\nRegards, \r\nJan","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ericsson.onmicrosoft.com\n\theader.i=@ericsson.onmicrosoft.com header.b=\"R30iXuEq\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=jan.scheurich@ericsson.com; "],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ymVQ34Mlcz9t16\n\tfor ;\n\tWed, 29 Nov 2017 04:04:27 +1100 (AEDT)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 33A38CB9;\n\tTue, 28 Nov 2017 17:04:22 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 305E1CA6\n\tfor ; Tue, 28 Nov 2017 17:04:20 +0000 (UTC)","from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3356D3CC\n\tfor ; Tue, 28 Nov 2017 17:04:18 +0000 (UTC)","from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51])\n\tby sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id\n\t49.C5.08439.1179D1A5; Tue, 28 Nov 2017 18:04:17 +0100 (CET)","from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145)\n\tby oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server\n\t(TLS) id 14.3.352.0; Tue, 28 Nov 2017 18:04:17 +0100","from VI1PR0702MB3839.eurprd07.prod.outlook.com (52.134.7.160) by\n\tVI1PR0702MB3837.eurprd07.prod.outlook.com (52.134.1.148) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.282.3; Tue, 28 Nov 2017 17:04:15 +0000","from VI1PR0702MB3839.eurprd07.prod.outlook.com\n\t([fe80::15be:fedb:29bc:caf0]) by\n\tVI1PR0702MB3839.eurprd07.prod.outlook.com\n\t([fe80::15be:fedb:29bc:caf0%13]) with mapi id 15.20.0282.002;\n\tTue, 28 Nov 2017 17:04:15 +0000"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-AuditID":"c1b4fb25-d91ff700000020f7-18-5a1d9711f521","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ericsson.onmicrosoft.com; s=selector1-ericsson-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=UBHITLfp0exbZQWouXv92O78mcnW4jY1vwY1j2z0pls=;\n\tb=R30iXuEqv1t66rUPDf1uN4qGI4uCEYVH2PUuLfFBQev/v1rlZ+QKGpION4t/D6Fi2lhOj6hUaF7s8P1drNheYATQLVHYgqjKTuhPqN1XkskmRRiden1eJU3/Mhig+0G9yJyjGlunPyqqWrfSw6ymchI0FpLGdGYS8wMTE8QrV/k=","From":"Jan Scheurich ","To":"\"Loftus, Ciara\" ","Thread-Topic":"[PATCH v4 0/2] vHost Dequeue Zero Copy","Thread-Index":"AQHTU7xEYscyPuEyjk6oBeAJ+eEbc6MjUD6AgAAzchCABOrtgIAABU7QgAGiSoCAAABwIA==","Date":"Tue, 28 Nov 2017 17:04:15 +0000","Message-ID":"","References":"<1509614611-4233-1-git-send-email-ciara.loftus@intel.com>\n\t\n\t\n\t<74F120C019F4A64C9B78E802F6AD4CC278E47FBA@IRSMSX106.ger.corp.intel.com>\n\t\n\t<74F120C019F4A64C9B78E802F6AD4CC278E49280@IRSMSX106.ger.corp.intel.com>","In-Reply-To":"<74F120C019F4A64C9B78E802F6AD4CC278E49280@IRSMSX106.ger.corp.intel.com>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","authentication-results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ericsson.onmicrosoft.com\n\theader.i=@ericsson.onmicrosoft.com header.b=\"R30iXuEq\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=jan.scheurich@ericsson.com; "],"x-originating-ip":"[129.192.10.2]","x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; VI1PR0702MB3837;\n\t6:eGrIGzOthvaf67rvoqguGmkshg8EV5jGpIh+V6ao27MOwwi7IA5nkBtGJl0+L3mMUW5yhQFEP1P56+r/ZVaUS6mwoEzIiVwK2dj1YyTc/PPXONbwgdf98RbE6JpW7slqDotcK4EgkYzkHR4laB4H4HJ6GkPBTIi7zVReqtZqkFPPA8wtF9YcZmXemXyg9ZCxtUYYusmY8PXO6KYEelJDt1BoThCyrAgatiOZ0q/2ayuYujWV8XxdDHM5SwW8OID/sF6kkYfdopXBKl3liV0LTYl56pcvYxnkSLc223Z5FgnSW6te9PYVrAbT5llc0v4kn/1VJ7AMEzWAzcmnm7cAxmlH4Pr0C2AMUNlkjQ5sUMc=;\n\t5:1wpTzFUgbRPkWKR0LrfkKQwva6OKFSsOGo10TjEWU9Bc8CHTq0bGTNNVExL8C4Lf5UQciCT9alcy2zQUWO081umEJmVTUBLHfqBjqhn5YGyL2bZGt7KlPkrEtZ8ZefM2NBpx/opkMccWX4WEXOGcWvaTIMhI3UyZWJ6I1sgGaGw=;\n\t24:KYvRFguvT1wmZkJ6zGqQdnxdymmnV7Ik/g8D4UTAQKTDPWaKW07FZxJFUZ+PuUk7aAaJ1WJ5t9kSWA9T59nSj4HEyYXnNhUWNklWLsPZ4uA=;\n\t7:d9eG2LkpR8YIG1ZaJ7aS0Tz2GmjaTohYugL5PFuFl/QDX1HNAnuDjSK4BziXUGyc7Gi1Ir14VHldno+jESKH1GPLrsuk8mhLDKniq/9rpMSbpTs7LaBQS4bf9AtDiXlWxENukpUyityhXBT3cElzyLRBT7mFw/g/h5fmNGl9sm+rgZRsZnXPX8fixyG0RG3HkMPNYYuS1hheuv0qyrI2BQP/w5F2xFwKglx149jicpnAXzvXbjojWrEcVwpghX2T","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"f6fc03c1-e2db-47d4-0946-08d536820e1a","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199);\n\tSRVR:VI1PR0702MB3837; ","x-ms-traffictypediagnostic":"VI1PR0702MB3837:","x-microsoft-antispam-prvs":"","x-exchange-antispam-report-test":"UriScan:(228905959029699)(17755550239193);","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011);\n\tSRVR:VI1PR0702MB3837; BCL:0; PCL:0;\n\tRULEID:(100000803101)(100110400095); SRVR:VI1PR0702MB3837; ","x-forefront-prvs":"0505147DDB","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(366004)(39860400002)(346002)(376002)(189002)(199003)(86362001)(105586002)(97736004)(4326008)(478600001)(25786009)(7696005)(9686003)(3660700001)(6506006)(6436002)(14454004)(3280700002)(66066001)(229853002)(2906002)(5250100002)(54906003)(2950100002)(8676002)(81156014)(81166006)(305945005)(2900100001)(7736002)(189998001)(6916009)(316002)(5660300001)(8936002)(76176999)(54356999)(74316002)(93886005)(6246003)(106356001)(3846002)(53936002)(101416001)(50986999)(55016002)(99286004)(33656002)(102836003)(6116002)(68736007);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0702MB3837;\n\tH:VI1PR0702MB3839.eurprd07.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; MX:1; A:1; LANG:en; ","received-spf":"None (protection.outlook.com: ericsson.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","MIME-Version":"1.0","X-MS-Exchange-CrossTenant-Network-Message-Id":"f6fc03c1-e2db-47d4-0946-08d536820e1a","X-MS-Exchange-CrossTenant-originalarrivaltime":"28 Nov 2017 17:04:15.2247\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"92e84ceb-fbfd-47ab-be52-080c6b87953f","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"VI1PR0702MB3837","X-OriginatorOrg":"ericsson.com","X-Brightmail-Tracker":"H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42KZGbHdWFdwumyUwZyDchYt/TOZLY6e3sNs\n\tsfHhWVYHZo/Fe14yeTy7+Z8xgCmKyyYlNSezLLVI3y6BK2PSv9PMBRPkK/7cf8HewLhCrouR\n\tk0NCwETi4OpWxi5GLg4hgcOMEm1LF7BBOCcYJb4v+ssO4rAI9DJL/PozBapsBpPE3bWToJzn\n\tjBI7/+5h6WLk4GATMJCYvdsBZK6IgI7E348vWUFsZoFwiT0TdjKB2MICxhI/1i5hh6gxkZjQ\n\t/p8Fwg6T6Pu+lBFkDIuAqsSBL8UgYV6BBIn/6x6xQ6y6yCzx5VsLM0iCUyBE4vupeWDzGQXE\n\tgOw1TBC7xCVuPZnPBPGbgMSSPeeZIWxRiZeP/0HVx0p0Tr7OChFXkNjw8RQLhC0rcWl+NyOE\n\tfYRdonGVBYStJ7F14luouK/Ek2MLmUEOkhBYBgyipV+gBulIPNu7AaooX2L32QtQR3hL3Ht0\n\tgR2iYQmzxLYzv9ggEjIS/59tYZnAqDcLyeGzgAHALKApsX6XPkRYUWJK90P2WeDAEJQ4OfMJ\n\tywJGllWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgQnk4JbfqjsYL79xPMQowMGoxMP7dKps\n\tlBBrYllxZe4hRgkOZiUR3spJQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Jz15o4QE0hNLUrNT\n\tUwtSi2CyTBycUg2MiXN//VjVqz9NL2SVnBHDJBmnfCvFyZpBirf2L9ead6s5znbP9iimE2Yy\n\tIkbZ7cVTufO7Jzks2hrUZRD/53Dop6smW9d/uS6cfXC9rcKdQkb+h66XH6YkiPuWvjHlidbc\n\tEXZ2onbxMwnrav3XVkqL1XUf1nu4efv0bjHRfx7zqFOnzudaobUSS3FGoqEWc1FxIgDqHAPX\n\tHAMAAA==","X-Spam-Status":"No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,\n\tDKIM_VALID,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"dev@openvswitch.org\" ","Subject":"Re: [ovs-dev] [PATCH v4 0/2] vHost Dequeue Zero Copy","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1818631,"web_url":"http://patchwork.ozlabs.org/comment/1818631/","msgid":"<74F120C019F4A64C9B78E802F6AD4CC278E50794@IRSMSX106.ger.corp.intel.com>","list_archive_url":null,"date":"2017-12-08T12:59:32","subject":"Re: [ovs-dev] [PATCH v4 0/2] vHost Dequeue Zero Copy","submitter":{"id":67255,"url":"http://patchwork.ozlabs.org/api/people/67255/","name":"Ciara Loftus","email":"ciara.loftus@intel.com"},"content":"> \r\n> > > Can you comment on that? Can a user also reduce the problem by\r\n> > > configuring\r\n> > > a) a larger virtio Tx queue size (up to 1K) in Qemu, or\r\n> >\r\n> > Is this possible right now without modifying QEMU src? I think the size is\r\n> hardcoded to 256 at the moment although it may become\r\n> > configurable in the future. If/when it does, we can test and update the\r\n> docs if it does solve the problem. I don’t think we should suggest\r\n> > modifying the QEMU src as a workaround now.\r\n> \r\n> The possibility to configure the tx queue size has been upstreamed in Qemu\r\n> 2.10:\r\n> \r\n> commit 9b02e1618cf26aa52cf786f215d757506dda14f8\r\n> Author: Wei Wang \r\n> Date: Wed Jun 28 10:37:59 2017 +0800\r\n> \r\n> virtio-net: enable configurable tx queue size\r\n> \r\n> This patch enables the virtio-net tx queue size to be configurable\r\n> between 256 (the default queue size) and 1024 by the user when the\r\n> vhost-user backend is used....\r\n> \r\n> So you should be able to test larger tx queue sizes with Qemu 2.10.\r\n\r\nThat's good news, thanks for sharing the details.\r\nI tested with tx_queue_size=1024 and it didn't resolve the issue completely, but allowed for a greater number of txq descriptors for the NIC:\r\nFor default QEMU VQ size = 256, max n_txq_desc value = 256\r\nFor QEMY VQ size = 1024, max n_txq_desc value = 512\r\n\r\n> \r\n> >\r\n> > > b) a larger mempool for packets in Tx direction inside the guest (driver?)\r\n> >\r\n> > Using the DPDK driver in the guest & generating traffic via testpmd I\r\n> modified the number of descriptors given to the virtio device from\r\n> > 512 (default) to 2048 & 4096 but it didn't resolve the issue unfortunately.\r\n> \r\n> I re-read the virtio 1.0 spec and it states that the total number of virtio\r\n> descriptors per virtqueue equals the size of the virtqueue. Descriptors just\r\n> point to guest mbufs. The mempool the guest driver uses for mbufs is\r\n> irrelevant. OVS as virtio device needs to return the virtio descriptors to the\r\n> guest driver. That means the virtio queue size sets the limit on the packets in\r\n> flight in OVS and physical NICs.\r\n> \r\n> I would like to add a statement in the documentation that explains this\r\n> dependency between Qemu Tx queue size and maximum physical NIC Tx\r\n> queue size when using the vhost zero copy feature on a port.\r\n\r\nI will put my findings above in the documentation.\r\n\r\n> \r\n> > > > > And what about increased packet drop risk due to shortened tx\r\n> queues?\r\n> > > >\r\n> > > > I guess this could be an issue. If I had some data to back this up I would\r\n> > > include it in the documentation and mention the risk.\r\n> > > > If the risk is unacceptable to the user they may choose to not enable\r\n> the\r\n> > > feature. It's disabled by default so shouldn't introduce an issue for\r\n> > > > the standard case.\r\n> > >\r\n> > > Yes, but it would be good to understand the potential drawback for a\r\n> better\r\n> > > judgement of the trade-off between better raw throughput and higher\r\n> loss\r\n> > > risk.\r\n> >\r\n> > I ran RFC2544 0% packet loss tests for ZC on & off (64B PVP) and observed\r\n> the following:\r\n> >\r\n> > Max rate (Mpps) with 0% loss\r\n> > ZC Off 2599518\r\n> > ZC On 1678758\r\n> >\r\n> > As you suspected, there is a trade-off. I can mention this in the docs.\r\n> \r\n> That degradation looks severe.\r\n> It would be cool if you could re-run the test with a 1K queue size configured\r\n> in Qemu 2.10 and NIC\r\n\r\nI ran a couple of configurations, again 64B RFC2544 PVP:\r\n\r\nNIC-TXD Virtio-TXD ZC Mpps\r\n2048 256 off 2.105 # default case\r\n128 256 off 2.162 # checking effect of modifying NIC TXD (positive)\r\n2048 1024 off 2.455 # checking effect of modifying Virtio TXD (positive)\r\n128 256 on 1.587 # default zero copy case\r\n512 1024 on 0.321 # checking effect of modifying NIC & Virtio TXD (negative)\r\n\r\nFor the default non-zero copy case, it seems increasing the virtio queue size in the guest has a positive effect wrt packet loss, but has the opposite effect for the zero copy case.\r\nIt looks like the zero copy feature may increase the likelihood of packet loss, which I guess is a tradeoff for the increase pps you get with the feature.\r\n\r\nThanks,\r\nCiara\r\n\r\n\r\n> \r\n> Regards,\r\n> Jan","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ytXW26LmXz9s4s\n\tfor ;\n\tFri, 8 Dec 2017 23:59:42 +1100 (AEDT)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 4511CD2C;\n\tFri, 8 Dec 2017 12:59:38 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id C4B7FD1F\n\tfor ; Fri, 8 Dec 2017 12:59:36 +0000 (UTC)","from mga12.intel.com (mga12.intel.com [192.55.52.136])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id B255F1B4\n\tfor ; Fri, 8 Dec 2017 12:59:35 +0000 (UTC)","from orsmga001.jf.intel.com ([10.7.209.18])\n\tby fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t08 Dec 2017 04:59:35 -0800","from irsmsx103.ger.corp.intel.com ([163.33.3.157])\n\tby orsmga001.jf.intel.com with ESMTP; 08 Dec 2017 04:59:34 -0800","from irsmsx106.ger.corp.intel.com ([169.254.8.36]) by\n\tIRSMSX103.ger.corp.intel.com ([169.254.3.49]) with mapi id\n\t14.03.0319.002; Fri, 8 Dec 2017 12:59:33 +0000"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-Amp-Result":"SKIPPED(no attachment in message)","X-Amp-File-Uploaded":"False","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.45,377,1508828400\"; d=\"scan'208\";a=\"14260406\"","From":"\"Loftus, Ciara\" ","To":"'Jan Scheurich' ","Thread-Topic":"[PATCH v4 0/2] vHost Dequeue Zero Copy","Thread-Index":"AQHTU7xSICO74TbUe0u9Wj/fY6jtaKMjUD6AgAA2+wCABOSAIIAAChKAgAFguOCAAFfbgIAEUYsg","Date":"Fri, 8 Dec 2017 12:59:32 +0000","Message-ID":"<74F120C019F4A64C9B78E802F6AD4CC278E50794@IRSMSX106.ger.corp.intel.com>","References":"<1509614611-4233-1-git-send-email-ciara.loftus@intel.com>\n\t\n\t\n\t<74F120C019F4A64C9B78E802F6AD4CC278E47FBA@IRSMSX106.ger.corp.intel.com>\n\t\n\t<74F120C019F4A64C9B78E802F6AD4CC278E49280@IRSMSX106.ger.corp.intel.com>\n\t","In-Reply-To":"","Accept-Language":"en-GB, en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjRlOTY4ZmItNTk4ZS00ZTZjLTk4NzktNThmMjhiOWYwYTQ4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkxKUDJkUlorVUNON2l0a1NmUHZRT05QODZxODE4VGo2d0MySit4N0hLWEE9In0=","x-ctpclassification":"CTP_IC","dlp-product":"dlpe-windows","dlp-version":"11.0.0.116","dlp-reaction":"no-action","x-originating-ip":"[163.33.239.180]","MIME-Version":"1.0","X-Spam-Status":"No, score=-1.9 required=5.0 tests=BAYES_00, T_RP_MATCHES_RCVD\n\tautolearn=ham version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"dev@openvswitch.org\" ","Subject":"Re: [ovs-dev] [PATCH v4 0/2] vHost Dequeue Zero Copy","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}}]