Re: altq on a gif tunnel

[Tho <tho%useless-ficus.net@localhost>]

On Monday  5 Nov 2018, at 19:48, Greg Troxel wrote:
> NetBSD-current/src/sys/net > egrep ALTQ *.c
> [run it yourself and have a look]

I actually rather did `grep IFQ_ if_gif.c`, as according to altq(9)
this is what seems more relevant.
The "#ifdef ALTQ" and similar were removed in if_gif.c 1.39 (back in
2002) with the comment "ALTQify some drivers".
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/net/if_gif.c.diff?r1=1.38&r2=1.39

> From a really quick look, it seems that there is support in if_gif.c.
> (However, perhaps sometimes the support is via if.c.)

You meant "no support", right? I think there is actually some support,
according to rev. 1.39 (link above), and even since rev. 1.33 with the
comment "make gif ALTQ-capable on outgoing".
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/net/if_gif.c.diff?r1=1.32&r2=1.33

In particular, if_gif.c uses IFQ_SET_READY() -- quoting altq(9): "ALTQ
can be enabled only on interfaces with this flag" -- and IFQ_CLASSIFY().

However, my quick investigations showed that a call to IFQ_ENQUEUE()
was removed in rev. 119 by knakahara@ to fix some MP issues
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/net/if_gif.c.diff?r1=1.118&r2=1.119

Now, gif_output() eventually calls ip{,6}_output() with no call to
IFQ_ENQUEUE(), even though there is still the IFQ_CLASSIFY call. I
think that might be the issue? The rev. 1.33 "make gif ALTQ-capable"
added such a call, for instance.

So I wonder if rev. 119 did not introduce a regression (knakahara@,
what do you think?) and how to fix this ... ? :)

> Look at if_tun.c, and where ALTQ shows up.  It's really an interesting
> question exactly what ALTQ in gif should mean, but there is an analogous
> method to how tun works that seems sensible.

Of course, it makes more sense to altq directly on the physical
interface. However, what I want to achieve is to give lower priority
to certain TCP traffic, and the only place where the original packet
can be spotted by altq is on the gif interface ifself. So I wanted to
give it a try and see if it was actually doing something useful, but I
was stopped by the previous issue.

I also thought about using just an altq conditioner on the gif
interface to mark packet (using the ToS/traffic class byte) and then
use the IFF_LINK1 flag of gif to pass the mark to the outer
encaspsulation and then altq again on the physical interface just
matching the ToS ... (but this requires altq to work on gif).

I was also wondering if a NPF plugin able to change the Tos/Traffic
Class byte of packets couldn't be a good alternative (and then using
altqd on the physical interface with a filter for the specific
ToS added by npf). It should be easy to do, I guess. I could have a
look if this seems more useful than using altq on gif?