OK, Here goes the solution. There is a 8 bit field in each message that is being exchanged between the services (which contains the message priority, mds prot_ver(mds protocol and mds version)) when message send is attempted. 6 bits are allocated for the mds prot_ver, present value for this field is 0xA8. This field can be used for versioning(and intended for this type of changes in MDS). This version can be dynamically learnt for a destination, when the first message is received from that destination and is stored in the Subscription result table. MDS prot_ver value will be changed in this release. So we can identify the old and new ones. If the destination is an old one, we will send with the old logic and if its a new one we will send with the bigger message.
There is other solution, but this includes quite code changes. For example, In each node bind a new type say X and in each process subscribe for this X. When we get up this means, it indicates a new node and messaging is with bigger size else the normal one. Only a single extra bind is done for a node. There is one more solution, but it breaks the inservice upgradabilty, where in which the vdest id range is decreased. Regards Surya On Wednesday 07 May 2014 08:44 AM, A V Mahesh wrote: > Surya, > > Thank for reiterating arch_word of the MDS feature ,we all in sync. > > On 5/6/2014 3:55 PM, SuryaNarayana Garlapati wrote: >>> MDS version unless we get alternate bits/variables used for MDS >>> version. >> [Surya] Thats the reason i am asking for some time. > > [AVM] If we get some alternate bits/variables used for MDS version > this will the best Option > and we can retain arch_word MDS feature. > > > On 5/6/2014 3:55 PM, SuryaNarayana Garlapati wrote: >>> >>> 6) This current patch Honors the default Opensaf configuration ` >>> mds_arch=0` behavior ( point 1 & 2 ) and it removed >>> hidden `same arc message optimization` feature related code >>> and used those 3bits/variable for the purpose of MDS version. >> [Surya] Current patch has still problems. I am repeating the same, >> but for your convenience, they are listed below. >> 1. Its taking out MDS optimization feature for the performance >> enhancement of the messaging. > > [AVM] we all in sync on this , now we are at the point whether we > should expose this or not to OpenSAF users? > >> 2. 64 bit and 32 bit combination will not work on the local node as >> it is doing flat encode which is wrong. > > [AVM] The current patch do ENC_TYPE_FULL for mixed 32/64 bit clients > on the same Node. > > -AVM > > > On 5/6/2014 3:55 PM, SuryaNarayana Garlapati wrote: >> Before going ahead, Following is the explanation for the arch_word of >> the MDS. >> >> Arch word(4bits) is combination of architecture and bit size of the >> machine. 3 bits are allocated >> for architecture and 1 bit is allocated for bit size. >> architecture of value 0 means unspecified. >> >> Message encoding is done as follows: >> 1. If the source and destination of the message is same process, then >> copy callback is called. >> 2. If source and destination arch_word are same, >> then encode flat is called. >> >> But there are some exceptions here, >> >> Say there are two nodes, A(Intel) and B(Powerpc) communicating with >> each other and are 64 bit each and >> opensaf code was compiled without giving any mds_arch input. In this >> case mds_arch is set to default 0. >> So as per the rule, encode flat callback should be called. But in >> this case if the flat encode is called, then >> the communication between A and B will not work as one is little >> endian and other is big endian. >> For handling this type of situations where the mds_arch is >> unspecified, mds checks for the mds_arch >> and if it is set to 0, MDS will call the encode full such that the >> communication will work between the nodes >> as the message is fully encoded. >> >> Encode flat will also be called if the source and destination are on >> the same node and arch_word is same. >> >> 3. If source and destination arch_word are different, then encode >> full is called. In this case the source and destination >> can be on the same or different node. >> >> On Tuesday 06 May 2014 09:05 AM, A V Mahesh wrote: >>> Hi All, >>> >>> I re-verified the behavior of OpenSAF >>> MDS_ENC_TYPE_FULL/MDS_ENC_TYPE_FLAT messaging >>> and its optimization , following is my observation and option: >>> >>> 1) In the default OpenSAF configuration (` mds_arch=0` ) , >>> messaging across the node is ENC_TYPE_FULL and >>> messaging with-in the node is ENC_TYPE_FLAT . >> [Surya] See the explanation in point 2 and point 3. >>> >>> 2) Even though Opensaf is configured with default `mds_arch=0`, if >>> their is difference of 32--bit application communicating to >>> 64-bit middle-ware >>> ( mixed 32/64 bit clients on the same Node), messaging >>> with-in the node is also ENC_TYPE_FULL. >> [Surya] See the explanation in point 3. >>> >>> 3) when OpenSAF is configured with `mds_arch=1... to 7` messaging >>> across & with-in the node is ENC_TYPE_FLAT , >>> hear we have advantage of message optimization , only when >>> explicitly enabling this configuration . >> [Surya] See the exception explanation in point 2. MDS was always >> designed to have this optimization a long time. It was just the >> build system was not using it. >>> >>> 4) Unfortunate the same arc message optimization feature got >>> broken in few services such as RDE & PLM >>> doesn't support ENC_TYPE_FLAT , we need fix these issue along >>> with in-service upgrade to make it work properly . >> [Surya] Optimization feature is triggered by MDS. RDE & PLM are >> missing the implementation for this callbacks. >>> >>> 5) One more important note is that the `same arc message >>> optimization` feature was not exposed to OpenSAF user till now. >> [Surya] It was always present in the confiure. Its just that, it was >> not used any time and default option was choosed for the mds_arch. >>> >>> 6) This current patch Honors the default Opensaf configuration ` >>> mds_arch=0` behavior ( point 1 & 2 ) and it removed >>> hidden `same arc message optimization` feature related code >>> and used those 3bits/variable for the purpose of MDS version. >> [Surya] Current patch has still problems. I am repeating the same, >> but for your convenience, they are listed below. >> 1. Its taking out MDS optimization feature for the performance >> enhancement of the messaging. >> 2. 64 bit and 32 bit combination will not work on the local node as >> it is doing flat encode which is wrong. >>> >>> >>> So I agree with Hans and let us not regressed for Un exposed feature , >> [Surya] Feature is present, the only thing is it was not used. >>> and we will use the ARCHTYPE 3 bits for >>> MDS version unless we get alternate bits/variables used for MDS >>> version. >> [Surya] Thats the reason i am asking for some time. >>> I also NOT much in favor of little bit expensive >>> `new Node install & subscribe its Mds version` (My previously >>> published approach) >>> >>> So following are current options : >>> >>> - Use ARCHTYPE 3 bits for MDS version and discard un exposed >>> feature ( `mds_arch` config option) >>> >>> - Find out alter native bits for MDS version fix all the >>> ENC_TYPE_FLAT issue with in-service upgrade >>> and expose `same arc message optimization` feature to OpenSAF >>> users. >>> >>> - Use `new Node install & subscribe` option for Mds version (My >>> previously published approach) and fix >>> all the ENC_TYPE_FLAT issue with in-service upgrade and expose >>> `same arc message optimization` >>> feature to OpenSAF users. >>> >>> >>> -AVM >>> >>> On 5/1/2014 2:45 PM, SuryaNarayana Garlapati wrote: >>>> >>>> On Thursday 01 May 2014 02:30 PM, Hans Feldt wrote: >>>>> Let's be clear that MDS a pure internal opensaf service since >>>>> quite a long time. There are no "applications" to consider at all. >>>>> This means the only thing to care about is in-service performance >>>>> and making sure characteristics are improved, not regressed. >>>> [Surya] I am saying in the context of internal messaging between >>>> the services which use MDS. Yes, thats what even i am trying to. >>>>> >>>>> I am not sure we have to maintain some legacy requirement of mixed >>>>> 32/64 bit clients on the same system. I don't see why we should. >>>> [Surya] This is not limited to even 32/64 bit. Its how the encoding >>>> is handled for the destinations. >>>>> >>>>> Thanks, >>>>> Hans >>>>> >>>>>> -----Original Message----- >>>>>> From: SuryaNarayana Garlapati >>>>>> [mailto:suryanarayana.garlap...@oracle.com] >>>>>> Sent: den 1 maj 2014 10:54 >>>>>> To: A V Mahesh >>>>>> Cc: opensaf-devel@lists.sourceforge.net >>>>>> Subject: Re: [devel] [PATCH 3 of 4] mds: use TIPC >>>>>> segmentation/reassembly [#654] >>>>>> >>>>>> >>>>>> On Thursday 01 May 2014 01:04 PM, A V Mahesh wrote: >>>>>>> On 5/1/2014 10:16 AM, SuryaNarayana Garlapati wrote: >>>>>>>> The archtype is not a legacy one, it was introduced to have the >>>>>>>> optimization for the message encoding by the applications. >>>>>>> Passing compile flags `mds_arch=1` `mds_arch=2` (mds_arch, [The >>>>>>> arch-type input to MDS - valid values 1-7]) , is not a standard >>>>>>> Open-Source ( enterprise things for legacy product ) option for >>>>>>> compilations. >>>>>> [Surya] Wrong, if you see any standard linux configure options >>>>>> for any >>>>>> linux application code distributions, they do provide the options >>>>>> for >>>>>> supporting the options to provide such powerpc, intel, 32/64bit >>>>>> etc. So >>>>>> similar is the configure options for opensaf as well. For example >>>>>> you >>>>>> can see the configure options for the net-snmp as well. >>>>>>> Open source user not need to Understand/get-Educate about this >>>>>>> internal options , >>>>>> [Surya] This is not a internal option, configure option which is >>>>>> exposed >>>>>> to user as well. >>>>>>> we are ok loose advantage of flat encode optimization , >>>>>>> from now we want to send full_encode to different node. >>>>>> [Surya] This is not only done for optimization, this internally >>>>>> effects >>>>>> the message performance between the opensaf services which do huge >>>>>> messaging. >>>>>> I am on way of thinking the solution for this. Lets wait. >>>>>>> >>>>>>> We are also raising enhancement ticket for code clean. >>>>>>> >>>>>>> -AVM >>>>>>> >>>>>>> >>>>>>> On 5/1/2014 10:16 AM, SuryaNarayana Garlapati wrote: >>>>>>>> On Thursday 01 May 2014 09:56 AM, A V Mahesh wrote: >>>>>>>>> Hi Surya, >>>>>>>>> >>>>>>>>> On 5/1/2014 7:28 AM, Suryanarayana Garlapati wrote: >>>>>>>>>> Nack. >>>>>>>>>> MDS ARCHWORD is used for deciding the factor whether the message >>>>>>>>>> which is being sent to the destination should be encoded >>>>>>>>>> full/flat/copied. This >>>>>>>>>> bits were introduced to do a optimization in the way the >>>>>>>>>> callbacks >>>>>>>>>> encode full/flat are called. For example, if there are two >>>>>>>>>> processes(can be present in the same node or different node) and >>>>>>>>>> there architecture and bit size is same, so in this case, the >>>>>>>>>> encode flat can be called (or simply a flat copy of the >>>>>>>>>> message can >>>>>>>>>> be done in the UB). If these bits were not used, earlier the >>>>>>>>>> messages was being full encoded when the messages were sent to >>>>>>>>>> another node. At the same time, the arch field is given in the >>>>>>>>>> configure such that this can be used for different architectures >>>>>>>>>> such as the powerpc, etc. >>>>>>>>> [AVM] >>>>>>>>> “ARCHTYPE” is getting only used while cross-compiling, >>>>>>>>> and to >>>>>>>>> distinguish architecture flavors: x86, >>>>>>>>> PowerPC, m68k ,ect . >>>>>>>>> In the code "arch_word" is used while encoding whether to do >>>>>>>>> MDS_ENC_TYPE_FLAT/MDS_ENC_TYPE_FULL. >>>>>>>>> >>>>>>>>> Keeping “ARCHTYPE” doesn't have any significance in >>>>>>>>> current >>>>>>>>> Open-sourced Opnesaf code , >>>>>>>> [Surya] This is provided to accommodate different architectures >>>>>>>> and >>>>>>>> is a build option which optimizes the applications way of message >>>>>>>> encoding(full/flat) and corresponding decode(full/flat). >>>>>>>> So that means, you want to remove this support and introduce >>>>>>>> the over >>>>>>>> head again. One more thing, with the new changes if you have two >>>>>>>> nodes one with powerpc and intel, both will not be able to >>>>>>>> communicate >>>>>>>> each other as both will result in flat encode/flat decode(as the >>>>>>>> value is one with the latest changes). >>>>>>>>> why because In the current MDS messaging we do full encoded when >>>>>>>>> the messages were sent to another process/node, irrelevant of >>>>>>>>> “ARCHTYPE” >>>>>>>> [Surya] Wrong, the decision is done always on the archword only. >>>>>>>>> I already verified cross 32/64 middle-ware & application >>>>>>>>> combination , all the fowls are working fine . >>>>>>>> [Surya] As you said this might work, but you are loosing the >>>>>>>> optimization and would always result in full encode/full decode of >>>>>>>> application messages which is an overhead. >>>>>>>>>> I am thinking of a solution for this and will get back to you. >>>>>>>>> [AVM] we already have an alternative option of new node do >>>>>>>>> install >>>>>>>>> & subscribe its Node Mds version, to handle in-service Upgrade , >>>>>>>>> but we used legacy “ARCHTYPE” 3 bits for Mds version >>>>>>>>> which is optimized solution then install & subscribe. >>>>>>>> [Surya] Thats what we had discussed before as well. The >>>>>>>> archtype is >>>>>>>> not a legacy one, it was introduced to have the optimization >>>>>>>> for the >>>>>>>> message encoding by the applications. >>>>>>>>> -AVM >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Surya >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: osafde...@gmail.com >>>>>>>>>> To: mahesh.va...@oracle.com >>>>>>>>>> Cc: opensaf-devel@lists.sourceforge.net >>>>>>>>>> Sent: Tuesday, April 29, 2014 10:58:53 AM GMT +05:30 Chennai, >>>>>>>>>> Kolkata, Mumbai, New Delhi >>>>>>>>>> Subject: [devel] [PATCH 3 of 4] mds: use TIPC >>>>>>>>>> segmentation/reassembly [#654] >>>>>>>>>> >>>>>>>>>> configure.ac | 21 >>>>>>>>>> --------------------- >>>>>>>>>> osaf/libs/core/mds/Makefile.am | 1 - >>>>>>>>>> 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 | 11 ++++++++++- >>>>>>>>>> osaf/libs/core/mds/mds_log.c | 4 ++-- >>>>>>>>>> 6 files changed, 25 insertions(+), 43 deletions(-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> diff --git a/configure.ac b/configure.ac >>>>>>>>>> --- a/configure.ac >>>>>>>>>> +++ b/configure.ac >>>>>>>>>> @@ -470,27 +470,6 @@ if test "$enable_java" = no; then >>>>>>>>>> fi >>>>>>>>>> ############################################# >>>>>>>>>> -# MDS ARCH TYPE: MDS advises message encode/decode >>>>>>>>>> -# optimization to its clients if the sender and receiver >>>>>>>>>> -# are of "compatible-type". For this optimization to work, >>>>>>>>>> -# the sender's platform and receiver's platform should be >>>>>>>>>> -# similar (for e.g. both PowerPC) and use an libncs_core built >>>>>>>>>> -# with the same value for "mds_arch". An "mds_arch" value of 0 >>>>>>>>>> -# is the default value and stands for a platform which is NOT >>>>>>>>>> -# compatible with any platform. >>>>>>>>>> -############################################# >>>>>>>>>> - >>>>>>>>>> -AC_ARG_VAR([mds_arch], [The arch-type input to MDS - valid >>>>>>>>>> values >>>>>>>>>> 1-7]) >>>>>>>>>> - >>>>>>>>>> -if test "$mds_arch" = ""; then >>>>>>>>>> - mdsarchtype=0 >>>>>>>>>> -else >>>>>>>>>> - mdsarchtype=$mds_arch >>>>>>>>>> -fi >>>>>>>>>> - >>>>>>>>>> -AC_SUBST([MDS_WORD_ARCH_FLAGS], [" >>>>>>>>>> -DMDS_ARCH_TYPE=$mdsarchtype"]) >>>>>>>>>> - >>>>>>>>>> -############################################# >>>>>>>>>> # Checks for libraries. >>>>>>>>>> ############################################# >>>>>>>>>> PKG_CHECK_MODULES([XML2], [libxml-2.0]) >>>>>>>>>> diff --git a/osaf/libs/core/mds/Makefile.am >>>>>>>>>> b/osaf/libs/core/mds/Makefile.am >>>>>>>>>> --- a/osaf/libs/core/mds/Makefile.am >>>>>>>>>> +++ b/osaf/libs/core/mds/Makefile.am >>>>>>>>>> @@ -23,7 +23,6 @@ SUBDIRS = include >>>>>>>>>> noinst_LTLIBRARIES = libmds.la >>>>>>>>>> libmds_la_CPPFLAGS = \ >>>>>>>>>> - @MDS_WORD_ARCH_FLAGS@ \ >>>>>>>>>> $(AM_CPPFLAGS) >>>>>>>>>> libmds_la_LDFLAGS = -static >>>>>>>>>> diff --git a/osaf/libs/core/mds/include/mds_dt2c.h >>>>>>>>>> b/osaf/libs/core/mds/include/mds_dt2c.h >>>>>>>>>> --- a/osaf/libs/core/mds/include/mds_dt2c.h >>>>>>>>>> +++ b/osaf/libs/core/mds/include/mds_dt2c.h >>>>>>>>>> @@ -33,17 +33,16 @@ >>>>>>>>>> typedef uint8_t MDS_SVC_ARCHWORD_TYPE; /*MDS app-svc arch >>>>>>>>>> and word_size combination */ >>>>>>>>>> -/* MDS_WORD_SIZE_TYPE and MDS_ARCH_TYPE are compile-time >>>>>>>>>> macros */ >>>>>>>>>> - >>>>>>>>>> -#ifndef MDS_ARCH_TYPE >>>>>>>>>> -#define MDS_ARCH_TYPE 0 /* Stands for unspecified >>>>>>>>>> architecture type */ >>>>>>>>>> -#elif (MDS_ARCH_TYPE > 7) >>>>>>>>>> -#error MDS_ARCH_TYPE should be in the range 0 to 7. >>>>>>>>>> -#endif >>>>>>>>>> - >>>>>>>>>> #define MDS_WORD_SIZE_TYPE ((sizeof(long)/4) - 1) /* 0 for >>>>>>>>>> 32-bit, 1 for 64-bit */ >>>>>>>>>> -#define MDS_SELF_ARCHWORD ((MDS_SVC_ARCHWORD_TYPE) >>>>>>>>>> ((MDS_WORD_SIZE_TYPE<<3) | MDS_ARCH_TYPE)) >>>>>>>>>> +/* >>>>>>>>>> + * 4 bit ARCHWORD usage: >>>>>>>>>> + * Bit 3 is wordsize >>>>>>>>>> + * Bit 2:0 is a version field indicating capabilities. >>>>>>>>>> + * Version 0 uses 1400 bytes fragmentation. >>>>>>>>>> + * Version 1 uses TIPC max msg (66000 bytes) fragmentation. >>>>>>>>>> + */ >>>>>>>>>> +#define MDS_SELF_ARCHWORD ((MDS_SVC_ARCHWORD_TYPE) >>>>>>>>>> ((MDS_WORD_SIZE_TYPE<<3) | 1)) >>>>>>>>>> typedef enum { >>>>>>>>>> MDS_VIEW_NORMAL, >>>>>>>>>> diff --git a/osaf/libs/core/mds/mds_c_sndrcv.c >>>>>>>>>> b/osaf/libs/core/mds/mds_c_sndrcv.c >>>>>>>>>> --- a/osaf/libs/core/mds/mds_c_sndrcv.c >>>>>>>>>> +++ b/osaf/libs/core/mds/mds_c_sndrcv.c >>>>>>>>>> @@ -1483,10 +1483,10 @@ static uint32_t mcm_msg_encode_full_or_f >>>>>>>>>> msg_send.dest_pwe_id = >>>>>>>>>> m_MDS_GET_PWE_ID_FROM_SVC_HDL(svc_cb->svc_hdl); >>>>>>>>>> msg_send.dest_vdest_id = dest_vdest_id; >>>>>>>>>> msg_send.src_svc_sub_part_ver = svc_cb->svc_sub_part_ver; >>>>>>>>>> + msg_send.msg_arch_word = to_msg->rem_svc_arch_word; >>>>>>>>>> if (msg_send.msg.encoding == MDS_ENC_TYPE_FULL) { >>>>>>>>>> if (NULL == bcast_ptr) { >>>>>>>>>> - msg_send.msg_fmt_ver = >>>>>>>>>> cbinfo.info.enc.o_msg_fmt_ver; /* archword will be filled in >>>>>>>>>> next label */ >>>>>>>>>> - msg_send.msg_arch_word = to_msg->rem_svc_arch_word; >>>>>>>>>> + msg_send.msg_fmt_ver = >>>>>>>>>> cbinfo.info.enc.o_msg_fmt_ver; >>>>>>>>>> } >>>>>>>>>> } else { >>>>>>>>>> if (NULL == bcast_ptr) { >>>>>>>>>> @@ -6502,14 +6502,10 @@ static uint32_t mcm_query_for_node_dest_ >>>>>>>>>> if (m_MDS_GET_ADEST == adest) { >>>>>>>>>> *to = DESTINATION_SAME_PROCESS; >>>>>>>>>> } else if (MDS_SELF_ARCHWORD == arch_word) { >>>>>>>>>> - if ((0 == (MDS_SELF_ARCHWORD & 0x7) && (0 == >>>>>>>>>> (arch_word & >>>>>>>>>> 0x7)))) { >>>>>>>>>> - if >>>>>>>>>> (m_MDS_GET_NODE_ID_FROM_ADEST(m_MDS_GET_ADEST) == >>>>>>>>>> m_MDS_GET_NODE_ID_FROM_ADEST(adest)) { >>>>>>>>>> - *to = DESTINATION_ON_NODE; /* This hash define >>>>>>>>>> may give a wrong impression, but actually it means to do >>>>>>>>>> flat_enc */ >>>>>>>>>> - } else { >>>>>>>>>> - *to = DESTINATION_OFF_NODE; >>>>>>>>>> - } >>>>>>>>>> + if (m_MDS_GET_NODE_ID_FROM_ADEST(m_MDS_GET_ADEST) == >>>>>>>>>> m_MDS_GET_NODE_ID_FROM_ADEST(adest)) { >>>>>>>>>> + *to = DESTINATION_ON_NODE; /* This hash >>>>>>>>>> define may >>>>>>>>>> give a wrong impression, but actually it means to do flat_enc */ >>>>>>>>>> } else { >>>>>>>>>> - *to = DESTINATION_ON_NODE; >>>>>>>>>> + *to = DESTINATION_OFF_NODE; >>>>>>>>>> } >>>>>>>>>> } else { >>>>>>>>>> *to = DESTINATION_OFF_NODE; >>>>>>>>>> diff --git a/osaf/libs/core/mds/mds_dt_tipc.c >>>>>>>>>> b/osaf/libs/core/mds/mds_dt_tipc.c >>>>>>>>>> --- a/osaf/libs/core/mds/mds_dt_tipc.c >>>>>>>>>> +++ b/osaf/libs/core/mds/mds_dt_tipc.c >>>>>>>>>> @@ -2035,7 +2035,16 @@ uint32_t mds_mdtm_send_tipc(MDTM_SEND_RE >>>>>>>>>> m_MDS_LOG_INFO("MDTM: User Sending Data >>>>>>>>>> lenght=%d >>>>>>>>>> Fr_svc=%d to_svc=%d\n", len, >>>>>>>>>> req->src_svc_id, req->dest_svc_id); >>>>>>>>>> - int frag_size = MDTM_NORMAL_MSG_FRAG_SIZE; >>>>>>>>>> + // determine fragment limit using a bit in >>>>>>>>>> destination archword >>>>>>>>>> + int frag_size; >>>>>>>>>> + int version = req->msg_arch_word & 0x7; >>>>>>>>>> + if (version > 0) { >>>>>>>>>> + // normal mode, use TIPC fragmentation >>>>>>>>>> + frag_size = TIPC_MAX_USER_MSG_SIZE; >>>>>>>>>> + } else { >>>>>>>>>> + // old mode, completely skip TIPC >>>>>>>>>> fragmentation >>>>>>>>>> + frag_size = MDTM_NORMAL_MSG_FRAG_SIZE; >>>>>>>>>> + } >>>>>>>>>> if (len > frag_size) { >>>>>>>>>> /* Packet needs to be fragmented and >>>>>>>>>> send */ >>>>>>>>>> diff --git a/osaf/libs/core/mds/mds_log.c >>>>>>>>>> b/osaf/libs/core/mds/mds_log.c >>>>>>>>>> --- a/osaf/libs/core/mds/mds_log.c >>>>>>>>>> +++ b/osaf/libs/core/mds/mds_log.c >>>>>>>>>> @@ -64,8 +64,8 @@ uint32_t mds_log_init(char *log_file_nam >>>>>>>>>> if ((fh = fopen(lf, "a+")) != NULL) { >>>>>>>>>> fclose(fh); >>>>>>>>>> - log_mds_notify("BEGIN MDS LOGGING| >>>>>>>>>> PID=%d|ARCH=%d|64bit=%ld\n", >>>>>>>>>> - process_id, MDS_ARCH_TYPE, >>>>>>>>>> (long)MDS_WORD_SIZE_TYPE); >>>>>>>>>> + log_mds_notify("BEGIN MDS LOGGING| >>>>>>>>>> PID=%d|ARCHW=%x|64bit=%ld\n", >>>>>>>>>> + process_id, MDS_SELF_ARCHWORD, >>>>>>>>>> (long)MDS_WORD_SIZE_TYPE); >>>>>>>>>> } >>>>>>>>>> return NCSCC_RC_SUCCESS; >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> "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 >>>>>>>>>> Opensaf-devel@lists.sourceforge.net >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> "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 >>>>>> Opensaf-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>> >>> >> > ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
