05/03/2020 17:06, Ferruh Yigit: > On 3/5/2020 3:11 PM, Thomas Monjalon wrote: > > 05/03/2020 15:55, Ferruh Yigit: > >> FDIR -> Flow Director > > > > In general I prefer avoiding FDIR for two reasons: > > 1/ this is an Intel-only acronym > > Yes, it is "Intel Ethernet Flow Director" but still it is a valid abbreviation > and we have it in our git logs. > > > 2/ rte_flow API is superseding it > > I think there is a confusion here, two things seems confused. > > Flow director is a NIC feature for filtering different flows to different > queues. It is kind of advanced RSS [1]. > > You can use rte_flow to program FDIR, which is what we are doing for a while. > So > this is *not* something conflicts with rte_flow. > > Also there is 'filter_ctrl' API (rte_eth_dev_filter_ctrl) which is deprecated, > and which can be used to control HW filtering, including FDIR. > > So 'rte_flow' doesn't supersede 'FDIR', it supersede 'filter_ctrl' API, and > 'FDIR' feature can be used with rte_flow.
Yes I understand the difference between the vendor's naming of the feature and the API. > [1] > https://software.intel.com/en-us/articles/setting-up-intel-ethernet-flow-director > " > Intel® Ethernet Flow Director (Intel® Ethernet FD) directs Ethernet packets to > the core where the packet consuming process, application, container, or > microservice is running. It is a step beyond receive side scaling (RSS) in > which > packets are sent to different cores for interrupt processing, and then > subsequently forwarded to cores on which the consuming process is running. > > Intel Ethernet FD supports advanced filters that direct received packets to > different queues, and enables tight control on flow in the platform. It > matches > flows and CPU cores where the processing application is running for flow > affinity, and supports multiple parameters for flexible flow classification > and > load balancing. When operating in Application Targeting Routing (ATR) mode, > Intel Ethernet FD is essentially the hardware offloaded version of Receive > Flow > Steering available on Linux* systems, and when running in this mode, Receive > Packet Steering and Receive Flow Steering are disabled. > " As said above, "flow steering" is a well understood description of such a feature. I don't see the need for using "FDIR" instead of "flow steering". The other issue is that I see other vendors using this term which should be reserved to Intel. Adding FDIR to the dictionary may increase the confusion. At the end, it is OK to use vendor-specific acronyms, the most important to me was to explain things in this discussion :-) > >> OOB -> Out Of Bounds > > > > I don't think it is a good idea to use this acronym. It is not a techno. > > I prefer out-of-bounds with all letters. > > This is coming from the git history, it seems we have used it in past at least > once. Do you prefer to drop it? I prefer to drop yes. It could also mean Out Of Band, so it is confusing.
