Hi Hans , *ACK from me for your published patch , please go-ahead and push the patch as it is.*
I discussion/syncdup with Surya, following are the summary points : By *default *MDS does FULL encode/decode between different nodes (inter-node communication), also the behavior is same when the MDS messaging happens between 32-bit and 64-bit processes. your published Patch: #654 is not impacting any of these default functionality**. Even though MDS is providing a compile time flag called "mds_arch", when this flag is set explicitly to the same value on different nodes, then only MDS messaging across nodes will happen with FLAT encode/decode routines, but most of the OpenSAF services (mds application) are still doing FULL encode/decode even when the MDS is triggered FLAT encode/decode callbacks ( Middle ware applications are not using advantage of "mds_arch" ). Till now none of the OpenSAF user are using the 'mds_arch' field and all are going with the MDS default settings. So they are NO impacts of deprecating "mds_arch" and considering that for versions. -AVM On 5/7/2014 12:20 PM, SuryaNarayana Garlapati wrote: > 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 >>>>> >>>> >>> >> > ------------------------------------------------------------------------------ "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
