From: Sasha Khapyorsky <sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org>
To: Hal Rosenstock <hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-rdma <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] opensm/osm_trap_rcv.c: In trap_rcv_process_request, no need to sweep on trap 145 and certain trap 144s
Date: Sun, 1 Nov 2009 17:49:29 +0200 [thread overview]
Message-ID: <20091101154929.GC29434@me> (raw)
In-Reply-To: <f0e08f230910300823j56edb800nf88efca23165bf5-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11:23 Fri 30 Oct , Hal Rosenstock wrote:
> >
> > In general: function trap_rcv_process_request() already has 400 lines of
> > code and adding there more lines without simplifying flows makes me
> > nervous.
>
> Are you going to block this change until such restructure ?
I would prefer to improve it at least in a part where patch adds even
more flows. Also there are many issues yet without restructuring.
>
> >> - /* Check for node description update. IB Spec v1.2.1 pg 823 */
> >> - if (ib_notice_is_generic(p_ntci) &&
> >> - cl_ntoh16(p_ntci->g_or_v.generic.trap_num) == 144 &&
> >> - p_ntci->data_details.ntc_144.local_changes & TRAP_144_MASK_OTHER_LOCAL_CHANGES &&
> >> - p_ntci->data_details.ntc_144.change_flgs & TRAP_144_MASK_NODE_DESCRIPTION_CHANGE) {
> >> - OSM_LOG(sm->p_log, OSM_LOG_INFO, "Trap 144 Node description update\n");
> >> -
> >> - if (p_physp) {
> >> - CL_PLOCK_ACQUIRE(sm->p_lock);
> >> - osm_req_get_node_desc(sm, p_physp);
> >> - CL_PLOCK_RELEASE(sm->p_lock);
> >> - } else
> >> - OSM_LOG(sm->p_log, OSM_LOG_ERROR,
> >> - "ERR 3812: No physical port found for "
> >> - "trap 144: \"node description update\"\n");
> >> - }
> >> + if (ib_notice_is_generic(p_ntci)) {
> >> + /* Check for node description update. IB Spec v1.2.1 pg 823 */
> >> + if (cl_ntoh16(p_ntci->g_or_v.generic.trap_num) == 144) {
> >> + /* update port's capability mask (in PortInfo) */
> >> + p_physp->port_info.capability_mask = p_ntci->data_details.ntc_144.new_cap_mask;
> >
> > Hmm, could this introduce some issues?
>
> Like what ?
Like ignoring isSM bit and maybe some other "problematic" bits which
required SM DB update.
>
> >> + if (p_ntci->data_details.ntc_144.local_changes & TRAP_144_MASK_OTHER_LOCAL_CHANGES) {
> >> + if (p_ntci->data_details.ntc_144.change_flgs & TRAP_144_MASK_NODE_DESCRIPTION_CHANGE) {
> >
> > if ((p_ntci->data_details.ntc_144.local_changes &
> > TRAP_144_MASK_OTHER_LOCAL_CHANGES) &&
> > (p_ntci->data_details.ntc_144.change_flgs &
> > TRAP_144_MASK_NODE_DESCRIPTION_CHANGE)) {
> >
> >> + OSM_LOG(sm->p_log, OSM_LOG_INFO,
> >> + "Trap 144 Node description update\n");
> >> +
> >> + if (p_physp) {
> >> + CL_PLOCK_ACQUIRE(sm->p_lock);
> >> + osm_req_get_node_desc(sm, p_physp);
> >> + CL_PLOCK_RELEASE(sm->p_lock);
> >> + } else
> >> + OSM_LOG(sm->p_log, OSM_LOG_ERROR,
> >> + "ERR 3812: No physical port found for "
> >> + "trap 144: \"node description update\"\n");
> >> + }
> >> + }
> >> + if (p_ntci->data_details.ntc_144.change_flgs & TRAP_144_MASK_LINK_WIDTH_ENABLE_CHANGE ||
> >> + p_ntci->data_details.ntc_144.change_flgs & TRAP_144_MASK_LINK_SPEED_ENABLE_CHANGE ||
> >> + p_ntci->data_details.ntc_144.change_flgs & TRAP_144_MASK_SM_PRIORITY_CHANGE)
> >
> > if ((p_ntci->data_details.ntc_144.change_flgs &
> > (TRAP_144_MASK_LINK_WIDTH_ENABLE_CHANGE |
> > TRAP_144_MASK_LINK_SPEED_ENABLE_CHANGE |
> > TRAP_144_MASK_SM_PRIORITY_CHANGE)))
> >
> >
> >> + is_trap144_sweep = TRUE;
> >> + }
> >>
> >> - /* do a sweep if we received a trap */
> >> - if (sm->p_subn->opt.sweep_on_trap) {
> >> - /* if this is trap number 128 or run_heavy_sweep is TRUE -
> >> - update the force_heavy_sweep flag of the subnet.
> >> - Sweep also on traps 144/145 - these traps signal a change of
> >> - certain port capabilities/system image guid.
> >> - TODO: In the future this can be changed to just getting
> >> - PortInfo on this port instead of sweeping the entire subnet. */
> >> - if (ib_notice_is_generic(p_ntci) &&
> >> - (cl_ntoh16(p_ntci->g_or_v.generic.trap_num) == 128 ||
> >> - cl_ntoh16(p_ntci->g_or_v.generic.trap_num) == 144 ||
> >> - cl_ntoh16(p_ntci->g_or_v.generic.trap_num) == 145 ||
> >> - run_heavy_sweep)) {
> >> - OSM_LOG(sm->p_log, OSM_LOG_VERBOSE,
> >> - "Forcing heavy sweep. Received trap:%u\n",
> >> - cl_ntoh16(p_ntci->g_or_v.generic.trap_num));
> >> + if (cl_ntoh16(p_ntci->g_or_v.generic.trap_num) == 145) {
> >> + /* update system image guid (in NodeInfo) */
> >> + p_node = osm_physp_get_node_ptr(p_physp);
> >> + if (p_node)
> >
> > When 'p_node' could be NULL?
>
> It's just a possible return from osm_physp_get_node_ptr and wanted to
> be sure this was not the case before setting node_info. Should this be
> eliminated ?
If p_physp->p_node cannot be NULL legally, then the check should be
eliminated in order to not hide an errors and to not eat cpu cycles.
>
> >> + p_node->node_info.node_guid = p_ntci->data_details.ntc_145.new_sys_guid;
> >
> > Didn't you mean 'node_info.sys_guid' and 'node_info.node_guid'?
>
> Just sys_guid.
Sorry typo, I tried to ask: shouldn't be:
p_node->node_info.sys_guid = p_ntci->data_details.ntc_145.new_sys_guid;
, instead?
>
> >> + }
> >> +
> >> + /* do a sweep if we received a trap */
> >> + if (sm->p_subn->opt.sweep_on_trap) {
> >> + /* if this is trap number 128 or run_heavy_sweep is
> >> + TRUE - update the force_heavy_sweep flag of the
> >> + subnet. Also, sweep on certain types of trap 144.
> >> + TODO: In the future this can be changed to just
> >> + getting PortInfo on this port instead of sweeping
> >> + the entire subnet. */
> >> + if (cl_ntoh16(p_ntci->g_or_v.generic.trap_num) == 128 ||
> >> + is_trap144_sweep || run_heavy_sweep) {
> >
> > It looks that prevents sweeping on PortInfo:CapMask change which
> > is effectively breaks at least SM handover - new SM will be undetected.
>
> Yes, CapMask change should be included along with the other local
> changes to cause sweep.
So this should change the patch.
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-11-01 15:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090805222737.GA8523@comcast.net>
[not found] ` <20090805222737.GA8523-Wuw85uim5zDR7s880joybQ@public.gmane.org>
2009-10-30 1:57 ` [PATCH] opensm/osm_trap_rcv.c: In trap_rcv_process_request, no need to sweep on trap 145 and certain trap 144s Sasha Khapyorsky
2009-10-30 15:23 ` Hal Rosenstock
[not found] ` <f0e08f230910300823j56edb800nf88efca23165bf5-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-11-01 15:49 ` Sasha Khapyorsky [this message]
2009-11-02 15:27 ` Hal Rosenstock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091101154929.GC29434@me \
--to=sashak-smomgflxvozwk0htik3j/w@public.gmane.org \
--cc=hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox