public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
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

  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