Hi Mathi, I looked in to the patch, change are considerable , it may take some time for reviewing and testing , so is it Ok to consider this patch as new ticket and can it be pushed after 5.0 tomorrow tagging ?
-AVM On 3/31/2016 11:47 AM, Anders Widell wrote: > If we decide to go for this change in OpenSAF 5.0 then I will push it > as part of ticket [#1613]. We still need to verify that it doesn't > cause any problems during an upgrade. > > regards, > Anders Widell > > On 03/31/2016 05:52 AM, A V Mahesh wrote: >> Hi Anders Widell, >> >> Is this patch will p[art of ticket #1613 or New ticket on top of >> #1613 ? >> >> -AVM >> >> On 3/30/2016 8:07 PM, Anders Widell wrote: >>> Hi! >>> >>> I have implemented the completely flat addressing in the attached >>> patch, but haven't tested if it causes any problems during an upgrade. >>> It should be applied on top of the patches for ticket [#1613]. Please >>> feel free to try it out! >>> >>> / Anders Widell >>> >>> On 03/29/2016 06:09 PM, Anders Widell wrote: >>>> I saw that it was also semi-hard-coded in /etc/opensaf/fmd.conf, but >>>> when looking a bit closer I notice that this configuration is not >>>> actually used by FM... :-) >>>> >>>> Ok, if we feel adventurous we could give it a try. The only known >>>> place >>>> where node_id has been hard-coded is SMF, which unfortunately is very >>>> much involved in upgrades. But the good thing is that thanks to ticket >>>> [#79], SMF will automatically discover the node_id of system >>>> controllers >>>> in OpenSAF 5.0. Thus, only pre-5.0 versions of SMF are problematic. It >>>> /might/ work, so let's try it! >>>> >>>> regards, >>>> Anders Widell >>>> >>>> On 03/29/2016 05:44 PM, Mathivanan Naickan Palanivelu wrote: >>>>> I guess we have deferred this (from moving to a direct mapping of >>>>> slot_id to the node_id) for a long time now. >>>>> I think SMF's dependency on fixed ids can (and must) be managed once >>>>> when we move to multiple standbys. >>>>> >>>>> Iam thinking where else we could get stuck during upgrade!? >>>>> >>>>> Mathi. >>>>> >>>>> >>>>> ----- [email protected] wrote: >>>>> >>>>>> It is "almost flat" in the proposed patches: the user only needs to >>>>>> configure slot_id on each node, in the range [1, 4095]. subslot_id >>>>>> should not be configured by the user. When using TIPC, the TIPC >>>>>> address >>>>>> of each node will be "1.1.slot_id". So the only non-flat thing is >>>>>> node_id, which is not configured by the user. We could have a direct >>>>>> mapping from slot_id to node_id (i.e. set node_id to the same >>>>>> value as >>>>>> >>>>>> slot_id), but I am worried about what will happen during an upgrade. >>>>>> Old >>>>>> nodes will translate e.g. slot_id 0x1 to node_id 0x2010f. New nodes >>>>>> will >>>>>> translate slot_id 0x1 to node_id 0x1. To make things worse, there >>>>>> are >>>>>> >>>>>> some places in OpenSAF that have been hard-coded to expect the two >>>>>> system controllers to have node_id 0x2010f and 0x2020f, >>>>>> respectively. >>>>>> >>>>>> Maybe we can make it work somehow, but I anticipate there could be >>>>>> problems during an upgrade. >>>>>> >>>>>> regards, >>>>>> Anders Widell >>>>>> >>>>>> On 03/29/2016 10:29 AM, Mathivanan Naickan Palanivelu wrote: >>>>>>> We should consider removing subslots entirely and go for a truly >>>>>> flat addressing scheme, if that is backward compatible. >>>>>>> There are other standard ways(PLM HE dependency) of provisioning >>>>>>> AMC >>>>>> subslots kind of hardware. >>>>>>> Mathi. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Anders Widell [mailto:[email protected]] >>>>>>>> Sent: Friday, March 18, 2016 9:38 PM >>>>>>>> To: Venkata Mahesh Alla >>>>>>>> Cc: [email protected] >>>>>>>> Subject: [devel] [PATCH 1 of 1] mds: Support up to 4095 nodes >>>>>> [#1613] >>>>>>>> osaf/libs/core/mds/include/mds_dt.h | 26 >>>>>> +++++++++++++++++--------- >>>>>>>> osaf/libs/core/mds/mds_c_db.c | 26 >>>>>> ++++++++++++-------------- >>>>>>>> 2 files changed, 29 insertions(+), 23 deletions(-) >>>>>>>> >>>>>>>> >>>>>>>> Support up to 4095 nodes in the flat addressing scheme for >>>>>>>> TIPC, by >>>>>> encoding >>>>>>>> the slot ID in the lower eight bits and the ones' complement of >>>>>>>> the >>>>>> subslot ID >>>>>>>> in bits 8 to 11 in the node identifier of the TIPC address. The >>>>>> reason for taking >>>>>>>> the ones' complement of the subslot ID is backwards compatibility >>>>>> with >>>>>>>> existing installations, so that this enhancement can be upgraded >>>>>> in-service. >>>>>>>> diff --git a/osaf/libs/core/mds/include/mds_dt.h >>>>>>>> b/osaf/libs/core/mds/include/mds_dt.h >>>>>>>> --- a/osaf/libs/core/mds/include/mds_dt.h >>>>>>>> +++ b/osaf/libs/core/mds/include/mds_dt.h >>>>>>>> @@ -237,7 +237,8 @@ bool mdtm_mailbox_mbx_cleanup(NCSCONTEXT >>>>>>>> >>>>>>>> /* >>>>>>>> * In the default flat addressing scheme, TIPC node addresses >>>>>> looks like >>>>>>>> - * 1.1.1, 1.1.2 etc. >>>>>>>> + * 1.1.1, 1.1.2 etc. The ones' complement of the subslot ID is >>>>>> shifted >>>>>>>> + 8 >>>>>>>> + * bits up and the slot ID is added in the 8 LSB. >>>>>>>> * In the non flat (old/legacy) addressing scheme TIPC >>>>>>>> addresses >>>>>> looks like >>>>>>>> * 1.1.31, 1.1.47. The slot ID is shifted 4 bits up and >>>>>>>> subslot >>>>>> ID is added >>>>>>>> * in the 4 LSB. >>>>>>>> @@ -248,13 +249,20 @@ bool mdtm_mailbox_mbx_cleanup(NCSCONTEXT >>>>>>>> >>>>>>>> #if (MDS_USE_SUBSLOT_ID == 0) >>>>>>>> #define MDS_TIPC_NODE_ID_MIN 0x01001001 >>>>>>>> -#define MDS_TIPC_NODE_ID_MAX 0x010010ff >>>>>>>> -#define MDS_NCS_NODE_ID_MIN (MDS_NCS_CHASSIS_ID|0x0000010f) >>>>>>>> -#define MDS_NCS_NODE_ID_MAX (MDS_NCS_CHASSIS_ID|0x0000ff0f) >>>>>>>> -#define m_MDS_GET_NCS_NODE_ID_FROM_TIPC_NODE_ID(node) \ >>>>>>>> - (NODE_ID)( MDS_NCS_CHASSIS_ID | (((node)&0xff)<<8) | >>>>>> (0xf)) >>>>>>>> -#define m_MDS_GET_TIPC_NODE_ID_FROM_NCS_NODE_ID(node) \ >>>>>>>> - (NODE_ID)( MDS_TIPC_COMMON_ID | (((node)&0xff00)>>8) ) >>>>>>>> +#define MDS_TIPC_NODE_ID_MAX 0x01001fff >>>>>>>> +static inline NODE_ID >>>>>>>> m_MDS_GET_NCS_NODE_ID_FROM_TIPC_NODE_ID(NODE_ID node) { >>>>>>>> + return MDS_NCS_CHASSIS_ID | ((node & 0xff) << 8) | >>>>>>>> (((node >>>>>> & >>>>>>>> +0xf00) >> 8) ^ 0xf); } static inline NODE_ID >>>>>>>> +m_MDS_GET_TIPC_NODE_ID_FROM_NCS_NODE_ID(NODE_ID node) { >>>>>>>> + return MDS_TIPC_COMMON_ID | ((node & 0xff00) >> 8) | >>>>>> (((node & >>>>>>>> +0xf) ^ 0xf) << 8); } static inline uint32_t >>>>>>>> +m_MDS_CHECK_TIPC_NODE_ID_RANGE(NODE_ID node) { >>>>>>>> + return node < MDS_TIPC_NODE_ID_MIN || node > >>>>>>>> MDS_TIPC_NODE_ID_MAX ? >>>>>>>> + NCSCC_RC_FAILURE : NCSCC_RC_SUCCESS; >>>>>>>> +} >>>>>>>> +static inline uint32_t m_MDS_CHECK_NCS_NODE_ID_RANGE(NODE_ID >>>>>>>> node) { >>>>>>>> + return >>>>>>>> +m_MDS_CHECK_TIPC_NODE_ID_RANGE(m_MDS_GET_TIPC_NODE_ID_FR >>>>>>>> OM_NCS_NODE_ID( >>>>>>>> +node)); >>>>>>>> +} >>>>>>>> #else >>>>>>>> #define MDS_TIPC_NODE_ID_MIN 0x01001001 >>>>>>>> #define MDS_TIPC_NODE_ID_MAX 0x0100110f >>>>>>>> @@ -264,10 +272,10 @@ bool mdtm_mailbox_mbx_cleanup(NCSCONTEXT >>>>>>>> (NODE_ID)( MDS_NCS_CHASSIS_ID | ((node)&0xf) | >>>>>>>> (((node)&0xff0)<<4)) #define >>>>>>>> m_MDS_GET_TIPC_NODE_ID_FROM_NCS_NODE_ID(node) \ >>>>>>>> (NODE_ID)( MDS_TIPC_COMMON_ID | >>>>>>>> (((node)&0xff00)>>4) | >>>>>>>> ((node)&0xf) ) -#endif >>>>>>>> >>>>>>>> #define m_MDS_CHECK_TIPC_NODE_ID_RANGE(node) >>>>>>>> (((((node)<MDS_TIPC_NODE_ID_MIN)||((node)>MDS_TIPC_NODE_ID_MA >>>>>>>> X))?NCSCC_RC_FAILURE:NCSCC_RC_SUCCESS)) >>>>>>>> #define m_MDS_CHECK_NCS_NODE_ID_RANGE(node) >>>>>>>> (((((node)<MDS_NCS_NODE_ID_MIN)||((node)>MDS_NCS_NODE_ID_MA >>>>>>>> X))?NCSCC_RC_FAILURE:NCSCC_RC_SUCCESS)) >>>>>>>> +#endif >>>>>>>> >>>>>>>> /* ******************************************** */ >>>>>>>> /* ******************************************** */ diff --git >>>>>>>> a/osaf/libs/core/mds/mds_c_db.c b/osaf/libs/core/mds/mds_c_db.c >>>>>>>> --- a/osaf/libs/core/mds/mds_c_db.c >>>>>>>> +++ b/osaf/libs/core/mds/mds_c_db.c >>>>>>>> @@ -37,14 +37,13 @@ void get_adest_details(MDS_DEST adest, c >>>>>>>> char *token, *saveptr; >>>>>>>> struct stat s; >>>>>>>> uint32_t process_id = 0; >>>>>>>> - NCS_PHY_SLOT_ID phy_slot; >>>>>>>> - NCS_SUB_SLOT_ID sub_slot; >>>>>>>> + SlotSubslotId slot_subslot_id; >>>>>>>> char pid_path[1024]; >>>>>>>> char *pid_name = NULL; >>>>>>>> char process_name[MDS_MAX_PROCESS_NAME_LEN]; >>>>>>>> bool remote = false; >>>>>>>> >>>>>>>> - >>>>>>>> m_NCS_GET_PHYINFO_FROM_NODE_ID(m_NCS_NODE_ID_FROM_ >>>>>>>> MDS_DEST(adest), NULL, &phy_slot, &sub_slot); >>>>>>>> + slot_subslot_id = >>>>>>>> +GetSlotSubslotIdFromNodeId(m_NCS_NODE_ID_FROM_MDS_DEST(adest) >>>>>>>> ); >>>>>>>> >>>>>>>> if (!tipc_mode_enabled) { >>>>>>>> process_id = >>>>>>>> m_MDS_GET_PROCESS_ID_FROM_ADEST(adest); >>>>>>>> @@ -111,11 +110,11 @@ void get_adest_details(MDS_DEST adest, c >>>>>>>> } >>>>>>>> >>>>>>>> if (remote == true) >>>>>>>> - snprintf(adest_details, MDS_MAX_PROCESS_NAME_LEN, >>>>>>>> "<rem_nodeid[%d]:%s>", >>>>>>>> - phy_slot, process_name); >>>>>>>> + snprintf(adest_details, MDS_MAX_PROCESS_NAME_LEN, >>>>>>>> "<rem_nodeid[%u]:%s>", >>>>>>>> + slot_subslot_id, process_name); >>>>>>>> else >>>>>>>> - snprintf(adest_details, MDS_MAX_PROCESS_NAME_LEN, >>>>>>>> "<nodeid[%d]:%s>", >>>>>>>> - phy_slot, process_name); >>>>>>>> + snprintf(adest_details, MDS_MAX_PROCESS_NAME_LEN, >>>>>>>> "<nodeid[%u]:%s>", >>>>>>>> + slot_subslot_id, process_name); >>>>>>>> >>>>>>>> m_MDS_LOG_DBG("MDS:DB: adest_details: %s ", >>>>>>>> adest_details); >>>>>>>> m_MDS_LEAVE(); >>>>>>>> @@ -129,8 +128,7 @@ void get_adest_details(MDS_DEST adest, c void >>>>>>>> get_subtn_adest_details(MDS_PWE_HDL pwe_hdl, MDS_SVC_ID svc_id, >>>>>>>> MDS_DEST adest, char* adest_details) { >>>>>>>> uint32_t process_id = 0; >>>>>>>> - NCS_PHY_SLOT_ID phy_slot; >>>>>>>> - NCS_SUB_SLOT_ID sub_slot; >>>>>>>> + SlotSubslotId slot_subslot_id; >>>>>>>> char process_name[MDS_MAX_PROCESS_NAME_LEN]; >>>>>>>> bool remote = false; >>>>>>>> MDS_SVC_INFO *svc_info = NULL; >>>>>>>> @@ -139,7 +137,7 @@ void get_subtn_adest_details(MDS_PWE_HDL >>>>>>>> char *pid_name = NULL; >>>>>>>> struct stat s; >>>>>>>> >>>>>>>> - >>>>>>>> m_NCS_GET_PHYINFO_FROM_NODE_ID(m_NCS_NODE_ID_FROM_ >>>>>>>> MDS_DEST(adest), NULL, &phy_slot, &sub_slot); >>>>>>>> + slot_subslot_id = >>>>>>>> +GetSlotSubslotIdFromNodeId(m_NCS_NODE_ID_FROM_MDS_DEST(adest) >>>>>>>> ); >>>>>>>> process_id = m_MDS_GET_PROCESS_ID_FROM_ADEST(adest); >>>>>>>> >>>>>>>> if (NCSCC_RC_SUCCESS == mds_mcm_check_intranode(adest)) { >>>>>>>> @@ -185,11 +183,11 @@ void get_subtn_adest_details(MDS_PWE_HDL >>>>>>>> } >>>>>>>> >>>>>>>> if (remote == true) >>>>>>>> - snprintf(adest_details, MDS_MAX_PROCESS_NAME_LEN, >>>>>>>> "<rem_node[%d]:%s>", >>>>>>>> - phy_slot, process_name); >>>>>>>> + snprintf(adest_details, MDS_MAX_PROCESS_NAME_LEN, >>>>>>>> "<rem_node[%u]:%s>", >>>>>>>> + slot_subslot_id, process_name); >>>>>>>> else >>>>>>>> - snprintf(adest_details, MDS_MAX_PROCESS_NAME_LEN, >>>>>>>> "<node[%d]:%s>", >>>>>>>> - phy_slot, process_name); >>>>>>>> + snprintf(adest_details, MDS_MAX_PROCESS_NAME_LEN, >>>>>>>> "<node[%u]:%s>", >>>>>>>> + slot_subslot_id, process_name); >>>>>>>> done: >>>>>>>> m_MDS_LOG_DBG("MDS:DB: adest_details: %s ", >>>>>>>> adest_details); >>>>>>>> m_MDS_LEAVE(); >>>>>>>> >>>>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>>>> Transform Data into Opportunity. >>>>>>>> Accelerate data analysis in your applications with Intel Data >>>>>> Analytics >>>>>>>> Acceleration Library. >>>>>>>> Click to learn more. >>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 >>>>>>>> _______________________________________________ >>>>>>>> Opensaf-devel mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> >>>> Transform Data into Opportunity. >>>> Accelerate data analysis in your applications with >>>> Intel Data Analytics Acceleration Library. >>>> Click to learn more. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 >>>> _______________________________________________ >>>> Opensaf-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> Transform Data into Opportunity. >>> Accelerate data analysis in your applications with >>> Intel Data Analytics Acceleration Library. >>> Click to learn more. >>> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 >>> >>> >>> _______________________________________________ >>> Opensaf-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >> ------------------------------------------------------------------------------ >> >> >> Transform Data into Opportunity. >> Accelerate data analysis in your applications with >> Intel Data Analytics Acceleration Library. >> Click to learn more. >> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 >> _______________________________________________ >> Opensaf-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >> > ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
