From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by dpdk.org (Postfix) with ESMTP id B8FA11B1FB for ; Wed, 15 Nov 2017 06:12:48 +0100 (CET) X-AuditID: c1b4fb25-1763d9c0000020f7-51-5a0bccd06af8 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 85.A8.08439.0DCCB0A5; Wed, 15 Nov 2017 06:12:48 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 15 Nov 2017 06:12:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZAgQJayqquFsbtN9mep+jFXeCJcQuZ0P+03rlcuAQ0I=; b=aKMQGpcNMhxxSd09cw1Bq3X1POkLoUbJj9vmhrRnqSu7u6/oew4rJrGQOVzPyJj4s0SOjdksrFsqcEqQFTImMuVq2hEsvwvJlPWadFAXjucYNURkRLqn+43Zr/C3cNCKyEcAnX9QKAMoHk/530GZf7iazWgZY+3lAagCOkU/clY= Received: from AM4PR07MB3300.eurprd07.prod.outlook.com (10.171.189.29) by DB4PR07MB473.eurprd07.prod.outlook.com (10.141.238.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Wed, 15 Nov 2017 05:12:45 +0000 Received: from AM4PR07MB3300.eurprd07.prod.outlook.com ([fe80::e515:6326:3ce7:4f56]) by AM4PR07MB3300.eurprd07.prod.outlook.com ([fe80::e515:6326:3ce7:4f56%13]) with mapi id 15.20.0239.005; Wed, 15 Nov 2017 05:12:44 +0000 From: Nitin Katiyar To: Stephen Hemminger CC: "dev@dpdk.org" , "helin.zhang@intel.com" , "jingjing.wu@intel.com" , Venkatesan Pradeep Thread-Topic: [dpdk-dev] Issue with MTU/max_rx_pkt_len handling by different NICs/PMD drivers Thread-Index: AdNMwgOEx2YlMXQMTkycBBMjdRRlvAABi58AACO9ZVAEHjN6MA== Date: Wed, 15 Nov 2017 05:12:44 +0000 Message-ID: References: <20171024150124.6dbe211f@shemminger-XPS-13-9360> In-Reply-To: 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=nitin.katiyar@ericsson.com; x-originating-ip: [122.172.68.19] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB473; 6:dWbiB3BKGMC3HS9VPFAc3u+MavEUMOQGQmXNjUCJpwNH9Q6ssyXn/inrVzxEbsG1G5F6KeSc4MeeGfPCJQpRDNfd3/HaPzvNu7k89NFoCBIimLWA+GibfLyw1ChVHehzJjZDwhFZmkFAhWMMMqGFiOEapgRcyabuRavuG6UR6Ebyx7HRsBUlO1GI4X9G7aIeegn4RBHTw2zE1GGHwMpxWwyRQ3z8gcU23LTuBePaDLck/EuGbHurzDxPvWtPTPwPuR+McBl6KDBGB498Btk2nKxi/OrMRV27BcXli90FPnUnQ53HAFE91uRqTgIGLXHvimrMRiLAV1qEV4O+J46wcfIHSAQM2+lW40mnksdUlxU=; 5:BNlu+ukRLFWWM866gInbCS0n7+I5B5/aLJT4nWkqR08Y4cBsi9ZmnT+BJhxoI5UrURnMUFEmxqSgrScijQ2VLdIkduJosVOtF+2ZhrZJA03jwkjruJVnfPwieIK/Wqv0qY4NmrPTz1gsJCmvgtJqb+VeGre4AXS8cmoQabnGGkM=; 24:KKcmS/zT/u4d5d/h5ND0aT6uPYX5zZksnt6i2ltQTW2BdSo9wh/xUZVjQ5N9bZfmlgRfGhjr50wjhS6WosITDyAgfu+PFvGUBYgFhAYDp4c=; 7:fQsNeQdp3JIpvPCzZqSXgAtsAcWJfdK9qkMwLp408FbJs2EC7+ISa6u4GsJJzVoiK9vNms7lCcCVnvPmXjx7Pdew6wGlPcEy3ncN/3tcyKweQ/XufDGVf8UkhGY+TCYB7K943QV7Zo6EHtXj8x1aXnzu5bhnuqus74R/G5wVN5DxcMdkuGkiQ+ZNChoWk9TzwW/LyfK4ipS6doJYuoKy1mETBbRqf7kcBosUegyNvLDk+OTDQRcB/y8dSsE1D09O x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39860400002)(13464003)(189002)(24454002)(199003)(316002)(107886003)(5660300001)(54906003)(478600001)(81156014)(6246003)(102836003)(7696004)(6116002)(2950100002)(229853002)(105586002)(9686003)(53936002)(99286004)(81166006)(5250100002)(6916009)(14454004)(97736004)(6436002)(8676002)(66066001)(6506006)(86362001)(3280700002)(189998001)(101416001)(7736002)(2906002)(2900100001)(53546010)(68736007)(33656002)(106356001)(305945005)(3846002)(4326008)(76176999)(74316002)(55016002)(3660700001)(25786009)(54356999)(50986999)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB473; H:AM4PR07MB3300.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: efebcf89-5250-49f4-c572-08d52be780ec x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DB4PR07MB473; x-ms-traffictypediagnostic: DB4PR07MB473: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231022)(10201501046)(100000703101)(100105400095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB473; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB473; x-forefront-prvs: 0492FD61DD received-spf: None (protection.outlook.com: ericsson.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-MS-Exchange-CrossTenant-Network-Message-Id: efebcf89-5250-49f4-c572-08d52be780ec X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 05:12:44.2139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB473 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHObv3zutseDJfnhTThgalLtNCP0hmIIzeiCCoMbOlFx3qlF0T rQ8aLJOlZWKmVm5pFlr6QaxZTXCzTKdgmWnqiHS+UhrMD4ZKte0Y9O33PL//Oefh4bCUTzUT yKrU+ZxGrcyWCEV03TljctSHIS95dM+tgPgVh1EQXz1mRPF1hlUU32TbdYSWrRuaGVmTaUkg Kx9oEJym5KKEdC5bVcBp9h++KMq0jfTQeR0hha1NsSVoYqcOsSzggzBeptAhEeuDexGUdg4J SdGPoKayz13QuIKCoflRmpgaAawvvqNIYUdw/ctbp/FkhTgajB+rPFzsi2OgdaEMuUIU7kbQ M6p3h3bgC6BtsdAklArNXc8owkfhT3upm2kcDvfNNUIXi7ECqsent4aaQfBtzcy4hCdOAeuN CXcIYX9Ysz4XuJjCATA5q3czYAyPTcMUYT9Ysv9mSD4FVuxzDNnAbnhdUUwiwTCiv+keGrDZ A8yTvVtnY0FXaWKIWGFgafMOQ8RJsA72ComoRbC4MI2I2AtPK8eE5AUVNM7vIe3jUPegYeui EQa+fn5IVSJp/X+DE44EwxuHkHAEPHn0nap3b2M7DNTN0gZEtyI/nuMv5WTExEo5jSqN53PV UjWX34Gcf8XcuRHehT79SLIgzCLJNnHFSy+5D6Ms4ItyLAhYSuIrTrvtbInTlUVXOE1uquZy NsdbUBBLSwLEMl+nwhnKfC6L4/I4zT8rYD0DS9ChPkHSxnKyd4jN7q1oNgVNDcTNJmo9hk3i n+lxD2RTwi5L1KsE7b3OrMJjEa2rnGoZTk1ZkVyX3e9QDJzR94raV4tfLEuDq2wz+Pz70J7B xRPddl3I+kzYtUlv7a9+L1lLm2Ki8exV/8TQyKxNfLd8riyxPazB4Khl+TaHhOYzlQf2URpe +RfbQmpBJwMAAA== Subject: Re: [dpdk-dev] Issue with MTU/max_rx_pkt_len handling by different NICs/PMD drivers X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:12:48 -0000 Hi, Does anyone have any inputs/suggestion on this issue? Regards, Nitin -----Original Message----- From: Nitin Katiyar=20 Sent: Wednesday, October 25, 2017 11:57 AM To: 'Stephen Hemminger' Cc: dev@dpdk.org Subject: RE: [dpdk-dev] Issue with MTU/max_rx_pkt_len handling by different= NICs/PMD drivers Thanks Stephen for reply. I agree that it is advisory for device driver. I = am also reporting the issue with PMD dpdk drivers. We see different behavio= r with 2 NICs which we have tested with OVS-DPDK (i.e. Fortville and Nianti= c). And by looking at other PMD driver, there could be issue with other NIC= s also. If you look at *_dev_mtu_set then you can see that some driver adds= Vlan tag(s) while determining max_rx_pkt_len (which is MTU + ETH_HDR (14 b= ytes) + CRC(4 bytes) + VLAN (4 or 8 bytes) and some don't do that. But duri= ng *_rx_init() driver uses only max_rx_pkt_len (which does not have VLAN ad= ded into it which means MTU + ETH_HDR(14 bytes) + CRC (4bytes)) is used. OV= S doesn't use *_dev_mtu_set().=20 So, there is inconsistency with the maximum size tagged packet that differe= nt device can receive due to consideration of Vlan tag size in configuring = hw register for Max Frame Size. This should be addressed by drivers not the= application. Regards, Nitin -----Original Message----- From: Stephen Hemminger [mailto:stephen@networkplumber.org]=20 Sent: Tuesday, October 24, 2017 6:31 PM To: Nitin Katiyar Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Issue with MTU/max_rx_pkt_len handling by different= NICs/PMD drivers On Tue, 24 Oct 2017 12:25:38 +0000 Nitin Katiyar wrote: > Hi, > While testing MTU configuration of physical ports using OVS-DPDK we have = found that Fortville and Niantic behaves differently for Tagged packets. Bo= th allows TX of packets with size up to programmed MTU value but in receive= direction Fortville drops packets of size equal to configured MTU. Additio= nally, Fortville does not report any error/drop counter if packets with siz= e more than configured MTU (max frame size) are received. In Niantic we can= see error counters getting incremented if packets of size more than MTU ar= e received. >=20 > When ports are started, device attribute max_rx_pkt_len is set during dev= ice/queue init by application (OVS in our case) and this max_rx_pkt_len is = used to program hardware register in device which in turn determines the ma= ximum size of packet/frame that it can receive. > What we have found during testing is that Niantic could receive tagged/un= tagged packets of size equal to max_rx_pkt_len but Fortville could only rec= eive tagged packets (single tag) up to size <=3D (max_rx_pkt_len - 4). Data= sheet of Niantic mentions that device implicitly accounts for VLAN tag(s) = in addition to Maximum Frame size programmed which is not the case for Fort= ville. This causes issue with MTU settings and maximum frame size that NIC = can receive with tagged and untagged traffic. > We have tested it with OVS-DPDK where it uses device attribute max_rx_pkt= _len to set max frame size in accordance with the configured MTU size of po= rt. However, Ixgbe (Niantic) and i40e (Fortville) interpret it differently.= I looked at some other PMD drivers and different drivers interpret dev_con= f.rxmode.max_rx_pkt_len differently i.e. some adds one or two VLAN, few don= 't include it and some use this field differently. It creates issue with MT= U while running same application on different NICs and PMD drivers need to = be fixed to have consistent behavior with MTU/Max Frame Size settings. >=20 > Regards, > Nitin Katiyar MTU on most operating systems is advisory to device driver. The device driver may receive packets up to that MTU or larger. How much bigger depends on how the hardware receive packet limit is impleme= nted. Same thing happens in Linux and BSD.