[cgl_discussion] Re: TIPC

Jon Maloy jon.maloy at ericsson.com
Thu Feb 13 12:01:49 PST 2003


I should have done 'reply all"

/Jon

Jon Maloy wrote:

> See below.
>
> /Jon
>
> Rod Van Meter wrote:
>
>> Mika wants us to make this a priority in PoC, and I can get on board
>> with that, I think.  It should be a good "proof of concept" for the
>> "Proof of Concept" subgroup.
>>
>> This is from half an hour of looking at it, so there are likely things
>> I'm wrong about...
>>
>> Comments on TIPC:
>>
>> First off, this looks like very useful functionality.  I'm happy to
>> see it.  And it comes with documentation, too!
>>
> ;-)
>
>>
>> General:
>>
>> * There are test programs near the back of the 60-page document, but I
>>  don't see those in the source code kit anywhere.  Are they
>>  available?
>>
> They were more "demo" programs to show how the interface is used.
> I have them somewhere, but it will take me a little time to gather them
> from wherever they are. Why don't you just do copy-paste from
> the document?
>
>>
>> * I don't see a "TODO" list -- what do YOU think needs help?
>>
> There is a short one in the README-file. But the perhaps most urgent
> thing is missing: making the socket interface more appetizing for
> conservatives, i.e. making it possible to use connect(), shutdown() etc
> in the more traditional way, while exchanging SYN/ACK/FIN in a
> TCP-like manner.( I really hate this way of setting up connections, but
> being a pragmatic I realize that this option must be added. The
> current way of doing things can be preserved by use of fcntl())
>
> Another important issue is to get rid of the buffer copying
> in tipc_sk_send(), since this results in an extra buffer copying
> when messaged are longer than MTU. It probably is very easy to fix, we
> call tipc_sendMsg() instead of tipc_sendBuf()) and release/re-grab
> the lock at each copy_from_user. We just did not have time to
> test this before the release.
>
> It would also be interesting to see what can still be done with general
> performance. I suspect that all the macro expansions and other
> code result in unecessary amounts of code and bad cache hit in
> the critical data phase path of the code.
>
>>
>> * Is there a ChangeLog?  How do you intend to do revision management
>>  -- CVS?  (I see a short comment in the README, but we probably need
>>  more.)
>>
> Not yet, except what is in the README file.
>
>>
>> Specifics things to work on:
>>
>> * Code janitoring: there are still a fair number of warnings during
>>  compile, at least on my RH 8.0 system.  I'm looking into them.
>>
> Fine.
>
>>
>> * There seem to be a lot of numeric constants sprinkled throughout the
>>  code (65408, 65404, 65000, 17777777, 17, 117, 999640, etc.  Where do
>>  these come from?  Should they be replaced with #defs?
>>
> In general I am cautious with both #defines and typedefs: as long as they
> are used within only a very limited scope, like in the masks of
> the msg_xx() functions, I think it will just make the code less readable
> to use #defines.
>
> With most of the examples you mention above you are probably right,
> It could be useful with an explanatory #define, and in the case of 65408
> there is already one. (It was the old value for amx message length,
> now changed to 66000). I still use this limitation when sending
> certain messages for preserving protocol compatibility.
>
>>
>> * This could be made to run over UDP/IPv6 as well as UDP/IPv4 (in
>>  ./TipcLinuxModAdaptation_SCC/src/udp_adaptation.c).
>>
> Sure. I would suggest a completely new 'bearer type ' however, like
> "udpv6" in a separate file, since the address format is so different.
>
>>
>> * Possibly, a port to 2.5, if it doesn't run there yet?
>>
> It is not done, so I would be very happy.
>
>>
>>         --Rod
>>
>>  
>>
>




More information about the cgl_discussion mailing list