From: Ying X. <yin...@wi...> - 2015-01-19 02:44:11
|
On 01/16/2015 07:49 PM, Erik Hugne wrote: >>> > > +/** >>> > > + * 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. >> > > What's holding me from sending another version now is the skb reallocation > from kernel_sendmsg(). > On lowmem systems this is causing the kworker thread to spin heavily on memory > allocation because it has run out of memory in the kmalloc-2048 pool. > It should be possible to reuse the TIPC skb and pass that to the IP stack, but > i don't know exactly how to do this. If this is another reason why we have to send TIPC buffers in a separate thread, maybe we should seriously consider the idea I proposed before. If we are really able to make the TIPC sending path non-atomic, this is not only of benefit to UDP bearer, but also it gives TIPC an extreme flexibility, for example, we can use all kinds of tunnels implemented in networking stack as TIPC bearers, such as, ipip, vti, vxlan, ipv6_tunnels etc. Regards, Ying |