From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0048.outbound.protection.outlook.com [104.47.40.48]) by dpdk.org (Postfix) with ESMTP id A2C332BFF for ; Fri, 9 Sep 2016 05:44:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5D0geFWZV7MahYjWUah4dsGhgNDoas8XesLyN+OK1R8=; b=JBxQbuypSjUXVFC6moGcbvqoqcxPFVPDRhpqHz8uaFWYjCcUwjTxAIacmFkadIHTHtYRMlWVlRGEqrCx90GkE9h4hx/Pu+0Oo+yTbLJFO/gqEzluxeTRPQ4dh34dIRlfXYKoZELT+BANY6NhRpQocwpvK5mqq35ukqMq0nEbUWQ= Received: from BN3PR03MB1494.namprd03.prod.outlook.com (10.163.35.145) by BN3PR03MB1495.namprd03.prod.outlook.com (10.163.35.146) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Fri, 9 Sep 2016 03:44:52 +0000 Received: from BN3PR03MB1494.namprd03.prod.outlook.com ([10.163.35.145]) by BN3PR03MB1494.namprd03.prod.outlook.com ([10.163.35.145]) with mapi id 15.01.0599.016; Fri, 9 Sep 2016 03:44:52 +0000 From: "Dey, Souvik" To: Yuanhan Liu , Maxime Coquelin CC: "stephen@networkplumber.org" , "huawei.xie@intel.com" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v2] add mtu set in virtio Thread-Index: AQHSAkl6WQg/4EBiA0S3i2wQUSIyp6BhI8iAgAxGsYCAAGIRgIABdKKAgAAFnACAAAHXgIABS0ag Date: Fri, 9 Sep 2016 03:44:52 +0000 Message-ID: References: <20160829230240.20164-1-sodey@sonusnet.com> <20160907032547.GG23158@yliu-dev.sh.intel.com> <20160908073029.GM23158@yliu-dev.sh.intel.com> <20160908075709.GN23158@yliu-dev.sh.intel.com> In-Reply-To: <20160908075709.GN23158@yliu-dev.sh.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sodey@sonusnet.com; x-originating-ip: [2601:191:8300:9cda:f8b8:9ca:b4df:2874] x-ms-office365-filtering-correlation-id: f2ff7c34-045c-4372-668e-08d3d863a84c x-microsoft-exchange-diagnostics: 1; BN3PR03MB1495; 6:NZGNs9z0+3eHHdOxdQl+/B0ELZRmZ3Al2T76xTPZWoO8aAq2gh4UnDAr6zLJy+nnmy4Fpovee2hsL4771x18QBWIVS6a8/kqodVpKIZvm7OHxOEC7LcvXaLbyTpvlPgNFdS8GLtVottkx7rVeqZwtaRboGG6G8jFiMOD1+xcQsdE6g/zL8wz5ggxJ6lAdKthHDA0aCQQ5kQWJF9CbZ4vXp//OPr0YOTS6obEfCExhzgFJhgJEKq31THMA36eSqNP26HidhBGdg9EcJ/4slcnMETsijPQMnKu1bE5jqrld6c=; 5:cUPcwWpWfs2tNnXr3P4JYlDyHwirHX+K+YVJ2o40SAmGUab1TSqavT9X7kvQXtNOsmkulOUSJwiqAMUKN8P+LHPTVkCVaXHjQLbr/i914yWFuhaBmTfGiuXytimeGd+GHj/i73HDZ9lLnnFVdB/f5g==; 24:PE+e4Ii/f3pLlocL4HzS3PttyPQhE4S/1WTOuSnJRYAyqOUxpwVHT+sCj6VxRB9rLfpKdHu96mbORyp1Djr6O3x53KSuwr1MlNvv4okIS7k=; 7:KHSW1E08skK5Xgk4yIZ00vMjLbVXFkzRpVhcCHn+RFguGlbIMTUoZn504sAJGQOGsZP88gcZ/B5tRkScgw+oTOpIFvlGdSkQSWNT3rDjE8ELwwnuL08R/aNjZoT1C8RzK8vmK0JLLCBTNP02fhh2zaTn8bNuAZKu45BQvEKiVWXbyM0Lwons3l1vvMcq3JjHeHkds7sGqAVXzLK7MCt4lIJy8IN0AOsvCWzZH/h5HhLng9xVsgRHlInAdmLWs+DX x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1495; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN3PR03MB1495; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1495; x-forefront-prvs: 00603B7EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(51914003)(43544003)(377454003)(199003)(13464003)(69234005)(189002)(87936001)(7736002)(19580405001)(19580395003)(81166006)(2900100001)(106356001)(8936002)(189998001)(97736004)(2950100001)(54356999)(105586002)(81156014)(50986999)(8676002)(7696004)(7846002)(2906002)(86362001)(92566002)(5001770100001)(76176999)(9686002)(76576001)(10400500002)(3660700001)(11100500001)(4326007)(6116002)(102836003)(74316002)(33656002)(586003)(99286002)(5002640100001)(122556002)(77096005)(305945005)(3280700002)(106116001)(5660300001)(101416001)(68736007)(93886004)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR03MB1495; H:BN3PR03MB1494.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2016 03:44:52.4281 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1495 Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio 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: Fri, 09 Sep 2016 03:44:56 -0000 Are we good to get this in for 16.11 and then revisit this when the VHOST i= mprovements comes in. This will atleast take care of the gap between 16.11 = and VHOST improvements coming in. -- Regards, Souvik -----Original Message----- From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]=20 Sent: Thursday, September 8, 2016 3:57 AM To: Maxime Coquelin Cc: Dey, Souvik ; stephen@networkplumber.org; huawei.xi= e@intel.com; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio On Thu, Sep 08, 2016 at 09:50:34AM +0200, Maxime Coquelin wrote: >=20 >=20 > On 09/08/2016 09:30 AM, Yuanhan Liu wrote: > >On Wed, Sep 07, 2016 at 11:16:47AM +0200, Maxime Coquelin wrote: > >> > >> > >>On 09/07/2016 05:25 AM, Yuanhan Liu wrote: > >>>On Tue, Aug 30, 2016 at 09:57:39AM +0200, Maxime Coquelin wrote: > >>>>Hi Souvik, > >>>> > >>>>On 08/30/2016 01:02 AM, souvikdey33 wrote: > >>>>>Signed-off-by: Souvik Dey > >>>>> > >>>>>Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey=20 > >>>>>") > >>>>>Reviewed-by: Stephen Hemminger > >>>>> > >>>>>Virtio interfaces should also support setting of mtu, as in case=20 > >>>>>of cloud it is expected to have the consistent mtu across the=20 > >>>>>infrastructure that the dhcp server sends and not hardcoded to 1500(= default). > >>>>>--- > >>>>>drivers/net/virtio/virtio_ethdev.c | 12 ++++++++++++ > >>>>>1 file changed, 12 insertions(+) > >>>> > >>>>FYI, there are some on-going changes in the VIRTIO specification=20 > >>>>so that the VHOST interface exposes its MTU to its VIRTIO peer. > >>>>It may also be used as an alternative of what you patch achieves. > >>>> > >>>>I am working on its implementation in Qemu/DPDK, our goal being to=20 > >>>>reduce performance drops for small packets with Rx mergeable=20 > >>>>buffers feature enabled. > >>> > >>>Mind to educate me a bit on how that works? > >> > >>Of course. > >> > >>Basically, this is a way to advise the MTU we want in the guest. > >>In the guest, if GRO is not enabled: > >> - In case of Kernel virtio-net, it could be used to size the SKBs=20 > >>at the expected MTU. If possible, we could disable Rx mergeable=20 > >>buffers. > >> - In case of virtio PMD, if the MTU advised by host is lower than=20 > >>the pre-allocated mbuf size for the receive queue, then we should=20 > >>not need mergeable buffers. > > > >Thanks for the explanation! > > > >I see. So, the point is to avoid using mergeable buffers while it is=20 > >enabled. > > > >>Does that sound reasonnable? > > > >Yeah, maybe. Just don't know how well it may work in real life. Have=20 > >you got any rought data so far? >=20 > The PoC is not done yet, only Qemu part is implemented. > But what we noticed is that for small packets, we have a 50%=20 > degradation when rx mergeable buffers are on when running PVP=20 > use-case. >=20 > Main part of the degradation is due an additional cache-miss in=20 > virtio-pmd receive path, because we fetch the header to get the number=20 > of buffer. >=20 > When sending only small packets and removing this access, we recover=20 > 25% of the degradation. >=20 > The 25% remaining part may be reduced significantly with Zhihong series. >=20 > Hope it answer your questions. Yes, it does and thanks for the info. --yliu