[Codel] R: R: Jumbo frames with fq_codel

Alessandro Bolletta alessandro at mediaspot.net
Mon Nov 25 13:30:44 EST 2013


No, we are running on batman-adv and it runs on layer-2 and encapsulates layer-2 ethernet frames.

This encapsulation costs a bit in terms of throughput but it's a big deal on mesh networks ;)

--
Alessandro Bolletta
Mediaspot S.r.l.

-----Messaggio originale-----
Da: Dave Taht [mailto:dave.taht at gmail.com] 
Inviato: lunedì 25 novembre 2013 19.27
A: Alessandro Bolletta
Cc: codel at lists.bufferbloat.net
Oggetto: Re: [Codel] R: Jumbo frames with fq_codel

On Mon, Nov 25, 2013 at 10:17 AM, Alessandro Bolletta <alessandro at mediaspot.net> wrote:
>>On Mon, Nov 25, 2013 at 10:02 AM, Alessandro Bolletta <alessandro at mediaspot.net> wrote:
>> Hi guys,
>> I'm working on an environment which runs on jumbo ethernet frames (about 1550bytes) and I would ask you if do you think that it's needed >a trick in order to correctly debloat interfaces as ath9k and ag71xx which carries such big frames.
>
>>I am under the impression that the ag71xx does not support jumbo frames.
>>Slightly larger than usual frames? dunno.
>
> We are thinking to implement jumbo frames support on some devices 
> based on ag71xx :) Many SoCs support up to 2028 bytes or 4076 bytes of MTU but the driver still can't manage MTUs higher than 1518bytes.

It sounds like you are going down the path I went down about 7 years back in the WISP6 project. Back then I wanted to deliver a pure ipv6 backbone and encapsulate ipv4 traffic inside it at the normal 1500 MTU.

I built hardware that worked with larger MTUs, and encountered more bugs in ipv6 encapsulation than I care to think about. Then I tried to change hardware because the manufacturer had canceled the product and ran into great difficulty finding a replacement.

For the record, that device was this one, which supported 2028 bytes or so:

http://www.embeddedarm.com/products/board-detail.php?product=TS-7250

>>the ath9k supports frames up to the size of the wireless standards 
>>(23xx bytes or so)
>
> Yes.
>
>>fq_codel's internal quantum is the actual ip packet size, not the wire size.
>>at lower bandwidths it pays to have a lower quantum (like 300) on outgoing interfaces.
>
>>In openwrt the default on all interfaces is 300, which I dont necessarily agree with.
>
> Ok. I thought that codel would leverage on layer-2 parameters, as the size of the ethernet frame.
>
>>
>> Thanks
>>
>> --
>> Alessandro Bolletta
>> Mediaspot S.r.l.
>>
>>
>> _______________________________________________
>> Codel mailing list
>> Codel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/codel
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: 
> http://www.teklibre.com/cerowrt/subscribe.html
>
>
> _______________________________________________
> Codel mailing list
> Codel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel



--
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html





More information about the Codel mailing list