On 4/16/2019 10:33 AM, Andrew Rybchenko wrote: > On 4/12/19 8:57 PM, Ferruh Yigit wrote: >> On 4/11/2019 9:43 AM, Andrew Rybchenko wrote: >>> On 4/11/19 10:49 AM, Thomas Monjalon wrote: >>>> About the features called flow director, filtering or flow steering, >>>> we have some overlap in our API that we should clean. >>>> It is especially important when considering to freeze the API for >>>> stability. >>>> >>>> Please read this deprecation notice from December 2016: >>>> >>>> * ethdev: the legacy filter API, including >>>> ``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as >>>> well >>>> as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR, >>>> HASH and L2_TUNNEL, is superseded by the generic flow API (rte_flow) in >>>> PMDs that implement the latter. >>>> Target release for removal of the legacy API will be defined once most >>>> PMDs have switched to rte_flow. >>>> >>>> We must mark the eth_dev_filter API as deprecated and decide about >>>> a date to remove it. >>>> >>>> Which PMD is implementing this API and not rte_flow? >>> In accordance with feature matrix is it i40e_vec, ixgbe_vec and qede, but >>> I think it is just a mistake in documentation. >>> >>> Flow API support tick is missing for many PMDs which actually implement >>> (as far as I can see): bonding, dppa2, e100, mlx4, qede, mvpp2, softnic. >>> I've added maintainers to CC. >> I think having both "Flow control" and "Flow API" is confusing, it looks to >> me >> "Flow control" is name of the feature, "Flow API" is implementation detail >> and >> other implementation detail is "Flow director" >> >> From the consumers point of view, to they need to know if the flow control >> implemented using "Flow API"? This information looks like more driver >> internal. > > Flow control and flow API are absolutely different features. > Flow control is about Ethernet pauses etc.
Yes they are, not sure what I was thinking, scratch what I said ... > Flow API is about filtering and actions. > Flow director is mainly filtering approach and I would agree to classify > it as > implementation detail. I'd consider to move it under flow API umbrella > finally, but I don't know enough details on it. I was trying to say "flow api" is not target, target is "filtering" support, "flow api" it method to have it, perhaps can merge "flow API" & "Flow director" under "flow filtering" ... > >> Keeping only "Flow control" in feature list, and remove "Flow API" & "Flow >> director", and set "Flow control" as support both with implementations makes >> sense to me. What do you think? >> >>>> If there are still some, deadlines should help them to be converted :) >>>> If some help is needed, please ask. >>>> >>>> Anyway, after more than 2 years of notice, I think it is fair to mark >>>> the legacy API as deprecated in 19.05 release. >>> I agree. I think it is a good idea. >>> >>> Andrew. >
