Re: [tipc-discussion] [PATCH 5/5] tipc: add ip/udp media type

[Ying X. <yin...@wi...>]

>> +/**
>> + * tipc_send_msg - enqueue a send request
>> + *
>> + * The send request need to be deferred since we cannot call kernel
>> + * socket API functions while holding the node spinlock.
>> + */
> 
> Yes. Unfortunately this is necessary for now, but we should aim at
> releasing the node spinlock before sending the buffers, on all
> bearers. This will probably have some positive impact on performance.
> 

About the problem, I have an idea avoiding to always take node lock
during sending path: currently it's hard for us to release node lock
before sending SKBs to bearer. Instead if we can exactly simulate the
behaviour of socket lock when implementing node lock, we should be able
to eliminate the limitation that bearer sending function must be atomic.
Precisely speaking, on sending patch, tipc_node_lock() simulates the
implementation of lock_sock(). It first checks whether its owner flag is
zero under node spin lock's protection. If the flag is set, the caller
of tipc_node_lock() would be blocked until the owner is released,
otherwise, the caller can continue to operate any member of node
structure and go on other operations without node spin lock being token.
So without node spin lock, we are not afraid that the sending function
of UDP bearer may be blocked. Of course, tipc_node_unlock() also needs
to wakeup processes that are being blocked as they do not obtain node'
owner.

But on receiving path, we have to introduce a backlog queue for link. If
node's owner is set on receiving path, the got SKB should be queued to
the backlog queue, otherwise, it can be put into deferred_queue or
directly deliver to socket layer.

As a new input buffer queue is introduced in Jon's series (" tipc:
resolve message disordering problem"), maybe it's easier for us to
implement the idea based on it :)

Regards,
Ying