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

Reply via email to