From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
Neal Cardwell <ncardwell@google.com>,
Yuchung Cheng <ycheng@google.com>
Subject: Re: [PATCH net-next] tcp: add tcp_add_backlog()
Date: Fri, 23 Sep 2016 09:45:17 -0300 [thread overview]
Message-ID: <20160923124517.GB17222@localhost.localdomain> (raw)
In-Reply-To: <1474586490.28155.10.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, Sep 22, 2016 at 04:21:30PM -0700, Eric Dumazet wrote:
> On Thu, 2016-09-22 at 19:34 -0300, Marcelo Ricardo Leitner wrote:
> > On Sat, Aug 27, 2016 at 07:37:54AM -0700, Eric Dumazet wrote:
> > > +bool tcp_add_backlog(struct sock *sk, struct sk_buff *skb)
> > > +{
> > > + u32 limit = sk->sk_rcvbuf + sk->sk_sndbuf;
> > ^^^
> > ...
> > > + if (!skb->data_len)
> > > + skb->truesize = SKB_TRUESIZE(skb_end_offset(skb));
> > > +
> > > + if (unlikely(sk_add_backlog(sk, skb, limit))) {
> > ...
> > > - } else if (unlikely(sk_add_backlog(sk, skb,
> > > - sk->sk_rcvbuf + sk->sk_sndbuf))) {
> > ^---- [1]
> > > - bh_unlock_sock(sk);
> > > - __NET_INC_STATS(net, LINUX_MIB_TCPBACKLOGDROP);
> > > + } else if (tcp_add_backlog(sk, skb)) {
> >
> > Hi Eric, after this patch, do you think we still need to add sk_sndbuf
> > as a stretching factor to the backlog here?
> >
> > It was added by [1] and it was justified that the (s)ack packets were
> > just too big for the rx buf size. Maybe this new patch alone is enough
> > already, as such packets will have a very small truesize then.
> >
> > Marcelo
> >
> > [1] da882c1f2eca ("tcp: sk_add_backlog() is too agressive for TCP")
> >
>
> Hi Marcelo
>
> Yes, it is still needed, some drivers provide linear skbs, so the
> skb->truesize of ack packets will likely be the same (skb->head points
> to a full size frame allocated by the driver)
Aye. In that case, what about using tail instead of end? Because
accounting for something that we have to tweak the limits to accept is
like adding a constant to both sides of the equation.
But perhaps that would cut out too much of the fat which could be used
later by the stack.
next prev parent reply other threads:[~2016-09-23 12:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-27 14:37 [PATCH net-next] tcp: add tcp_add_backlog() Eric Dumazet
2016-08-27 16:13 ` Yuchung Cheng
2016-08-27 16:25 ` Eric Dumazet
2016-08-29 16:53 ` Yuchung Cheng
2016-08-27 18:24 ` Neal Cardwell
2016-08-29 4:20 ` David Miller
2016-08-29 18:51 ` Marcelo Ricardo Leitner
2016-08-29 19:22 ` Eric Dumazet
2016-08-29 19:33 ` Marcelo Ricardo Leitner
2016-09-22 22:34 ` Marcelo Ricardo Leitner
2016-09-22 23:21 ` Eric Dumazet
2016-09-23 12:45 ` Marcelo Ricardo Leitner [this message]
2016-09-23 13:42 ` Eric Dumazet
2016-09-23 14:09 ` Marcelo Ricardo Leitner
2016-09-23 14:36 ` Eric Dumazet
2016-09-23 14:43 ` David Laight
2016-09-23 15:12 ` Marcelo Ricardo Leitner
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=20160923124517.GB17222@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=ycheng@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).