From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0078.outbound.protection.outlook.com [104.47.41.78]) by dpdk.org (Postfix) with ESMTP id 4B6262C50 for ; Mon, 29 Aug 2016 00:43:58 +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=G7vQVDDeoyZTTW3bB2+TwoxjJ0jQuWs+HT/9C+sFBTw=; b=doEdZvkW9li9GMh3yN/NVjQQIkebHX9RsgFNhVHuOOPGmv8IKMDarmyDBuPRaJrw0K1CT9jr+djNGhL7rDbLn6CWwmxTQf+24ViOkB5+ja9nx9a+OZQmshGcpfD7OAyYSVtMw63GehYxLfAGPUuEAkbMcAdE/qtp5hEcNpwp8Dc= Received: from BN6PR03MB2740.namprd03.prod.outlook.com (10.173.144.135) by BN6PR03MB2740.namprd03.prod.outlook.com (10.173.144.135) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Sun, 28 Aug 2016 22:43:54 +0000 Received: from BN6PR03MB2740.namprd03.prod.outlook.com ([10.173.144.135]) by BN6PR03MB2740.namprd03.prod.outlook.com ([10.173.144.135]) with mapi id 15.01.0587.013; Sun, 28 Aug 2016 22:43:54 +0000 From: "Dey, Souvik" To: Stephen Hemminger CC: "huawei.xie@intel.com" , "yuanhan.liu@linux.intel.com" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v1] add mtu set in virtio Thread-Index: AQHR//2h9IuLF04epUu392CynAnVbqBdgqOAgAF3eyA= Date: Sun, 28 Aug 2016 22:43:54 +0000 Message-ID: References: <20160827005428.16556-1-sodey@sonusnet.com> <20160827171541.5f6b17c2@xeon-e3> In-Reply-To: <20160827171541.5f6b17c2@xeon-e3> 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:3dae:306c:3cd0:e0eb] x-ms-office365-filtering-correlation-id: d9f45708-8e3d-4931-a4a1-08d3cf94ca6d x-microsoft-exchange-diagnostics: 1; BN6PR03MB2740; 6:yKoCoZ+3Fbs5Hrai+QX1ralNgkBWMR7RU6KVMhmW5ALWFW2h6rs7sRVZzHUM+fsADVABopW8NXYaJnZuH2nryfxb1ycadlzsyVlZc9ks87pNLJK/AnuYQB5LNloflZxnVDuPOYYglJG+/DrFX20XjwLQGIyGstVYjZ1mK8y17k0Ss/t4KADkWgagBLpEQWLv7BPmiw1HO5taWd/zk+wZlm3ElFcK2G0t3oeLlEMHZFVi2FffosBvPjt8nzEaQ3x6h1su03xSMbdqwZUus50oUhQ/yQY7ZI/4G1cRvR1ifrg=; 5:/S42Ic77wZN1c/mheS00kr9n/lEdrUWBHFKkQWn1m0ZtNkT5QCrUh2p8zp7fFndG+rxt5hYvl3JP14saBeNSUjkNCb6S9M5+DnttNtHftaY7VrkKUnoJJJXtj+WPGPp4AWsUuzBBoYVqoOqh3+k1ug==; 24:8Ij7pmol4mcCPIxQ6gUaPayzZ8yp22457U4ZGbp+inFJoYZrNC+Xno0sQreUQkoAr2knY/a0CnoXzXXLeF0ZcUEYGaW8xwOUNQ30Y14sgjY=; 7:laoOuIvbBRHjAI7e+CVJV9aMSZlR6HxYM4ui+9ZFejeerRwwHqf+UrW1Zrb0tWe18DJh/aeplI/FZzLbi6XOFg2vcCdPFvt0ERf9hv2cQUXyhgJFf3c2hNvKnnGfSgcSSj50gXHBkf2WjIOqd0sYK7qFbfSG7DcpDyFwcbzdZu+7nGX2l3a5p/KtlnU9onh+IoulYaaQ0gTKCgtb34HnJCecmt5wcIJXpfGM1N/pYP0c27M/HlvpiHQf7h7dFXdZ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2740; 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)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN6PR03MB2740; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2740; x-forefront-prvs: 0048BCF4DA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(51914003)(199003)(189002)(377454003)(13464003)(24454002)(74316002)(86362001)(7846002)(586003)(101416001)(5660300001)(99286002)(10400500002)(8936002)(305945005)(102836003)(6116002)(11100500001)(4326007)(8676002)(19580405001)(81156014)(7696003)(76576001)(76176999)(122556002)(110136002)(81166006)(77096005)(54356999)(92566002)(9686002)(50986999)(3660700001)(106116001)(2906002)(87936001)(105586002)(97736004)(189998001)(106356001)(7736002)(33656002)(2950100001)(68736007)(5002640100001)(19580395003)(2900100001)(3280700002)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR03MB2740; H:BN6PR03MB2740.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: 28 Aug 2016 22:43:54.4371 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2740 Subject: Re: [dpdk-dev] [PATCH v1] 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: Sun, 28 Aug 2016 22:43:58 -0000 Hi , Currently as you have mentioned, I have changed the code to: static int=20 virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)=20 { struct virtio_hw *hw =3D dev->data->dev_private; - if (unlikely(mtu < (uint32_t)hw->vtnet_hdr_size + ETHER_HDR_LEN)) { - return -1; + if (unlikely(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; } Yes, we should support till 64K as the kernel does , but I need to go throu= gh the changes and test it properly before submitting it for review. Moreov= er I was thinking with the changes in the mtu, we should also support multi= -segment buffers in kni. What do you suggest ? -- Regards, Souvik -----Original Message----- From: Stephen Hemminger [mailto:stephen@networkplumber.org]=20 Sent: Saturday, August 27, 2016 8:16 PM To: Dey, Souvik Cc: huawei.xie@intel.com; yuanhan.liu@linux.intel.com; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v1] add mtu set in virtio On Fri, 26 Aug 2016 20:54:28 -0400 souvikdey33 wrote: > This functionality is required mostly in the cloud infrastructure. > For example, if we use gre or vxlan network between compute and=20 > controller, then we should not use 1500 mtu in the guest as with=20 > encapsulation the sixe of the packet will be more and will get dropped=20 > in the infrastructure. So, in that case we should honor the mtu size=20 > sent by the dhcp server and configure the same on the virtual=20 > interfaces in the guest. This will also keep a consistent mtu through=20 > out the infrastructure. >=20 > souvikdey33 (1): > Signed-off-by: Souvik Dey >=20 > drivers/net/virtio/virtio_ethdev.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) >=20 Thanks for the patch, it is a good step forward but it looks like more code= is needed to do this safely. At a minimum, need to check that MTU is not g= reater than VIRTIO_MAX_RX_PKTLEN. And error return should be negative errno not -1. Something like: if (mtu < VIRTIO_MIN_MTU || mtu > VIRTIO_MAX_RX_PKTLEN) return -EINVAL; Looking at Linux driver, it allows MTU of up to 64K, yet DPDK only allows 9= 728. That should probably be fixed.