Re: [tipc-discussion] Some TIPC thoughts.....

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

[copied to TIPC discussion list, since this topic may be of general
interest]
 
Hi John:
 
It was never intended that the configuration strings used during TIPC
initialization be capable of supporting all of the commands provided at
run-time using tipcConfig, since a number of them don't make sense in
that context.  The "lp", "lt", and "lw" orginally fell into the "don't
make sense" category because there was no way to change the settings of
links that did not yet exist.  With the introduction of the newer
flavors of these commands that allow defaults to be set on a per-bearer
or per-media type basis this situation has changed to a degree, but
(until now) there was no requirement to enhance the TIPC initialization
code so nothing was done along these lines.
 
I apologize for my earlier (mis)statement which indicated that this sort
of thing could currently be done in TIPC ... I forgot that only the
bearer domain and priority could be set this way, but not the tolerance
and window size.
 
One difficulty in adding support for the initialization-time setting of
bearer tolerance and window size is deciding exactly how it should be
done.  It probably would not be too difficult to add support for
"lt=eth/10000" (or perhaps even "lt=10000" to set the default value for
all media types), but something like "lt=eth:fei0/10000" would be more
difficult to do as it would depend on a prior "be=eth:fei0" command ...
and once the "be" command was executed it is possible that a link might
be created before the "lt=eth:..." command was processed.
 
An alternative would be to allow tolerance and window size to be
specified as part of the "be" command.  This avoids the race condition
mentioned in the previous paragraph (albeit at the cost of making the
command a bit lengthy), but might be an architecturally cleaner
solution.  The change could be implemented to both the
initialization-time and run-time versions of the "be" command to
maintain the existing consistency between them.
 
You can certainly generate a TSR to capture this issue.  I suspect that
it will be classed as an enhancement request rather than a defect.
 
Regards,
Al



________________________________

	From: Lyscars, John [mailto:jly...@en...] 
	Sent: Tuesday, April 21, 2009 4:26 PM
	To: Stephens, Allan
	Subject: RE: Some TIPC thoughts.....
	
	

	Hi Allan,

	 

	It's been quite some time, and I have been having some

	success merging up to the VxWorks 6.7, with a few bumps

	along the road.

	 

	With regards to TIPC, I think I have found a snag related to 

	this discussion on configuring a link tolerance value, where 

	you said ; 

	 

	once they had decided on the values they wanted to use,

	 this info could be hard-coded into their TIPC configuration
strings 

	(or routine).  I'm not sure what more you really need.

	 

	So along with the merge, I configured our link tolerance value

	using a string lt=eth/10000;  Now TIPC failed to init, so I
began

	debugging, and think I have found the culprit.

	 

	In the routine, tipc_info_parse() found int tipc_core.c,

	the static struct tokenInfo does not appear to have a

	case for the keyword "lt=" so a failure is returned from

	tipc_ifno_parse().  I appear to have the latest code, so wanted

	to ask if this is an oversight, and do you want me to generate

	a TSR for this?

	 

	Thanks,

	 

	John Lyscars, x41343

	jly...@en...

	 

	From: Stephens, Allan [mailto:all...@wi...] 
	Sent: Wednesday, February 04, 2009 5:44 PM
	To: Lyscars, John
	Subject: RE: Some TIPC thoughts.....

	 

	Hi John:

	 

	TIPC allows you to change the default link tolerance by means of
tipcConfig's "-lt" option.  For example, "-lt=eth/100" sets the default
link tolerance for Ethernet links to 100 ms.  You can also change the
link tolerance for existing links in a similar manner  -- for example,
using "-lt=?eth/100".  The idea was to give users the freedom to
manually adjust these values from the shell during system tuning; once
they had decided on the values they wanted to use, this info could be
hard-coded into their TIPC configuration strings (or routine).  I'm not
sure what more you really need.

	 

	TIPC also allows you to change the connection timeout used by a
socket using the TIPC_CONN_TIMEOUT socket option.  Unfortunately, there
is no way to change the system default value, so you have to explicitly
change the timeout used by each socket after you create it.  To date,
most users have either been content to use the default supplied by TIPC,
or they have known in advance what timeout value they need to have in
their systems and have coded their applications to call setsockopt()
accordingly.  Again, though, the approach is to provide the flexibility
to allow users to experiment with different settings without having to
recompile TIPC, after which the desired values are "nailed in" to the
user's applications.

	 

	Regards,

	Al

		 

		
________________________________


		From: Lyscars, John [mailto:jly...@en...] 
		Sent: Wednesday, February 04, 2009 4:37 PM
		To: Stephens, Allan
		Subject: Some TIPC thoughts.....

		Hi Al,

		 

		During TIPC system integration, I have found a need to
raise and lower

		values controlling TIPC socket timeouts as well as TIPC
link timeouts.  Currently

		these two values are adjusted within the following
files:

		 

		TIPC_DEF_LINK_TOL in target/h/tipc/tipc_config.h

		CONN_TIMEOUT_DEFAULT in target/src/tipc/tipc_socket.c

		 

		Now ideally, I would love to see these types of
parameters dynamically

		retrievable, so that I could adjust them within my
device dependent

		firmware (what Wind River calls a board support
package), for example:

		 

		extern unsigned int getTipcDefLinkTol(void);

		extern unsigned int getTipcSockConnDefTimeout(void);

		 

		but with their usage currently within TIPC data
structures, I can

		see how this might not be realistic with the use of
constants.  Just 

		some food for thought as how a real customer is using
this stuff, and

		what problems I have to overcome with the current
program structure.

		 

		Regards,

		 

		John Lyscars, x41343

		jly...@en...