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
