From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10050.outbound.protection.outlook.com [40.107.1.50]) by dpdk.org (Postfix) with ESMTP id 76BE01B22A; Sun, 12 Nov 2017 08:08:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lJf8z/qKVNmPbL6lITENh96WOXztKeIU4kU8w07X8Qk=; b=oePlkZpgcId06yDEcCayOXG+xPcok4ijsKA8OfPZCN8z3iocgHvLTBpcDTq8DYvHkDZnLAHzGzQAX8u7oW8jEHZmGfa7N1uJeMX/EETJ5DTUAox4++MAOytt9EOTpPBMNS498cgU2Iw4Zvf15H40XaTxjnv+K16JxppGP0aCzL4= Received: from AM4PR05MB3202.eurprd05.prod.outlook.com (10.171.186.31) by HE1PR0501MB2042.eurprd05.prod.outlook.com (10.167.245.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Sun, 12 Nov 2017 07:08:15 +0000 Received: from AM4PR05MB3202.eurprd05.prod.outlook.com ([fe80::7d32:49d9:bab3:fb94]) by AM4PR05MB3202.eurprd05.prod.outlook.com ([fe80::7d32:49d9:bab3:fb94%13]) with mapi id 15.20.0218.011; Sun, 12 Nov 2017 07:08:15 +0000 From: Ori Kam To: Yongseok Koh , Adrien Mazarguil CC: =?iso-8859-1?Q?N=E9lio_Laranjeiro?= , "dev@dpdk.org" , "stable@dpdk.org" Thread-Topic: [PATCH] net/mlx5: fix number of segment calculation Thread-Index: AQHTWXSArQoPPG52g0e5mH6mdFjlWKMNZDmAgAC9BgCAAjWo0A== Date: Sun, 12 Nov 2017 07:08:15 +0000 Message-ID: References: <1510243472-24872-1-git-send-email-orika@mellanox.com> <20171110100625.GF24849@6wind.com> <20171110212257.GA4189@yongseok-MBP.local> In-Reply-To: <20171110212257.GA4189@yongseok-MBP.local> 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=orika@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0501MB2042; 6:w0GgvSmdYSS2/vxdWb0HMle80XdV20VBsgJq4ld7qlpQwDu4H/HhU7F0vmn8L18tJAOd4T7lrXNVsCCg3Ahfzpm9Gku5si25zJ6LpHv4qH8yeQJRXGhQZlDqd34SSL9jg04NGDSFLgzTunBMOYTInuqK3OdXDrH/BkiS6DyfDK3v0N/OB3+8akn7mrUShZhYQINpDj5+FjRmmW73U2DVKtdW4/pOgvVBKmcZK07FM7HfqiwipbE5ht3o1qiKHXddGluau6lNzQIa9Tgzj5VbS8NM/Sd5flfGPRbTXdYpBd0DOmwGnOCzewiNSw2a8XYFERcY5AtTD2QxfK6odgcJE0taUS9kg7+LPlGPDN2WWHo=; 5:zhmDp2UVY4jz9HnPWMS+KcwkrZLGF/AUWnU0OUyqfqy85OSt+ZsnEg9joFudKmVHsIWz+s6fQj8EMH4LMzQhZTjYEWvQorjwgssM78MP64IL2ov7v+O1greF6Mbk+sNKNxi7AEyXgKoZ6a78rLpVgFw79aeXptI5A53mG1S7c6w=; 24:mizWkVoNeNuFIzdRE7BxYGermXqxUKSO6R3Z4x7LO0vxQDRYjy64V5g1iLbnMd3h+FkfcyNP+ypjFOE0dDrYlvFhoTrGzQeQjrmdhrMe/aU=; 7:vmeAb150VyEZDY+SzSAF/LV9vcUaoLqPnXAtM7oPb9dC1VplOUelDCV6bz64d8/eRlmReQITuu3nxu6yb3gycaeOM7c+pnufQKhoRd5cVCwNwTq0gLVMTOvfE/D6P9GGM1SN3NAJB9u3n4DNj5EX33zEsdI8FFXgLEeQkSoR80isUUK6m3btVnSyjWnWXoWg3LII/dbBOqrIJvbcgRd8SzwO+Glz6P8L5+P2VNYr1CP9Qo3SfkRNPUMq1Jz8/L2/ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 94af06c8-0175-4f1e-e304-08d5299c24c9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:HE1PR0501MB2042; x-ms-traffictypediagnostic: HE1PR0501MB2042: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3231022)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0501MB2042; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0501MB2042; x-forefront-prvs: 0489CFBAC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(39830400002)(189002)(43784003)(199003)(13464003)(24454002)(101416001)(561944003)(14454004)(106356001)(50986999)(55016002)(105586002)(54356999)(68736007)(76176999)(478600001)(102836003)(6116002)(3846002)(53546010)(5250100002)(316002)(229853002)(110136005)(54906003)(53936002)(2950100002)(33656002)(25786009)(3660700001)(99286004)(5660300001)(8936002)(2906002)(7696004)(4326008)(6246003)(6436002)(3280700002)(97736004)(6506006)(86362001)(9686003)(189998001)(8676002)(81166006)(81156014)(2900100001)(305945005)(7736002)(66066001)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0501MB2042; H:AM4PR05MB3202.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 94af06c8-0175-4f1e-e304-08d5299c24c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2017 07:08:15.0390 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0501MB2042 Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix number of segment calculation X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 07:08:17 -0000 Hi, Thanks Adrien and Yongseok for your review. Due to Adrien comment I'm withdrawing the patch. Thanks again, Ori Kam > -----Original Message----- > From: Yongseok Koh > Sent: Friday, November 10, 2017 11:23 PM > To: Adrien Mazarguil > Cc: Ori Kam ; N=E9lio Laranjeiro > ; dev@dpdk.org; stable@dpdk.org > Subject: Re: [PATCH] net/mlx5: fix number of segment calculation >=20 > On Fri, Nov 10, 2017 at 11:06:25AM +0100, Adrien Mazarguil wrote: > > Hi Ori, > > > > On Thu, Nov 09, 2017 at 06:04:32PM +0200, Ori Kam wrote: > > > The CRC size should be taken into consideration when computing the > > > number of mbuf segments for packet on the receive path. > > > Large packets can be dropped due to extra CRC length. > > > > > > Fixes: a1366b1a2be3 ("net/mlx5: add reference counter on DPDK Rx > > > queues") > > > Cc: stable@dpdk.org > > > Cc: nelio.laranjeiro@6wind.com > > > > > > Signed-off-by: Ori Kam > > > > I don't think there's an issue to fix, there's actually a reason it's > > done that way, perhaps I'm wrong but let me elaborate. > > > > When applications request CRC to be written to mbuf (more precisely > > not to be stripped), its extra 4 bytes are neither part of > > mbuf->pkt_len nor > > mbuf->data_len. It just happens to be written past mbuf data if > > mbuf->there's room > > for it, where applications knowingly expect it based on how they > > configured the PMD. That's the API. > > > > This implies applications also size mbufs accordingly; if they don't > > provide room for the CRC, it can't be written. This extra room is > > assumed to be part of max_rx_pkt_len. When CRC stripping is requested, > > they do not have to provide such room (IBV_WQ_FLAGS_SCATTER_FCS is > not set on mlx5 Rx queues). >=20 > I looked around other driver/example codes as it is not documented (or to= o > obvious to do?), it looks there's consensus that max_rx_pkt_len includes = 4B > FCS. > Then, I agree that PMD doesn't need to care about this. >=20 > > One problem with your proposal is assuming all segments are consumed > > entirely during Rx and max_rx_pkt_len is reached, another segment with > > zero data length gets appended just to hold the CRC. Applications may > > interpret this as a bug. >=20 > I don't think this patch causes the issue. It just unnecessarily reserves= extra > 4B room if CRC strip is disabled. And even apps should not interpret this= as a > bug because apps requested to have CRC. > Currently mlx5_rx_busrt() doesn't allow this situation (putting only 4B C= RC in > the last segment) because it subtracts ETHER_CRC_LEN from pkt_len if CRC > isn't stripped. And it is done before looking for the next segment. I thi= nk this > is a problem to fix on the contrary - app wanted to see CRC but it's not = there. > Right? >=20 > Thanks, > Yongseok