On Wed, 2017-01-25 at 09:14 -0500, Josef Bacik wrote: > On Tue, Jan 24, 2017 at 9:07 AM, Eric Dumazet <eric.duma...@gmail.com>
> > > > git grep -n SOCK_QUEUE_SHRUNK > > > > -> tcp_check_space() > > But tcp_check_space() doesn't actually reduce sk_wmem_queued from what > I can see. The only places that appear to reduce it are tcp_trim_head, > which is only called in the retransmit path, and sk_wmem_free_skb, > which seems to be right, This is exactly how it works. We free a bunch of skbs (an ACK can acknowledge dozens of them), and set the SOCK_QUEUE_SHRUNK. Then later, tcp_check_space() is called once and check if the bit was set by a prior call to tcp_trim_head() or full skb freeing. > but I added a trace_printk() in it to see if > it was firing during my test and it never fires. So we _appear_ to > only ever be incrementing this counter, but never decrementing it. I'm > doing a bunch of tracing trying to figure out what is going on here but > so far nothing is popping which is starting to make me think ftrace is > broken. Thanks, > Just to make sure, are you telling use native/standard TCP is broken over loopback, or is that only when using an additional kernel module ?
