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. >
