From: Wei Liu <wei.liu2@citrix.com>
To: Zoltan Kiss <zoltan.kiss@citrix.com>
Cc: ian.campbell@citrix.com, wei.liu2@citrix.com,
xen-devel@lists.xenproject.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, jonathan.davies@citrix.com,
"Roger Pau Monné" <roger.pau@citrix.com>,
"David Vrabel" <david.vrabel@citrix.com>
Subject: Re: [PATCH net-next v3 1/9] xen-netback: Introduce TX grant map definitions
Date: Thu, 9 Jan 2014 15:30:10 +0000 [thread overview]
Message-ID: <20140109153010.GE12164@zion.uk.xensource.com> (raw)
In-Reply-To: <1389139818-24458-2-git-send-email-zoltan.kiss@citrix.com>
On Wed, Jan 08, 2014 at 12:10:10AM +0000, Zoltan Kiss wrote:
> This patch contains the new definitions necessary for grant mapping.
>
> v2:
> - move unmapping to separate thread. The NAPI instance has to be scheduled
> even from thread context, which can cause huge delays
> - that causes unfortunately bigger struct xenvif
> - store grant handle after checking validity
>
> v3:
> - fix comment in xenvif_tx_dealloc_action()
> - call unmap hypercall directly instead of gnttab_unmap_refs(), which does
> unnecessary m2p_override. Also remove pages_to_[un]map members
Is it worthy to have another function call
gnttab_unmap_refs_no_m2p_override in Xen core driver, or just add a
parameter to control wether we need to touch m2p_override? I *think* it
will benefit block driver as well?
(CC Roger and David for input)
> - BUG() if grant_tx_handle corrupted
>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>
> ---
[...]
>
> #define XENVIF_QUEUE_LENGTH 32
> #define XENVIF_NAPI_WEIGHT 64
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index addfe1d1..7c241f9 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -771,6 +771,19 @@ static struct page *xenvif_alloc_page(struct xenvif *vif,
> return page;
> }
>
> +static inline void xenvif_tx_create_gop(struct xenvif *vif, u16 pending_idx,
> + struct xen_netif_tx_request *txp,
> + struct gnttab_map_grant_ref *gop)
Indentation.
> +{
> + gnttab_set_map_op(gop, idx_to_kaddr(vif, pending_idx),
> + GNTMAP_host_map | GNTMAP_readonly,
> + txp->gref, vif->domid);
> +
> + memcpy(&vif->pending_tx_info[pending_idx].req, txp,
> + sizeof(*txp));
> +
> +}
> +
[...]
> +void xenvif_zerocopy_callback(struct ubuf_info *ubuf, bool zerocopy_success)
> +{
> + unsigned long flags;
> + pending_ring_idx_t index;
> + u16 pending_idx = ubuf->desc;
> + struct pending_tx_info *temp =
> + container_of(ubuf, struct pending_tx_info, callback_struct);
> + struct xenvif *vif =
> + container_of(temp - pending_idx, struct xenvif,
> + pending_tx_info[0]);
Indentation.
> +
> + spin_lock_irqsave(&vif->dealloc_lock, flags);
> + do {
> + pending_idx = ubuf->desc;
> + ubuf = (struct ubuf_info *) ubuf->ctx;
> + index = pending_index(vif->dealloc_prod);
> + vif->dealloc_ring[index] = pending_idx;
> + /* Sync with xenvif_tx_action_dealloc:
xenvif_tx_dealloc_action I suppose.
> + * insert idx then incr producer.
> + */
> + smp_wmb();
> + vif->dealloc_prod++;
> + } while (ubuf);
> + wake_up(&vif->dealloc_wq);
> + spin_unlock_irqrestore(&vif->dealloc_lock, flags);
> +}
> +
> +static inline void xenvif_tx_dealloc_action(struct xenvif *vif)
> +{
> + struct gnttab_unmap_grant_ref *gop;
> + pending_ring_idx_t dc, dp;
> + u16 pending_idx, pending_idx_release[MAX_PENDING_REQS];
> + unsigned int i = 0;
> +
> + dc = vif->dealloc_cons;
> + gop = vif->tx_unmap_ops;
> +
> + /* Free up any grants we have finished using */
> + do {
> + dp = vif->dealloc_prod;
> +
> + /* Ensure we see all indices enqueued by all
> + * xenvif_zerocopy_callback().
> + */
> + smp_rmb();
> +
> + while (dc != dp) {
> + pending_idx =
> + vif->dealloc_ring[pending_index(dc++)];
> +
> + /* Already unmapped? */
> + if (vif->grant_tx_handle[pending_idx] ==
> + NETBACK_INVALID_HANDLE) {
> + netdev_err(vif->dev,
> + "Trying to unmap invalid handle! "
> + "pending_idx: %x\n", pending_idx);
> + continue;
You seemed to miss the BUG_ON we discussed?
See thread starting <52AF1A84.3090304@citrix.com>.
Wei.
> + }
> +
> + pending_idx_release[gop-vif->tx_unmap_ops] =
> + pending_idx;
> + gnttab_set_unmap_op(gop,
> + idx_to_kaddr(vif, pending_idx),
> + GNTMAP_host_map,
> + vif->grant_tx_handle[pending_idx]);
> + vif->grant_tx_handle[pending_idx] =
> + NETBACK_INVALID_HANDLE;
> + ++gop;
> + }
> +
next prev parent reply other threads:[~2014-01-09 15:30 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-08 0:10 [PATCH net-next v2 0/9] xen-netback: TX grant mapping with SKBTX_DEV_ZEROCOPY instead of copy Zoltan Kiss
2014-01-08 0:10 ` [PATCH net-next v3 1/9] xen-netback: Introduce TX grant map definitions Zoltan Kiss
2014-01-08 1:29 ` David Miller
2014-01-08 14:08 ` Zoltan Kiss
2014-01-09 15:30 ` Wei Liu [this message]
2014-01-09 15:42 ` David Vrabel
2014-01-09 17:28 ` [Xen-devel] " Stefano Stabellini
2014-01-09 17:46 ` David Vrabel
2014-01-09 18:09 ` Stefano Stabellini
2014-01-09 18:23 ` David Vrabel
2014-01-09 15:49 ` Roger Pau Monné
2014-01-09 19:53 ` Zoltan Kiss
2014-01-08 0:10 ` [PATCH net-next v3 2/9] xen-netback: Change TX path from grant copy to mapping Zoltan Kiss
2014-01-09 15:30 ` Wei Liu
2014-01-10 11:35 ` Zoltan Kiss
2014-01-10 11:45 ` Wei Liu
2014-01-10 13:16 ` Wei Liu
2014-01-10 15:24 ` Zoltan Kiss
2014-01-10 16:02 ` [Xen-devel] " David Vrabel
2014-01-10 16:08 ` Wei Liu
2014-01-12 23:19 ` Zoltan Kiss
2014-01-08 0:10 ` [PATCH net-next v3 3/9] xen-netback: Remove old TX grant copy definitons and fix indentations Zoltan Kiss
2014-01-08 0:10 ` [PATCH net-next v3 4/9] xen-netback: Change RX path for mapped SKB fragments Zoltan Kiss
2014-01-08 0:10 ` [PATCH net-next v3 5/9] xen-netback: Add stat counters for zerocopy Zoltan Kiss
2014-01-08 0:10 ` [PATCH net-next v3 6/9] xen-netback: Handle guests with too many frags Zoltan Kiss
2014-01-08 2:12 ` Eric Dumazet
2014-01-08 13:49 ` Zoltan Kiss
2014-01-08 13:54 ` Eric Dumazet
2014-01-08 14:13 ` Zoltan Kiss
2014-01-08 0:10 ` [PATCH net-next v3 7/9] xen-netback: Add stat counters for frag_list skbs Zoltan Kiss
2014-01-08 0:10 ` [PATCH net-next v3 8/9] xen-netback: Timeout packets in RX path Zoltan Kiss
2014-01-08 21:34 ` Zoltan Kiss
2014-01-09 9:20 ` Paul Durrant
2014-01-13 0:20 ` Zoltan Kiss
2014-01-13 9:53 ` Paul Durrant
2014-01-08 0:10 ` [PATCH net-next v3 9/9] xen-netback: Aggregate TX unmap operations Zoltan Kiss
2014-01-08 0:16 ` [PATCH net-next v2 0/9] xen-netback: TX grant mapping with SKBTX_DEV_ZEROCOPY instead of copy Zoltan Kiss
2014-01-08 14:43 ` Wei Liu
2014-01-08 14:44 ` Zoltan Kiss
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=20140109153010.GE12164@zion.uk.xensource.com \
--to=wei.liu2@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=jonathan.davies@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
--cc=zoltan.kiss@citrix.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
all inboxes | Powered by JetHome®