public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Alex Netes <alexne-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Cc: linux-rdma <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH/opensm] Fix SANodeRecord.nodeInfo.localPortNum
Date: Wed, 9 Mar 2011 10:11:26 -0700	[thread overview]
Message-ID: <20110309171126.GB15419@obsidianresearch.com> (raw)
In-Reply-To: <20110309154744.GV5577-iQai9MGU/dyyaiaB+Ve85laTQe2KTcn/@public.gmane.org>

On Wed, Mar 09, 2011 at 05:47:44PM +0200, Alex Netes wrote:
> Hi Jason,
> 
> On 17:29 Tue 01 Mar     , Jason Gunthorpe wrote:
> > This value must match the portGUID, so it needs to vary on a per port
> > basis like portGUID and not simply reflect the value opensm acquired
> > during the sweep.
> > 
> > Prior to this patch opensm returns the same value for localPortNum for
> > all ports on a HCA, now it returns the correct localPortNum for the
> > portGUID.
> > 
> > Also fixes query matching in the same way
> > 
 
> Spec defines the SA NodeRecord.LocalPortNum field as the number of the link
> port which received this SMP (14.2.5.3). This definition doesn't make any
> sense when it comes to SA.

I think the spec is pretty sound on this point. The SA is expected to
return SA queries for SMP records that match what is present in the
fabric if the requestor did the SMP query itself. The constraints IBA
places on a NodeInfo SMP query are such that localPortNum and
portGUID must *always* match. You cannot enter on port 1 and query the
NodeInfo for port 2 for a CA.

So the current SA behavior of returning garbage for localPortNum
is essentially returning a NodeInfo that can never be returned by a
raw SMP query, which is clearly not aligned with the intent of the spec.

I mispoke a bit in the commit message, opensm returns the localPortNum
it acquired during the sweep *for a random port*, eg it collects and
stores the NodeInfo for the first port it sees, then stores portGUID
and localPortNum seperately. When it generates the SA reply it
corretly replaces the port GUID but uses the random old
localPortNum. This is clearly incorrect.

> I understand your motivation for the patch and the fact that current
> LocalPortNum query matching in the SM doesn't sound right. So maybe
> IBA spec fine tuning is needed, before applying the patch, so this
> field won't be open to free interpretations.

I don't think there is really any free interpretation here. For
everything but a switch localPortNum must always reflect the port that
portGUID is associated with. This is is what is defined to happen when
the NodeRecord SMP is generated by the SMA, the SA must do the same.

This causes real problems, without an accurate localPortNumber it is
impossible to associate the portGUID with a port number when doing SA
queries

Jason
--
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:[~2011-03-09 17:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-02  0:29 [PATCH/opensm] Fix SANodeRecord.nodeInfo.localPortNum Jason Gunthorpe
     [not found] ` <20110302002941.GA22729-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2011-03-09 15:47   ` Alex Netes
     [not found]     ` <20110309154744.GV5577-iQai9MGU/dyyaiaB+Ve85laTQe2KTcn/@public.gmane.org>
2011-03-09 17:11       ` Jason Gunthorpe [this message]
     [not found]         ` <20110309171126.GB15419-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2011-03-09 18:26           ` Hal Rosenstock
     [not found]             ` <AANLkTimu0RxDbbjiRsni4gdmanvp_eaWA=xFoH9P8qZP-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-03-09 18:34               ` Jason Gunthorpe
     [not found]                 ` <20110309183441.GB25229-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2011-03-09 18:38                   ` Hal Rosenstock
     [not found]                     ` <AANLkTikjrO_Uga2v4H6fWBXOuUNw=scka3rjRyRuOyHV-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-03-09 18:40                       ` Jason Gunthorpe
     [not found]                         ` <20110309184022.GC25229-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2011-03-09 18:47                           ` Hal Rosenstock
     [not found]                             ` <AANLkTim_4=d-PnyoMVdJ1z4Emu+QafwQPqp+wLJi=AMB-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-03-09 18:51                               ` Jason Gunthorpe
     [not found]                                 ` <20110309185118.GD25229-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2011-03-09 19:00                                   ` Hal Rosenstock
     [not found]                                     ` <AANLkTimfEYU4+U_-QpvwAxYK-bLDfFiO6WJcshe-vF5h-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-03-09 19:07                                       ` Jason Gunthorpe
2011-03-11  9:35           ` Alex Netes
     [not found]             ` <20110311093552.GW5577-iQai9MGU/dyyaiaB+Ve85laTQe2KTcn/@public.gmane.org>
2011-03-11 18:47               ` Jason Gunthorpe
2011-03-13 15:59   ` Alex Netes

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=20110309171126.GB15419@obsidianresearch.com \
    --to=jgunthorpe-epgobjl8dl3ta4ec/59zmfatqe2ktcn/@public.gmane.org \
    --cc=alexne-VPRAkNaXOzVWk0Htik3J/w@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