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.
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. 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
