All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J K" <jaika@hotmail.com>
To: lartc@vger.kernel.org
Subject: [LARTC] draining multiple sockets
Date: Fri, 22 Mar 2002 00:25:10 +0000	[thread overview]
Message-ID: <marc-lartc-101675679417470@msgid-missing> (raw)

Hi,

  I am looking into the codes of linux kernel(ipv4/tcp.c,tcp_output.c
  /net/core/dev.c etc.) to find out how multiple sockets are
  drained on to the network. Here is the picture that I got so
  far: If there are 'n' sockets with data to send over TCP,
  then they all supposedly take equal turns draining their
  data on to the xmit_queue.

1. However, this 'equal turn' (fair) philosophy is guided more in
  part due to the nature of the TCP behavior under competing flows,
  than anything else.
2. In practice though, the draining of sockets is like a FCFS
  scheduling discipline!!!
  Which ever socket has data to send, will grab a piece of the
  TCP sk->sndbuf (16KB) and write it out. If the sndbuf is full,
  the process waits a random amount of time (between 2 and 21
  jiffies) then retries again.
3. Once inside the sndbuf, the packet is passed on to the IP
  level and then to the device level (default device_xmit_queue
  length of 100 packets for ethernet). At every instant the
  routines constantly try to push as much data out on to the
  network (device_xmit_queue) as possible. right?

  If I am wrong regarding any of the above 3 statements, **please**
  correct me.


socket1
||||| ---> TCP processing  -->  IP processing _
                                                \
socket2                                          \   n/w xmit_queue
|||| ---> TCP processing  -->  IP processing ------>  |||||||--->
.                                                 /
.                                                /
.                                               /
socket n                                       /
||||| ---> TCP processing  -->  IP processing -

- jaika

ps:  Here is what I gleaned from the sources:
  in tcp_ipv4.c: sk->sndbuff is initialised to sysctl_tcp_wmem[1];
  and in net/ipv4/tcp.c: int sysctl_tcp_wmem[3] = {4*1024, 16*1024, 
128*1024};
  So I guess the sndbuff is initialised to 16K.







_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

             reply	other threads:[~2002-03-22  0:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-22  0:25 J K [this message]
2002-03-22 10:06 ` [LARTC] draining multiple sockets bert hubert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-101675679417470@msgid-missing \
    --to=jaika@hotmail.com \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.