Messages in this thread |  | | From | kuznet@ms2 ... | Subject | Re: Q: sock output serialization | Date | Sat, 9 Sep 2000 20:25:28 +0400 (MSK DST) |
| |
Hello!
> I guess I╢d also need to call lock_sock() from sendmsg(). And before > calling x25_kick from socket input path, I╢d need to verify that > sk->lock.users is zero. If sk->lock.users was !=0, I╢d need some atomic > variable anyway in order to defer the kick.
In input path you have a packet. Add it to backlog and processing will be resumed after lock is released. Compare 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).
Being legal in principle, using non-standard serialization primitives is seriously deprecated. It is impossible to maintain. In you case, it is even not evident that it does not lose events with smp.
> - introduce a protocol-global spinlock and protect protocol-global > critical section by spin_lock_bh() instead of cli()
Why? It is not required. There are no reasons to protect protocol as whole, if sockets are protected.
> - protect all sock proto_ops methods by lock_sock()
Yes.
> - when bh functions need to be protected from sk state change, they > need to aquire bh_lock_sock()
And check for sk->lock.users. If it is not zero, operation is deferred.
> - before bh (timer) function change sk state, they need to aquire > bh_lock_sock and verify, that sk->lock.users!=0
Yes.
> - remove the SOCKOPS_WRAPPED() macro from the proto_ops
Yes. And finally announce protocol to be SMP aware setting data field of packet_type to 1.
> Can NET_TX_SOFTIRQ be prempted by NET_RX_SOFTIRQ or timer?
It cannot be preempted, but it is not very essential, because all they can run in parallel on different cpus.
Alexey - 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/
|  |