From: Paul Durrant <paul.durrant@citrix.com>
To: <netdev@vger.kernel.org>, <xen-devel@lists.xenproject.org>
Cc: Paul Durrant <paul.durrant@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
Wei Liu <wei.liu2@citrix.com>
Subject: [PATCH net-next 3/8] xen-netback: support multiple extra info segments passed from frontend
Date: Wed, 21 Oct 2015 11:36:20 +0100 [thread overview]
Message-ID: <1445423785-4654-4-git-send-email-paul.durrant@citrix.com> (raw)
In-Reply-To: <1445423785-4654-1-git-send-email-paul.durrant@citrix.com>
The code does not currently allow a frontend to pass multiple extra info
segments to the backend in a tx request. A subsequent patch in this series
needs this functionality so it is added here, without any other
modification, for better bisectability.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
drivers/net/xen-netback/common.h | 1 +
drivers/net/xen-netback/netback.c | 27 +++++++++++++++++++--------
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 136ace1..ce40bd7 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -51,6 +51,7 @@ typedef unsigned int pending_ring_idx_t;
struct pending_tx_info {
struct xen_netif_tx_request req; /* tx request */
+ unsigned int extra_count; /* Number of extras following the request */
/* Callback data for released SKBs. The callback is always
* xenvif_zerocopy_callback, desc contains the pending_idx, which is
* also an index in pending_tx_info array. It is initialized in
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 27c6779..9f0c9f5 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -95,7 +95,8 @@ static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx,
static void make_tx_response(struct xenvif_queue *queue,
struct xen_netif_tx_request *txp,
- s8 st);
+ s8 st,
+ unsigned int extra_count);
static void push_tx_responses(struct xenvif_queue *queue);
static inline int tx_work_todo(struct xenvif_queue *queue);
@@ -646,7 +647,7 @@ static void xenvif_tx_err(struct xenvif_queue *queue,
do {
spin_lock_irqsave(&queue->response_lock, flags);
- make_tx_response(queue, txp, XEN_NETIF_RSP_ERROR);
+ make_tx_response(queue, txp, XEN_NETIF_RSP_ERROR, 0);
push_tx_responses(queue);
spin_unlock_irqrestore(&queue->response_lock, flags);
if (cons == end)
@@ -1292,7 +1293,8 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
make_tx_response(queue, &txreq,
(ret == 0) ?
XEN_NETIF_RSP_OKAY :
- XEN_NETIF_RSP_ERROR);
+ XEN_NETIF_RSP_ERROR,
+ 1);
push_tx_responses(queue);
continue;
}
@@ -1303,7 +1305,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
extra = &extras[XEN_NETIF_EXTRA_TYPE_MCAST_DEL - 1];
xenvif_mcast_del(queue->vif, extra->u.mcast.addr);
- make_tx_response(queue, &txreq, XEN_NETIF_RSP_OKAY);
+ make_tx_response(queue, &txreq, XEN_NETIF_RSP_OKAY, 1);
push_tx_responses(queue);
continue;
}
@@ -1411,6 +1413,9 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
sizeof(txreq));
}
+ if (extras[XEN_NETIF_EXTRA_TYPE_GSO - 1].type)
+ queue->pending_tx_info[pending_idx].extra_count++;
+
queue->pending_cons++;
gop = xenvif_get_requests(queue, skb, txfrags, gop,
@@ -1749,7 +1754,9 @@ static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx,
spin_lock_irqsave(&queue->response_lock, flags);
- make_tx_response(queue, &pending_tx_info->req, status);
+ make_tx_response(queue, &pending_tx_info->req, status,
+ pending_tx_info->extra_count);
+ memset(pending_tx_info, 0, sizeof(*pending_tx_info));
/* Release the pending index before pusing the Tx response so
* its available before a new Tx request is pushed by the
@@ -1766,7 +1773,8 @@ static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx,
static void make_tx_response(struct xenvif_queue *queue,
struct xen_netif_tx_request *txp,
- s8 st)
+ s8 st,
+ unsigned int extra_count)
{
RING_IDX i = queue->tx.rsp_prod_pvt;
struct xen_netif_tx_response *resp;
@@ -1775,8 +1783,11 @@ static void make_tx_response(struct xenvif_queue *queue,
resp->id = txp->id;
resp->status = st;
- if (txp->flags & XEN_NETTXF_extra_info)
- RING_GET_RESPONSE(&queue->tx, ++i)->status = XEN_NETIF_RSP_NULL;
+ WARN_ON(!(txp->flags & XEN_NETTXF_extra_info) != !extra_count);
+
+ while (extra_count-- != 0)
+ RING_GET_RESPONSE(&queue->tx, ++i)->status =
+ XEN_NETIF_RSP_NULL;
queue->tx.rsp_prod_pvt = ++i;
}
--
2.1.4
next prev parent reply other threads:[~2015-10-21 10:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-21 10:36 [PATCH net-next 0/8] xen-netback/core: packet hashing Paul Durrant
2015-10-21 10:36 ` [PATCH net-next 1/8] xen-netback: re-import canonical netif header Paul Durrant
2015-10-26 17:05 ` Wei Liu
2015-10-21 10:36 ` [PATCH net-next 2/8] xen-netback: remove GSO information from xenvif_rx_meta Paul Durrant
2015-10-26 17:05 ` Wei Liu
2015-10-21 10:36 ` Paul Durrant [this message]
2015-10-26 17:05 ` [PATCH net-next 3/8] xen-netback: support multiple extra info segments passed from frontend Wei Liu
2015-10-21 10:36 ` [PATCH net-next 4/8] xen-netback: accept an L4 or L3 skb hash value from the frontend Paul Durrant
2015-10-26 17:05 ` Wei Liu
2015-10-21 10:36 ` [PATCH net-next 5/8] skbuff: store hash type in socket buffer Paul Durrant
2015-10-21 10:36 ` [PATCH net-next 6/8] xen-netback: pass an L4 or L3 skb hash value to the frontend Paul Durrant
2015-10-26 17:05 ` Wei Liu
2015-10-21 10:36 ` [PATCH net-next 7/8] xen-netback: add support for a multi-queue hash mapping table Paul Durrant
2015-10-26 17:05 ` Wei Liu
2015-10-21 10:36 ` [PATCH net-next 8/8] xen-netback: add support for toeplitz hashing Paul Durrant
2015-10-26 17:05 ` Wei Liu
2015-10-22 14:15 ` [PATCH net-next 0/8] xen-netback/core: packet hashing David Miller
2015-10-24 11:55 ` David Miller
2015-10-26 10:38 ` [Xen-devel] " David Vrabel
2015-10-26 12:09 ` David Miller
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=1445423785-4654-4-git-send-email-paul.durrant@citrix.com \
--to=paul.durrant@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=netdev@vger.kernel.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.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).