[Make-wifi-fast] [PATCH v2 4/4] mac80211: Use Airtime-based Queue Limits (AQL) on packet dequeue

[Sebastian Moeller]

> On Oct 19, 2019, at 18:56, Toke Høiland-Jørgensen <toke at redhat.com> wrote:
> 
> Sebastian Moeller <moeller0 at gmx.de> writes:
> 
>> On October 19, 2019 2:14:42 PM GMT+02:00, "Toke Høiland-Jørgensen" <toke at redhat.com> wrote:
>>> Sebastian Moeller <moeller0 at gmx.de> writes:
>>> 
>>>>> On Oct 18, 2019, at 16:15, Johannes Berg <johannes at sipsolutions.net>
>>> wrote:
>>>>> 
>>>>> On Thu, 2019-10-17 at 18:11 -0700, Kan Yan wrote:
>>>>>> I don't think it is hard to take care of extra header size for
>>> frames
>>>>>> with VLAN tags
>>>>> 
>>>>> VLAN tags are payload as far as wifi is concerned, so no need to
>>> take
>>>>> that into account ...
>>>> 
>>>> 	Ah, good to know; but just out of curiosity is any of the
>>>> 	following 7 Byte Preamble + 1 Byte start of frame delimiter
>>>> 	(SFD) + 12 Byte inter frame gap (IFG) actually packaged into
>>>> 	ethernet frames inside 802.11 packets? I would have guessed that
>>>> 	at least the IFG would be dropped as it does not really exist as
>>>> 	"data"?
>>> 
>>> No, those are accounted in the airtime calculation in airtime.c (Felix'
>>> code). E.g.,:
>>> 
>>> 		duration = 20 + 16; /* premable + SIFS */
>> 
>> 
>> Looks like apples and pears to me. These seem to be the wifi preamble
>> and short interframe space in microseconds. Sure you need to add those
>> to the airtime estimate as these will hog airtime.
>> 
>> But the 12 byte interframe gap of the Ethernet packets that are
>> transmitted over a 802.11 link surely will not be actually transmitted
>> as a stretch of zeros? Same for the Ethernet preamble and the start of
>> frame marker, as those can/will be trivially added by the Ethernet NIC
>> that will handle the encapsulated Ethernet frame after the wifi link,
>> no?
>> 
>> As far as I can tell, the wifi SIFS is constant time independent of
>> wifi link speed while the IFG size is constant but it's duration is
>> not?
>> 
>> Again, I am trying to understand this conceptually, which seems
>> orthogonal to the question of whether 38 is the correct number....
>> 
>> Best Regards
>>        Sebastian
>> 
>> P.S.: Is there a repository I could look into to try to figure this
>> out myself?
> 
> This paper has a fairly comprehensive description of how frames look
> when transmitted over the air: http://dx.doi.org/10.1155/2015/548109
> (see Figure 1 and Table 2, and the text in Section 2).
> 
> Otherwise you'll have to go read the standards, I guess (though I can't
> say I'd recommend it as light reading :P)
> 

Thanks!
Well, that certainly was "fun", but as far as I can tell neither the ethernet preamble, the Start of frame delimiter or the ethernet inter frame gap will be actually transmitted/encapsulated over wifi; wifi will use its own equivalents (in multiple versions) but these are seemingly not guaranteed to have the same octet equivalents as their ethernet counter parts. (Looking at the standard made my head slightly hurt and looking at the massive overhead expansion wifi brings, I wonder why the ethernet frame is not simply carried completely as payload... I guess that is what WDS is doing, except for the "simple" part)

Learned something new... ;)

Regards
	Sebastian

> -Toke