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