From: jason <huz...@gm...> - 2011-03-25 15:36:16
|
Hi Allan, Thanks for the information! 2011/3/23 Stephens, Allan <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 > > -- Yours, jason |