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. >>>> >>>> >>>> ----- anders.wid...@ericsson.com 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:anders.wid...@ericsson.com] >>>>>>> Sent: Friday, March 18, 2016 9:38 PM >>>>>>> To: Venkata Mahesh Alla >>>>>>> Cc: opensaf-devel@lists.sourceforge.net >>>>>>> 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 >>>>>>> Opensaf-devel@lists.sourceforge.net >>>>>>> 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 >>> Opensaf-devel@lists.sourceforge.net >>> 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 >> Opensaf-devel@lists.sourceforge.net >> 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 > Opensaf-devel@lists.sourceforge.net > 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 Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
