From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0081.outbound.protection.outlook.com [104.47.1.81]) by dpdk.org (Postfix) with ESMTP id 7D7C7239 for ; Tue, 12 Dec 2017 07:30:45 +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=deu0f1cuZHwR7ZmOg9kMdde/jwivlKYsVd4DPc7dSxs=; b=PoLEffYcDql0l2KoXaoQm6LDOG17TWYP3iM32cRVjBZoQwlgxqJqBJ0hWp7mrVdLH9twSsOvFuQJWskvAi3/gYnmcciJ7VevQTxDMBW0oc/aXPVsF4YdGDj6uLjqR70laeC8JnhEncQsaqJAYlA79ddRCwcWku8oO4ANukqf5V0= Received: from VI1PR05MB3149.eurprd05.prod.outlook.com (10.170.237.142) by VI1PR05MB3149.eurprd05.prod.outlook.com (10.170.237.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Tue, 12 Dec 2017 06:30:43 +0000 Received: from VI1PR05MB3149.eurprd05.prod.outlook.com ([fe80::3905:ed70:f744:9dc6]) by VI1PR05MB3149.eurprd05.prod.outlook.com ([fe80::3905:ed70:f744:9dc6%13]) with mapi id 15.20.0302.013; Tue, 12 Dec 2017 06:30:43 +0000 From: Shahaf Shuler To: "Ananyev, Konstantin" , "dev@dpdk.org" , Radu Nicolau Thread-Topic: [dpdk-dev] [PATCH 14/39] examples/ip_reassembly: convert to new ethdev offloads API Thread-Index: AQHTZFV8X2dpS9wyok+mtTdyRqom/qM+WcuAgAEBB2A= Date: Tue, 12 Dec 2017 06:30:43 +0000 Message-ID: References: <20171123121941.144335-1-shahafs@mellanox.com> <20171123121941.144335-5-shahafs@mellanox.com> <2601191342CEEE43887BDE71AB9772585FAC8030@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAC8030@irsmsx105.ger.corp.intel.com> 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=shahafs@mellanox.com; x-originating-ip: [31.154.10.107] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR05MB3149; 6:ggNviDKxZJBKwLDItfAYwZORUv93aHSCbbAJA1Op+gnShCqVrzjo0zWdfdhHNnoBfUL0NtGfBMRa9/uH+tDFVqJ7DcokDaVHWY89FvGySt72du2SIioVWmjdt69NaO19NkKi4GxEr3EV9q41wXpd8fONpe0j8OBWivMnSTQbaCp6Mku3xdCPUumbyM5nHqpcuvkJysQbj/uQdwmV1n7on2hXBcN+sJ1Zh/R0uwtGi7ZnXPU2T4qGcZbAR9PLoMwd6F/WkzIuEHkaD8cLzpBkeH7Ejxu3OD3xNxoBDxnbX76RyyVJtq6mfBQz3BmpIC2VgrecTuPLYaypWxkYnRM+kqo39irXYcRMrtmKQR0+tlM=; 5:LJKkSN1y/B/x++BuS41KMPqUNbQotlVQAUT3uft13hFg3LRfp7RiCuj3gvDO6pK5hGcDgmAaMXWvkMWjeu0Ms8LHrXiN1WK/RzWtWFlAoTPnpp0YCbmAso4pDOOUGY+HWraBoxfzhoJE1Khyws6k8ooh7dmNh852ir0Chc50sRU=; 24:Z/1M+P1QmpnnimRjJRwLHmxoQXr88aFqOwi6h7TEG/4fQGqce2nRta7yn+8XuvXAEu9lkXGSEmTsJw9JBp2QXBkxGGerfl5gqucv3tU4q74=; 7:c7krMOuP55AODP00y1a1f1KbcEYVnYRONucYe7WkvhGCG6ydwX/9wJx1rjQGzl7GlSUyzy90RaIyvKUHZrVpBvZOzB6hMrRyqG5vc5xbhd5LKA2/t0t2yIAr6KYCZi4kbEiiD3K7ICRH7+A6w6cO1/0I69lDttKiG5lk4Z0j9VKR7bYmJeOtxzBWvmhTiuLuILn7Sa4jRB17DGGWuzoy3EY1IRWyMvJbhDaOaOpd/r0FGF+zVRSPKQsy2r2iCSs+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4f5b34a7-7b64-46f1-241c-08d54129df10 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:VI1PR05MB3149; x-ms-traffictypediagnostic: VI1PR05MB3149: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231023)(6055026)(6041248)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR05MB3149; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR05MB3149; x-forefront-prvs: 051900244E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(366004)(189003)(199004)(6506006)(68736007)(7736002)(8936002)(74316002)(66066001)(305945005)(5660300001)(3846002)(99286004)(3280700002)(3660700001)(6116002)(102836003)(81156014)(2906002)(33656002)(2900100001)(81166006)(5250100002)(2950100002)(106356001)(105586002)(97736004)(478600001)(6436002)(53376002)(25786009)(316002)(6246003)(7696005)(86362001)(55016002)(229853002)(76176011)(966005)(9686003)(110136005)(59450400001)(53936002)(6306002)(2501003)(14454004)(533714002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB3149; H:VI1PR05MB3149.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f5b34a7-7b64-46f1-241c-08d54129df10 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2017 06:30:43.3384 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB3149 Subject: Re: [dpdk-dev] [PATCH 14/39] examples/ip_reassembly: convert to new ethdev offloads API 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: Tue, 12 Dec 2017 06:30:45 -0000 Monday, December 11, 2017 5:04 PM, Ananyev, Konstantin: > > + if ((dev_info.tx_offload_capa & port_conf.txmode.offloads) > !=3D > > + port_conf.txmode.offloads) { > > + printf("Some Tx offloads are not supported " > > + "by port %d: requested 0x%lx supported > 0x%lx\n", > > + portid, port_conf.txmode.offloads, > > + dev_info.tx_offload_capa); > > + port_conf.txmode.offloads &=3D > dev_info.tx_offload_capa; > > + } >=20 > Sort of generic question regarding most examples - wouldn't it be better = to > do rte_exit() if device doesn't support the offloads we expect instead of > masking off unsupported offloads and continue? > Konstantin We already started to discuss this question, see [1]. I agree that it is wrong approach to mask the not supported offloads and co= ntinue the application.=20 So now I we have 2 options: 1. report the warning and let the PMD to fail the device configuration. 2. like you suggested, report the error and exit the application. While it is wrong for application to set offloads which are not reported by= the device capabilities, the input I got from Radu is that there are a lot= of PMDs that will break with option 2, see [1].=20 One example is ixgbe which expects to have CRC offload enabled with IPSEC b= ut don't report it on its caps.=20 So my current direction is to make the examples less strict, and give the o= ption for the PMD to fail those if not supported. Any objection?=20 [1] http://dpdk.org/ml/archives/dev/2017-December/083441.html