Messages in this thread |  | | Date | Mon, 11 Sep 2000 22:30:39 +0200 | From | Henner Eisen <> | Subject | Re: Q: sock output serialization |
| |
Hi,
>>>>> "kuznet" == kuznet <kuznet@ms2.inr.ac.ru> writes:
kuznet> Hello!
kuznet> In input path you have a packet. Add it to backlog and kuznet> processing will be resumed after lock is released. Compare kuznet> with tcp.
>> serializing the kick. Well, maybe my solution could still be >> simplified (maybe some test_and_set/clear_bit() magic could >> achieve the same).
kuznet> Being legal in principle, using non-standard serialization kuznet> primitives is seriously deprecated. It is impossible to kuznet> maintain. In you case, it is even not evident that it does kuznet> not lose events with smp.
Yes, I see. I did not realize before that the lock_sock and the sk->backlog framework are not two independent things. They really seem to be designed for team work only. Did I get this right?
And I realize that the lock_sock framework is superior to my approach. It does not only serialize output, it also serialized output and input such that other problems are solved as well (the current code, even after serializing output, could still suffer from atomicity problems when input path interrupts output path an modifies protocol control block variables in a non-atomic manner). The lock_sock framework properly applied seems to make socket propgramming as easy as in the old cli()/sti() days again. Basically, it seems to be a Ždisable interrupts for this socketŽ
>> - introduce a protocol-global spinlock and protect >> protocol-global critical section by spin_lock_bh() instead of >> cli()
kuznet> Why? It is not required. There are no reasons to protect kuznet> protocol as whole, if sockets are protected.
Well, the term Žprotocol globalŽ was misleading. I should have said Žglobal to the protocol-familyŽ. E.g. there are currently some cli()/sti() pairs to protect socket list and routing table manipulations. tcp also seems to use some additional protocol-global spinlocks (like tcp_portalloc_lock).
>> Can NET_TX_SOFTIRQ be prempted by NET_RX_SOFTIRQ or timer?
kuznet> It cannot be preempted, but it is not very essential, kuznet> because all they can run in parallel on different cpus.
The reason why I was asking is that I recently got IP and PPP tunneling over X.25 working (in-kernel). In that case, protocol output processing would be done from NET_TX_SOFTIRQ context, which is only allowed to to bh_lock_sock(), but not lock_sock(). As bh_lock_sock() is just spin_lock() -- and not spin_lock_bh() -- this could stall the CPU if NET_TX_SOFTIRQ were preempted by a timer or NET_RX_SOFTIRQ while holding the spinlock. In that case, beeing preemptable would make a very essential difference.
kuznet> Alexey
Thanks for the insight. I hope this is sufficient to migrate the code. Not before 2.4.0-final, however :-).
Anyway, it seems that I can already make use the lock_sock() infrastructure for fixing the output serialization, even without making the whole protocol stack SMP-aware at once.
Henner
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |