12 Oct, 2006
1 commit
-
When doing receiver buffer accounting, we always used skb->truesize.
This is problematic when processing bundled DATA chunks because for
every DATA chunk that could be small part of one large skb, we would
charge the size of the entire skb. The new approach is to store the
size of the DATA chunk we are accounting for in the sctp_ulpevent
structure and use that stored value for accounting.Signed-off-by: Vlad Yasevich
Signed-off-by: Sridhar Samudrala
Signed-off-by: David S. Miller
18 Jun, 2006
1 commit
-
Right now, every time we increase our rwnd by more then MTU bytes, we
trigger a SACK. When processing large messages, this will generate a
SACK for almost every other SCTP fragment. However since we are freeing
the entire message at the same time, we might as well collapse the SACK
generation to 1.Signed-off-by: Tsutomu Fujii
Signed-off-by: Vlad Yasevich
Signed-off-by: Sridhar Samudrala
Signed-off-by: David S. Miller
12 Nov, 2005
1 commit
-
Also introduces a sysctl option to configure the receive buffer
accounting policy to be either at socket or association level.
Default is all the associations on the same socket share the
receive buffer.Signed-off-by: Neil Horman
Signed-off-by: Sridhar Samudrala
Signed-off-by: David S. Miller
29 Oct, 2005
1 commit
-
Rename SCTP specific control message flags to use SCTP_ prefix rather than
MSG_ prefix as per the latest sctp sockets API draft.Signed-off-by: Ivan Skytte Jorgensen
Signed-off-by: Sridhar Samudrala
09 Oct, 2005
1 commit
-
- added typedef unsigned int __nocast gfp_t;
- replaced __nocast uses for gfp flags with gfp_t - it gives exactly
the same warnings as far as sparse is concerned, doesn't change
generated code (from gcc point of view we replaced unsigned int with
typedef) and documents what's going on far better.Signed-off-by: Al Viro
Signed-off-by: Linus Torvalds
12 Jul, 2005
1 commit
-
Signed-off-by: Alexey Dobriyan
Signed-off-by: David S. Miller
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!