[Codel] Jumbo frames with fq_codel

[Codel] Jumbo frames with fq_codel

[Alessandro Bolletta]

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.

Thanks

--
Alessandro Bolletta
Mediaspot S.r.l.

Re: [Codel] Jumbo frames with fq_codel

[Jonathan Morton]

On 25 Nov, 2013, at 8:02 pm, Alessandro Bolletta wrote:

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

If it is really 1550 bytes, then that's barely bigger than a standard Ethernet frame of 1500 bytes.  No special adjustment could possibly be needed for that, beyond standard debloating techniques.

 - Jonathan Morton

Re: [Codel] Jumbo frames with fq_codel

[Dave Taht]

On Mon, Nov 25, 2013 at 10:02 AM, Alessandro Bolletta
<alessandro@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.

the ath9k supports frames up to the size of the wireless standards
(23xx bytes or so)

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.

>
> Thanks
>
> --
> Alessandro Bolletta
> Mediaspot S.r.l.
>
>
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel



-- 
Dave Täht

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

[Codel] R: Jumbo frames with fq_codel

[Alessandro Bolletta]

>On 25 Nov, 2013, at 8:02 pm, Alessandro Bolletta wrote:

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

>If it is really 1550 bytes, then that's barely bigger than a standard Ethernet frame of 1500 bytes.  No special adjustment could possibly be >needed for that, beyond standard debloating techniques.

> - Jonathan Morton

So, do you think that the debloat script that can be found in cerowrt could manage correctly those frames with no changes?

[Codel] R: Jumbo frames with fq_codel

[Alessandro Bolletta]

>On Mon, Nov 25, 2013 at 10:02 AM, Alessandro Bolletta <alessandro@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.

>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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel



--
Dave Täht

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

Re: [Codel] R: Jumbo frames with fq_codel

[Dave Taht]

On Mon, Nov 25, 2013 at 10:17 AM, Alessandro Bolletta
<alessandro@mediaspot.net> wrote:
>>On Mon, Nov 25, 2013 at 10:02 AM, Alessandro Bolletta <alessandro@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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel



-- 
Dave Täht

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

[Codel] R: R: Jumbo frames with fq_codel

[Alessandro Bolletta]

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@gmail.com] 
Inviato: lunedì 25 novembre 2013 19.27
A: Alessandro Bolletta
Cc: codel@lists.bufferbloat.net
Oggetto: Re: [Codel] R: Jumbo frames with fq_codel

On Mon, Nov 25, 2013 at 10:17 AM, Alessandro Bolletta <alessandro@mediaspot.net> wrote:
>>On Mon, Nov 25, 2013 at 10:02 AM, Alessandro Bolletta <alessandro@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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel



--
Dave Täht

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

Re: [Codel] R: Jumbo frames with fq_codel

[Dave Taht]

On Mon, Nov 25, 2013 at 10:17 AM, Alessandro Bolletta
<alessandro@mediaspot.net> wrote:
>>On Mon, Nov 25, 2013 at 10:02 AM, Alessandro Bolletta <alessandro@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.
>
>>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.

One of the beauties of codel is it doesn't care the size of the frame
at all, it only cares about how long it takes to deliver it.

Now, there are some interesting interactions between codel delivering
a big fat TSO string of packets and then a smaller packet (collatoral
damage), but they aren't bad, and there's fixes in 3.12 for tso that
make life saner.

fq_codel's quantum controls the degree of mixing between flows, set it
really low (say 300) to help voip and acks out on slow asymmetric
links, don't set it lower, otherwise leave it alone.

>>
>> Thanks
>>
>> --
>> Alessandro Bolletta
>> Mediaspot S.r.l.
>>
>>
>> _______________________________________________
>> Codel mailing list
>> Codel@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel



-- 
Dave Täht

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