mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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;
> +		}
> +


  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®