From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0079.outbound.protection.outlook.com [104.47.38.79]) by dpdk.org (Postfix) with ESMTP id 5E9C829D1 for ; Thu, 22 Sep 2016 02:08:40 +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=98qmPCU/qu0009ayoT33TdiJ+E0McAJOPsqjWab4hmw=; b=f+9ytRDcB6NnZQ5nkvN/N5XX5jOq3VvvNt9jS1b4ySpBqCEs8w3MjXHBqN3IY+ctkqY0TNJaGmiMMbwwXy8xD4vNhZ+it3zuxdio4O5gG35SnyY26hXU/JYW0zM0CaBJaLLlBxw4aAppd4kgUmSryOUEv+441bJk/dvLeVL7/jc= Received: from BN3PR03MB1494.namprd03.prod.outlook.com (10.163.35.145) by BN3PR03MB1494.namprd03.prod.outlook.com (10.163.35.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Thu, 22 Sep 2016 00:08:38 +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.0629.015; Thu, 22 Sep 2016 00:08:38 +0000 From: "Dey, Souvik" To: Stephen Hemminger CC: "mark.b.kavanagh@intel.com" , "yuanhan.liu@linux.intel.com" , "dev@dpdk.org" Thread-Topic: [PATCH v6] net/virtio: add set_mtu in virtio Thread-Index: AQHSFF2bGYWatJTFW0SUpX36+50+dKCElTyAgAALYiA= Date: Thu, 22 Sep 2016 00:08:38 +0000 Message-ID: References: <20160921231147.26820-1-sodey@sonusnet.com> <20160921162213.4b79d1ce@xeon-e3> In-Reply-To: <20160921162213.4b79d1ce@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: [66.30.138.194] x-ms-office365-filtering-correlation-id: 527edc6e-8d6d-4ab3-2d6f-08d3e27c9abc x-microsoft-exchange-diagnostics: 1; BN3PR03MB1494; 6:dPHGJGBOlNsBlOq30bvFIWYPoJlm0aObpZwlOAZ8wGQaDXIuqr12bjMpq7qstCtA75q9FwIDM0wi8Iri3RYoM/PjbNAzhJ/DflGtlvqmQP7Y5wU4VDhczqrE5GdCg5mtVTmKxUTl8vfNGGmMNXmIve+jkRT7juqi1svv7OQeAGXTXQf4inzFLfcL6rDtiIWc8aiytawQ2iM74N2+EFxF6HBlAOxyZZXErIcqUwEQPeFY7PbCvYjHJuejVQDFpUNTDn1fhQlzc9bBX3tZ1z4NS1BS0/xD4X8e4/3dvgp+6+A=; 5:0Btb2UuB6C/LRrjH7I6oORNkD6T4ZJUN9Tz7iSqCOaPBZYenpQAo5SHDlg7vEkpOczFTCugUoWldbgJW8jzYYZmhUdteiUZC/j9mhPO4yvZixfMetuz/j56NSlEkD9ToBd18Ar9VDZTqhuaeU9frIA==; 24:lGxxxvITsZsF+HWXs+uPH7Lqk/umw5ar5wOAMKQAjccg6zDWU5dv9MELQQ9mxp5+OuOsj+saTqn0MpxRFoKoUW7lAzrGFE2xpFVz+x7P9m8=; 7:zkB/ejGQnN4J9iAnltjgxiz63tj9VFLt76NhlhTtgsD4GCJic5oZCJyuSUrKTHEhM8IN3Fp3P5Z1kVKOAKAlanO65SMlDibqXGAxh1d9oBndP0+fb0cXlYYbFeKb+T4I8WyX6aMKV2n6k2FGSiEVOHrVQS7XI0pKckpq3lxQY2MK8yKoG1LqM6DwcHcxlroGszKyaixXSk/0DMWFxz//tt28Jpd9M8WN3VWr7B9WnQtD0v1AYepkCb2j+xRiMJkGZw34g6HQhgm6NkPO1QeozbjXWf5/iV5DoZ2ViYHb0jEDJ3odKhkzFZR95my8rgv9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1494; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR03MB1494; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1494; x-forefront-prvs: 0073BFEF03 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(377454003)(199003)(13464003)(24454002)(76176999)(50986999)(54356999)(87936001)(92566002)(122556002)(105586002)(106116001)(189998001)(66066001)(106356001)(99286002)(76576001)(5002640100001)(97736004)(10400500002)(7846002)(8676002)(8936002)(7736002)(81156014)(81166006)(586003)(3280700002)(305945005)(77096005)(86362001)(3660700001)(102836003)(33656002)(6116002)(3846002)(19580405001)(19580395003)(9686002)(11100500001)(4326007)(2950100001)(68736007)(110136003)(2906002)(2900100001)(5660300001)(7696004)(74316002)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR03MB1494; H:BN3PR03MB1494.namprd03.prod.outlook.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) 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: 22 Sep 2016 00:08:38.7606 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1494 Subject: Re: [dpdk-dev] [PATCH v6] net/virtio: add set_mtu 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: Thu, 22 Sep 2016 00:08:40 -0000 Answers inline. -- Regards, Souvik -----Original Message----- From: Stephen Hemminger [mailto:stephen@networkplumber.org]=20 Sent: Wednesday, September 21, 2016 7:22 PM To: Dey, Souvik Cc: mark.b.kavanagh@intel.com; yuanhan.liu@linux.intel.com; dev@dpdk.org Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio On Wed, 21 Sep 2016 19:11:47 -0400 Dey wrote: > =20 > + > +#define VLAN_TAG_SIZE 4 /* 802.3ac tag (not DMA'd) */ > + > +static int virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) { > + struct rte_eth_dev_info dev_info; > + uint32_t ether_hdr_len =3D ETHER_HDR_LEN + ETHER_CRC_LEN + VLAN_T= AG_SIZE; > + uint32_t frame_size =3D mtu + ether_hdr_len; > + > + virtio_dev_info_get(dev, &dev_info); > + > + if (mtu < ETHER_MIN_MTU || frame_size > dev_info.max_rx_pktlen) { > + PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n", > + ETHER_MIN_MTU, > + (dev_info.max_rx_pktlen - ether_hdr_len))= ; > + return -EINVAL; > + } > + return 0; > +} I am fine with the general idea of this patch but: 1. Calling virtio_dev_info_get is needlessly wasteful when all you want is to access the max packet length. Since max_rx_pktlen is always VIRTIO_MAX_RX_PKTLEN, please just use that. [Dey, Souvik] I am using the virtio_dev_info_get as in future can/may suppo= rt the max_rx_pktlen as a variable to be set by the application. This will= keep the changes future proof. As we need to support till 65535 instead of= 9728 as the linux does. 2. Defining VLAN_TAG_SIZE is irrelevant if doing vlan offload. [Dey, Souvik] vlan offload is not mandatory. Se again still have vlan being= sent up to the application. In that case we need to consider the vlan leng= th in the Ethernet size. 3. Virtio doesn't insert CRC, therefore CRC_LEN is irrelevant [Dey, Souvik] I am not sure of this. Mark commented earlier to consider thi= s length too. Mark what do you suggest ?