netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Eric Dumazet' <eric.dumazet@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>
Cc: netdev <netdev@vger.kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	Alexander Duyck <alexanderduyck@fb.com>,
	Paolo Abeni <pabeni@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Greg Thelen <gthelen@google.com>
Subject: RE: [PATCH net] net: avoid 32 x truesize under-estimation for tiny skbs
Date: Wed, 13 Jan 2021 22:23:31 +0000	[thread overview]
Message-ID: <b0c5b2164e90492c99752584070510d7@AcuMS.aculab.com> (raw)
In-Reply-To: <20210113161819.1155526-1-eric.dumazet@gmail.com>

From: Eric Dumazet
> Sent: 13 January 2021 16:18
> 
> From: Eric Dumazet <edumazet@google.com>
> 
> Both virtio net and napi_get_frags() allocate skbs
> with a very small skb->head
> 
> While using page fragments instead of a kmalloc backed skb->head might give
> a small performance improvement in some cases, there is a huge risk of
> under estimating memory usage.

There is (or was last time I looked) also a problem with
some of the USB ethernet drivers.

IIRC one of the ASXnnnnnn (???) USB3 ones allocates 64k skb to pass
to the USB stack and then just lies about skb->truesize when passing
them into the network stack.
The USB hardware will merge TCP receives and put multiple ethernet
packets into a single USB message.
But single frames can end up in very big kernel memory buffers.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  parent reply	other threads:[~2021-01-14  2:09 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13 16:18 [PATCH net] net: avoid 32 x truesize under-estimation for tiny skbs Eric Dumazet
2021-01-13 18:00 ` Alexander Duyck
2021-01-13 19:19 ` Michael S. Tsirkin
2021-01-13 22:23 ` David Laight [this message]
2021-01-14  5:16   ` Eric Dumazet
2021-01-14  9:29     ` David Laight
2021-01-14 19:00 ` patchwork-bot+netdevbpf
     [not found] ` <1617007696.5731978-1-xuanzhuo@linux.alibaba.com>
2021-03-29  9:06   ` Eric Dumazet
2021-03-31  8:11     ` Michael S. Tsirkin
2021-03-31  8:36       ` Eric Dumazet
2021-03-31  8:46         ` Eric Dumazet
2021-03-31  8:49           ` Eric Dumazet
2021-03-31  8:54             ` Eric Dumazet
     [not found]               ` <1617248264.4993114-2-xuanzhuo@linux.alibaba.com>
2021-04-01  5:06                 ` Eric Dumazet
     [not found]                   ` <1617357110.3822439-1-xuanzhuo@linux.alibaba.com>
2021-04-02 12:52                     ` Eric Dumazet
2021-04-01 13:51         ` Michael S. Tsirkin
2021-04-01 14:08           ` Eric Dumazet
2021-04-01  7:14       ` Jason Wang
     [not found]         ` <1617267183.5697193-1-xuanzhuo@linux.alibaba.com>
2021-04-01  9:58           ` Eric Dumazet
2021-04-02  2:52             ` Jason Wang
     [not found]               ` <1617361253.1788838-2-xuanzhuo@linux.alibaba.com>
2021-04-02 12:53                 ` Eric Dumazet
2021-04-06  2:04                 ` Jason Wang
     [not found]       ` <1617190239.1035674-1-xuanzhuo@linux.alibaba.com>
2021-03-31 12:08         ` Eric Dumazet
2021-04-01 13:36         ` Michael S. Tsirkin
2022-09-07 20:19 ` Paolo Abeni
2022-09-07 20:40   ` Eric Dumazet
2022-09-08 10:48     ` Paolo Abeni
2022-09-08 12:20       ` Eric Dumazet
2022-09-08 14:26         ` Paolo Abeni
2022-09-08 16:00           ` Eric Dumazet
2022-09-07 21:36   ` Alexander H Duyck
2022-09-08 11:00     ` Paolo Abeni
2022-09-08 14:53       ` Alexander H Duyck
2022-09-08 18:01         ` Paolo Abeni
2022-09-08 19:26           ` Alexander Duyck

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=b0c5b2164e90492c99752584070510d7@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=alexanderduyck@fb.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=gthelen@google.com \
    --cc=kuba@kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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).