Michael Blizek wrote:
1) Congestion handling is usually done by the sender and not the receiver.
I'm not sure about this. After all I can send as much data over network as I can and the receiver might have not enough resources to handle it. Isn't receiver the one that should worry about congestion?
2) packets are dropped either when entering the qdisc, which is triggered by dev_queue_xmit or lost during transmission (e.g. a switch is overloaded and does not do XON/XOFF). If it is dropped by the qdisc, NET_XMIT_DROP as defined in include/linux/netdevice.h is returned dev dev_queue_xmit.
As far as I know dev_queue_xmit is called by transmitter. I might not write it clearly, but I'm concerned about congestion on receiver's side.
3) If all you do is providing virtual interfaces on top of physical interfaces, you do not need to bother about congestion handling. Protocols on top (e.g. TCP) will do this. However, if should return NET_XMIT_DROP or whatever dev_queue_xmit returns, if you can. But .f you do not, it should run anyway.
Still, I would like to know if kernel is dropping Ethernet packets of type that belongs to my driver.
Thanks for your answer, looking forward to see reply:) -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
