netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: <xen-devel@lists.xen.org>, <netdev@vger.kernel.org>,
	<ian.campbell@citrix.com>, <konrad.wilk@oracle.com>,
	<annie.li@oracle.com>
Subject: Re: [Xen-devel] [PATCH 5/8] netback: multi-page ring support
Date: Tue, 5 Mar 2013 10:41:41 +0000	[thread overview]
Message-ID: <5135CBE5.2040902@citrix.com> (raw)
In-Reply-To: <1360944010-15336-6-git-send-email-wei.liu2@citrix.com>

On 15/02/13 16:00, Wei Liu wrote:
> [nothing]

You need to describe the protocol used to negotiate this.  What happens
when a frontend without such support connects to a backend with support?
And vice-versa?

> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -45,6 +45,12 @@
>  #include <xen/grant_table.h>
>  #include <xen/xenbus.h>
>  
> +#define NETBK_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> +#define NETBK_MAX_RING_PAGES      (1U << NETBK_MAX_RING_PAGE_ORDER)
> +
> +#define NETBK_MAX_TX_RING_SIZE XEN_NETIF_TX_RING_SIZE(NETBK_MAX_RING_PAGES)
> +#define NETBK_MAX_RX_RING_SIZE XEN_NETIF_RX_RING_SIZE(NETBK_MAX_RING_PAGES)

See comment below.

> @@ -105,15 +113,19 @@ static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
>  	return to_xenbus_device(vif->dev->dev.parent);
>  }
>  
> -#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> -#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> +#define XEN_NETIF_TX_RING_SIZE(_nr_pages)		\
> +	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))

Ring size is no longer const.

Would these be better as inline functions with a struct xenvif parameter?

Would need to fixup the MAX_XX_RING_SIZE macros above.

> index db638e1..fa4d46d 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -305,10 +305,16 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
>  	return vif;
>  }
>  
> -int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
> -		   unsigned long rx_ring_ref, unsigned int evtchn)
> +int xenvif_connect(struct xenvif *vif,
> +		   unsigned long *tx_ring_ref, unsigned int tx_ring_ref_count,
> +		   unsigned long *rx_ring_ref, unsigned int rx_ring_ref_count,
> +		   unsigned int evtchn)
>  {
>  	int err = -ENOMEM;
> +	void *addr;
> +	struct xen_netif_tx_sring *txs;
> +	struct xen_netif_rx_sring *rxs;
> +	int tmp[NETBK_MAX_RING_PAGES], i;

grant_ref_t, and elsewhere probably -- I didn't check.

> @@ -382,7 +413,8 @@ void xenvif_disconnect(struct xenvif *vif)
>  
>  	unregister_netdev(vif->dev);
>  
> -	xen_netbk_unmap_frontend_rings(vif);
> +	xen_netbk_unmap_frontend_rings(vif, (void *)vif->tx.sring);
> +	xen_netbk_unmap_frontend_rings(vif, (void *)vif->rx.sring);

Don't need the casts here.

> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -47,6 +47,19 @@
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/page.h>
>  
> +unsigned int MODPARM_netback_max_rx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
> +module_param_named(netback_max_rx_ring_page_order,
> +		   MODPARM_netback_max_rx_ring_page_order, uint, 0);

Please don't prefix new module parameters with "netback",
"max_rx_ring_page_order" is fine.

> +MODULE_PARM_DESC(netback_max_rx_ring_page_order,
> +		 "Maximum supported receiver ring page order");
> +
> +unsigned int MODPARM_netback_max_tx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
> +module_param_named(netback_max_tx_ring_page_order,
> +		   MODPARM_netback_max_tx_ring_page_order, uint, 0);

Ditto.

> +MODULE_PARM_DESC(netback_max_tx_ring_page_order,
> +		 "Maximum supported transmitter ring page order");
> +
> +
[...]
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
[...]
> +	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
> +			   &tx_ring_order);
> +	if (err < 0) {
> +		tx_ring_order = 0;
> +
> +		err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-ref", "%lu",
> +				   &tx_ring_ref[0]);
> +		if (err < 0) {
> +			xenbus_dev_fatal(dev, err, "reading %s/tx-ring-ref",
> +					 dev->otherend);
> +			return err;
> +		}
> +	} else {
> +		unsigned int i;
> +
> +		if (tx_ring_order > MODPARM_netback_max_tx_ring_page_order) {
> +			err = -EINVAL;
> +			xenbus_dev_fatal(dev, err,
> +					 "%s/tx-ring-page-order too big",
> +					 dev->otherend);
> +			return err;
> +		}
> +
> +		for (i = 0; i < (1U << tx_ring_order); i++) {
> +			char ring_ref_name[sizeof("tx-ring-ref") + 2];
> +
> +			snprintf(ring_ref_name, sizeof(ring_ref_name),
> +				 "tx-ring-ref%u", i);
> +
> +			err = xenbus_scanf(XBT_NIL, dev->otherend,
> +					   ring_ref_name, "%lu",
> +					   &tx_ring_ref[i]);
> +			if (err < 0) {
> +				xenbus_dev_fatal(dev, err,
> +						 "reading %s/%s",
> +						 dev->otherend,
> +						 ring_ref_name);
> +				return err;
> +			}
> +		}

Refactor this whole if/else block and the similar code below for rx into
a common library function?

It will be useful for blkback etc. as well.

> @@ -454,11 +566,28 @@ static int connect_rings(struct backend_info *be)
>  	vif->csum = !val;
>  
>  	/* Map the shared frame, irq etc. */
> -	err = xenvif_connect(vif, tx_ring_ref, rx_ring_ref, evtchn);
> +	err = xenvif_connect(vif, tx_ring_ref, (1U << tx_ring_order),
> +			     rx_ring_ref, (1U << rx_ring_order),
> +			     evtchn);
>  	if (err) {
> +		/* construct 1 2 3 / 4 5 6 */

This comment doesn't make sense to me.

David

  parent reply	other threads:[~2013-03-05 10:41 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-15 16:00 [PATCH 0/8] Bugfix and mechanical works for Xen network driver Wei Liu
2013-02-15 16:00 ` [PATCH 1/8] netback: don't bind kthread to cpu Wei Liu
2013-03-04 20:51   ` Konrad Rzeszutek Wilk
2013-03-05 13:30     ` Wei Liu
2013-03-05 13:56       ` [Xen-devel] " Konrad Rzeszutek Wilk
2013-03-05 14:04         ` Wei Liu
2013-03-05 14:42         ` David Vrabel
2013-03-05 15:52           ` Konrad Rzeszutek Wilk
2013-02-15 16:00 ` [PATCH 2/8] netback: add module unload function Wei Liu
2013-03-04 20:55   ` [Xen-devel] " Konrad Rzeszutek Wilk
2013-03-04 20:58     ` Andrew Cooper
2013-03-05 13:30     ` Wei Liu
2013-03-04 21:58   ` Stephen Hemminger
2013-03-05 13:30     ` Wei Liu
2013-02-15 16:00 ` [PATCH 3/8] netback: get/put module along with vif connect/disconnect Wei Liu
2013-03-04 20:56   ` Konrad Rzeszutek Wilk
2013-03-05 10:02   ` [Xen-devel] " David Vrabel
2013-03-05 13:30     ` Wei Liu
2013-03-05 14:07       ` David Vrabel
2013-03-05 14:44         ` Wei Liu
2013-03-05 15:53         ` Konrad Rzeszutek Wilk
2013-02-15 16:00 ` [PATCH 4/8] xenbus_client: Extend interface to support multi-page ring Wei Liu
2013-02-15 16:17   ` [Xen-devel] " Jan Beulich
2013-02-15 16:33     ` Wei Liu
2013-02-15 16:59       ` Jan Beulich
2013-02-15 17:01         ` Wei Liu
2013-03-04 21:12   ` Konrad Rzeszutek Wilk
2013-03-05 10:25   ` [Xen-devel] " David Vrabel
2013-02-15 16:00 ` [PATCH 5/8] netback: multi-page ring support Wei Liu
2013-03-04 21:00   ` [Xen-devel] " Konrad Rzeszutek Wilk
2013-03-05 10:41   ` David Vrabel [this message]
2013-02-15 16:00 ` [PATCH 6/8] netfront: " Wei Liu
2013-02-26  6:52   ` ANNIE LI
2013-02-26 12:35     ` Wei Liu
2013-02-27  7:39       ` ANNIE LI
2013-02-27 15:49         ` Wei Liu
2013-02-28  5:19           ` ANNIE LI
2013-02-28 11:02             ` Wei Liu
2013-02-28 12:55               ` annie li
2013-03-04 21:16   ` Konrad Rzeszutek Wilk
2013-02-15 16:00 ` [PATCH 7/8] netback: split event channels support Wei Liu
2013-03-04 21:22   ` Konrad Rzeszutek Wilk
2013-02-15 16:00 ` [PATCH 8/8] netfront: " Wei Liu
2013-03-04 21:24   ` Konrad Rzeszutek Wilk
2013-02-26  3:07 ` [Xen-devel] [PATCH 0/8] Bugfix and mechanical works for Xen network driver ANNIE LI
2013-02-26 11:33   ` Wei Liu

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=5135CBE5.2040902@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=annie.li@oracle.com \
    --cc=ian.campbell@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=netdev@vger.kernel.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).