DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] devtools: add more headline case rules
@ 2020-05-20 10:25 Ferruh Yigit
  2020-05-24 21:01 ` Thomas Monjalon
  0 siblings, 1 reply; 10+ messages in thread
From: Ferruh Yigit @ 2020-05-20 10:25 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev, Ferruh Yigit

AltiVec ->
IOTLB   -> Input/Output Translation Lookaside Buffer
IPsec   -> Internet Protocol security
PPPoE   -> Point-to-Point Protocol over Ethernet
PVID    -> Port VLAN IDentifier

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
 devtools/words-case.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/devtools/words-case.txt b/devtools/words-case.txt
index ae3bd4c450..bdfd2a2d96 100644
--- a/devtools/words-case.txt
+++ b/devtools/words-case.txt
@@ -1,5 +1,6 @@
 aarch32
 aarch64
+AltiVec
 API
 Arm
 armv7
@@ -15,7 +16,9 @@ FW
 GENEVE
 HW
 IO
+IOTLB
 IOVA
+IPsec
 L2
 L3
 L4
@@ -37,6 +40,8 @@ PCI
 PF
 PHY
 PMD
+PPPoE
+PVID
 RDMA
 RETA
 RSS
-- 
2.25.4


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] devtools: add more headline case rules
  2020-05-20 10:25 [dpdk-dev] [PATCH] devtools: add more headline case rules Ferruh Yigit
@ 2020-05-24 21:01 ` Thomas Monjalon
  0 siblings, 0 replies; 10+ messages in thread
From: Thomas Monjalon @ 2020-05-24 21:01 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: dev

20/05/2020 12:25, Ferruh Yigit:
> AltiVec ->
> IOTLB   -> Input/Output Translation Lookaside Buffer
> IPsec   -> Internet Protocol security
> PPPoE   -> Point-to-Point Protocol over Ethernet
> PVID    -> Port VLAN IDentifier
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied, thanks




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] devtools: add more headline case rules
  2020-03-05 16:35     ` Thomas Monjalon
@ 2020-03-05 17:43       ` Ferruh Yigit
  0 siblings, 0 replies; 10+ messages in thread
From: Ferruh Yigit @ 2020-03-05 17:43 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: dev, David Marchand, Andrew Rybchenko, Xiaolong Ye, Qi Zhang

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] devtools: add more headline case rules
  2020-03-05 16:06   ` Ferruh Yigit
@ 2020-03-05 16:35     ` Thomas Monjalon
  2020-03-05 17:43       ` Ferruh Yigit
  0 siblings, 1 reply; 10+ messages in thread
From: Thomas Monjalon @ 2020-03-05 16:35 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: dev, David Marchand, Andrew Rybchenko, Xiaolong Ye, Qi Zhang

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.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] devtools: add more headline case rules
  2020-03-05 15:11 ` Thomas Monjalon
@ 2020-03-05 16:06   ` Ferruh Yigit
  2020-03-05 16:35     ` Thomas Monjalon
  0 siblings, 1 reply; 10+ messages in thread
From: Ferruh Yigit @ 2020-03-05 16:06 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: dev, David Marchand, Andrew Rybchenko, Xiaolong Ye, Qi Zhang

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.



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


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

> 
> The rest looks fine, thanks.
> 
> 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] devtools: add more headline case rules
  2020-03-05 15:39   ` Ferruh Yigit
@ 2020-03-05 15:42     ` Andrew Rybchenko
  0 siblings, 0 replies; 10+ messages in thread
From: Andrew Rybchenko @ 2020-03-05 15:42 UTC (permalink / raw)
  To: Ferruh Yigit, Thomas Monjalon; +Cc: dev, David Marchand

On 3/5/20 6:39 PM, Ferruh Yigit wrote:
> On 3/5/2020 3:08 PM, Andrew Rybchenko wrote:
>> On 3/5/20 5:55 PM, Ferruh Yigit wrote:
>>> BAR    -> Base Address Register
>>> FDIR   -> Flow Director
>>> GENEVE -> Generic Network Virtualization Encapsulation
>>> IO     -> Input/Output
>>> MPLS   -> Multiprotocol Label Switching
>>> NEON
>>> null
>>> NVGRE  -> Network Virtualization using Generic Routing Encapsulation
>>> OOB    -> Out Of Bounds
>>> RDMA   -> Remote Direct Memory Access
>>> TC     -> Traffic Class
>>> VFIO   -> Virtual Function I/O
>>> VXLAN  -> Virtual Extensible LAN
>>> XDP    -> eXpress Data Path
>>>
>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>
>> I'm not sure about 'null'. Otherwise
> 
> I have no preference on it, but that is from the git history, so just to be
> consistent.

OK, makes sense.

>>
>> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>
> 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] devtools: add more headline case rules
  2020-03-05 15:08 ` Andrew Rybchenko
@ 2020-03-05 15:39   ` Ferruh Yigit
  2020-03-05 15:42     ` Andrew Rybchenko
  0 siblings, 1 reply; 10+ messages in thread
From: Ferruh Yigit @ 2020-03-05 15:39 UTC (permalink / raw)
  To: Andrew Rybchenko, Thomas Monjalon; +Cc: dev, David Marchand

On 3/5/2020 3:08 PM, Andrew Rybchenko wrote:
> On 3/5/20 5:55 PM, Ferruh Yigit wrote:
>> BAR    -> Base Address Register
>> FDIR   -> Flow Director
>> GENEVE -> Generic Network Virtualization Encapsulation
>> IO     -> Input/Output
>> MPLS   -> Multiprotocol Label Switching
>> NEON
>> null
>> NVGRE  -> Network Virtualization using Generic Routing Encapsulation
>> OOB    -> Out Of Bounds
>> RDMA   -> Remote Direct Memory Access
>> TC     -> Traffic Class
>> VFIO   -> Virtual Function I/O
>> VXLAN  -> Virtual Extensible LAN
>> XDP    -> eXpress Data Path
>>
>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 
> I'm not sure about 'null'. Otherwise

I have no preference on it, but that is from the git history, so just to be
consistent.

> 
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] devtools: add more headline case rules
  2020-03-05 14:55 Ferruh Yigit
  2020-03-05 15:08 ` Andrew Rybchenko
@ 2020-03-05 15:11 ` Thomas Monjalon
  2020-03-05 16:06   ` Ferruh Yigit
  1 sibling, 1 reply; 10+ messages in thread
From: Thomas Monjalon @ 2020-03-05 15:11 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: dev, David Marchand

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
2/ rte_flow API is superseding it

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

The rest looks fine, thanks.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] devtools: add more headline case rules
  2020-03-05 14:55 Ferruh Yigit
@ 2020-03-05 15:08 ` Andrew Rybchenko
  2020-03-05 15:39   ` Ferruh Yigit
  2020-03-05 15:11 ` Thomas Monjalon
  1 sibling, 1 reply; 10+ messages in thread
From: Andrew Rybchenko @ 2020-03-05 15:08 UTC (permalink / raw)
  To: Ferruh Yigit, Thomas Monjalon; +Cc: dev, David Marchand

On 3/5/20 5:55 PM, Ferruh Yigit wrote:
> BAR    -> Base Address Register
> FDIR   -> Flow Director
> GENEVE -> Generic Network Virtualization Encapsulation
> IO     -> Input/Output
> MPLS   -> Multiprotocol Label Switching
> NEON
> null
> NVGRE  -> Network Virtualization using Generic Routing Encapsulation
> OOB    -> Out Of Bounds
> RDMA   -> Remote Direct Memory Access
> TC     -> Traffic Class
> VFIO   -> Virtual Function I/O
> VXLAN  -> Virtual Extensible LAN
> XDP    -> eXpress Data Path
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>

I'm not sure about 'null'. Otherwise

Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [dpdk-dev] [PATCH] devtools: add more headline case rules
@ 2020-03-05 14:55 Ferruh Yigit
  2020-03-05 15:08 ` Andrew Rybchenko
  2020-03-05 15:11 ` Thomas Monjalon
  0 siblings, 2 replies; 10+ messages in thread
From: Ferruh Yigit @ 2020-03-05 14:55 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev, Ferruh Yigit, David Marchand

BAR    -> Base Address Register
FDIR   -> Flow Director
GENEVE -> Generic Network Virtualization Encapsulation
IO     -> Input/Output
MPLS   -> Multiprotocol Label Switching
NEON
null
NVGRE  -> Network Virtualization using Generic Routing Encapsulation
OOB    -> Out Of Bounds
RDMA   -> Remote Direct Memory Access
TC     -> Traffic Class
VFIO   -> Virtual Function I/O
VXLAN  -> Virtual Extensible LAN
XDP    -> eXpress Data Path

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
 devtools/words-case.txt | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/devtools/words-case.txt b/devtools/words-case.txt
index 6bfb81985..126f2c86a 100644
--- a/devtools/words-case.txt
+++ b/devtools/words-case.txt
@@ -4,13 +4,17 @@ API
 Arm
 armv7
 armv8
+BAR
 CRC
 DCB
 DMA
 EEPROM
+FDIR
 FreeBSD
 FW
+GENEVE
 HW
+IO
 IOVA
 L2
 L3
@@ -20,20 +24,27 @@ Linux
 LRO
 LSC
 MAC
+MPLS
 MSS
 MTU
+NEON
 NIC
 NUMA
+null
+NVGRE
 NVM
+OOB
 PCI
 PF
 PHY
 PMD
+RDMA
 RETA
 RSS
 Rx
 SCTP
 SW
+TC
 TOS
 TPID
 TSO
@@ -42,6 +53,9 @@ Tx
 UDP
 vDPA
 VF
+VFIO
 VLAN
 VMDq
 VSI
+VXLAN
+XDP
-- 
2.24.1


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-05-24 21:01 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-20 10:25 [dpdk-dev] [PATCH] devtools: add more headline case rules Ferruh Yigit
2020-05-24 21:01 ` Thomas Monjalon
  -- strict thread matches above, loose matches on Subject: below --
2020-03-05 14:55 Ferruh Yigit
2020-03-05 15:08 ` Andrew Rybchenko
2020-03-05 15:39   ` Ferruh Yigit
2020-03-05 15:42     ` Andrew Rybchenko
2020-03-05 15:11 ` Thomas Monjalon
2020-03-05 16:06   ` Ferruh Yigit
2020-03-05 16:35     ` Thomas Monjalon
2020-03-05 17:43       ` Ferruh Yigit

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).