Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: >> 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. Hmm, guess that makes sense. Bugger. Will think about how to do that. > > 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? (assuming the last line was supposed to read 'seq=1,frag=1') Yes, that could happen, in principle (it depends on the fragments' size in relation to the FQ quantum). When does fragmentation happen anyway? Is it safe to assume there's no aggregation when it does? -Toke
