[OpenAFS] replication over slower bandwidth

muayad y muayad_y@yahoo.com
Sat, 11 Feb 2012 16:02:30 -0800 (PST)


--944242502-1388717478-1329004950=:38268
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

when maxPacketSize has been uncommented, it did change=A0 rx_connection str=
uct behavoir,=A0 rx_connection is being called on vos (userspace code)
Or I am not reading the header correctly?=20
struct rx_connection {
=A0=A0=A0 struct rx_connection *next; /*=A0 on hash chain _or_ free list */
=A0=A0=A0 struct rx_peer *peer;
#endif
#ifdef=A0 RX_ENABLE_LOCKS
=A0=A0=A0 afs_kmutex_t conn_call_lock;=A0=A0=A0=A0=A0=A0=A0 /* locks conn_c=
all_cv */
=A0=A0=A0 afs_kcondvar_t conn_call_cv;
=A0=A0=A0 afs_kmutex_t conn_data_lock;=A0=A0=A0=A0=A0=A0=A0 /* locks packet=
 data */
#endif
=A0=A0=A0 afs_uint32 epoch;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Process start =
time of client side of connection */
=A0=A0=A0 afs_uint32 cid;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Connection=
 id (call channel is bottom bits) */
=A0=A0=A0 afs_int32 error;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* If this conn=
ection is in error, this is it */
#ifdef KDUMP_RX_LOCK
=A0=A0=A0 struct rx_call_rx_lock *call[RX_MAXCALLS];
#else
=A0=A0=A0 struct rx_call *call[RX_MAXCALLS];
#endif
=A0=A0=A0 afs_uint32 callNumber[RX_MAXCALLS]; /* Current call numbers */
=A0=A0=A0 afs_uint32 serial;=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Next outgoing pa=
cket serial number */
=A0=A0=A0 afs_uint32 lastSerial;=A0=A0=A0=A0=A0 /* # of last packet receive=
d, for computing skew */
=A0=A0=A0 afs_int32 maxSerial;=A0=A0=A0=A0=A0=A0=A0 /* largest serial numbe=
r seen on incoming packets */
=A0=A0=A0 afs_int32 maxPacketSize;=A0=A0 /* max packet size should be per-c=
onnection since */
=A0=A0 .........................
=A0=A0 ............................................


--- On Sat, 2/11/12, Simon Wilkinson <simonxwilkinson@gmail.com> wrote:

From: Simon Wilkinson <simonxwilkinson@gmail.com>
Subject: Re: [OpenAFS] replication over slower bandwidth
To: muayad_y@yahoo.com
Cc: "Neil Davies" <semanticphilosopher@gmail.com>, "OpenAFS Info" <openafs-=
info@openafs.org>, "Jeffrey Altman" <jaltman@your-file-system.com>
Received: Saturday, February 11, 2012, 12:27 PM


On 10 Feb 2012, at 04:29, Jeffrey Altman wrote:

> That field was commented out before OpenAFS and maxPacketSize was not
> referenced anywhere in the source code.=A0 What restoring that field to
> rx.h does is force the struct rxevent * values that follow it to become
> properly aligned in 64-bit builds.
>=20
> Lack of proper alignment can really hurt.

I'm a little confused here. The System V ABI, which Linux claims to follow,=
 specifies that pointers are 8 byte aligned - see Figure 3.1 of http://www.=
x86-64.org/documentation/abi.pdf

Given that your speed improvements are from vos release, this must be users=
pace code, so I'm not certain that this is an alignment issue.

Cheers,

Simon.

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

--944242502-1388717478-1329004950=:38268
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;">when maxPacketSize has been uncommented, it d=
id change&nbsp; rx_connection struct behavoir,&nbsp; rx_connection is being=
 called on vos (userspace code)<br>Or I am not reading the header correctly=
? <br>struct rx_connection {<br>&nbsp;&nbsp;&nbsp; struct rx_connection *ne=
xt; /*&nbsp; on hash chain _or_ free list */<br>&nbsp;&nbsp;&nbsp; struct r=
x_peer *peer;<br>#endif<br>#ifdef&nbsp; RX_ENABLE_LOCKS<br>&nbsp;&nbsp;&nbs=
p; afs_kmutex_t conn_call_lock;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /=
* locks conn_call_cv */<br>&nbsp;&nbsp;&nbsp; afs_kcondvar_t conn_call_cv;<=
br>&nbsp;&nbsp;&nbsp; afs_kmutex_t conn_data_lock;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; /* locks packet data */<br>#endif<br>&nbsp;&nbsp;&nbsp; a=
fs_uint32 epoch;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; /* Process start time of client side of connection */<br>&nbsp;&nbsp;&nbs=
p;
 afs_uint32 cid;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; /* Connection id (call channel is bottom bits) */<br>&nbsp;&n=
bsp;&nbsp; afs_int32 error;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; /* If this connection is in error, this is it */<br>#ifd=
ef KDUMP_RX_LOCK<br>&nbsp;&nbsp;&nbsp; struct rx_call_rx_lock *call[RX_MAXC=
ALLS];<br>#else<br>&nbsp;&nbsp;&nbsp; struct rx_call *call[RX_MAXCALLS];<br=
>#endif<br>&nbsp;&nbsp;&nbsp; afs_uint32 callNumber[RX_MAXCALLS]; /* Curren=
t call numbers */<br>&nbsp;&nbsp;&nbsp; afs_uint32 serial;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* Next outgoing packet serial number=
 */<br>&nbsp;&nbsp;&nbsp; afs_uint32 lastSerial;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; /* # of last packet received, for computing skew */<br>&nbsp;&nbsp;&nbs=
p; afs_int32 maxSerial;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* larges=
t serial number seen on incoming packets */<br>&nbsp;&nbsp;&nbsp;
 afs_int32 maxPacketSize;&nbsp;&nbsp; /* max packet size should be per-conn=
ection since */<br>&nbsp;&nbsp; .........................<br>&nbsp;&nbsp; .=
...........................................<br><br><br>--- On <b>Sat, 2/11/=
12, Simon Wilkinson <i>&lt;simonxwilkinson@gmail.com&gt;</i></b> wrote:<br>=
<blockquote style=3D"border-left: 2px solid rgb(16, 16, 255); margin-left: =
5px; padding-left: 5px;"><br>From: Simon Wilkinson &lt;simonxwilkinson@gmai=
l.com&gt;<br>Subject: Re: [OpenAFS] replication over slower bandwidth<br>To=
: muayad_y@yahoo.com<br>Cc: "Neil Davies" &lt;semanticphilosopher@gmail.com=
&gt;, "OpenAFS Info" &lt;openafs-info@openafs.org&gt;, "Jeffrey Altman" &lt=
;jaltman@your-file-system.com&gt;<br>Received: Saturday, February 11, 2012,=
 12:27 PM<br><br><div class=3D"plainMail"><br>On 10 Feb 2012, at 04:29, Jef=
frey Altman wrote:<br><br>&gt; That field was commented out before OpenAFS =
and maxPacketSize was not<br>&gt; referenced anywhere in the source
 code.&nbsp; What restoring that field to<br>&gt; rx.h does is force the st=
ruct rxevent * values that follow it to become<br>&gt; properly aligned in =
64-bit builds.<br>&gt; <br>&gt; Lack of proper alignment can really hurt.<b=
r><br>I'm a little confused here. The System V ABI, which Linux claims to f=
ollow, specifies that pointers are 8 byte aligned - see Figure 3.1 of <a hr=
ef=3D"http://www.x86-64.org/documentation/abi.pdf" target=3D"_blank">http:/=
/www.x86-64.org/documentation/abi.pdf</a><br><br>Given that your speed impr=
ovements are from vos release, this must be userspace code, so I'm not cert=
ain that this is an alignment issue.<br><br>Cheers,<br><br>Simon.<br><br>__=
_____________________________________________<br>OpenAFS-info mailing list<=
br><a ymailto=3D"mailto:OpenAFS-info@openafs.org" href=3D"/mc/compose?to=3D=
OpenAFS-info@openafs.org">OpenAFS-info@openafs.org</a><br><a href=3D"https:=
//lists.openafs.org/mailman/listinfo/openafs-info"
 target=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-info<=
/a><br></div></blockquote></td></tr></table>
--944242502-1388717478-1329004950=:38268--