Re: [dpdk-dev] [PATCH] devtools: add more headline case rules

[Thomas Monjalon <thomas@monjalon.net>]

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.