From: "Michael S. Tsirkin" <mst@redhat.com>
To: Shirley Ma <mashirle@us.ibm.com>
Cc: David Miller <davem@davemloft.net>,
Eric Dumazet <eric.dumazet@gmail.com>,
Avi Kivity <avi@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 3/8] Add userspace buffers support in skb
Date: Mon, 2 May 2011 13:53:48 +0300 [thread overview]
Message-ID: <20110502105348.GA21706@redhat.com> (raw)
In-Reply-To: <1303328877.19336.28.camel@localhost.localdomain>
On Wed, Apr 20, 2011 at 12:47:57PM -0700, Shirley Ma wrote:
> This patch adds userspace buffers support in skb. A new struct
> skb_ubuf_info is needed to maintain the userspace buffers argument
> and index, a callback is used to notify userspace to release the
> buffers once lower device has done DMA (Last reference to that skb
> has gone).
>
> Signed-off-by: Shirley Ma <xma@us.ibm.com>
> ---
>
> include/linux/skbuff.h | 14 ++++++++++++++
> net/core/skbuff.c | 15 ++++++++++++++-
> 2 files changed, 28 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index d0ae90a..47a187b 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -189,6 +189,16 @@ enum {
> SKBTX_DRV_NEEDS_SK_REF = 1 << 3,
> };
>
> +/* The callback notifies userspace to release buffers when skb DMA is done in
> + * lower device, the desc is used to track userspace buffer index.
> + */
> +struct skb_ubuf_info {
> + /* support buffers allocation from userspace */
> + void (*callback)(struct sk_buff *);
> + void *arg;
> + size_t desc;
> +};
> +
> /* This data is invariant across clones and lives at
> * the end of the header data, ie. at skb->end.
> */
> @@ -211,6 +221,10 @@ struct skb_shared_info {
> /* Intermediate layers must ensure that destructor_arg
> * remains valid until skb destructor */
> void * destructor_arg;
> +
> + /* DMA mapping from/to userspace buffers */
> + struct skb_ubuf_info ubuf;
> +
> /* must be last field, see pskb_expand_head() */
> skb_frag_t frags[MAX_SKB_FRAGS];
> };
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 7ebeed0..822c07d 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -210,6 +210,8 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
> shinfo = skb_shinfo(skb);
> memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
> atomic_set(&shinfo->dataref, 1);
> + shinfo->ubuf.callback = NULL;
> + shinfo->ubuf.arg = NULL;
> kmemcheck_annotate_variable(shinfo->destructor_arg);
>
> if (fclone) {
> @@ -327,7 +329,15 @@ static void skb_release_data(struct sk_buff *skb)
> for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
> put_page(skb_shinfo(skb)->frags[i].page);
> }
> -
> + /*
> + * if skb buf is from userspace, we need to notify the caller
> + * the lower device DMA has done;
> + */
> + if (skb_shinfo(skb)->ubuf.callback) {
> + skb_shinfo(skb)->ubuf.callback(skb);
> + skb_shinfo(skb)->ubuf.callback = NULL;
> + skb_shinfo(skb)->ubuf.arg = NULL;
> + }
> if (skb_has_frag_list(skb))
> skb_drop_fraglist(skb);
>
We probably don't need to touch arg if callback is NULL?
> @@ -480,6 +490,9 @@ bool skb_recycle_check(struct sk_buff *skb, int skb_size)
> if (irqs_disabled())
> return false;
>
> + if (shinfo->ubuf.callback)
> + return false;
> +
> if (skb_is_nonlinear(skb) || skb->fclone != SKB_FCLONE_UNAVAILABLE)
> return false;
This is not the only API unsupported for these skbs, is it?
Probably need to check and fail there as well.
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-05-02 10:54 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-20 19:36 [PATCH V3 0/8] macvtap/vhost TX zero copy support Shirley Ma
2011-04-20 19:42 ` [PATCH V3 1/8] Add a new sock zerocopy flag Shirley Ma
2011-04-20 19:44 ` [PATCH V3 2/8] Add a new zerocopy device flag Shirley Ma
2011-04-20 19:48 ` Ben Hutchings
2011-04-20 20:05 ` Shirley Ma
2011-04-20 20:09 ` Shirley Ma
2011-04-20 20:24 ` Dimitris Michailidis
2011-04-20 20:28 ` Shirley Ma
2011-04-20 20:30 ` Shirley Ma
2011-05-02 10:42 ` Michael S. Tsirkin
2011-05-02 18:47 ` Shirley Ma
2011-05-02 19:53 ` Michael S. Tsirkin
2011-05-03 17:42 ` Shirley Ma
2011-05-03 20:11 ` Shirley Ma
2011-04-20 19:47 ` [PATCH V3 3/8] Add userspace buffers support in skb Shirley Ma
2011-05-02 10:53 ` Michael S. Tsirkin [this message]
2011-05-03 17:36 ` Shirley Ma
2011-04-20 20:07 ` [PATCH V3 4/8] vhost TX zero copy support Shirley Ma
2011-04-20 20:12 ` [PATCH V3 0/8] macvtap/vhost " Shirley Ma
2011-04-20 20:13 ` [PATCH V3 5/8] Enable cxgb3 to support zerocopy Shirley Ma
2011-04-20 20:52 ` Dimitris Michailidis
2011-04-20 20:58 ` Shirley Ma
2011-04-20 21:15 ` Shirley Ma
2011-04-20 20:15 ` [PATCH V3 7/8] Enable ixgbe " Shirley Ma
2011-04-20 20:17 ` [PATCH V3 8/8] Enable benet " Shirley Ma
2011-04-20 20:27 ` [PATCH V3 6/8] macvtap/vhost TX zero copy support Shirley Ma
2011-05-02 18:35 ` Shirley Ma
2011-04-21 14:29 ` [PATCH V3 0/8] " Jon Mason
2011-04-22 17:31 ` Shirley Ma
2011-04-22 17:52 ` Shirley Ma
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=20110502105348.GA21706@redhat.com \
--to=mst@redhat.com \
--cc=arnd@arndb.de \
--cc=avi@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mashirle@us.ibm.com \
--cc=netdev@vger.kernel.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.