Searched hist:cb95ea32a457871f72752164de8d94fa20f4703c (Results 1 – 3 of 3) sorted by relevance
| /openbmc/linux/net/sctp/ |
| H A D | chunk.c | diff cb95ea32a457871f72752164de8d94fa20f4703c Fri Sep 04 17:20:59 CDT 2009 Vlad Yasevich <vladislav.yasevich@hp.com> sctp: Don't do NAGLE delay on large writes that were fragmented small
SCTP will delay the last part of a large write due to NAGLE, if that
part is smaller then MTU. Since we are doing large writes, we might
as well send the last portion now instead of waiting untill the next
large write happens. The small portion will be sent as is regardless,
so it's better to not delay it.
This is a result of much discussions with Wei Yongjun <yjwei@cn.fujitsu.com>
and Doug Graham <dgraham@nortel.com>. Many thanks go out to them.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
|
| H A D | output.c | diff cb95ea32a457871f72752164de8d94fa20f4703c Fri Sep 04 17:20:59 CDT 2009 Vlad Yasevich <vladislav.yasevich@hp.com> sctp: Don't do NAGLE delay on large writes that were fragmented small
SCTP will delay the last part of a large write due to NAGLE, if that
part is smaller then MTU. Since we are doing large writes, we might
as well send the last portion now instead of waiting untill the next
large write happens. The small portion will be sent as is regardless,
so it's better to not delay it.
This is a result of much discussions with Wei Yongjun <yjwei@cn.fujitsu.com>
and Doug Graham <dgraham@nortel.com>. Many thanks go out to them.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
|
| /openbmc/linux/include/net/sctp/ |
| H A D | structs.h | diff cb95ea32a457871f72752164de8d94fa20f4703c Fri Sep 04 17:20:59 CDT 2009 Vlad Yasevich <vladislav.yasevich@hp.com> sctp: Don't do NAGLE delay on large writes that were fragmented small
SCTP will delay the last part of a large write due to NAGLE, if that
part is smaller then MTU. Since we are doing large writes, we might
as well send the last portion now instead of waiting untill the next
large write happens. The small portion will be sent as is regardless,
so it's better to not delay it.
This is a result of much discussions with Wei Yongjun <yjwei@cn.fujitsu.com>
and Doug Graham <dgraham@nortel.com>. Many thanks go out to them.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
|