Re: dccp send

2008-01-03 Thread Ian McDonald
On Jan 4, 2008 11:19 AM, Tomasz Grobelny [EMAIL PROTECTED] wrote:
 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?

I wrote the code here so let me comment - there is no fixed amount of
memory allocated - it is determined by the tx_qlen. I was looking at
implementing memory limits but it got too hard and as DCCP doesn't
combine packets I thought it made it much simpler just to put a limit
by packets.

 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?

Correct. Remember of course all your locking mechanisms. If you want a
good example look at the below towards the end:
http://wand.net.nz/~iam4/dccp/patches20/30-best_packet_next.diff

(NB this patch applies against 2.6.20 after previous patches in series).

Regards,

Ian
-- 
Web1: http://wand.net.nz/~iam4/
Web2: http://www.jandi.co.nz
-
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


Re: dccp send

2008-01-03 Thread Arnaldo Carvalho de Melo
Em Fri, Jan 04, 2008 at 11:25:29AM +1300, Ian McDonald escreveu:
 On Jan 4, 2008 11:19 AM, Tomasz Grobelny [EMAIL PROTECTED] wrote:
  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?
 
 I wrote the code here so let me comment - there is no fixed amount of
 memory allocated - it is determined by the tx_qlen. I was looking at

there is no memory allocated in advance nor explicit, DCCP specific
mechanism for limiting the amount of memory a socket can use for its
write queue, but DCCP uses sock_alloc_send_skb and that function does
memory accounting and checks if the maximum memory (SO_SNDBUF) has been
reached, when it makes the app to sleep if O_NONBLOCK is not set.

 implementing memory limits but it got too hard and as DCCP doesn't
 combine packets I thought it made it much simpler just to put a limit
 by packets.
 
  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?
 
 Correct. Remember of course all your locking mechanisms. If you want a
 good example look at the below towards the end:
 http://wand.net.nz/~iam4/dccp/patches20/30-best_packet_next.diff
 
 (NB this patch applies against 2.6.20 after previous patches in series).

Correct if he is in-kernel.

- 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