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
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to