All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
Cc: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	linux-rdma <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: adding path record wire format to libibverbs
Date: Thu, 18 Mar 2010 12:20:15 -0600	[thread overview]
Message-ID: <20100318182015.GC29129@obsidianresearch.com> (raw)
In-Reply-To: <adar5nh7c6q.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>

On Thu, Mar 18, 2010 at 10:49:01AM -0700, Roland Dreier wrote:
> Including this structure is no problem in principle.
> 
>  > Could we use the bitfield versions of this I posted awhile back? :)
> 
> I don't have that patch handy, but bitfields often end up ugly with
> endian stuff, and also some compilers/architecture generate awful code
> for it.  What's the advantage over Sean's patch?

It is user space code, the interface should be trivially usable
without a huge hassle to the user. Bitfields can help provide
that. The LE/BE issue is easy to solve, but I admit the solution I
prefer (32 bit byte swap) might not fit very well with Sean's intended
use.

For instance if you want to override the hoplimit to 1:
 pr.flowlabel_hoplimit = htonl((ntohl(pr.flowlabel_hoplimit) & (~0xFF)) | 1);
vs
 swap32_all(&pr, sizeof(pr);
 pr.hopLimit = 1;
 swap32_all(&pr, sizeof(ptr));

For this application I don't think the codegen is a concern, and I've
seen that x86 and ppc generate acceptable code for this.. Certainly,
this approach is definately faster than the pack/unpack scheme I've
seen used in many place.

#ifdef BIG_ENDIAN
struct SAPathRecord {
    uint32_t rsv0;

    uint32_t rsv1;

    uint8_t DGID[16];

    uint8_t SGID[16];

    uint16_t DLID;
    uint16_t SLID;

    uint32_t rawTraffic:1;
    uint32_t rsv2:3;
    uint32_t flowLabel:20;
    uint32_t hopLimit:8;

    uint8_t TClass;
    uint8_t reversible:1;
    uint8_t numbPath:7;
    uint16_t PKey;

    uint16_t rsv3:12;
    uint16_t SL:4;
    uint8_t MTUSelector:2;
    uint8_t MTU:6;
    uint8_t rateSelector:2;
    uint8_t rate:6;

    uint8_t packetLifeTimeSelector:2;
    uint8_t packetLifeTime:6;
    uint8_t preference;
    uint16_t rsv4;

    uint32_t rsv5;
};
#else
// Must ntohl() every 32 bit word prior to appling this structure
struct SAPathRecord {
    uint32_t rsv0;

    uint32_t rsv1;

    uint8_t DGID[16];

    uint8_t SGID[16];

    uint16_t SLID;
    uint16_t DLID;

    uint32_t hopLimit:8;
    uint32_t flowLabel:20;
    uint32_t rsv2:3;
    uint32_t rawTraffic:1;

    uint16_t PKey;
    uint8_t numbPath:7;
    uint8_t reversible:1;
    uint8_t TClass;

    uint8_t rate:6;
    uint8_t rateSelector:2;
    uint8_t MTU:6;
    uint8_t MTUSelector:2;
    uint16_t SL:4;
    uint16_t rsv3:12;

    uint16_t rsv4;
    uint8_t preference;
    uint8_t packetLifeTime:6;
    uint8_t packetLifeTimeSelector:2;

    uint32_t rsv5;
};
#endif

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:[~2010-03-18 18:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-17 17:48 adding path record wire format to libibverbs Sean Hefty
     [not found] ` <77007DB2D13246B9A031DE3B0094C024-Zpru7NauK7drdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2010-03-18  6:08   ` Jason Gunthorpe
     [not found]     ` <20100318060812.GB28042-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2010-03-18 15:57       ` Sean Hefty
2010-03-18 17:49       ` Roland Dreier
     [not found]         ` <adar5nh7c6q.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-03-18 18:20           ` Jason Gunthorpe [this message]

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=20100318182015.GC29129@obsidianresearch.com \
    --to=jgunthorpe-epgobjl8dl3ta4ec/59zmfatqe2ktcn/@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org \
    --cc=sean.hefty-ral2JQCrhuEAvxtiuMwx3w@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.