In neigh_update() in neighbor.c, we're looping through the list calling
__skb_dequeue(). Is there any particular reason why this was chosen rather than
__skb_dequeue_tail()? The latter would result in FIFO flushing of the buffer
which could have some benefits to udp applications that retry on out-of-order
message receipt, and it doesn't seem to be many more instructions, if any.
Besides, this isn't the fast path so a few extra instructions shouldn't matter.
Would you anticipate any odd side effects if we did change to FIFO flushing?
Chris
-- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/