From: Andi Kleen <andi@firstfloor.org>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: xiaohui.xin@intel.com, netdev@vger.kernel.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
mst@redhat.com, mingo@elte.hu, davem@davemloft.net,
herbert@gondor.hengli.com.au, jdike@linux.intel.com
Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external.
Date: Mon, 07 Jun 2010 09:51:11 +0200 [thread overview]
Message-ID: <87pr03gu1c.fsf@basil.nowhere.org> (raw)
In-Reply-To: <20100606161348.427822fb@nehalam> (Stephen Hemminger's message of "Sun\, 6 Jun 2010 16\:13\:48 -0700")
Stephen Hemminger <shemminger@vyatta.com> writes:
> Still not sure this is a good idea for a couple of reasons:
>
> 1. We already have lots of special cases with skb's (frags and fraglist),
> and skb's travel through a lot of different parts of the kernel. So any
> new change like this creates lots of exposed points for new bugs. Look
> at cases like MD5 TCP and netfilter, and forwarding these SKB's to ipsec
> and ppp and ...
>
> 2. SKB's can have infinite lifetime in the kernel. If these buffers come from
> a fixed size pool in an external device, they can easily all get tied up
> if you have a slow listener. What happens then?
3. If they come from an internal pool what happens when the kernel runs
low on memory? How is that pool balanced against other kernel
memory users?
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2010-06-07 7:51 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-05 10:14 [RFC PATCH v7 01/19] Add a new structure for skb buffer from external xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 02/19] Add a new struct for device to manipulate external buffer xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 03/19] Export 2 func for device to assign/deassign new strucure xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 04/19] Add a ndo_mp_port_prep pointer to net_device_ops xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 05/19] Add a function make external buffer owner to query capability xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 06/19] Add a function to indicate if device use external buffer xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 07/19] Add interface to get external buffers xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 08/19] Make __alloc_skb() to get external buffer xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 09/19] Ignore room skb_reserve() when device is using " xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 10/19] Don't do skb recycle, if device use " xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 11/19] Use callback to deal with skb_release_data() specially xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 12/19] Add a hook to intercept external buffers from NIC driver xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 13/19] To skip GRO if buffer is external currently xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 14/19] Add header file for mp device xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 15/19] Add basic funcs and ioctl to " xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 16/19] Manipulate external buffers in " xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 17/19] Export proto_ops to vhost-net driver xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 18/19] Add a kconfig entry and make entry for mp device xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 19/19] Provides multiple submits and asynchronous notifications xiaohui.xin
2010-06-05 10:14 ` [RFC PATCH v7 00/19] Provide a zero-copy method on KVM virtio-net xiaohui.xin
2010-06-05 14:56 ` [RFC PATCH v7 11/19] Use callback to deal with skb_release_data() specially Eric Dumazet
2010-06-09 7:30 ` Xin, Xiaohui
2010-06-05 14:53 ` [RFC PATCH v7 08/19] Make __alloc_skb() to get external buffer Eric Dumazet
2010-06-09 7:34 ` Xin, Xiaohui
2010-06-05 14:51 ` [RFC PATCH v7 03/19] Export 2 func for device to assign/deassign new strucure Eric Dumazet
2010-06-06 23:13 ` [RFC PATCH v7 01/19] Add a new structure for skb buffer from external Stephen Hemminger
2010-06-07 7:51 ` Andi Kleen [this message]
2010-06-07 8:17 ` Mitchell Erblich
2010-06-09 9:22 ` Xin, Xiaohui
2010-06-09 8:48 ` Xin, Xiaohui
2010-06-08 5:27 ` Herbert Xu
2010-06-09 9:54 ` Xin, Xiaohui
2010-06-11 5:21 ` Herbert Xu
2010-06-12 9:31 ` Xin, Xiaohui
2010-06-13 8:58 ` Xin, Xiaohui
2010-06-17 11:21 ` Herbert Xu
2010-06-18 5:26 ` Xin, Xiaohui
2010-06-18 5:59 ` Herbert Xu
2010-06-18 7:14 ` Xin, Xiaohui
2010-06-18 7:45 ` Herbert Xu
2010-06-20 10:06 ` Michael S. Tsirkin
2010-06-20 10:32 ` Herbert Xu
2010-06-20 10:39 ` Michael S. Tsirkin
2010-06-20 11:02 ` Herbert Xu
2010-06-20 11:11 ` Michael S. Tsirkin
2010-06-20 11:36 ` Herbert Xu
2010-06-20 11:47 ` Michael S. Tsirkin
2010-06-20 11:59 ` Herbert Xu
2010-06-20 12:48 ` Michael S. Tsirkin
2010-06-20 15:19 ` Ben Hutchings
2010-06-23 8:09 ` Dong, Eddie
2010-06-23 9:52 ` Herbert Xu
2010-06-23 10:05 ` Dong, Eddie
2010-06-24 10:08 ` Herbert Xu
2010-06-25 1:03 ` Dong, Eddie
2010-06-25 11:06 ` Michael S. Tsirkin
2010-06-27 6:14 ` Herbert Xu
2010-06-28 9:56 ` Xin, Xiaohui
2010-06-28 10:00 ` Michael S. Tsirkin
2010-07-03 9:12 ` Herbert Xu
2010-06-25 2:07 ` Xin, Xiaohui
2010-06-17 11:20 ` Herbert Xu
2010-06-09 8:29 ` Xin, Xiaohui
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=87pr03gu1c.fsf@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.hengli.com.au \
--cc=jdike@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
--cc=xiaohui.xin@intel.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