All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Mike Waychison <mikew@google.com>, "Michael S. Tsirkin" <mst@redhat.com>
Cc: netdev@vger.kernel.org, earhart@google.com,
	digitaleric@google.com, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v2 1/3] virtio_net: Split receive buffer alloc/add
Date: Wed, 11 Jan 2012 12:00:25 +1030	[thread overview]
Message-ID: <8739bn6n66.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20120110174100.4505.8939.stgit@mike2.sea.corp.google.com>

On Tue, 10 Jan 2012 09:41:01 -0800, Mike Waychison <mikew@google.com> wrote:
> In preparation for allocating receive buffers in the slow path without
> disabling NAPI, split the allocation and addition of receive buffers
> apart into two separate functions (per receive buffer type).
> 
> While here, move the vi->num accounting into the add functions.
> 
> Signed-off-by: Mike Waychison <mikew@google.com>

Hi Mike...

        This exposes a nasty ugliness in the way virtio_net works.  We
allocate an skbuff for the small packet case, and just allocate the
pages for the large packet cases, and alloc the skbuff when we fill the
pages.

        I think all the allocators should return a populated skbuff;
this uses a bit more memory in theory, but should make the code simpler.
As an added bonus, your life should get much simpler for these patches.

I'll try to create such a patch tonight, but I'm busy finalizing my
linux.conf.au presentation, so it might take longer :(

Thanks,
Rusty.

WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Mike Waychison <mikew@google.com>, "Michael S. Tsirkin" <mst@redhat.com>
Cc: netdev@vger.kernel.org, earhart@google.com,
	virtualization@lists.linux-foundation.org,
	digitaleric@google.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] virtio_net: Split receive buffer alloc/add
Date: Wed, 11 Jan 2012 12:00:25 +1030	[thread overview]
Message-ID: <8739bn6n66.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20120110174100.4505.8939.stgit@mike2.sea.corp.google.com>

On Tue, 10 Jan 2012 09:41:01 -0800, Mike Waychison <mikew@google.com> wrote:
> In preparation for allocating receive buffers in the slow path without
> disabling NAPI, split the allocation and addition of receive buffers
> apart into two separate functions (per receive buffer type).
> 
> While here, move the vi->num accounting into the add functions.
> 
> Signed-off-by: Mike Waychison <mikew@google.com>

Hi Mike...

        This exposes a nasty ugliness in the way virtio_net works.  We
allocate an skbuff for the small packet case, and just allocate the
pages for the large packet cases, and alloc the skbuff when we fill the
pages.

        I think all the allocators should return a populated skbuff;
this uses a bit more memory in theory, but should make the code simpler.
As an added bonus, your life should get much simpler for these patches.

I'll try to create such a patch tonight, but I'm busy finalizing my
linux.conf.au presentation, so it might take longer :(

Thanks,
Rusty.

  reply	other threads:[~2012-01-11  1:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-10 17:40 [PATCH v2 0/3] virtio_net: Better low memory handling Mike Waychison
2012-01-10 17:40 ` Mike Waychison
2012-01-10 17:41 ` [PATCH v2 1/3] virtio_net: Split receive buffer alloc/add Mike Waychison
2012-01-10 17:41   ` Mike Waychison
2012-01-11  1:30   ` Rusty Russell [this message]
2012-01-11  1:30     ` Rusty Russell
2012-01-11  1:42     ` Mike Waychison
2012-01-11  1:42       ` Mike Waychison
2012-01-10 17:41 ` [PATCH v2 2/3] virtio_net: Batch receive buffer filling Mike Waychison
2012-01-10 17:41   ` Mike Waychison
2012-01-10 17:41 ` [PATCH v2 3/3] virtio_net: Don't disable NAPI while allocating Mike Waychison
2012-01-10 17:41   ` Mike Waychison

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=8739bn6n66.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=digitaleric@google.com \
    --cc=earhart@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikew@google.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.