Thread: [SSI-devel] ICS message inline data space utilization
Brought to you by:
brucewalker,
rogertsang
From: Smith, S. <sta...@in...> - 2006-08-03 18:12:59
|
Can someone help me understand why ICS message inline data space is not utilized more? During a remote node boot sequence, of the 12943 ICS messages sent to the boot node, counted in ics_llsendmsg() over all channels, the inline data size ranged from a min(4) to a max(164) with the average being 9 bytes? The max inline is set @ 300 bytes? Why would the RPC generator favor OOL data? Seems like OOL message data processing overhead (encode & decode) might be reduced? Thanks, Stan. |
From: John B. <joh...@hp...> - 2006-08-03 19:19:37
|
"Think of it as evolution in action." -- _Oath of Fealty_ by Larry Niven and Jerry Pournelle If you are talking about the nsc_rcall() XDR RPCs, they were a legacy from an earlier transport before ICS and all calls using it were supposed to be rewritten and never were. It would probably be worthwhile to to modify the OOL marshalling routines to make a decision to code inline if space permitted. It gets a little tricky if there is more than 1 OOL parameter involved since icsgen has no notion of how much overhead is required for an OOL parameter at the moment. Dumping all the XDR code on the floor would be a good thing too. It's Just Work. John Well, if you are talking about the nsc_rcall() interface Smith, Stan wrote: > Can someone help me understand why ICS message inline data space is not > utilized more? > > During a remote node boot sequence, of the 12943 ICS messages sent to > the boot node, counted in ics_llsendmsg() over all channels, the inline > data size ranged from a min(4) to a max(164) with the average being 9 > bytes? The max inline is set @ 300 bytes? > > Why would the RPC generator favor OOL data? > > Seems like OOL message data processing overhead (encode & decode) might > be reduced? > > Thanks, > > Stan. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > |
From: Aneesh K. <ane...@gm...> - 2006-08-13 10:23:22
|
On 8/4/06, John Byrne <joh...@hp...> wrote: > > "Think of it as evolution in action." -- _Oath of Fealty_ by Larry Niven > and Jerry Pournelle > > If you are talking about the nsc_rcall() XDR RPCs, they were a legacy > from an earlier transport before ICS and all calls using it were > supposed to be rewritten and never were. This is the plan with the new rewrite/cleanup i am doing at git.openssi.org/~kvaneesh. I have ICS more or less clean. Only one Hack of using some of the sock structure member variable. Right now working on token code, but this is happening really slowly than i expected due to my day job pressure. John if you would like me send those changes again to you let me know > > It would probably be worthwhile to to modify the OOL marshalling > routines to make a decision to code inline if space permitted. It gets a > little tricky if there is more than 1 OOL parameter involved since > icsgen has no notion of how much overhead is required for an OOL > parameter at the moment. > > Dumping all the XDR code on the floor would be a good thing too. > This is what the current icsgen does with the cleanup Stan, An explanation of OOL by john can be found at http://git.openssi.org/~kvaneesh/gitweb.cgi?p=ci-to-linus.git;a=commitdiff;h=e138f79b48b760f89f0051abbdb739113db53130 -aneesh |