On 5/2/2018 6:09 PM, Shahaf Shuler wrote: > Wednesday, May 2, 2018 1:06 PM, Thomas Monjalon: >> Subject: Re: [dpdk-dev] [PATCH] ethdev: fix applications failure on configure >> >> 02/05/2018 11:58, Xueming(Steven) Li: >>> From: Ferruh Yigit <ferruh.yi...@intel.com> >>>> Or as Xueming suggested, we can take rss_hf config as best effort and >> not return error at all. >>>> >>>> I think this forces PMDs to have up-to-date flow_type_rss_offloads >> values, is there any other benefit? >>>> What was the initial motivation to add error return on this check? >>> >>> The original idea is to add rss_hf check on mlx5 PMD, while it looks >>> more generic to move the check to ethdev api from discussion[1]. >>> >>> [1] >>> >> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww >> w. >>> dpdk.org%2Fml%2Farchives%2Fdev%2F2018- >> April%2F095136.html&data=02%7C01 >>> >> %7Cshahafs%40mellanox.com%7Cc773c15dcbda49d21da008d5b0145864%7C >> a652971 >>> >> c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636608523825745897&sdata=jDU >> OyU0E% >>> 2FY5g3oSKBQxUsz8Ehr%2FN3ek5h8kotQBLZBU%3D&reserved=0 >> >> I think it is not correct to not return an error when the app request an >> offload >> which is not supported. >> >> Do we agree to work on PMDs and applications to fix this offload >> compliance? >> And submit a deprecation notice to return an error in a later release? > > I probably missed it but why deprecation notice is required? > Per my understanding it is just a fix to enforce better the API which is: > 1. application reads capabilities > 2. application sets offloads accordingly.
The return error on some values is new, and this is a behavior change in API. Some applications working fine will start throwing error, and for DPDK application developers this may mean go and update their application. For possible application update I believe the change should be announced in deprecation notice in advance.
