[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <88B766C272F2C64B944B21AD078333151C964A670B@EXMAIL.ad.emulex.com>
Date: Thu, 22 Mar 2012 14:10:35 -0700
From: <Parav.Pandit@...lex.Com>
To: <jgunthorpe@...idianresearch.com>
CC: <David.Laight@...LAB.COM>, <roland@...estorage.com>,
<linux-rdma@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: RE: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA adapter
> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgunthorpe@...idianresearch.com]
> Sent: Friday, March 23, 2012 2:28 AM
> To: Pandit, Parav
> Cc: David.Laight@...LAB.COM; roland@...estorage.com; linux-
> rdma@...r.kernel.org; netdev@...r.kernel.org
> Subject: Re: [PATCH 2/9] ocrdma: Driver for Emulex OneConnect RDMA
> adapter
>
> On Thu, Mar 22, 2012 at 01:52:30PM -0700, Parav.Pandit@...lex.Com
> wrote:
>
> > > This can be used to force 32bit alignment in amd64 code in order to
> > > match definitions in 32bit userspace.
> > > For new things it would make sense to force 64bit alignment of 64bit
> > > fields for 32bit code.
> >
> > o.k. so I'll use aligned attribute to align user-kernel interface data
> > structure to 8 byte boundary. That should work for 32-bit and 64-bit
> > user and kernel space and does't hurt performance either?
>
> If the structure is only for user/kernel interfacing then it is much better to
> add explicit padding fields to naturally place 64 bit quantities on an 8 byte
> alignment than to mess with gcc specific attributes (user space has a much
> wide choice of compilers).
>
> This was David's second suggestion. Better to do this now before the driver is
> accepted :)
>
o.k. I'll align them to naturally 8 byte boundary.
> Jason
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists