[BK PATCH] 2.6.2 SCTP updates

[BK PATCH] 2.6.2 SCTP updates

[Sridhar Samudrala]

Hi Dave,

Please do a
	bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work
to get the following udpates to SCTP on top of linux 2.6.2

These csets include fixes for a couple of issues that were reported by
SCTP users.
- Removed deprecated ADLER32 checksum support as it is unexpectedly
  getting selected in certain configurations (ex: allyesconfig) and we
  no longer need to support it.
- Updated the default max socket receive buffer to 64K from 32K and also
  added sysctl variables to change sctp socket send/receive buffers.

# This patch includes the following deltas:
#	           ChangeSet	1.1548  -> 1.1550
#	net/sctp/associola.c	1.64    -> 1.65
#	net/sctp/endpointola.c	1.29    -> 1.30
#	    net/sctp/Kconfig	1.7     -> 1.8
#	include/net/sctp/constants.h	1.17    -> 1.18
#	   net/sctp/sysctl.c	1.15    -> 1.16
#	include/linux/sysctl.h	1.57    -> 1.58
#	 net/sctp/protocol.c	1.59    -> 1.61
#	  net/sctp/adler32.c	1.8     ->         (deleted)
#	 net/sctp/ulpqueue.c	1.26    -> 1.27
#	include/net/sctp/structs.h	1.78    -> 1.79
#	   net/sctp/Makefile	1.9     -> 1.10
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
ChangeSet@1.1550, 2004-02-05 13:58:37-08:00, sri@us.ibm.com
  [SCTP] Removed the deprecated ADLER32 checksum support.

ChangeSet@1.1474.108.5, 2004-01-23 14:58:38-08:00, sri@us.ibm.com
  [SCTP] Add sysctl parameters to update socket send/receive buffers.

ChangeSet@1.1474.108.4, 2004-01-19 11:12:44-08:00, sri@us.ibm.com
  [SCTP] provide valid tos and oif values for ip_route_output_key. (ja@ssi.bg)

Thanks
Sridhar

Re: [BK PATCH] 2.6.2 SCTP updates

[David S. Miller]

On Fri, 6 Feb 2004 17:24:32 -0800 (PST)
Sridhar Samudrala <sri@us.ibm.com> wrote:

> Please do a
> 	bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work
> to get the following udpates to SCTP on top of linux 2.6.2

Pulled, but.

> - Updated the default max socket receive buffer to 64K from 32K and also
>   added sysctl variables to change sctp socket send/receive buffers.

Why do you use specialized SCTP rmem/wmem values and not the globally
sysctl's ones we have for sockets already?

Re: [BK PATCH] 2.6.2 SCTP updates

[Sridhar Samudrala]

On Fri, 6 Feb 2004, David S. Miller wrote:

> On Fri, 6 Feb 2004 17:24:32 -0800 (PST)
> Sridhar Samudrala <sri@us.ibm.com> wrote:
>
> > Please do a
> > 	bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work
> > to get the following udpates to SCTP on top of linux 2.6.2
>
> Pulled, but.
>
> > - Updated the default max socket receive buffer to 64K from 32K and also
> >   added sysctl variables to change sctp socket send/receive buffers.
>
> Why do you use specialized SCTP rmem/wmem values and not the globally
> sysctl's ones we have for sockets already?

Dave,

I guess i was influenced by the TCP specific tcp_rmem/tcp_wmem. But TCP
seems to be using them as a vector of 3 values and tuning the buffer sizes
dynamically based on these values.
As of now, SCTP doesn't do any tuning dynamically so i could have used the
core rmem_default/wmem_default.

Do you want me to remove the specialized SCTP sysctl's?

Thanks
Sridhar

Re: [BK PATCH] 2.6.2 SCTP updates

[David S. Miller]

On Sun, 8 Feb 2004 09:07:48 -0800 (PST)
Sridhar Samudrala <sri@us.ibm.com> wrote:

> I guess i was influenced by the TCP specific tcp_rmem/tcp_wmem. But TCP
> seems to be using them as a vector of 3 values and tuning the buffer sizes
> dynamically based on these values.
> As of now, SCTP doesn't do any tuning dynamically so i could have used the
> core rmem_default/wmem_default.
> 
> Do you want me to remove the specialized SCTP sysctl's?

It seems as duplication if there is no specific need to have seperate
controls right?

Re: [BK PATCH] 2.6.2 SCTP updates

[Sridhar Samudrala]

On Sun, 8 Feb 2004, David S. Miller wrote:

> On Sun, 8 Feb 2004 09:07:48 -0800 (PST)
> Sridhar Samudrala <sri@us.ibm.com> wrote:
>
> > I guess i was influenced by the TCP specific tcp_rmem/tcp_wmem. But TCP
> > seems to be using them as a vector of 3 values and tuning the buffer sizes
> > dynamically based on these values.
> > As of now, SCTP doesn't do any tuning dynamically so i could have used the
> > core rmem_default/wmem_default.
> >
> > Do you want me to remove the specialized SCTP sysctl's?
>
> It seems as duplication if there is no specific need to have seperate
> controls right?

OK. I removed the SCTP specific rmem/wmem. Please do a pull again from
	http://linux-lksctp.bkbits.net/lksctp-2.5.work
to get the following cset.

ChangeSet@1.1551, 2004-02-09 11:14:24-08:00, sri@us.ibm.com
  [SCTP] Removed SCTP specific rmem/wmem sysctl's and use the global
         rmem_default/wmem_default values for SCTP socket buffer sizes.

Thanks
Sridhar

Re: [BK PATCH] 2.6.2 SCTP updates

[David S. Miller]

On Mon, 9 Feb 2004 12:01:20 -0800 (PST)
Sridhar Samudrala <sri@us.ibm.com> wrote:

> OK. I removed the SCTP specific rmem/wmem. Please do a pull again from
> 	http://linux-lksctp.bkbits.net/lksctp-2.5.work
> to get the following cset.
> 
> ChangeSet@1.1551, 2004-02-09 11:14:24-08:00, sri@us.ibm.com
>   [SCTP] Removed SCTP specific rmem/wmem sysctl's and use the global
>          rmem_default/wmem_default values for SCTP socket buffer sizes.

Pulled, thanks for following up on this Sridhar.

What is the status of synchronizing the 2.4.x SCTP sources?

Re: [BK PATCH] 2.6.2 SCTP updates

[Sridhar Samudrala]

On Mon, 9 Feb 2004, David S. Miller wrote:

>
> What is the status of synchronizing the 2.4.x SCTP sources?

It is going on well. I hope to get it done by the end of this week. Do you
want me to wait for 2.4.25 release? Or can i submit it even in the -rc phase?

-Sridhar

Re: [BK PATCH] 2.6.2 SCTP updates

[David S. Miller]

On Mon, 9 Feb 2004 12:34:06 -0800 (PST)
Sridhar Samudrala <sri@us.ibm.com> wrote:

> It is going on well. I hope to get it done by the end of this week. Do you
> want me to wait for 2.4.25 release? Or can i submit it even in the -rc phase?

I would like to have it as soon as possible.  Not necessarily so that
it gets merged into 2.4.25 (I don't think I'll try to do that) but moreso
because I'd like to do review it now such that when 2.4.26-preX starts up
I can just push it along.

Re: [BK PATCH] 2.6.2 SCTP updates

[Nivedita Singhvi]

Sridhar Samudrala wrote:

> ChangeSet@1.1551, 2004-02-09 11:14:24-08:00, sri@us.ibm.com
>   [SCTP] Removed SCTP specific rmem/wmem sysctl's and use the global
>          rmem_default/wmem_default values for SCTP socket buffer sizes.

Sorry to pitch in on this so late - and I'm not suggesting
this was not the right thing to do here, but I feel that
having the per-protocol globals (as we do for TCP) is a
good thing, as then you don't affect all (raw, udp..)
traffic on the system just because someone is tuning
for SCTP, etc.

Just my 0.2c :)

thanks,
Nivedita

Re: [BK PATCH] 2.6.2 SCTP updates

[David S. Miller]

On Mon, 09 Feb 2004 12:34:18 -0800
Nivedita Singhvi <niv@us.ibm.com> wrote:

> Sorry to pitch in on this so late - and I'm not suggesting
> this was not the right thing to do here, but I feel that
> having the per-protocol globals (as we do for TCP) is a
> good thing, as then you don't affect all (raw, udp..)
> traffic on the system just because someone is tuning
> for SCTP, etc.

I understand.

But there was no known reason to tweak things for SCTP.
If one wanted to adjust things system wide there was no
way for it to apply to SCTP too.

Also, the TCP controls are not as they would seem.  They don't
directly effect things like the sysctl*{rmem,wmem} stuff does,
rather it influences the dynamic socket buffer sizing which
TCP does.

Re: [BK PATCH] 2.6.2 SCTP updates

[Nivedita Singhvi]

David S. Miller wrote:

> I understand.
> 
> But there was no known reason to tweak things for SCTP.

Yeah, I agree it doesn't matter right now for SCTP.
I don't know of anyone running SCTP *and* heavy NFS/raw
apps simultaneously. But they open up those socket
buffers for some real decent SCTP performance and
watch that unconstrained raw or udp traffic bludgeon
any congestion controlled streams like TCP and SCTP
out of the network. But this is a rather intrinsic
problem with other solutions, really..

thanks,
Nivedita