On 3/5/2020 4:35 PM, Thomas Monjalon wrote: > 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".
It may matter in the PMD git log for clarity, the datasheet has it as FDIR, the base code API has it as FDIR, relevant users/customers will understand it as FDIR, so why limit this usage in the commit log. > The other issue is that I see other vendors using this term > which should be reserved to Intel. If they have this same functionality and use it as FDIR for the context I don't see why this needs to be limited to the 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. > OK
