Hello! > There is no socket spinlock anymore. > Above lock is skb_queue lock which is held inside > skb_dequeue/skb_queue_tail calls.
Lock is named differently, but it is still here. BTW for UDP even the name is the same. > > Equivalent of socket user lock. > > No, it is an equivalent for hash lock in socket table. OK. But you have to introduce socket mutex somewhere in any case. Even in ATCP. > Just an example - tcp_established() can be called with bh disabled under > the socket lock. When we have a process context in hands, it is not. Did you ask youself, why do not we put all the packets to backlog/prequeue and just wait when user will read the data? It would be 100% equivalent to "netchannels". The answer is simple: because we cannot wait. If user delays for 200msec, wait for connection collapse due to retransmissions. If the segment is out of order, immediate attention is required. Any scheme, which tries to wait for user unconditionally, at least has to run a watchdog timer, which fires before sender senses the gap. And this is what we do for ages. Grep for "VJ" in sources. :-) netchannels have nothing to do with it, it is much elder idea. > In that case one copies the whole data into userspace, so access for 20 > bytes of headers completely does not matter. For short packets it matters. But I said not this. I said it looks _worse_. A bit, but worse. > Hmm, for 80 bytes sized packets win was about 2.5 times. Could you > please show me lines inside existing code, which should be commented, so > I got 50Mbyte/sec for that? If I knew it would be done. :-) Actually, it is the action, which I would expect. This, but not dropping all the TCP stack. > I showed there, that using existing stack it is imposible Please, understand, it is such statements that compromise your work. If it is impossible then it is not interesting. Alexey - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
