[ewg] Re: [PATCH] call skb_orphan() after sending an SKB

[Eli Cohen]

On Wed, 2008-02-06 at 10:17 +0200, Or Gerlitz wrote:
> > commit f17ebf3e2099257da244587f1ee33f51745f7cdb
> > Author: Eli Cohen <eli at mellanox.co.il>
> > Date:   Tue Feb 5 11:15:46 2008 +0200
> >
> >     Call skb_orphan() after sending an SKB
> >
> >     This will call the destructor of the SKB (but not free the
> >     memory). It appears that some applications (ttcpv for example)
> >     are sensitive to delaying the time the SKB is freed. This commit
> >     fixes this problem.
> 
> Can you explain what is the difference from the socket send buffer accounting
> point of view, between freeing the SKB to freeing the memory?
When you call skb_orphan(), the destructor of the SKB is called, in the
case this a function put by the socket. So from the socket point of view
the packet has been sent. The memory is still no freed since it is
needed by HW. Once we get a completion for the send operation, the SKB
is freed.


>  what was the
> problem with ttcpv, did it hanged?
The problem with ttcpv was that it stopped sending packets since it was
waiting for freeing the memory. The system did not hang, just the
application (ttcpv) stopped sending. Other applications could continue
working over the ipoib interface.

>  have you tested the unsig_udqp.patch with
> different socket buffer sizes to make sure there's no live-lock etc?
Yes, our regression system does that with different applications and
benchmarks.

>  what was the app you were using?
ttcpv


> 
> Also, I see that you have added a call to netif_stop_queue(), is this to
> solve another problem?

This was just a whole that I found in code review - when I post a zero
length packet, I still want this to affect the net queue control.
> 
> Or.
>