[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 rx_connection struct behavoir, rx_connection is being=
called on vos (userspace code)<br>Or I am not reading the header correctly=
? <br>struct rx_connection {<br> struct rx_connection *ne=
xt; /* on hash chain _or_ free list */<br> struct r=
x_peer *peer;<br>#endif<br>#ifdef RX_ENABLE_LOCKS<br> &nbs=
p; afs_kmutex_t conn_call_lock; /=
* locks conn_call_cv */<br> afs_kcondvar_t conn_call_cv;<=
br> afs_kmutex_t conn_data_lock; &=
nbsp; /* locks packet data */<br>#endif<br> a=
fs_uint32 epoch;  =
; /* Process start time of client side of connection */<br> &nbs=
p;
afs_uint32 cid;  =
; /* Connection id (call channel is bottom bits) */<br> &n=
bsp; afs_int32 error; =
/* If this connection is in error, this is it */<br>#ifd=
ef KDUMP_RX_LOCK<br> struct rx_call_rx_lock *call[RX_MAXC=
ALLS];<br>#else<br> struct rx_call *call[RX_MAXCALLS];<br=
>#endif<br> afs_uint32 callNumber[RX_MAXCALLS]; /* Curren=
t call numbers */<br> afs_uint32 serial;  =
; /* Next outgoing packet serial number=
*/<br> afs_uint32 lastSerial; &nb=
sp; /* # of last packet received, for computing skew */<br> &nbs=
p; afs_int32 maxSerial; /* larges=
t serial number seen on incoming packets */<br>
afs_int32 maxPacketSize; /* max packet size should be per-conn=
ection since */<br> .........................<br> .=
...........................................<br><br><br>--- On <b>Sat, 2/11/=
12, Simon Wilkinson <i><simonxwilkinson@gmail.com></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 <simonxwilkinson@gmai=
l.com><br>Subject: Re: [OpenAFS] replication over slower bandwidth<br>To=
: muayad_y@yahoo.com<br>Cc: "Neil Davies" <semanticphilosopher@gmail.com=
>, "OpenAFS Info" <openafs-info@openafs.org>, "Jeffrey Altman" <=
;jaltman@your-file-system.com><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>> That field was commented out before OpenAFS =
and maxPacketSize was not<br>> referenced anywhere in the source
code. What restoring that field to<br>> rx.h does is force the st=
ruct rxevent * values that follow it to become<br>> properly aligned in =
64-bit builds.<br>> <br>> 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--