> More pondering on this is needed...
Dave, I slept for 12 hours today, and now my mind is a bit clearer.
My advice, have good sleep and the problems will be solved
themselves :):) Let's not touch this cursed wmem_alloc for a while,
its interaction with tcp is so weird, that it is worth to think
a bit before trying to cure it.
Now:
- we should add to wmem_alloc at least 1 byte per clone.
(and Alan will say, and he will be absolutely right, that
you must add at least sizeof(struct sk_buff))
- your loop in tcp_send_fin will kill host, if sock_wmalloc
fails because of problems in device (f.e. excess collisions)
Even worse, if it will fail because queue is saturated
by tcp send queue, if will block forever, because socket
is locked and nobody will able to shrink the queue.
Apparently, you wanted to write alloc_skb() there
rather than sock_wmalloc.
Actually, I have strong feeling, that for tcp wmem_alloc should
be split to two parts. One of them is for tcp send queue
and driven only by tcp protocol logic, another is for packets,
which are in fly. At least, it would solve the conflict between
resource limiting and flow control. The idea is not mature,
but I feel it is correct. Dave, do not forget also about
those poor ppp guys; now device driven flow control does not work
for tcp, which can be incorrect in some curcumstances.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu