Re: altq on a gif tunnel

[Greg Troxel <gdt%lexort.com@localhost>]

Tho <tho%useless-ficus.net@localhost> writes:

> On Monday  5 Nov 2018, at 19:48, Greg Troxel wrote:
>> 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

I meant that I thought there was support in if_tun.

> 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 ... ? :)

You are well on your way to understanding.

Without following the details, I'll observe that gif could be
implemented with no output queue, and just putting packets into the
system input queue when created.  So having gif have a possibly
rate-limited output is different and harder.  Also, ALTQ partly tends to
operate under the assumption that a transmission opportunity will arise,
and then what to do (at least, for work-conserving queue disciplines).
Here, we are talking about a limit even if a packet could be put
someplace.

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

I did not mean to say I thought what you were doing was wrong.   Just
that 3 people could want 3 different behaviors.

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

A classifier could look inside the ipip header.  But your point is
almost entirely valid.

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

I think it would be nice to have altq work.