From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: dccp@vger.kernel.org
Subject: Re: dccp send
Date: Thu, 03 Jan 2008 23:23:48 +0000 [thread overview]
Message-ID: <20080103232348.GM29523@ghostprotocols.net> (raw)
In-Reply-To: <200801020141.16432.tomasz@grobelny.oswiecenia.net>
Em Thu, Jan 03, 2008 at 11:19:32PM +0100, Tomasz Grobelny escreveu:
> Dnia Thursday 03 January 2008, Arnaldo Carvalho de Melo napisał:
> > Em Wed, Jan 02, 2008 at 11:34:25PM +0100, Tomasz Grobelny escreveu:
> > > with speed at which packets can be transmitted over the network. Is it
> > > the case for dccp as well? If so, does it mean that provided stable
> > > network conditions over longer period of time and using blocking version
> > > of sendmsg in a loop very few packets should be lost? (By very few I mean
> > > < 10%)
> >
> > If the application sends many packets in rapid succession before the
> > DCCP core gets permission from the CCID in use to send those packets to
> > the network what will happen is that sk_write_queue will have packets
> > waiting, using the memory allowed to be allocated for the socket send
> > buffer, which will make sock_alloc_send_skb wait for the packets in
> > sk_write_queue to be sent, freeing up send buffer space, when it will be
> > possible for sock_alloc_send_skb to actually allocate memory for the
> > packet and return to dccp_sendmsg, that in turn will return to the
> > application after putting the newly allocated packet in sk_write_queue,
> > doing the send buffer accounting and trying to send something in
> > dccp_write_xmit, where it will ask the CCID if it can send some more
> > packets, got it?
> >
> I think I almost got it. Thanks a lot for the detailed explanation. But I've
> got two more questions:
> 1. How can I control the amount of "memory allowed to be allocated for the
> socket send buffer"? It it somehow connected with tx_qlen or is it not?
setsockopt(socket_descriptor, SOL_SOCKET, SO_SNDBUF, ...)
execute:
man 7 socket
/SO_SNDBUF
tx_qlen is something experimental, system wide.
> 2. If I decide that for whatever reason a given skb already in sk_write_queue
> should not be transmitted I should remove it from queue and call kfree_skb on
> it, it that right?
There is no interface for that right now, once you pass a packet to the
kernel, the application has no control over it anymore. But there has
been talks about things like setting a timeout for packets to stay on
the queue, or even for the app to have an interface for dropping packets
from the head of the queue.
- Arnaldo
next prev parent reply other threads:[~2008-01-03 23:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-02 0:41 dccp send Tomasz Grobelny
2008-01-02 2:37 ` Arnaldo Carvalho de Melo
2008-01-02 22:34 ` Tomasz Grobelny
2008-01-03 1:02 ` Arnaldo Carvalho de Melo
2008-01-03 22:19 ` Tomasz Grobelny
2008-01-03 22:25 ` Ian McDonald
2008-01-03 23:23 ` Arnaldo Carvalho de Melo [this message]
2008-01-03 23:27 ` Arnaldo Carvalho de Melo
2008-01-04 16:28 ` Tomasz Grobelny
2008-01-04 18:56 ` Ian McDonald
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=20080103232348.GM29523@ghostprotocols.net \
--to=acme@redhat.com \
--cc=dccp@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.