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