Hi! On 22:36 Sun 26 Jul , ?ukasz Jachymczyk wrote: > 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? Slow receivers are handled by windowing. The receivers specifies how much data he will be able to receive even if the application does not do any recv(). This is set in /proc/sys/net/ipv4/tcp_rmem . The values mean min, default, max in bytes. The default can be overridden by the application by calling setsockopt(). In every ACK which is send, the receiver specifies how much space is still free. If the program does not read fast enough, the window gets smaller and the sender slows down. > >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. This was about network congestion. > >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. dev_queue_xmit tells you so when sending. I do not know a way to find out when it drops received packets, but it should not bother you. -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
