Re: [tipc-discussion] Questions about broadcast link link reset.

[Stephens, A. <all...@wi...>]

Jason wrote:

> When sending say a NAME_DISTRIBUTOR message through broadcast
> pseudo link and reach the queue limits(which is 3000), the following call
> graph can
> happen:
> 
> tipc_bclink_send_msg(buf) -> tipc_link_send_buf (bcl,buf) ->
> tipc_link_reset(bcl) -> ...  (I produce it by decrease the queue limit)
> 
> 
> My questions are:
> 1) Why we call tipc_link_reset if importance is greater than
> CONN_MANAGER?
> Can you point me the background knowledge?

Jon may be in a better position to answer this question, since this logic pre-dates my involvement with TIPC. However, I believe the idea here is that TIPC is capable of surviving situations in which an application's payload message cannot be sent due to link congestion, but not an inability to send an "internal" message (such as a name distributor or fragmentation message). That is, TIPC can tell an application to wait and retry sending a payload message later, but it cannot tell itself to wait and resend its own internal messages. Consequently, when a non-payload message can't be sent TIPC resets the link to try and clear the congestion (which should really be happening in the first place).
	
> 2) Why not hold the tipc_node_lock while access the pseudo link/node like
> other paths such as tipc_bclink_recv_pkt  do?

When a message is sent over the broadcast link TIPC takes the bc_lock to do the job that taking tipc_node_lock() does for normal unicast links.

> Yours,
> jason

I should also point out that the code you are looking at was enhanced in TIPC 1.7.7 to allow TIPC to survive the situation in which a name distribution message can't be sent because of link congestion. This means that TIPC no longer attempts to reset the broadcast link if it can't send a name distribution message.

Regards,
Al