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.
Open source user not need to Understand/get-Educate about this
internal options , we are ok loose advantage of flat encode optimization ,
from now we want to send full_encode to different node.
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
