[nft PATCH] doc: nft.8: Describe iface_type data type

[nft PATCH] doc: nft.8: Describe iface_type data type

[Phil Sutter]

An entry in data-types.txt offers space for a name-value table. Even if
one would refer to ARPHRD_*, some names are not derived from the
respective macro name and thus not intuitive.

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 doc/data-types.txt         | 27 +++++++++++++++++++++++++++
 doc/primary-expression.txt |  2 --
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/doc/data-types.txt b/doc/data-types.txt
index e44308b5322cb..0b350effbea68 100644
--- a/doc/data-types.txt
+++ b/doc/data-types.txt
@@ -83,6 +83,33 @@ filter input iifname eth0
 filter input iifname "(eth0)"
 ----------------------------
 
+INTERFACE TYPE TYPE
+~~~~~~~~~~~~~~~~~~~
+[options="header"]
+|==================
+|Name | Keyword | Size | Base type
+|Interface type |
+iface_type|
+16 bit |
+integer
+|===================
+
+The interface type type is used with *meta iiftype/oiftype* expression. Its values correspond with respective ARPHRD_* defines in <linux/if_arp.h>.
+
+.The following keywords will automatically resolve into an interface type type with given value
+
+[options="header"]
+|==================
+|Keyword | Value
+| ether | 1
+| ppp | 512
+| ipip | 768
+| ipip6 | 769
+| loopback | 772
+| sit | 776
+| ipgre | 778
+|===================
+
 LINK LAYER ADDRESS TYPE
 ~~~~~~~~~~~~~~~~~~~~~~~
 [options="header"]
diff --git a/doc/primary-expression.txt b/doc/primary-expression.txt
index d5495e2c86291..bd80cd7f92fda 100644
--- a/doc/primary-expression.txt
+++ b/doc/primary-expression.txt
@@ -149,8 +149,6 @@ String value in the form HH:MM or HH:MM:SS. Values are expected to be less than
 Interface index (32 bit number). Can be specified numerically or as name of an existing interface.
 |ifname|
 Interface name (16 byte string). Does not have to exist.
-|iface_type|
-Interface type (16 bit number).
 |uid|
 User ID (32 bit number). Can be specified numerically or as user name.
 |gid|
-- 
2.51.0

Re: [nft PATCH] doc: nft.8: Describe iface_type data type

[Florian Westphal]

Phil Sutter <phil@nwl.cc> wrote:
> An entry in data-types.txt offers space for a name-value table. Even if
> one would refer to ARPHRD_*, some names are not derived from the
> respective macro name and thus not intuitive.
> 
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
>  doc/data-types.txt         | 27 +++++++++++++++++++++++++++
>  doc/primary-expression.txt |  2 --
>  2 files changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/data-types.txt b/doc/data-types.txt
> index e44308b5322cb..0b350effbea68 100644
> --- a/doc/data-types.txt
> +++ b/doc/data-types.txt
> @@ -83,6 +83,33 @@ filter input iifname eth0
>  filter input iifname "(eth0)"
>  ----------------------------
>  
> +INTERFACE TYPE TYPE
> +~~~~~~~~~~~~~~~~~~~

TYPE TYPE?

Re: [nft PATCH] doc: nft.8: Describe iface_type data type

[Phil Sutter]

On Tue, Jan 27, 2026 at 11:17:59PM +0100, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> wrote:
> > An entry in data-types.txt offers space for a name-value table. Even if
> > one would refer to ARPHRD_*, some names are not derived from the
> > respective macro name and thus not intuitive.
> > 
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > ---
> >  doc/data-types.txt         | 27 +++++++++++++++++++++++++++
> >  doc/primary-expression.txt |  2 --
> >  2 files changed, 27 insertions(+), 2 deletions(-)
> > 
> > diff --git a/doc/data-types.txt b/doc/data-types.txt
> > index e44308b5322cb..0b350effbea68 100644
> > --- a/doc/data-types.txt
> > +++ b/doc/data-types.txt
> > @@ -83,6 +83,33 @@ filter input iifname eth0
> >  filter input iifname "(eth0)"
> >  ----------------------------
> >  
> > +INTERFACE TYPE TYPE
> > +~~~~~~~~~~~~~~~~~~~
> 
> TYPE TYPE?

Yes, sadly. ;)

We also have "ICMP TYPE TYPE" and "ICMPV6 TYPE TYPE" - the types
themselves are called "icmp_type", "icmpv6_type" and "iface_type". So
section titles formed like "<type> type" end up this way. It seems
wrong, but "INTERFACE TYPE" is misleading as the type is not called
"interface" but "interface type".

Maybe we should include the underscores in the title?

Cheers, Phil

Re: [nft PATCH] doc: nft.8: Describe iface_type data type

[Florian Westphal]

Phil Sutter <phil@nwl.cc> wrote:
> On Tue, Jan 27, 2026 at 11:17:59PM +0100, Florian Westphal wrote:
> > Phil Sutter <phil@nwl.cc> wrote:
> > > +INTERFACE TYPE TYPE
> > > +~~~~~~~~~~~~~~~~~~~
> > 
> > TYPE TYPE?
> 
> Yes, sadly. ;)

Ugh.

> We also have "ICMP TYPE TYPE" and "ICMPV6 TYPE TYPE" - the types
> themselves are called "icmp_type", "icmpv6_type" and "iface_type". So
> section titles formed like "<type> type" end up this way. It seems
> wrong, but "INTERFACE TYPE" is misleading as the type is not called
> "interface" but "interface type".

Whats wrong with INTERFACE TYPE?

Its called interface type.
I'd remove the extra TYPE everywhere, its not many occurences:

data-types.txt:ICMP TYPE TYPE
data-types.txt:The ICMP Type type is used to conveniently specify the ICMP header's type field.
data-types.txt:ICMPV6 TYPE TYPE
data-types.txt:The ICMPv6 Type type is used to conveniently specify the ICMPv6 header's type field.

Re: [nft PATCH] doc: nft.8: Describe iface_type data type

[Phil Sutter]

On Tue, Jan 27, 2026 at 11:47:16PM +0100, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> wrote:
> > On Tue, Jan 27, 2026 at 11:17:59PM +0100, Florian Westphal wrote:
> > > Phil Sutter <phil@nwl.cc> wrote:
> > > > +INTERFACE TYPE TYPE
> > > > +~~~~~~~~~~~~~~~~~~~
> > > 
> > > TYPE TYPE?
> > 
> > Yes, sadly. ;)
> 
> Ugh.
> 
> > We also have "ICMP TYPE TYPE" and "ICMPV6 TYPE TYPE" - the types
> > themselves are called "icmp_type", "icmpv6_type" and "iface_type". So
> > section titles formed like "<type> type" end up this way. It seems
> > wrong, but "INTERFACE TYPE" is misleading as the type is not called
> > "interface" but "interface type".
> 
> Whats wrong with INTERFACE TYPE?

As said, these headers are all structured as "<typename> TYPE":

- INTEGER TYPE
- BITMASK TYPE
- STRING TYPE
- INTERFACE TYPE TYPE
- LINK LAYER ADDRESS TYPE
- IPV4 ADDRESS TYPE
...
- ICMP TYPE TYPE
- ICMP CODE TYPE
- ICMPV6 TYPE TYPE
...

IMO we could drop the " TYPE" suffix from them all, but only merging the
"TYPE TYPE" cases is inconsistent.

> Its called interface type.
> I'd remove the extra TYPE everywhere, its not many occurences:
> 
> data-types.txt:ICMP TYPE TYPE
> data-types.txt:The ICMP Type type is used to conveniently specify the ICMP header's type field.
> data-types.txt:ICMPV6 TYPE TYPE
> data-types.txt:The ICMPv6 Type type is used to conveniently specify the ICMPv6 header's type field.

Here we at least get a hint from the casing: The type's name is "ICMPv6
Type", so "the type named "ICMPv6 Type" becomes "the ICMPv6 Type type".

I get your point, it looks wrong and sounds odd when reading out loud
but it is formally correct.

Cheers, Phil

Re: [nft PATCH] doc: nft.8: Describe iface_type data type

[Florian Westphal]

Phil Sutter <phil@nwl.cc> wrote:
> As said, these headers are all structured as "<typename> TYPE":
> 
> - INTEGER TYPE
> - BITMASK TYPE
> - STRING TYPE
> - INTERFACE TYPE TYPE

- INTERFACE TYPE

> - LINK LAYER ADDRESS TYPE
> - IPV4 ADDRESS TYPE
> ...
> - ICMP TYPE TYPE

ICMP TYPE

> - ICMP CODE TYPE
> - ICMPV6 TYPE TYPE

> - ICMPV6 TYPE

> IMO we could drop the " TYPE" suffix from them all, but only merging the
> "TYPE TYPE" cases is inconsistent.

Why?!

INTEGER TYPE
INTERFACE TYPE TYPE

Thats absolutely sounds inconsistent.

Sure:
payload expression, datatype integer (integer), 4 bits
meta expression, datatype iface_type (network interface type) (basetype integer), 16 bits

So what?
I don't see any implication that you can take 'FOO TYPE' to mean
that the type is called 'foo' internally.

> I get your point, it looks wrong and sounds odd when reading out loud
> but it is formally correct.

Ok, I give up.

Re: [nft PATCH] doc: nft.8: Describe iface_type data type

[Phil Sutter]

On Wed, Jan 28, 2026 at 12:18:51AM +0100, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> wrote:
> > As said, these headers are all structured as "<typename> TYPE":
> > 
> > - INTEGER TYPE
> > - BITMASK TYPE
> > - STRING TYPE
> > - INTERFACE TYPE TYPE
> 
> - INTERFACE TYPE
> 
> > - LINK LAYER ADDRESS TYPE
> > - IPV4 ADDRESS TYPE
> > ...
> > - ICMP TYPE TYPE
> 
> ICMP TYPE
> 
> > - ICMP CODE TYPE
> > - ICMPV6 TYPE TYPE
> 
> > - ICMPV6 TYPE
> 
> > IMO we could drop the " TYPE" suffix from them all, but only merging the
> > "TYPE TYPE" cases is inconsistent.
> 
> Why?!
> 
> INTEGER TYPE
> INTERFACE TYPE TYPE
> 
> Thats absolutely sounds inconsistent.

Why is it? First type is named "integer", the second one "interface
type".

> Sure:
> payload expression, datatype integer (integer), 4 bits
> meta expression, datatype iface_type (network interface type) (basetype integer), 16 bits
> 
> So what?
> I don't see any implication that you can take 'FOO TYPE' to mean
> that the type is called 'foo' internally.

We start splitting hair, but IMO a user reading "ICMP CODE TYPE" and
"ICMP TYPE" will likely assume the first type is called "ICMP CODE" and
the second just "ICMP".

> > I get your point, it looks wrong and sounds odd when reading out loud
> > but it is formally correct.
> 
> Ok, I give up.

I'm just stating my point. If you think we should just
's/type type/type/g' and it's not a problem, just go for it and I'll
adjust my patch to it.

Cheers, Phil

Re: [nft PATCH] doc: nft.8: Describe iface_type data type

[Phil Sutter]

On Tue, Jan 27, 2026 at 11:12:52PM +0100, Phil Sutter wrote:
> An entry in data-types.txt offers space for a name-value table. Even if
> one would refer to ARPHRD_*, some names are not derived from the
> respective macro name and thus not intuitive.
> 
> Signed-off-by: Phil Sutter <phil@nwl.cc>

Patch applied.