Summary: MDS improvements Review request for Trac Ticket(s): 654 Peer Reviewer(s): Mahesh Pull request to: <<LIST THE PERSON WITH PUSH ACCESS HERE>> Affected branch(es): default Development branch: default
-------------------------------- Impacted area Impact y/n -------------------------------- Docs n Build system n RPM/packaging n Configuration files n Startup scripts n SAF services n OpenSAF services n Core libraries y Samples n Tests n Other n Comments (indicate scope for each "y" above): --------------------------------------------- MDs improvements for utilising TIPC's fragmentation/reassembly to achieve both better performace and reliability of MDS messaging. Especially the IMM & CKPT service will benefit from this. changeset b95551f0fbacb21fe2e0be01e24d6060a4f94bcf Author: Hans Feldt <[email protected]> Date: Mon, 28 Apr 2014 23:12:41 +0200 mds: use TIPC defined max msg size for rec buffer [#654] Using connection-less TIPC messaging the largest message that can be sent and received is 66000 defined by the constant TIPC_MAX_USER_MSG_SIZE defined in tipc.h The patch change the MDS TIPC code to use the TIPC constant instead of defining in its own lower limit (for no reason). No functional change. Just preparation for other changes. changeset f1ba21d5dbf69cdbff4788d815ce67ed86d1738a Author: Hans Feldt <[email protected]> Date: Mon, 28 Apr 2014 23:12:42 +0200 mds: support variable size fragmentation limit [#654] No functional change. Just preparation for other changes. changeset d14ef0c650ebadd564d6d40f1714f8f361cb5bec Author: Hans Feldt <[email protected]> Date: Thu, 12 Dec 2013 15:55:44 +0100 mds: use TIPC segmentation/reassembly [#654] TIPC supports sending message with a maximum length of 66000 bytes. MDS supports sending even bigger messages, upto ~46Mb. MDS has used an internal fragmentation of just 1400 bytes (MDTM_NORMAL_MSG_FRAG_SIZE) despite that the receive buffer is 8000 bytes (MDS_DIRECT_BUF_MAXSIZE) This patch changes MDS to use TIPC segmentation/reassembly. This gives benefits such as secure transmission (TIPC does retransmission). TIPC send congestion is reduced since TIPC counts messages not bytes. Less processing done in user space in the sending opensaf or client process. Since the receive buffer of older MDS cores is limited to 8000 bytes we have be sure not to send larger messages than that to older cores. Otherwise we have problems with in-service upgradeability. Each MDS TIPC port is bound to a functional address - a port name. The port name consists of 32 bit type and 32 bit instance. The 4 msb of the instance word contains the so called "archword" field. The msb indicates if this MDS core is 32 or 64 bit. The remaining 3 bits is now used as a version field. Version 0 is used by older versions of MDS, version 1 is now used to indicate the capability for longer fragmentation. This information is part of the published port name thus a subscriber will get them using the TIPC discovery service. These bits are ignored by old MDS cores, so it can receive messages from a new MDS core. When sending a message this bit is used to understand if the peer uses TIPC segmentation/reassembly (or not) and adapt the limit accordingly. The possibility to set mds_arch using configure has been removed. The change is in-service compliant and can be upgraded into a system. changeset 7cc70b5ed138b05084c5bce11d61d80136d96e0b Author: Hans Feldt <[email protected]> Date: Tue, 29 Apr 2014 07:08:42 +0200 mds: adjust some constants [#654] Adjust some MDS related constants. MDS_DIRECT_BUF_MAXSIZE defines the max size sending an unencoded message. This is changed to reflect the new fragmentation limit. MDTM_NORMAL_MSG_FRAG_SIZE defines the fragmentation limit supported by old MDS cores. Since the receive buffer was 8000 bytes, we change it to that. PAYLOAD_BUF_SIZE is a core constant that defines buffer size of each usrbuf. By increasing this value to 8000, less processing overhead for chaining buffers is needed. In the normal case all messages will fit into one usrbuf. Complete diffstat: ------------------ configure.ac | 21 --------------------- osaf/libs/core/include/mds_papi.h | 7 +++++-- osaf/libs/core/include/ncsusrbuf.h | 2 +- osaf/libs/core/mds/Makefile.am | 1 - osaf/libs/core/mds/include/mds_dt.h | 5 +---- osaf/libs/core/mds/include/mds_dt2c.h | 17 ++++++++--------- osaf/libs/core/mds/mds_c_sndrcv.c | 14 +++++--------- osaf/libs/core/mds/mds_dt_tipc.c | 41 ++++++++++++++++++++++++++--------------- osaf/libs/core/mds/mds_log.c | 4 ++-- 9 files changed, 48 insertions(+), 64 deletions(-) Testing Commands: ----------------- Test that and old MDS core can be used to sync a new one and vice versa. Testing, Expected Results: -------------------------- All tests should work Conditions of Submission: ------------------------- Ack from Mahesh Arch Built Started Linux distro ------------------------------------------- mips n n mips64 n n x86 n n x86_64 y y powerpc n n powerpc64 n n Reviewer Checklist: ------------------- [Submitters: make sure that your review doesn't trigger any checkmarks!] Your checkin has not passed review because (see checked entries): ___ Your RR template is generally incomplete; it has too many blank entries that need proper data filled in. ___ You have failed to nominate the proper persons for review and push. ___ Your patches do not have proper short+long header ___ You have grammar/spelling in your header that is unacceptable. ___ You have exceeded a sensible line length in your headers/comments/text. ___ You have failed to put in a proper Trac Ticket # into your commits. ___ You have incorrectly put/left internal data in your comments/files (i.e. internal bug tracking tool IDs, product names etc) ___ You have not given any evidence of testing beyond basic build tests. Demonstrate some level of runtime or other sanity testing. ___ You have ^M present in some of your files. These have to be removed. ___ You have needlessly changed whitespace or added whitespace crimes like trailing spaces, or spaces before tabs. ___ You have mixed real technical changes with whitespace and other cosmetic code cleanup changes. These have to be separate commits. ___ You need to refactor your submission into logical chunks; there is too much content into a single commit. ___ You have extraneous garbage in your review (merge commits etc) ___ You have giant attachments which should never have been sent; Instead you should place your content in a public tree to be pulled. ___ You have too many commits attached to an e-mail; resend as threaded commits, or place in a public tree for a pull. ___ You have resent this content multiple times without a clear indication of what has changed between each re-send. ___ You have failed to adequately and individually address all of the comments and change requests that were proposed in the initial review. ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc) ___ Your computer have a badly configured date and time; confusing the the threaded patch review. ___ Your changes affect IPC mechanism, and you don't present any results for in-service upgradability test. ___ Your changes affect user manual and documentation, your patch series do not contain the patch that updates the Doxygen manual. ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
