Message ID | 20160829230240.20164-1-sodey@sonusnet.com (mailing list archive) |
---|---|
State | Superseded, archived |
Delegated to: | Yuanhan Liu |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id A538D2BD4; Tue, 30 Aug 2016 01:02:59 +0200 (CEST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0065.outbound.protection.outlook.com [104.47.37.65]) by dpdk.org (Postfix) with ESMTP id 112A42BD1 for <dev@dpdk.org>; Tue, 30 Aug 2016 01:02:57 +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=PwsnXwkvPPgo4MhfZUmv+mcLIohTKcKMzNPi3bPWRM0=; b=eARmd11++33aV/SonY73Cj26NNLzRqliDN3p48ynf2RD2fklW20W5culYu4khG20eCV9sKdnA2mUE45gpxzwZG2JKs7pgA357oqsmL2Lni5mdAvbCq+7cDrnl31QUF0ZV25uoQ+EDlB8cWhirh4c0bEPyf2x9zPYIA4LLjqEPPk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=sodey@sonusnet.com; Received: from SODEY-LMA.sonusnet.com (2601:191:8300:9cda:dd87:47c2:f8d0:dc97) by MWHPR03MB2750.namprd03.prod.outlook.com (10.168.207.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Mon, 29 Aug 2016 23:02:52 +0000 From: souvikdey33 <sodey@sonusnet.com> To: <stephen@networkplumber.org>, <huawei.xie@intel.com>, <yuanhan.liu@linux.intel.com> CC: <dev@dpdk.org>, souvikdey33 <sodey@sonusnet.com> Date: Mon, 29 Aug 2016 19:02:40 -0400 Message-ID: <20160829230240.20164-1-sodey@sonusnet.com> X-Mailer: git-send-email 2.9.3.windows.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [2601:191:8300:9cda:dd87:47c2:f8d0:dc97] X-ClientProxiedBy: DM5PR20CA0035.namprd20.prod.outlook.com (10.171.161.149) To MWHPR03MB2750.namprd03.prod.outlook.com (10.168.207.148) X-MS-Office365-Filtering-Correlation-Id: fc3355bf-a445-43f2-2ee3-08d3d0609b2f X-Microsoft-Exchange-Diagnostics: 1; MWHPR03MB2750; 2:o28UEhersEtnxZOFfvP7kscxWukOQIUH5oe5HM4dqfdniuIRpywBXBBAUuzzHyU5NsfKbvHQ55BKHO5WEdkS1h3NTFxI1APm8rawf87qzbNRq8KZyuHqrvnj7WHHwKqXARMUOD7ZgBIm4r6pUprR/+hxgPWikFC3QEdFz3E/s+nKfC/svbcjhiLN/PZ6bYKw; 3:JxphZaTlceALhbDUn2BhOEN69quIe+4r/wPR7L400Zy5NPitPY+pzYLbmMzwbEAY4jbZS+NoXCUX5Vs7a1UOcyE6ghWdnoqCZ0LWRvQ2YPKuGBUgqkjKBE+7UUv9ufME X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2750; X-Microsoft-Exchange-Diagnostics: 1; MWHPR03MB2750; 25:NsRYINHfepHXbX+FiTal6H6FyX4gTUmpru4zva3TQw9dF+l+7FMJkpcuY8ZpHTe0nDxBow1uv3DwktICrhANBTaJi0eH7A0KP/faJJjBQRhf04N/zBd+Ti1HWJ2bgnzFgkBi/8Z6QFZhz8L1Imc7RgUgUwbAEMWfMIBFtbt0iLs5ye5EehFOqnPY1wyqtVsFzpycQp+4CLzfpi0SlaCILmoqf1quMJwRHLeSgnhl020OhrlnvWD/PlTzeCiDYgoB6WwbTOTeZ92892zJTfgOC1bJYHIBr3UNm8F9DVK2Q+Xw9NFtJtMw5gzRGY8+84Kmac0yYhhvIhfKXZWCrIHlNP0Jt1zwyB7NwNcNFbFgNWSGdU2kKzerXpr+PpI7sIutMa/6ccKlf63G4YBnS0gpM60BxnwESp2+dOlibWPfDqgdN7Eh+KEFeiOlzryLhgp+nDS7zh09sVjAdBOVMytX+rlZQZWlRbbEkTVikYZf+3cKFw2VVIscKgFb0ji2J8AxuZ4uAAnkMHRQts0Nhhc4WGXysMOWTyA6vSW3xTuGxxZWUxdwrNKTuExvmClJS1LyKWEEKov9s9VoHYejMMJ6UqmFdEeFl7/tym2DBfHTMOwpRjfOEDZb3W3xbdAs+dX4Gb/OVoRqsxyN47A97N5mFqgXl7iPG2G2RYOlI5yIMAevL3wcYAVgxqz2V7bGN1C/; 31:zQNW24bhxIswtAezeA1vgzWgQMQbhoNfq7BKKCEtsZVmwA79A22U2QUb3oJzU8IA/+1WnE4UhCdzbHJpjLGmuTU9ENDCKu0kF73/HCh/YUFuek0Y/PzrjYEzF2UKLj5fybOb0KwRrKls87OXLwELeLcXgfBCPX3YBP2KhBZ9rD3Ax5BQi/6LggcbxuVLih8UP+3rijt7TYMvjTMzH00tgEkFNZkSORTnh8Au0kyC2yo= X-Microsoft-Exchange-Diagnostics: 1; MWHPR03MB2750; 20:1ZZ1rPGuUVfE875M9Rg05FlpoXHz6NbRmcBi0AQaQhzMjUoLSKvxTJJKT0TDg5cD/NrrYFqzxU0jNv7y8jjJZJCQnc+Zf0ZbTjW3HJ66fKi7SxgfEQo87tIxs0ftOd62HDIQkSRiwchgz+tgeafnd3lpMEUbBUd4yRPi3RiFMzZ78T2QSGp/m5pMeyBLyU5tBkLKuzFkniAndnsV2LXyYpicjiMKhCIGVx2KLagYHSqziSp7XdtM4XQBvx9z5UJ41SlhGzSp8JUrDvJuv4PN8Wzmhbpq2c6JmlOpSlEmyYnWAe1wpW+dNJy9n0+TKdhVahPxmPdVI/IM48DhJEjeU300OMzT0xq8JMh/1Ww5/J2E7RZkpwHIB9AsORTdndAEEDbbJWH/JZL+LyJjDyAy8yYBNjeabx/Vh2PGFMyF6XU9aJqkXIqLuSZ1C4t1i668sWZ8wdVw7dAXl1GMXo4WeX+nr2Jg2iMNLwYiKnJ3UHZRKzHMBQj5iekGKO+ZOgaO; 4:zE9tQ6YRwdqx9k7OClH+J4tRXcmx53UTfI8HoCgZ9NXrGehlJeC3+tLzILWL4jMqTucjPI69+bk7hRp7IVjDZgGoz32FxZxri1JqWmjAj4Ekgp8KDP7yvETbq/rD3z4a5SwerQPkmX2dhvvVAaTq+M/V12ne/LPgYEH2ur0WwcaCHoSm2L+8vt0f9t9nLcHO3ocaifqurSYEzoPbNS4Z5FBzdQ2NQh++6PZx+wXuvf26uxlyvUC52wenH6RF1/xvyp0Kp4cxqiujMAvax90nM+kTq6aK7uXNa6hSb+nIp27N7kDNXeG4prKJa7naCpiemzXK5obAd88C/Sxr+0Dj8XsU5iAn18mdeYw/d8k18yLgQx0Jnqg0UTfL5H3/tlZDGd+eIStfF8bpcO1AXcybn7HQ6ylMMlbmazHc9NDSgMtZaBieoA5K+XT1P00CVyX5 X-Microsoft-Antispam-PRVS: <MWHPR03MB2750E16A0E80E16D00248743DAE10@MWHPR03MB2750.namprd03.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:MWHPR03MB2750; BCL:0; PCL:0; RULEID:; SRVR:MWHPR03MB2750; X-Forefront-PRVS: 0049B3F387 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(7916002)(189002)(199003)(4001430100002)(50226002)(81156014)(586003)(36756003)(33646002)(81166006)(8676002)(68736007)(86152002)(86362001)(50986999)(105586002)(7846002)(42186005)(2201001)(6116002)(106356001)(101416001)(5003940100001)(50466002)(4326007)(2906002)(5660300001)(229853001)(48376002)(107886002)(305945005)(53416004)(189998001)(7736002)(92566002)(5001770100001)(47776003)(97736004)(77096005)(19580405001)(69596002)(19580395003)(1076002)(43062003)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR03MB2750; H:SODEY-LMA.sonusnet.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR03MB2750; 23:ZDcVF0DZ12xAQFtTMZQc/AUsXSEiG6KHejer8302y?= =?us-ascii?Q?Ti2RIiHnz4z6iD93B0rBtrfLjCgKk9BF3tJSOgCHRLoWUpfNXZbmVzsmYwYw?= =?us-ascii?Q?o7koo+GdJejR6Vz6BUS8DhCPvW8bdt9FMtZ98vwTPXw85u6PaBD0pygUj+pX?= =?us-ascii?Q?1Iu06GXDB+MlD71fV+ghfO8StQLon7PHfMAYAEe5YVoyddtOrnNFjQrZazM6?= =?us-ascii?Q?w0zk+tIliJGLyVolvek1ZQI93hy6uW3a9A6rJR3byoKyqmvMHbZKWJ2D/mFB?= =?us-ascii?Q?Uf/iceyPs/9dcQVxGgGzfriXOpxH3aI2pL9SzlslNHCuNrfFo1Jn0okG15QX?= =?us-ascii?Q?W6olEYjk/dhhacCO52MLvb/7126qlja6W5sFWMKD+s9VQapz3TwtHGE4pDg3?= =?us-ascii?Q?UxUwo1IWD2VwoCdIqv0HyGu5TLgae/bOKhrZLKTMVUTukuMOuTmARsY+bIiv?= =?us-ascii?Q?GkANP1Ehhzrp+JSfU6H1XdgAA4TprvUtmd64BPl+onFgfurCBsClp7dtWmad?= =?us-ascii?Q?u5KtvAlrMIn9TiA6W9cvKzU52JOcY95Z66ghhIdCoGzousmRASqzP4U4BShc?= =?us-ascii?Q?pgsrLQwgpgvfrK6ppToZjOpjt4Lv+Z4Fn1nltkr7VFmHvdXonW3UcHAyppt9?= =?us-ascii?Q?CueouheEruF/Ey+GNN7irRL2KZ7OW7OtDWxvTDA5BDY8uodTOzktoBHQjx+H?= =?us-ascii?Q?xz08lktO4/yhfO6X4OfG/WCMy9c7E5A706hwMXDtZWUJvjrYDgWBLeYRRW5i?= =?us-ascii?Q?+6y0xQjRyo6a0kZZDay4Y4eixHlBYIA3nNJAzXETXOb1sZYs4p7RAMbVFn+q?= =?us-ascii?Q?OE3axWXTQDa5El3mkULcpWIA+35bmpqajZMoNUqzT9asPQrudLdjMbP547LU?= =?us-ascii?Q?ReoCD3tAOx6bXGSvQtKGsW1QDVE39oa3h12yifs4q4I91YXFDpsYwgiXDj5c?= =?us-ascii?Q?oiLQ28xVpum6tGaYEGa2twWMYpw5qqIW/WxxwWgB+E2+wWuNnvojmmDq5G1P?= =?us-ascii?Q?ugpMaY2DtIMroFKv0qO1I4u9Rimil1F2D17tCQVyzc0orLH6kNK5ztPg2B0v?= =?us-ascii?Q?e0CQu4SaXCFxF36cHBBZSEmDVGq7w+LptucT+G9L7qB+OZ+4h/r1pMuDQxfM?= =?us-ascii?Q?grOVOpTPQbbSneWlgBc3yJrDwNYDTbChMFvjiqN1VxQkcV+7AoImQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR03MB2750; 6:M9SGHekf1o7j6yQBzKmK7Olds4YU87mDsj3zEbOAhDBxzc8jgfy77Ljk3jg5pIqqzWui9zE51hNc5B+K8PEZyHtZGpoYF6NI29dEvvzEt/hmIBLguriSFbcx8Sqb2s+9lPFiCFUtyTHrWuQqHYDggZUD1n1g4lNkikcwbBRL+ai1nphkKUAyrMkfDIdzExa29XhANgBqzGaTnvqcid/OnN3ZeFQtIKYJyPlMH0lh6GJrrpZSb1mr1j9aGvqmVfY2mnFOCJGK5SjV8H56G/AaQxeimYuEzMrq20WJYdnyzzE=; 5:nbOaQ2E2nxq8qsBo7gJ1Npn2A0l7+b6DgKn7132U3/zkU3Br4ZvPDGTks8gmZBfLQyL2ohUfGwP3W5oP5lsZTLf9geBTr59G7sCDJjmAiiYuqa7zJQtN6V+j4f9uhcmjGRoePeqQOxAzvp2PyiKymQ==; 24:maAGx4eXWeh2YtRv+9Ab7hJhbAC2Qv704QZJ0d7XswO27/Mwwzbrwp/LGoZjOZD4p02WwiGTnKCuZnoY9n85gfYsT97HLe5PtC6ix1UylZc=; 7:5DbY7b9StCmk3ZvJMk2ZZgkEFADsgTP/RCrulTvmJ4E0Yxn0lgtM9uR9CA58HQZjCzNxXmsPfdMjhxMQDxg6okNznt3eXwxS1kRJ2m5wAyohWGQE+HHVx1AOyJ5xPdOTFzqCc4OO1/QjE6/g9bGiTgSIXXJSLO7/C3/4KOK0qtAzLKNbhHNeeNlk89oMmB/INj4ihhrSnGTzrjCiA6pqjD1riQD4GZoR4Z8yUQ0+RPxBYOBkos58p/e+nIC/uVRA SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2016 23:02:52.2245 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2750 Subject: [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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
souvikdey33
Aug. 29, 2016, 11:02 p.m. UTC
Signed-off-by: Souvik Dey <sodey@sonusnet.com> Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey <sodey@sonusnet.com>") Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Virtio interfaces should also support setting of mtu, as in case of cloud it is expected to have the consistent mtu across the infrastructure that the dhcp server sends and not hardcoded to 1500(default). --- drivers/net/virtio/virtio_ethdev.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Comments
Hi Souvik, On 08/30/2016 01:02 AM, souvikdey33 wrote: > Signed-off-by: Souvik Dey <sodey@sonusnet.com> > > Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey <sodey@sonusnet.com>") > Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> > > Virtio interfaces should also support setting of mtu, as in case of cloud > it is expected to have the consistent mtu across the 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 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 reduce performance drops for small packets with Rx mergeable buffers feature enabled. Regards, Maxime
Hi Maxime, When is patches or new implementation going to come in the release ? if it is not 16.11 then, can we keep this change till the new virtio changes come in the release. And if it is already planned for 16.11, then can I get a little more information on that. -- Regards, Souvik -----Original Message----- From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] Sent: Tuesday, August 30, 2016 3:58 AM To: Dey, Souvik <sodey@sonusnet.com>; stephen@networkplumber.org; huawei.xie@intel.com; yuanhan.liu@linux.intel.com Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio Hi Souvik, On 08/30/2016 01:02 AM, souvikdey33 wrote: > Signed-off-by: Souvik Dey <sodey@sonusnet.com> > > Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey <sodey@sonusnet.com>") > Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> > > Virtio interfaces should also support setting of mtu, as in case of > cloud it is expected to have the consistent mtu across the > 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 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 reduce performance drops for small packets with Rx mergeable buffers feature enabled. Regards, Maxime
Hi Souvik, On 09/02/2016 12:20 AM, Dey, Souvik wrote: > Hi Maxime, > When is patches or new implementation going to come in the release ? if it is not 16.11 then, can we keep this change till the new virtio changes come in the release. And if it is already planned for 16.11, then can I get a little more information on that. > I'm currently working on qemu part implementation, first RFC should be sent next week. Goal is to have it in 16.11, but I cannot commit, as the spec update has not been acked yet. For more information, you can start by having a look at the spec review: https://lists.oasis-open.org/archives/virtio-dev/201608/msg00056.html Regards, Maxime > -- > Regards, > Souvik > > -----Original Message----- > From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] > Sent: Tuesday, August 30, 2016 3:58 AM > To: Dey, Souvik <sodey@sonusnet.com>; stephen@networkplumber.org; huawei.xie@intel.com; yuanhan.liu@linux.intel.com > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio > > Hi Souvik, > > On 08/30/2016 01:02 AM, souvikdey33 wrote: >> Signed-off-by: Souvik Dey <sodey@sonusnet.com> >> >> Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey <sodey@sonusnet.com>") >> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> >> >> Virtio interfaces should also support setting of mtu, as in case of >> cloud it is expected to have the consistent mtu across the >> 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 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 reduce performance drops for small packets with Rx mergeable buffers feature enabled. > > Regards, > Maxime >
Hi Maxime, In that case let this fix be there till the time the new implementation comes in. We can re-visit the changes again in the new implementation and then decide to keep this or remove it. Hope this serves all the purposes. -- Regards, Souvik -----Original Message----- From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] Sent: Friday, September 2, 2016 3:06 AM To: Dey, Souvik <sodey@sonusnet.com>; stephen@networkplumber.org Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio Hi Souvik, On 09/02/2016 12:20 AM, Dey, Souvik wrote: > Hi Maxime, > When is patches or new implementation going to come in the release ? if it is not 16.11 then, can we keep this change till the new virtio changes come in the release. And if it is already planned for 16.11, then can I get a little more information on that. > I'm currently working on qemu part implementation, first RFC should be sent next week. Goal is to have it in 16.11, but I cannot commit, as the spec update has not been acked yet. For more information, you can start by having a look at the spec review: https://lists.oasis-open.org/archives/virtio-dev/201608/msg00056.html Regards, Maxime > -- > Regards, > Souvik > > -----Original Message----- > From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] > Sent: Tuesday, August 30, 2016 3:58 AM > To: Dey, Souvik <sodey@sonusnet.com>; stephen@networkplumber.org; > huawei.xie@intel.com; yuanhan.liu@linux.intel.com > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio > > Hi Souvik, > > On 08/30/2016 01:02 AM, souvikdey33 wrote: >> Signed-off-by: Souvik Dey <sodey@sonusnet.com> >> >> Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey >> <sodey@sonusnet.com>") >> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> >> >> Virtio interfaces should also support setting of mtu, as in case of >> cloud it is expected to have the consistent mtu across the >> 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 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 reduce performance drops for small packets with Rx mergeable buffers feature enabled. > > Regards, > Maxime >
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 <sodey@sonusnet.com> > > > >Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey <sodey@sonusnet.com>") > >Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> > > > >Virtio interfaces should also support setting of mtu, as in case of cloud > >it is expected to have the consistent mtu across the 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 > 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 > reduce performance drops for small packets with Rx mergeable buffers > feature enabled. Mind to educate me a bit on how that works? --yliu
On 09/07/2016 04:11 AM, Dey, Souvik wrote: > Hi Maxime, > In that case let this fix be there till the time the new implementation comes in. We can re-visit the changes again in the new implementation and then decide to keep this or remove it. Hope this serves all the purposes. Sure, I'm fine with your proposal. Thanks, Maxime > > -- > Regards, > Souvik > > -----Original Message----- > From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] > Sent: Friday, September 2, 2016 3:06 AM > To: Dey, Souvik <sodey@sonusnet.com>; stephen@networkplumber.org > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio > > Hi Souvik, > > On 09/02/2016 12:20 AM, Dey, Souvik wrote: >> Hi Maxime, >> When is patches or new implementation going to come in the release ? if it is not 16.11 then, can we keep this change till the new virtio changes come in the release. And if it is already planned for 16.11, then can I get a little more information on that. >> > I'm currently working on qemu part implementation, first RFC should be sent next week. > > Goal is to have it in 16.11, but I cannot commit, as the spec update has not been acked yet. > > For more information, you can start by having a look at the spec review: > https://lists.oasis-open.org/archives/virtio-dev/201608/msg00056.html > > Regards, > Maxime > >> -- >> Regards, >> Souvik >> >> -----Original Message----- >> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] >> Sent: Tuesday, August 30, 2016 3:58 AM >> To: Dey, Souvik <sodey@sonusnet.com>; stephen@networkplumber.org; >> huawei.xie@intel.com; yuanhan.liu@linux.intel.com >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio >> >> Hi Souvik, >> >> On 08/30/2016 01:02 AM, souvikdey33 wrote: >>> Signed-off-by: Souvik Dey <sodey@sonusnet.com> >>> >>> Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey >>> <sodey@sonusnet.com>") >>> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> >>> >>> Virtio interfaces should also support setting of mtu, as in case of >>> cloud it is expected to have the consistent mtu across the >>> 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 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 reduce performance drops for small packets with Rx mergeable buffers feature enabled. >> >> Regards, >> Maxime >>
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 <sodey@sonusnet.com> >>> >>> Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey <sodey@sonusnet.com>") >>> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> >>> >>> Virtio interfaces should also support setting of mtu, as in case of cloud >>> it is expected to have the consistent mtu across the 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 >> 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 >> reduce performance drops for small packets with Rx mergeable 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 at the expected MTU. If possible, we could disable Rx mergeable buffers. - In case of virtio PMD, if the MTU advised by host is lower than the pre-allocated mbuf size for the receive queue, then we should not need mergeable buffers. Does that sound reasonnable? Do I miss something? Thanks, Maxime
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 <sodey@sonusnet.com> > >>> > >>>Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey <sodey@sonusnet.com>") > >>>Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> > >>> > >>>Virtio interfaces should also support setting of mtu, as in case of cloud > >>>it is expected to have the consistent mtu across the 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 > >>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 > >>reduce performance drops for small packets with Rx mergeable 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 at the expected MTU. If possible, we could disable Rx > mergeable buffers. > - In case of virtio PMD, if the MTU advised by host is lower than the > pre-allocated mbuf size for the receive queue, then we should not need > mergeable buffers. Thanks for the explanation! I see. So, the point is to avoid using mergeable buffers while it is enabled. > Does that sound reasonnable? Yeah, maybe. Just don't know how well it may work in real life. Have you got any rought data so far? --yliu > Do I miss something? > > Thanks, > Maxime
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 <sodey@sonusnet.com> >>>>> >>>>> Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey <sodey@sonusnet.com>") >>>>> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> >>>>> >>>>> Virtio interfaces should also support setting of mtu, as in case of cloud >>>>> it is expected to have the consistent mtu across the 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 >>>> 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 >>>> reduce performance drops for small packets with Rx mergeable 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 at the expected MTU. If possible, we could disable Rx >> mergeable buffers. >> - In case of virtio PMD, if the MTU advised by host is lower than the >> pre-allocated mbuf size for the receive queue, then we should not need >> mergeable buffers. > > Thanks for the explanation! > > I see. So, the point is to avoid using mergeable buffers while it is > enabled. > >> Does that sound reasonnable? > > Yeah, maybe. Just don't know how well it may work in real life. Have > you got any rought data so far? The PoC is not done yet, only Qemu part is implemented. But what we noticed is that for small packets, we have a 50% degradation when rx mergeable buffers are on when running PVP use-case. Main part of the degradation is due an additional cache-miss in virtio-pmd receive path, because we fetch the header to get the number of buffer. When sending only small packets and removing this access, we recover 25% of the degradation. The 25% remaining part may be reduced significantly with Zhihong series. Hope it answer your questions. Thanks, Maxime
On Thu, Sep 08, 2016 at 09:50:34AM +0200, Maxime Coquelin wrote: > > > 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 <sodey@sonusnet.com> > >>>>> > >>>>>Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey <sodey@sonusnet.com>") > >>>>>Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> > >>>>> > >>>>>Virtio interfaces should also support setting of mtu, as in case of cloud > >>>>>it is expected to have the consistent mtu across the 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 > >>>>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 > >>>>reduce performance drops for small packets with Rx mergeable 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 at the expected MTU. If possible, we could disable Rx > >>mergeable buffers. > >> - In case of virtio PMD, if the MTU advised by host is lower than the > >>pre-allocated mbuf size for the receive queue, then we should not need > >>mergeable buffers. > > > >Thanks for the explanation! > > > >I see. So, the point is to avoid using mergeable buffers while it is > >enabled. > > > >>Does that sound reasonnable? > > > >Yeah, maybe. Just don't know how well it may work in real life. Have > >you got any rought data so far? > > The PoC is not done yet, only Qemu part is implemented. > But what we noticed is that for small packets, we have a 50% > degradation when rx mergeable buffers are on when running PVP > use-case. > > Main part of the degradation is due an additional cache-miss in > virtio-pmd receive path, because we fetch the header to get the number > of buffer. > > When sending only small packets and removing this access, we recover > 25% of the degradation. > > The 25% remaining part may be reduced significantly with Zhihong series. > > Hope it answer your questions. Yes, it does and thanks for the info. --yliu
Are we good to get this in for 16.11 and then revisit this when the VHOST improvements 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] Sent: Thursday, September 8, 2016 3:57 AM To: Maxime Coquelin <maxime.coquelin@redhat.com> Cc: Dey, Souvik <sodey@sonusnet.com>; stephen@networkplumber.org; huawei.xie@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: > > > 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 <sodey@sonusnet.com> > >>>>> > >>>>>Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey > >>>>><sodey@sonusnet.com>") > >>>>>Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> > >>>>> > >>>>>Virtio interfaces should also support setting of mtu, as in case > >>>>>of cloud it is expected to have the consistent mtu across the > >>>>>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 > >>>>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 > >>>>reduce performance drops for small packets with Rx mergeable > >>>>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 > >>at the expected MTU. If possible, we could disable Rx mergeable > >>buffers. > >> - In case of virtio PMD, if the MTU advised by host is lower than > >>the pre-allocated mbuf size for the receive queue, then we should > >>not need mergeable buffers. > > > >Thanks for the explanation! > > > >I see. So, the point is to avoid using mergeable buffers while it is > >enabled. > > > >>Does that sound reasonnable? > > > >Yeah, maybe. Just don't know how well it may work in real life. Have > >you got any rought data so far? > > The PoC is not done yet, only Qemu part is implemented. > But what we noticed is that for small packets, we have a 50% > degradation when rx mergeable buffers are on when running PVP > use-case. > > Main part of the degradation is due an additional cache-miss in > virtio-pmd receive path, because we fetch the header to get the number > of buffer. > > When sending only small packets and removing this access, we recover > 25% of the degradation. > > The 25% remaining part may be reduced significantly with Zhihong series. > > Hope it answer your questions. Yes, it does and thanks for the info. --yliu
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c index 07d6449..da16ad4 100644 --- a/drivers/net/virtio/virtio_ethdev.c +++ b/drivers/net/virtio/virtio_ethdev.c @@ -92,6 +92,7 @@ static void virtio_mac_addr_add(struct rte_eth_dev *dev, static void virtio_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index); static void virtio_mac_addr_set(struct rte_eth_dev *dev, struct ether_addr *mac_addr); +static int virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu); static int virtio_dev_queue_stats_mapping_set( __rte_unused struct rte_eth_dev *eth_dev, @@ -652,6 +653,16 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev) PMD_INIT_LOG(ERR, "Failed to disable allmulticast"); } +static int +virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) +{ + struct virtio_hw *hw = dev->data->dev_private; + if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) { + PMD_INIT_LOG(ERR,"Mtu should be between 64 and 9728." + return -EINVAL; + } + return 0; +} + /* * dev_ops for virtio, bare necessities for basic operation */ @@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = { .promiscuous_disable = virtio_dev_promiscuous_disable, .allmulticast_enable = virtio_dev_allmulticast_enable, .allmulticast_disable = virtio_dev_allmulticast_disable, + .mtu_set = virtio_mtu_set, .dev_infos_get = virtio_dev_info_get, .stats_get = virtio_dev_stats_get,