The error handling for skb's with frag_list was completely wrong, it caused
double unmap attempts to happen if the error was on the first skb. Move it to
the right place in the loop.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Reported-by: Armin Zentai armin.zen...@ezit.hu
Cc:
The error handling for skb's with frag_list was completely wrong, it caused
double unmap attempts to happen if the error was on the first skb. Move it to
the right place in the loop.
Signed-off-by: Zoltan Kiss
Reported-by: Armin Zentai
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
On 18/07/14 16:24, Wei Liu wrote:
On Thu, Jul 17, 2014 at 08:09:49PM +0100, Zoltan Kiss wrote:
The error handling for skb's with frag_list was completely wrong, it caused
double unmap attempts to happen if the error was on the first skb. Move it to
the right place in the loop.
Signed-off-by:
On Thu, Jul 17, 2014 at 08:09:49PM +0100, Zoltan Kiss wrote:
> The error handling for skb's with frag_list was completely wrong, it caused
> double unmap attempts to happen if the error was on the first skb. Move it to
> the right place in the loop.
>
> Signed-off-by: Zoltan Kiss
> Reported-by:
On 18/07/14 16:24, Wei Liu wrote:
On Thu, Jul 17, 2014 at 08:09:49PM +0100, Zoltan Kiss wrote:
The error handling for skb's with frag_list was completely wrong, it caused
double unmap attempts to happen if the error was on the first skb. Move it to
the right place in the loop.
Signed-off-by:
The error handling for skb's with frag_list was completely wrong, it caused
double unmap attempts to happen if the error was on the first skb. Move it to
the right place in the loop.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Reported-by: Armin Zentai armin.zen...@ezit.hu
Cc:
On Thu, Jul 17, 2014 at 08:09:49PM +0100, Zoltan Kiss wrote:
The error handling for skb's with frag_list was completely wrong, it caused
double unmap attempts to happen if the error was on the first skb. Move it to
the right place in the loop.
Signed-off-by: Zoltan Kiss
The error handling for skb's with frag_list was completely wrong, it caused
double unmap attempts to happen if the error was on the first skb. Move it to
the right place in the loop.
Signed-off-by: Zoltan Kiss
Reported-by: Armin Zentai
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
The error handling for skb's with frag_list was completely wrong, it caused
double unmap attempts to happen if the error was on the first skb. Move it to
the right place in the loop.
Signed-off-by: Zoltan Kiss
Reported-by: Armin Zentai
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
The error handling for skb's with frag_list was completely wrong, it caused
double unmap attempts to happen if the error was on the first skb. Move it to
the right place in the loop.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Reported-by: Armin Zentai armin.zen...@ezit.hu
Cc:
The error handling for skb's with frag_list was completely wrong, it caused
double unmap attempts to happen if the error was on the first skb. Move it to
the right place in the loop.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Reported-by: Armin Zentai armin.zen...@ezit.hu
Cc:
Dear Sir/Madam,
I am directed to inform you that a Grant Award have been approved by the United
Nations Development Programmed (UNDP) under your watch. Kindly establish
communication to know more about your approval details with the contact
information
Sincerely,
Mr. Jan Knutsson
Dear Sir/Madam,
I am directed to inform you that a Grant Award have been approved by the United
Nations Development Programmed (UNDP) under your watch. Kindly establish
communication to know more about your approval details with the contact
information
Sincerely,
Mr. Jan Knutsson
Attention,
The Ford Foundation has awarded the sum of 1.5m USD as a Grant Donation to you
please contacts Email: grantawa...@ford-foundation.org with your details.Thanks
Regards
Ford Foundation Orphanage
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
Attention,
The Ford Foundation has awarded the sum of 1.5m USD as a Grant Donation to you
please contacts Email: grantawa...@ford-foundation.org with your details.Thanks
Regards
Ford Foundation Orphanage
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Thu, 2014-04-03 at 10:48 +0100, David Vrabel wrote:
> On 03/04/14 09:12, Paul Durrant wrote:
> > Zoltan Kiss wrote:
> >>
> >> Create helper functions for grant copy operations and use them in netback.
> >>
> [...]
> >> --- a/drivers/net/xen-netb
On Thu, 2014-04-03 at 10:48 +0100, David Vrabel wrote:
On 03/04/14 09:12, Paul Durrant wrote:
Zoltan Kiss wrote:
Create helper functions for grant copy operations and use them in netback.
[...]
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
From: Zoltan Kiss
Date: Wed, 2 Apr 2014 18:04:58 +0100
> An old inefficiency of the TX path that we are grant mapping the first slot,
> and then copy the header part to the linear area. Instead, doing a grant copy
> for that header straight on is more reasonable. Especiall
On 03/04/14 09:12, Paul Durrant wrote:
> Zoltan Kiss wrote:
>>
>> Create helper functions for grant copy operations and use them in netback.
>>
[...]
>> --- a/drivers/net/xen-netback/netback.c
>> +++ b/drivers/net/xen-netback/netback.c
>> @@ -275,23 +275
ernel.org;
> > Jonathan Davies; Zoltan Kiss
> > Subject: [PATCH net-next v3 2/2] xen-netback: Grant copy the header
> > instead of map and memcpy
> >
> > An old inefficiency of the TX path that we are grant mapping the first slot,
> > and then copy th
.org; linux-
> ker...@vger.kernel.org; Jonathan Davies; Zoltan Kiss
> Subject: [PATCH] grant-table, xen-netback: Introduce helper functions for
> grant copy operations
>
> Create helper functions for grant copy operations and use them in netback.
>
> Signed-off-by: Zoltan Kiss
> ---
> d
> -Original Message-
> From: Zoltan Kiss
> Sent: 02 April 2014 18:05
> To: Ian Campbell; Wei Liu; xen-de...@lists.xenproject.org
> Cc: Paul Durrant; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Jonathan Davies; Zoltan Kiss
> Subject: [PATCH net-next v3 2/
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Wed, 2 Apr 2014 18:04:58 +0100
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part to the linear area. Instead, doing a grant copy
for that header straight on is more reasonable. Especially
-Original Message-
From: Zoltan Kiss
Sent: 02 April 2014 18:05
To: Ian Campbell; Wei Liu; xen-de...@lists.xenproject.org
Cc: Paul Durrant; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
Jonathan Davies; Zoltan Kiss
Subject: [PATCH net-next v3 2/2] xen-netback: Grant copy
; Jonathan Davies; Zoltan Kiss
Subject: [PATCH] grant-table, xen-netback: Introduce helper functions for
grant copy operations
Create helper functions for grant copy operations and use them in netback.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
---
diff --git a/drivers/net/xen-netback
Subject: [PATCH net-next v3 2/2] xen-netback: Grant copy the header
instead of map and memcpy
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part to the linear area. Instead, doing a grant
copy
for that header straight on is more
On 03/04/14 09:12, Paul Durrant wrote:
Zoltan Kiss wrote:
Create helper functions for grant copy operations and use them in netback.
[...]
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -275,23 +275,29 @@ static void xenvif_gop_frag_copy(struct xenvif
Create helper functions for grant copy operations and use them in netback.
Signed-off-by: Zoltan Kiss
---
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 8d3bb4a..874df60 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part to the linear area. Instead, doing a grant copy
for that header straight on is more reasonable. Especially because there are
ongoing efforts to make Xen avoiding TLB flush after unmap when
On 02/04/14 14:11, David Vrabel wrote:
On 01/04/14 12:40, Ian Campbell wrote:
On Mon, 2014-03-31 at 16:08 +0100, Zoltan Kiss wrote:
__skb_put(skb, data_len);
+ vif->tx_copy_ops[*copy_ops].source.u.ref = txreq.gref;
+
On Wed, 2014-04-02 at 14:11 +0100, David Vrabel wrote:
> I'd be in favour of a patch that:
>
> - renamed gnttab_map_refs() to gnttab_batch_map_pages()
> - refactored it to call gnttab_batch_map().
> - added documentation
>
> But I don't see why this would be a prerequisite for this series.
No,
On 01/04/14 12:40, Ian Campbell wrote:
> On Mon, 2014-03-31 at 16:08 +0100, Zoltan Kiss wrote:
>>
>> __skb_put(skb, data_len);
>> +vif->tx_copy_ops[*copy_ops].source.u.ref = txreq.gref;
>> +vif->tx_copy_ops[*copy_ops].source.domid = vif->domid;
>> +
; nr_frags; i++, gop_map++) {
> >>int j, newerr;
> >>
> >>pending_idx = frag_get_pending_idx(>frags[i]);
> >> - tx_info = >pending_tx_info[pending_idx];
> >>
> >>/* Check error status: if okay
;> -if (unlikely(xenvif_tx_check_gop(vif, skb, _map)))
> {
> >> +if (unlikely(xenvif_tx_check_gop(vif, skb, _map,
> >> _copy))) {
> >> netdev_dbg(vif->dev, "netback grant
> failed.\n");
> >
>
, gop_map)))
{
+if (unlikely(xenvif_tx_check_gop(vif, skb, gop_map,
gop_copy))) {
netdev_dbg(vif-dev, netback grant
failed.\n);
It could have been the copy that failed. You should probably change
the error message.
I've changed it to netback grant op failed
;
pending_idx = frag_get_pending_idx(shinfo-frags[i]);
- tx_info = vif-pending_tx_info[pending_idx];
/* Check error status: if okay then remember grant handle. */
- newerr = (++gop_map)-status;
+ newerr = (gop_map)-status;
You've reworked
On 01/04/14 12:40, Ian Campbell wrote:
On Mon, 2014-03-31 at 16:08 +0100, Zoltan Kiss wrote:
__skb_put(skb, data_len);
+vif-tx_copy_ops[*copy_ops].source.u.ref = txreq.gref;
+vif-tx_copy_ops[*copy_ops].source.domid = vif-domid;
+
On Wed, 2014-04-02 at 14:11 +0100, David Vrabel wrote:
I'd be in favour of a patch that:
- renamed gnttab_map_refs() to gnttab_batch_map_pages()
- refactored it to call gnttab_batch_map().
- added documentation
But I don't see why this would be a prerequisite for this series.
No, I
On 02/04/14 14:11, David Vrabel wrote:
On 01/04/14 12:40, Ian Campbell wrote:
On Mon, 2014-03-31 at 16:08 +0100, Zoltan Kiss wrote:
__skb_put(skb, data_len);
+ vif-tx_copy_ops[*copy_ops].source.u.ref = txreq.gref;
+
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part to the linear area. Instead, doing a grant copy
for that header straight on is more reasonable. Especially because there are
ongoing efforts to make Xen avoiding TLB flush after unmap when
Create helper functions for grant copy operations and use them in netback.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
---
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 8d3bb4a..874df60 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers
>frags[i]);
- tx_info = >pending_tx_info[pending_idx];
/* Check error status: if okay then remember grant handle. */
- newerr = (++gop_map)->status;
+ newerr = (gop_map)->status;
You've reworked the handling of gop_map
if (unlikely(xenvif_tx_check_gop(vif, skb, _map))) {
+ if (unlikely(xenvif_tx_check_gop(vif, skb, _map,
_copy))) {
netdev_dbg(vif->dev, "netback grant failed.\n");
It could have been the copy that failed. You should probably change the error
message.
I've changed it
s[i]);
> - tx_info = >pending_tx_info[pending_idx];
>
> /* Check error status: if okay then remember grant handle. */
> - newerr = (++gop_map)->status;
> + newerr = (gop_map)->status;
You've reworked the handling of gop
> -Original Message-
> From: Zoltan Kiss
> Sent: 31 March 2014 16:09
> To: Ian Campbell; Wei Liu; xen-de...@lists.xenproject.org
> Cc: Paul Durrant; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Jonathan Davies; Zoltan Kiss
> Subject: [PATCH net-next v2 2/
-Original Message-
From: Zoltan Kiss
Sent: 31 March 2014 16:09
To: Ian Campbell; Wei Liu; xen-de...@lists.xenproject.org
Cc: Paul Durrant; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
Jonathan Davies; Zoltan Kiss
Subject: [PATCH net-next v2 2/2] xen-netback: Grant copy
-pending_tx_info[pending_idx];
/* Check error status: if okay then remember grant handle. */
- newerr = (++gop_map)-status;
+ newerr = (gop_map)-status;
You've reworked the handling of gop_map and when and where it is
incremented, which might be a legit
))) {
netdev_dbg(vif-dev, netback grant failed.\n);
It could have been the copy that failed. You should probably change the error
message.
I've changed it to netback grant op failed.\n
@@ -1588,22 +1588,26 @@ static inline void xenvif_tx_dealloc_action(struct
xenvif *vif)
/* Called after
-frags[i]);
- tx_info = vif-pending_tx_info[pending_idx];
/* Check error status: if okay then remember grant handle. */
- newerr = (++gop_map)-status;
+ newerr = (gop_map)-status;
You've reworked the handling of gop_map and when and where
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part to the linear area. Instead, doing a grant copy
for that header straight on is more reasonable. Especially because there are
ongoing efforts to make Xen avoiding TLB flush after unmap when
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part to the linear area. Instead, doing a grant copy
for that header straight on is more reasonable. Especially because there are
ongoing efforts to make Xen avoiding TLB flush after unmap when
, it would need some grant-table.c changes first.
I've put it onto my todo list.
Zoli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please re
On 27/03/14 12:54, Ian Campbell wrote:
On Thu, 2014-03-27 at 12:46 +, Zoltan Kiss wrote:
On 27/03/14 11:35, Ian Campbell wrote:
On Wed, 2014-03-26 at 21:18 +, Zoltan Kiss wrote:
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part
On Thu, 2014-03-27 at 12:46 +, Zoltan Kiss wrote:
> On 27/03/14 11:35, Ian Campbell wrote:
> > On Wed, 2014-03-26 at 21:18 +, Zoltan Kiss wrote:
> >> An old inefficiency of the TX path that we are grant mapping the first
> >> slot,
> >> and then cop
On 27/03/14 11:35, Ian Campbell wrote:
On Wed, 2014-03-26 at 21:18 +, Zoltan Kiss wrote:
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part to the linear area. Instead, doing a grant copy
for that header straight on is more reasonable
On Wed, 2014-03-26 at 21:18 +, Zoltan Kiss wrote:
> An old inefficiency of the TX path that we are grant mapping the first slot,
> and then copy the header part to the linear area. Instead, doing a grant copy
> for that header straight on is more reasonable. Especiall
On Wed, 2014-03-26 at 21:18 +, Zoltan Kiss wrote:
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part to the linear area. Instead, doing a grant copy
for that header straight on is more reasonable. Especially because there are
ongoing
On 27/03/14 11:35, Ian Campbell wrote:
On Wed, 2014-03-26 at 21:18 +, Zoltan Kiss wrote:
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part to the linear area. Instead, doing a grant copy
for that header straight on is more reasonable
On Thu, 2014-03-27 at 12:46 +, Zoltan Kiss wrote:
On 27/03/14 11:35, Ian Campbell wrote:
On Wed, 2014-03-26 at 21:18 +, Zoltan Kiss wrote:
An old inefficiency of the TX path that we are grant mapping the first
slot,
and then copy the header part to the linear area. Instead, doing
On 27/03/14 12:54, Ian Campbell wrote:
On Thu, 2014-03-27 at 12:46 +, Zoltan Kiss wrote:
On 27/03/14 11:35, Ian Campbell wrote:
On Wed, 2014-03-26 at 21:18 +, Zoltan Kiss wrote:
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part
, it would need some grant-table.c changes first.
I've put it onto my todo list.
Zoli
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part to the linear area. Instead, doing a grant copy
for that header straight on is more reasonable. Especially because there are
ongoing efforts to make Xen avoiding TLB flush after unmap when
From: Zoltan Kiss
Date: Mon, 24 Mar 2014 23:59:50 +
> Ian made some late comments about the grant mapping series, I incorporated the
> non-functional outcomes into this patch:
>
> - typo fixes in a comment of xenvif_free(), and add another one there as well
> - typo
From: Zoltan Kiss
Date: Mon, 24 Mar 2014 23:59:51 +
> Ian made some late comments about the grant mapping series, I incorporated the
> functional outcomes into this patch:
>
> - use callback_param macro to shorten access to pending_tx_info in
> xenvif_fill_frags() and x
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Mon, 24 Mar 2014 23:59:51 +
Ian made some late comments about the grant mapping series, I incorporated the
functional outcomes into this patch:
- use callback_param macro to shorten access to pending_tx_info in
xenvif_fill_frags
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Mon, 24 Mar 2014 23:59:50 +
Ian made some late comments about the grant mapping series, I incorporated the
non-functional outcomes into this patch:
- typo fixes in a comment of xenvif_free(), and add another one there as well
- typo fix
An old inefficiency of the TX path that we are grant mapping the first slot,
and then copy the header part to the linear area. Instead, doing a grant copy
for that header straight on is more reasonable. Especially because there are
ongoing efforts to make Xen avoiding TLB flush after unmap when
Ian made some late comments about the grant mapping series, I incorporated the
functional outcomes into this patch:
- use callback_param macro to shorten access to pending_tx_info in
xenvif_fill_frags() and xenvif_tx_submit()
- print an error message in xenvif_idx_unmap() before panic
Signed
Ian made some late comments about the grant mapping series, I incorporated the
non-functional outcomes into this patch:
- typo fixes in a comment of xenvif_free(), and add another one there as well
- typo fix for comment of rx_drain_timeout_msecs
- remove stale comment before calling
Patches #2 and #3 have the same exact Subject line, please repost with unique
subject lines so that someone scanning the shortlog can tell what might
be different between these two commits.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Ian made some late comments about the grant mapping series, I incorporated the
functional outcomes into this patch:
- use callback_param macro to shorten access to pending_tx_info in
xenvif_fill_frags() and xenvif_tx_submit()
- print an error message in xenvif_idx_unmap() before panic
Signed
Ian made some late comments about the grant mapping series, I incorporated the
non-functional outcomes into this patch:
- typo fixes in a comment of xenvif_free(), and add another one there as well
- typo fix for comment of rx_drain_timeout_msecs
- remove stale comment before calling
On Fri, 2014-03-21 at 19:31 +, Zoltan Kiss wrote:
> On 21/03/14 09:41, Ian Campbell wrote:
> > On Thu, 2014-03-20 at 19:32 +, Zoltan Kiss wrote:
> >> Ian made some late comments about the grant mapping series, I incorporated
> >> the
> >> outcomes
On Fri, 2014-03-21 at 19:31 +, Zoltan Kiss wrote:
On 21/03/14 09:41, Ian Campbell wrote:
On Thu, 2014-03-20 at 19:32 +, Zoltan Kiss wrote:
Ian made some late comments about the grant mapping series, I incorporated
the
outcomes into this patch. Additional comments, refactoring etc
Ian made some late comments about the grant mapping series, I incorporated the
functional outcomes into this patch:
- use callback_param macro to shorten access to pending_tx_info in
xenvif_fill_frags() and xenvif_tx_submit()
- print an error message in xenvif_idx_unmap() before panic
Signed
Ian made some late comments about the grant mapping series, I incorporated the
non-functional outcomes into this patch:
- typo fixes in a comment of xenvif_free(), and add another one there as well
- typo fix for comment of rx_drain_timeout_msecs
- remove stale comment before calling
Patches #2 and #3 have the same exact Subject line, please repost with unique
subject lines so that someone scanning the shortlog can tell what might
be different between these two commits.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Ian made some late comments about the grant mapping series, I incorporated the
functional outcomes into this patch:
- use callback_param macro to shorten access to pending_tx_info in
xenvif_fill_frags() and xenvif_tx_submit()
- print an error message in xenvif_idx_unmap() before panic
Signed
Ian made some late comments about the grant mapping series, I incorporated the
non-functional outcomes into this patch:
- typo fixes in a comment of xenvif_free(), and add another one there as well
- typo fix for comment of rx_drain_timeout_msecs
- remove stale comment before calling
On 21/03/14 09:41, Ian Campbell wrote:
On Thu, 2014-03-20 at 19:32 +, Zoltan Kiss wrote:
Ian made some late comments about the grant mapping series, I incorporated the
outcomes into this patch. Additional comments, refactoring etc.
I don't know how davem feels about merging these kinds
From: Zoltan Kiss
Date: Thu, 20 Mar 2014 19:32:41 +
> Ian made some late comments about the grant mapping series, I incorporated the
> outcomes into this patch. Additional comments, refactoring etc.
>
> Signed-off-by: Zoltan Kiss
I would really prefer that pure non-functi
On Thu, 2014-03-20 at 19:32 +, Zoltan Kiss wrote:
> Ian made some late comments about the grant mapping series, I incorporated the
> outcomes into this patch. Additional comments, refactoring etc.
I don't know how davem feels about merging these kinds of thing into one
patch but from my
On Thu, 2014-03-20 at 19:32 +, Zoltan Kiss wrote:
Ian made some late comments about the grant mapping series, I incorporated the
outcomes into this patch. Additional comments, refactoring etc.
I don't know how davem feels about merging these kinds of thing into one
patch but from my point
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Thu, 20 Mar 2014 19:32:41 +
Ian made some late comments about the grant mapping series, I incorporated the
outcomes into this patch. Additional comments, refactoring etc.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
I would really
On 21/03/14 09:41, Ian Campbell wrote:
On Thu, 2014-03-20 at 19:32 +, Zoltan Kiss wrote:
Ian made some late comments about the grant mapping series, I incorporated the
outcomes into this patch. Additional comments, refactoring etc.
I don't know how davem feels about merging these kinds
Ian made some late comments about the grant mapping series, I incorporated the
outcomes into this patch. Additional comments, refactoring etc.
Signed-off-by: Zoltan Kiss
---
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 6837bfc..fa19538 100644
Ian made some late comments about the grant mapping series, I incorporated the
outcomes into this patch. Additional comments, refactoring etc.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
---
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index
On Mon, 10 Mar 2014, David Vrabel wrote:
> On 27/02/14 15:55, Zoltan Kiss wrote:
> > (This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override
> > during mapping")
> >
> > The grant mapping API does m2p_override unnecessarily: only gntdev
On Mon, 10 Mar 2014, David Vrabel wrote:
On 27/02/14 15:55, Zoltan Kiss wrote:
(This is a continuation of [PATCH v9] xen/grant-table: Avoid m2p_override
during mapping)
The grant mapping API does m2p_override unnecessarily: only gntdev needs it,
for blkback and future netback patches
with 10Gb NICs, and generally it's a
>huge perfomance penalty. The classic kernel version of netback used grant
>mapping, and to get notified when the page can be unmapped, it used page
>destructors. Unfortunately that destructor is not an upstreamable solution.
>Ian Campbell's skb frag
On 13/03/14 13:56, Ian Campbell wrote:
On Thu, 2014-03-13 at 13:17 +, Zoltan Kiss wrote:
On 13/03/14 10:33, Ian Campbell wrote:
On Thu, 2014-03-06 at 21:48 +, Zoltan Kiss wrote:
+ netdev_err(vif->dev,
+ "Page
ng[MAX_PENDING_REQS];
> >>struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
> >> + grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
> >>
> >>/* Coalescing tx requests before copying makes number of grant
> >> * copy ops greater or eq
];
+ grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
/* Coalescing tx requests before copying makes number of grant
* copy ops greater or equal to number of slots required. In
* worst case a tx request consumes 2 gnttab_copy.
*/
struct gnttab_copy tx_copy_ops[2
On 13/03/14 10:17, Ian Campbell wrote:
Pulling out this one comment for the attention on the core Xen/Linux
maintainers.
On Thu, 2014-03-06 at 21:48 +, Zoltan Kiss wrote:
[...]
@@ -343,8 +347,26 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t
domid,
vif->pending_prod
35,13 +146,31 @@ struct xenvif {
> > >> pending_ring_idx_t pending_cons;
> > >> u16 pending_ring[MAX_PENDING_REQS];
> > >> struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
> > >> +grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
> >
nding_ring_idx_t pending_cons;
>>>>u16 pending_ring[MAX_PENDING_REQS];
>>>>struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
>>>> + grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
>>>>
>>>>/* Coalescing tx requests
ng[MAX_PENDING_REQS];
> >>struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
> >> + grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
> >>
> >>/* Coalescing tx requests before copying makes number of grant
> >> * copy ops greater or eq
ng_tx_info[MAX_PENDING_REQS];
>> +grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
>>
>> /* Coalescing tx requests before copying makes number of grant
>> * copy ops greater or equal to number of slots required. In
>> * worst case a tx request consu
On Wed, 2014-03-12 at 15:40 +, Ian Campbell wrote:
> On Sat, 2014-03-08 at 18:57 -0500, David Miller wrote:
> > From: Zoltan Kiss
> > Date: Sat, 8 Mar 2014 14:37:50 +
> >
> > > Maybe you mixed up mine with that? But that's also not eligible to be
> > > applied yet.
> >
> > I can always
grant_tx_handle[MAX_PENDING_REQS];
>
> /* Coalescing tx requests before copying makes number of grant
>* copy ops greater or equal to number of slots required. In
>* worst case a tx request consumes 2 gnttab_copy.
>*/
> struct gnttab_copy tx_copy_ops[2*MAX_
701 - 800 of 1633 matches
Mail list logo
