FreeBSD src repository
Modified files:
sys/netinet sctp_bsd_addr.c sctp_crc32.c
sctp_indata.c sctp_input.c sctp_output.c
sctp_pcb.c sctp_structs.h sctp_uio.h
sctputil.c sctputil.h
sys/netinet6 sctp6_usrreq.c
Log:
Tons of fixes to get all the 64bit issues removed.
This also moves two 16 bit int's to become 32 bit
values so we do not have to use atomic_add_16.
Most of the changes are %p, casts and other various
nasty's that were in the orignal code base. With this
commit my machine will now do a build universe.. however
I as yet have not tested on a 64bit machine .. it may not work :-(
Revision Changes Path
1.2 +7 -7 src/sys/netinet/sctp_bsd_addr.c
1.3 +1 -1 src/sys/netinet/sctp_crc32.c
1.2 +4 -4 src/sys/netinet/sctp_indata.c
1.4 +7 -5 src/sys/netinet/sctp_input.c
1.2 +9 -9 src/sys/netinet/sctp_output.c
1.4 +8 -8 src/sys/netinet/sctp_pcb.c
1.2 +5 -4 src/sys/netinet/sctp_structs.h
1.2 +8 -8 src/sys/netinet/sctp_uio.h
1.3 +35 -21 src/sys/netinet/sctputil.c
1.2 +2 -2 src/sys/netinet/sctputil.h
1.3 +5 -4 src/sys/netinet6/sctp6_usrreq.c
_______________________________________________
cvs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-u...@freebsd.org"
> rrs 2006-11-05 13:25:18 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/netinet sctp_bsd_addr.c sctp_crc32.c
> sctp_indata.c sctp_input.c sctp_output.c
> sctp_pcb.c sctp_structs.h sctp_uio.h
> sctputil.c sctputil.h
> sys/netinet6 sctp6_usrreq.c
> Log:
> Tons of fixes to get all the 64bit issues removed.
> This also moves two 16 bit int's to become 32 bit
> values so we do not have to use atomic_add_16.
> Most of the changes are %p, casts and other various
> nasty's that were in the orignal code base. With this
> commit my machine will now do a build universe.. however
> I as yet have not tested on a 64bit machine .. it may not work :-(
>
*blink* I was just going through the universe builds (required for
other changes I'm playing with) and was nearing a commit here.
Thanks for saving me the time. :)
--
Tom Rhodes
I am real sorry I did not know about build universe until after
I committed :-(
I would have cleaned up all the 64 bit issues BEFORE committing :-(
Can't say I would have done the freebsd32/ compat syscalls right.. but
at least I would have not had so much egg on my face :-0
It should build clean now...
R
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
On Sun, Nov 05, 2006 at 01:25:18PM +0000, Randall Stewart wrote:
> rrs 2006-11-05 13:25:18 UTC
>=20
> FreeBSD src repository
>=20
> Modified files:
> sys/netinet sctp_bsd_addr.c sctp_crc32.c=20
> sctp_indata.c sctp_input.c sctp_output.c=20
> sctp_pcb.c sctp_structs.h sctp_uio.h=20
> sctputil.c sctputil.h=20
> sys/netinet6 sctp6_usrreq.c=20
> Log:
> Tons of fixes to get all the 64bit issues removed.
> This also moves two 16 bit int's to become 32 bit
> values so we do not have to use atomic_add_16.
> Most of the changes are %p, casts and other various
> nasty's that were in the orignal code base. With this
> commit my machine will now do a build universe.. however
> I as yet have not tested on a 64bit machine .. it may not work :-(
> =20
> Revision Changes Path
> 1.2 +7 -7 src/sys/netinet/sctp_bsd_addr.c
> 1.3 +1 -1 src/sys/netinet/sctp_crc32.c
> 1.2 +4 -4 src/sys/netinet/sctp_indata.c
> 1.4 +7 -5 src/sys/netinet/sctp_input.c
> 1.2 +9 -9 src/sys/netinet/sctp_output.c
> 1.4 +8 -8 src/sys/netinet/sctp_pcb.c
> 1.2 +5 -4 src/sys/netinet/sctp_structs.h
> 1.2 +8 -8 src/sys/netinet/sctp_uio.h
> 1.3 +35 -21 src/sys/netinet/sctputil.c
> 1.2 +2 -2 src/sys/netinet/sctputil.h
> 1.3 +5 -4 src/sys/netinet6/sctp6_usrreq.c
>=20
Backing out the sctp_crc32.c portion of this change which is just
plain wrong actually lets the amd64 build (and presumably universe)
to complete successfully; already sent more info on this to Randall
and George.
Cheers,
--=20
Ruslan Ermilov
r...@FreeBSD.org
FreeBSD committer
--nzri8VXeXB/g5ayr
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFFTfCYqRfpzJluFF4RAvENAJ0ddL5BXjTmwGNB168thosc7miPFACdGcCG
iEwd//xIHiEqP/RW/J9VdyM=
=JHiI
-----END PGP SIGNATURE-----
--nzri8VXeXB/g5ayr--
1) If you want to play with "mobility" type issues where you
can have addresses come and go dynamically by your SCTP
stack you need to:
a) bind all addresses (INADDR_ANY).
b) You need to enable the behavior with a sysctl
net.inet.sctp.auto_asconf..
c) This should enable you to do ifconfig inf new-addr netmask newmask
and the association you create with a peer will stay up and
reconfigure the addresses dynamically...
Why: Well the reason it is a sysctl and must be activated is that
currently the code needs some tweaking to make it so that if
you had 10,000 associations up and added an address you would
not sink the machine :-( ... In theory we need to move this to
a thread.. and/or to use the iterator (or both more like to help
keep supporting apple and other platforms that do not have
k-threads).
2) Paritial reliability is fully supported and can be accessed by
using the send options described in the sctp-sockets draft in
the IETF :-D
3) Authentication (sort-a like TCP-MD5.. but not requiring shared
keys.. they are optional) is also fully supported.. you may
use socket options to enable additional chunks (besides the
required dynamic addressing ones) to be auth'd. Note that if
you auth data, performance will drop to 1/5 of what it was :-0
Shared keys can be set also by socket option
(see the draft-ietf-tsvwg-auth .. soon to be RFC)... for more
details. Note also, that you MAY not work with older versions
that do not support the latest auth-draft (the one that finished
WG-LC).. they added the chunks being auth'd to the key material.
If you hit this problem (I don't any but BSD and IOS support this
but you never know).. there is a compile option that can get the
old draft behavior... send me an email in the "unlikely event of
a water landing" :-)
4) If you are deep into playing with "TCP emulation mode, you will be
turning on SCTP_EEOR on you socket (Explicit End Of Record). And
setting your partial delivery point to 1 byte. This is cool and works
gaining a bit of performance in the mix .. however there is currently
a bug I am chasing. If the peer is NOT in this same mode.. and is in
the more traditional.. implied-EEOR (where each send is considered a
message) and the PD-API point is NOT set (left to default).. when the
guy that is SCTP_EEOR mode closes the socket without sending the last
data with an explicit EOR.. the peer will get stuck.. waiting for
data. There is a missing wakeup somewhere that I need to find. All
other modes (EEOR -> EEOR), (NON-EEOR -> NON-EEOR),
(NON-EEOR -> EEOR) work fine.. its only the one case I have yet to
nail.. I will try to get this fixed (and approved by gnn) as soon
as I trace down this item.. I am hoping I can find it on my laptop
on loopback.. or debugging will be a bit of a challenge :-0
5) You are best to not compile in any options .. just option SCTP ...
however.. if you want to see LOTS of msgs on the console you can
add SCTP_DEBUG... then you can either play with the sysctl var:
net.inet.sctp.debug. This int is a bit mask that turns on various
prints in the code.. if you are a REAL glutton make it 0xffffffff
.. each bit has a different meaning... but please note I usualy
NEVER compile with this option.. it adds a LOT of
if(sctp_debug_on & MASK_VALUE) to the code... without it they
disappear from the code at compile time. The other option is
a socket option to set this value too... contact me offline if
you want to know it..
6) If you want to enable Sally Floyd's High Speed TCP Congestion Control
its a compile options option SCTP_HIGH_SPEED. In the future we will
be adding more "pluggable" congestion control with a varient of
Doug Leith's H-TCP as well as Sally's.. and make it a sysctl to
switch amongst the choices :-)
7) If you really really are a junky for fun, there are a set of various
logging utilites. You first start with SCTP_STAT_LOGGING options.
this enables a 80,000 entry chunk of memory and all the utilities to
log dynamically with minimal overhead (no locks, just an atomic op).
Once you turn this on, you must select one of the other logging
entries to get some real logs. There are things on cwnd/flight
blocking/locking.. and all sorts of things. I actually have some
tools where you can watch the cwnd/flight/rwnd in a conversation
between two machines over time graphically... you suck this data
out and then dump it into files which then can be plotted.. its
kinda-cool actually.. but you have to be a real junky to want
to play with this... if you are such a guy send me a private email
and I will send you code and further instructions.
8) I will try to figure out where libsctp.a should go (the extra SCTP
non-system call, system calls)... and a few select test tools.
(advice would be appreciated).....
You should, in theory, be able to take ANY TCP program and change
the sd = socket(AF_INET, SOCK_STREAM, 0) [the 0 is sloppy programming
in my mind now] and replace it with
sd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)
and your program should work.. there are equivilants to TCP_NODELAY
and other socket options (just change the TCP to SCTP :-D).
Note I usually use the one-2-many model.. which is gotten via
sd = socket(AF_INET, SOCK_DGRAM, IPPROTO_SCTP). This looks like
udp more than anything else.. You just send to who you want to
and if no assoc exists.. you will get one setup implicitly for
you (also carrying your first message piggyback on the 3rd leg
of the 4-way handshake) :-)
9) Tell me about anything strange please.. if there are issues (which
there may be even besides the 64 bit ones) I want to know about it
and get my small team working on fixing them. Most of the sctp geeks
will be at the IETF so any problems this next week can hopefully be
fixed fairly quickly :-)
Have fun and
Happy SCTPing :-)
Approved by: gnn
and also.. could someone give me a hint as to how I
get rcstemplate to copy correctly into my emacs window?
For some reason the only way I can get it is to go open
another emacs window and manually copy it.. there must
be some cvs-ism I am missing :-(
> Backing out the sctp_crc32.c portion of this change which is just
> plain wrong actually lets the amd64 build (and presumably universe)
> to complete successfully; already sent more info on this to Randall
> and George.
I just came across this. :)
--
Tom Rhodes
On Sun, Nov 05, 2006 at 09:36:25AM -0500, Tom Rhodes wrote:
> On Sun, 5 Nov 2006 17:09:28 +0300
> Ruslan Ermilov <r...@FreeBSD.org> wrote:
[...]
> > Backing out the sctp_crc32.c portion of this change which is just
> > plain wrong actually lets the amd64 build (and presumably universe)
> > to complete successfully; already sent more info on this to Randall
> > and George.
>=20
> I just came across this. :)
>=20
It's been just repaired, and "make universe" should be able to build new
universes again (mine is almost finished :-).
Cheers,
--=20
Ruslan Ermilov
r...@FreeBSD.org
FreeBSD committer
--Bd2KlmcTHfsQFEJ+
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFFTfkaqRfpzJluFF4RAjZwAJ4kJ5hREd2G5MIZJ9Xv4cTjz9zFKwCeL7cA
z+dEBk2gb18Gc5y0oHu/LeQ=
=HX8h
-----END PGP SIGNATURE-----
--Bd2KlmcTHfsQFEJ+--
> On Sun, Nov 05, 2006 at 09:36:25AM -0500, Tom Rhodes wrote:
> > On Sun, 5 Nov 2006 17:09:28 +0300
> > Ruslan Ermilov <r...@FreeBSD.org> wrote:
> [...]
> > > Backing out the sctp_crc32.c portion of this change which is just
> > > plain wrong actually lets the amd64 build (and presumably universe)
> > > to complete successfully; already sent more info on this to Randall
> > > and George.
> >
> > I just came across this. :)
> >
> It's been just repaired, and "make universe" should be able to build new
> universes again (mine is almost finished :-).
>
Mine's still on amd64, but I'm also doing several other things.
I need a better laptop. But I'm never happy. :)
On Sun, Nov 05, 2006 at 09:29:32AM -0500, Randall Stewart wrote:
> Randall Stewart wrote:
> >rrs 2006-11-05 13:25:18 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > sys/netinet sctp_bsd_addr.c sctp_crc32.c=20
> > sctp_indata.c sctp_input.c sctp_output.c=20
> > sctp_pcb.c sctp_structs.h sctp_uio.h=20
> > sctputil.c sctputil.h=20
> > sys/netinet6 sctp6_usrreq.c=20
> > Log:
> > Tons of fixes to get all the 64bit issues removed.
> > This also moves two 16 bit int's to become 32 bit
> > values so we do not have to use atomic_add_16.
> > Most of the changes are %p, casts and other various
> > nasty's that were in the orignal code base. With this
> > commit my machine will now do a build universe.. however
> > I as yet have not tested on a 64bit machine .. it may not work :-(
> > =20
> One other thing I forgot to attach.. the
>=20
> Approved by: gnn
>=20
> and also.. could someone give me a hint as to how I
> get rcstemplate to copy correctly into my emacs window?
>=20
> For some reason the only way I can get it is to go open
> another emacs window and manually copy it.. there must
> be some cvs-ism I am missing :-(
You can do a checkout or update with the FreeBSD specific CVS option -T,
i.e. "cvs -T update -d -P"
-- Brooks
--RASg3xLB4tUQ4RcS
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFFTh+gXY6L6fI4GtQRApsSAKDbsJl/XktWcioQYlQKgUU3Dm1fWQCggzVX
Se809Y9JEXug6+9t7L0mVDE=
=79P1
-----END PGP SIGNATURE-----
--RASg3xLB4tUQ4RcS--
Thanks
R
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)