(Mar 10 2014 06:07), Clemens Ladisch wrote:
Then this should be done only when we actually have one of these known devices (and only when this error is known to happen, i.e., directly after a no-data packet); otherwise, this could, in theory, interfere with dropped packets.
This commit add sorting of in-packets. When callback of receive-context is processed, the parameters of in-packets are stored in sort table and sorted by its value of data block counter. The sort algorism works faster in ordered sequence than in messy sequence. This is convinient for this purpose because the sequence is assumed not to be so messy. After sorting, packets are processed except for a last few packets in sort table. These packets are stored in buffer once and used in next cycle.
Only a single packet is out of order, i.e., only two packets are exchanged. So it is not necessary to run a general-purpose sorting algorithm; it would be sufficient to store a single packet if it is out of order.
I cannot prove 'there are only two packets are exchanged'. What I can prove is 'the sequence of packets includes a bit disorder'.
I think keeping packet sequence is important to all of devices. So here I applied generic processing for this purpose.
(I wonder why I received nothing about my RFC in November...)
A NULL check is not necessary for kfree().
I did read /mm/slab.c and realize it.
Thanks
Takashi Sakamoto o-takashi@sakamocchi.jp