> To avoid having to deal with fragmentation on dequeue, the split is > set to be after the fragmentation handler. This means that some > reordering of TX handlers is necessary, and some handlers had to be > made aware of fragmentation due to this reordering. Come to think of it, that's actually counterproductive. If a fragment is dropped, or even just if fragments are reordered, the receiver will not be able to defragment the frame, and will thus drop it. Therefore, it's all-or-nothing, and we shouldn't transmit any fragment if we drop/reorder one (*). So ... I think you'll just have to deal with fragmentation on the codel/fq/whatever queues and keep fragments together, or do fragmentation afterwards. johannes (*) also, couldn't this mean that we send something completely stupid like seq=1,frag=0 seq=2,frag=0 seq=2,frag=1 seq=2,frag=1 if reordering happened?
