fq_codel with 802.15.4 6LoWPAN fragmentation issue
Subsystems (3)
Alexander Aring
maintainerHi,
when using "fq_codel" as network scheduler, I noticed an issue with IEEE 802.15.4 6LoWPAN fragmentation. The issue is that high payloads IPv6 packets are dropped.
I detected the issue on the sending side which segments the 6LoWPAN packet into several fragments.
In the IEEE 802.15.4 6LoWPAN fragmentation we have a 6LoWPAN interface (MTU 1280) on top of an IEEE 802.15.4 interface (MTU 127). The 6LoWPAN fragmentation algorithm creates in the "ndo_start_xmit" netdev_ops callback function of the 6LoWPAN interface new sk_buffs for the underlaying IEEE 802.15.4 interface (as skb->dev) and sends them via a dev_queue_xmit.
IEEE 802.15.4 is a very slow connection and after each transmit there is an "interframe spacing time" which depends on frequency setting. In my testcase, that's about ~500 us for a payload above 18 bytes. This is done by calling netif_stop_queue for the interface and start a timer after each transmitted frame according to the interframe spacing time. When the timer fires, it wakes the queue again by calling netif_wake_queue.
Now: What I am noticed with fq_codel is that the code at [0] will drop high payloaded IPv6 packets. Of course, if we have an IPv6 packet of more than 1280 bytes payload we have a fragmentation (IPv6 fragmentation) over a fragmentation (802.15.4 6LoWPAN fragmentation).
When I increase the "params->interval" parameter I can send a "longer" IPv6 packet depending how much I increase the "params->interval" parameter.
I assume that the "params->interval" which defaults to MS2TIME(100) is too small. I further assume that at the beginning of fragmentation the interval measurement starts "vars->first_above_time = now + params->interval;" (line 247 at [0]) and while sending several fragments with the above mentioned interframe spacing time, the sending takes too long and the skb will be dropped.
My questions are:
- What's the best way to deal with something like that?
- Is there a way to set the "params->interval" _per interface_? So I can change the default parameter to a suitable value in the "ndo_init" callback of the 6LoWPAN interface.
Thanks in advance.
- Alex
[0] http://lxr.free-electrons.com/source/include/net/codel.h#L248
Quoted 42 lines · Alexander Aring
Hi,
when using "
fq_codel" as network scheduler, I noticed an issue with IEEE 802.15.4 6LoWPAN fragmentation. The issue is that high payloads IPv6 packets are dropped.I detected the issue on the sending side which segments the 6LoWPAN packet into several fragments.
In the IEEE 802.15.4 6LoWPAN fragmentation we have a 6LoWPAN interface (MTU 1280) on top of an IEEE 802.15.4 interface (MTU 127). The 6LoWPAN fragmentation algorithm creates in the "
ndo_start_xmit"netdev_opscallback function of the 6LoWPAN interface newsk_buffsfor the underlaying IEEE 802.15.4 interface (asskb->dev) and sends them via adev_queue_xmit.IEEE 802.15.4 is a very slow connection and after each transmit there is an "interframe spacing time" which depends on frequency setting. In my testcase, that's about ~500 us for a payload above 18 bytes. This is done by calling
netif_stop_queuefor the interface and start a timer after each transmitted frame according to the interframe spacing time. When the timer fires, it wakes the queue again by callingnetif_wake_queue.Now: What I am noticed with
fq_codelis that the code at [0] will drop high payloaded IPv6 packets. Of course, if we have an IPv6 packet of more than 1280 bytes payload we have a fragmentation (IPv6 fragmentation) over a fragmentation (802.15.4 6LoWPAN fragmentation).When I increase the "
params->interval" parameter I can send a "longer" IPv6 packet depending how much I increase the "params->interval" parameter.I assume that the "
params->interval" which defaults to MS2TIME(100) is too small. I further assume that at the beginning of fragmentation the interval measurement starts "vars->first_above_time= now +params->interval;" (line 247 at [0]) and while sending several fragments with the above mentioned interframe spacing time, the sending takes too long and the skb will be dropped.My questions are:
Quoted 7 lines
- What's the best way to deal with something like that?
- Is there a way to set the "
params->interval"_perinterface_? So I can change the default parameter to a suitable value in the "ndo_init" callback of the 6LoWPAN interface.Thanks in advance.
Sure, fq_codel is a qdisc, each network device gets its own qdisc hierarchy.
You can therefore set different parameter on your interface,
Very simple example :
tc qdisc dev lowpan0 root fq_codel interval XXX
Quoted 2 lines · Eric Dumazet
example :
Sorry, one keyword was missing :
tc qdisc replace dev lowpan0 root fq_codel interval XXX
Quoted 8 lines · Eric Dumazet
Quoted 2 lines · Eric Dumazet
example :
Sorry, one keyword was missing :
tc qdisc replace dev lowpan0 root
fq_codelinterval XXX
But the parameter that you probably want to change is not the interval. It is probably the target :
tc qdisc replace dev lowpan0 root fq_codel interval 200ms target 25ms
Now, if the fragmentation was done after qdisc dequeue, as in GSO layer, you would not have this issue : all segments of one ipv6 message would be transmitted, no matter what.