All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
Cc: saeedm@mellanox.com, gerlitz.or@gmail.com, eugenia@mellanox.com,
	Alexander Duyck <alexander.duyck@gmail.com>,
	brouer@redhat.com
Subject: Re: [net-next PATCH V1 0/3] net: enable use of kmem_cache_alloc_bulk in network stack
Date: Fri, 20 May 2016 10:14:46 +0200	[thread overview]
Message-ID: <20160520101446.64416d2b@redhat.com> (raw)
In-Reply-To: <20160509134352.3573.37044.stgit@firesoul>

On Mon, 09 May 2016 15:44:24 +0200
Jesper Dangaard Brouer <brouer@redhat.com> wrote:

> This patchset enables use of the slab/kmem_cache bulk alloc API, and
> completes the use the slab/kmem_cache bulking API in the network stack.
> 
> I've not included the patches that introduce a SKB bulk hint, which
> would beneficial for drivers like mlx5.  Lets see if we can agree on
> this patchset first.

Conclusion: Guess we could not agree on this patchset.

The main problem seems to be that the patch always bulk allocated 8
SKBs, without knowing if we actually need them.  My earlier patchset
also included a "hint" interface, as mlx5 driver knows after processing
the RX queue, how many SKBs it needs, thus it can request to bulk alloc
the needed amount. (The only problem with mlx5 is that preallocating
SKBs into it's RX ring is a broken scheme).

A better scheme would be, if the driver on RX knows how many packets
are available in the RX queue.  Then we can bulk alloc the needed
amount of SKBs.  Thus, we can circle back to this once the driver can
provide this information. (This goes nicely hand-in-hand with my idea
of pulling out avail RX packet-pages from the RX ring, and start
prefetch'es to hide the cache-misses).

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

      parent reply	other threads:[~2016-05-20  8:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09 13:44 [net-next PATCH V1 0/3] net: enable use of kmem_cache_alloc_bulk in network stack Jesper Dangaard Brouer
2016-05-09 13:44 ` [net-next PATCH V1 1/3] net: bulk alloc and reuse of SKBs in NAPI context Jesper Dangaard Brouer
2016-05-09 16:20   ` Alexander Duyck
2016-05-09 19:59     ` Jesper Dangaard Brouer
2016-05-09 20:46       ` Alexander Duyck
2016-05-10  9:29         ` Jesper Dangaard Brouer
2016-05-10 12:30         ` Jesper Dangaard Brouer
2016-05-10 13:48           ` Eric Dumazet
2016-05-10 14:48             ` Jesper Dangaard Brouer
2016-05-10 15:44               ` Eric Dumazet
2016-05-10 17:46           ` Alexander Duyck
2016-05-09 13:44 ` [net-next PATCH V1 2/3] mlx4: use napi_alloc_skb API to get SKB bulk allocations Jesper Dangaard Brouer
2016-05-09 16:47   ` Alexander Duyck
2016-05-09 20:05     ` Jesper Dangaard Brouer
2016-05-09 13:44 ` [net-next PATCH V1 3/3] net: warn on napi_alloc_skb being called in wrong context Jesper Dangaard Brouer
2016-05-09 13:53   ` Sergei Shtylyov
2016-05-09 13:53   ` Sergei Shtylyov
2016-05-09 16:33   ` Alexander Duyck
2016-05-09 20:03     ` Jesper Dangaard Brouer
2016-05-20  8:14 ` Jesper Dangaard Brouer [this message]

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=20160520101446.64416d2b@redhat.com \
    --to=brouer@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=eugenia@mellanox.com \
    --cc=gerlitz.or@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.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 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.