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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:17 EST