On 16/01/15 19:37, William Cohen wrote:
On 01/16/2015 01:29 PM, Zoltan Kiss wrote:
On 16/01/15 15:38, William Cohen wrote:
On 01/16/2015 09:01 AM, Zoltan Kiss wrote:
Hi,
I'm using OProfile to check some suspicious behaviour of dpdk-pktgen,
and I can see something which troubles me
at the wrong place as well.
Regards,
Zoltan
On 16/01/15 15:38, William Cohen wrote:
On 01/16/2015 09:01 AM, Zoltan Kiss wrote:
Hi,
I'm using OProfile to check some suspicious behaviour of dpdk-pktgen,
and I can see something which troubles me. Either the scheduler lies
about core affinity
On 16/01/15 15:38, William Cohen wrote:
On 01/16/2015 09:01 AM, Zoltan Kiss wrote:
Hi,
I'm using OProfile to check some suspicious behaviour of dpdk-pktgen,
and I can see something which troubles me. Either the scheduler lies
about core affinity or Oprofile accounts some samples wrongly
Hi,
On 16/01/15 15:38, William Cohen wrote:
On 01/16/2015 09:01 AM, Zoltan Kiss wrote:
Hi,
I'm using OProfile to check some suspicious behaviour of dpdk-pktgen,
and I can see something which troubles me. Either the scheduler lies
about core affinity or Oprofile accounts some samples wrongly
Hi,
I'm using OProfile to check some suspicious behaviour of dpdk-pktgen,
and I can see something which troubles me. Either the scheduler lies
about core affinity or Oprofile accounts some samples wrongly.
This userspace app runs in threads, which are assigned explicitly to one
single core
On 16/01/15 15:38, William Cohen wrote:
On 01/16/2015 09:01 AM, Zoltan Kiss wrote:
Hi,
I'm using OProfile to check some suspicious behaviour of dpdk-pktgen,
and I can see something which troubles me. Either the scheduler lies
about core affinity or Oprofile accounts some samples wrongly
at the wrong place as well.
Regards,
Zoltan
On 16/01/15 15:38, William Cohen wrote:
On 01/16/2015 09:01 AM, Zoltan Kiss wrote:
Hi,
I'm using OProfile to check some suspicious behaviour of dpdk-pktgen,
and I can see something which troubles me. Either the scheduler lies
about core affinity
On 16/01/15 19:37, William Cohen wrote:
On 01/16/2015 01:29 PM, Zoltan Kiss wrote:
On 16/01/15 15:38, William Cohen wrote:
On 01/16/2015 09:01 AM, Zoltan Kiss wrote:
Hi,
I'm using OProfile to check some suspicious behaviour of dpdk-pktgen,
and I can see something which troubles me
Hi,
I'm using OProfile to check some suspicious behaviour of dpdk-pktgen,
and I can see something which troubles me. Either the scheduler lies
about core affinity or Oprofile accounts some samples wrongly.
This userspace app runs in threads, which are assigned explicitly to one
single core
Hi,
On 16/01/15 15:38, William Cohen wrote:
On 01/16/2015 09:01 AM, Zoltan Kiss wrote:
Hi,
I'm using OProfile to check some suspicious behaviour of dpdk-pktgen,
and I can see something which troubles me. Either the scheduler lies
about core affinity or Oprofile accounts some samples wrongly
On 01/12/14 13:36, David Vrabel wrote:
On 01/12/14 08:55, Stefan Bader wrote:
On 11.08.2014 19:32, Zoltan Kiss wrote:
There is a long known problem with the netfront/netback interface: if the guest
tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
it gets
On 01/12/14 13:36, David Vrabel wrote:
On 01/12/14 08:55, Stefan Bader wrote:
On 11.08.2014 19:32, Zoltan Kiss wrote:
There is a long known problem with the netfront/netback interface: if the guest
tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
it gets
On 10/11/14 14:41, David Vrabel wrote:
On 10/11/14 14:35, Seth Forshee wrote:
On Fri, Nov 07, 2014 at 10:44:15AM +, David Vrabel wrote:
On 06/11/14 21:49, Seth Forshee wrote:
We've had several reports of hitting the following BUG_ON in
xennet_make_frags with 3.2 and 3.13 kernels (I'm
On 10/11/14 14:41, David Vrabel wrote:
On 10/11/14 14:35, Seth Forshee wrote:
On Fri, Nov 07, 2014 at 10:44:15AM +, David Vrabel wrote:
On 06/11/14 21:49, Seth Forshee wrote:
We've had several reports of hitting the following BUG_ON in
xennet_make_frags with 3.2 and 3.13 kernels (I'm
Hi,
On 07/11/14 11:08, Stefan Bader wrote:
On 07.11.2014 11:44, David Vrabel wrote:
On 06/11/14 21:49, Seth Forshee wrote:
We've had several reports of hitting the following BUG_ON in
xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
results of testing with 3.17):
On 07/11/14 12:15, Stefan Bader wrote:
On 07.11.2014 12:22, Eric Dumazet wrote:
On Fri, 2014-11-07 at 09:25 +, Zoltan Kiss wrote:
Please do not top post.
Hi,
AFAIK in this scenario your skb frag is wrong. The page pointer should
point to the original compound page (not a member
Hi,
AFAIK in this scenario your skb frag is wrong. The page pointer should
point to the original compound page (not a member of it), and offset
should be set accordingly.
For example, if your compound page is 16K (4 page), then the page
pointer should point to the first page, and if the data
Hi,
AFAIK in this scenario your skb frag is wrong. The page pointer should
point to the original compound page (not a member of it), and offset
should be set accordingly.
For example, if your compound page is 16K (4 page), then the page
pointer should point to the first page, and if the data
On 07/11/14 12:15, Stefan Bader wrote:
On 07.11.2014 12:22, Eric Dumazet wrote:
On Fri, 2014-11-07 at 09:25 +, Zoltan Kiss wrote:
Please do not top post.
Hi,
AFAIK in this scenario your skb frag is wrong. The page pointer should
point to the original compound page (not a member
Hi,
On 07/11/14 11:08, Stefan Bader wrote:
On 07.11.2014 11:44, David Vrabel wrote:
On 06/11/14 21:49, Seth Forshee wrote:
We've had several reports of hitting the following BUG_ON in
xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
results of testing with 3.17):
, and it can fail much easier as it tries to allocate a big linear
area for the whole packet, but probably easier by an order of magnitude than
anything else. Probably this code path is not touched very frequently anyway.
Signed-off-by: Zoltan Kiss
Cc: Wei Liu
Cc: Ian Campbell
Cc: Paul Durrant
Cc: net
On 08/08/14 17:33, Stephen Hemminger wrote:
This idea of bouncing carrier is wrong. If guest is flow blocked you don't
want to toggle carrier. That will cause problems because applications that are
looking for carrier transistions like routing daemons will be notified.
If running a routing
In the patch called "xen-netback: Turn off the carrier if the guest is not able
to receive" NAPI was descheduled when the carrier was set off. That's
not what most of the drivers do, and we don't have any specific reason to do so
as well, so revert that change.
Signed-off-by: Zoltan Kis
, and it can fail much easier as it tries to allocate a big linear
area for the whole packet, but probably easier by an order of magnitude than
anything else. Probably this code path is not touched very frequently anyway.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc
In the patch called xen-netback: Turn off the carrier if the guest is not able
to receive NAPI was descheduled when the carrier was set off. That's
not what most of the drivers do, and we don't have any specific reason to do so
as well, so revert that change.
Signed-off-by: Zoltan Kiss zoltan.k
On 08/08/14 17:33, Stephen Hemminger wrote:
This idea of bouncing carrier is wrong. If guest is flow blocked you don't
want to toggle carrier. That will cause problems because applications that are
looking for carrier transistions like routing daemons will be notified.
If running a routing
In the patch called "xen-netback: Turn off the carrier if the guest is not able
to receive" NAPI was descheduled when the carrier was set off. That's
not what most of the drivers do, and we don't have any specific reason to do so
as well, so revert that change.
Signed-off-by: Zoltan Kis
In the patch called xen-netback: Turn off the carrier if the guest is not able
to receive NAPI was descheduled when the carrier was set off. That's
not what most of the drivers do, and we don't have any specific reason to do so
as well, so revert that change.
Signed-off-by: Zoltan Kiss zoltan.k
On 06/08/14 00:07, David Miller wrote:
From: Zoltan Kiss
Date: Mon, 4 Aug 2014 16:20:56 +0100
This series starts using carrier off as a way to purge packets when the guest is
not able (or willing) to receive them. It is a much faster way to get rid of
packets waiting for an overwhelmed guest
On 06/08/14 22:01, David Miller wrote:
From: Zoltan Kiss
Date: Wed, 6 Aug 2014 20:20:55 +0100
The fundamental problem with netback that start_xmit place the
packet into an internal queue, and then the thread does the actual
transmission from that queue, but it doesn't know whether
In the patch called "xen-netback: Turn off the carrier if the guest is not able
to receive" new branches were introduced to this if statement, risking that a
queue with non-zero id can reenable the disabled interface.
Signed-off-by: Zoltan Kiss
Signed-off-by: David Vrabe
On 06/08/14 22:07, David Miller wrote:
From: Zoltan Kiss
Date: Wed, 6 Aug 2014 19:16:13 +0100
Signed-off-by: Zoltan Kiss
Signed-off-by: David Vrabel
Neither this nor your "Small fixes around internal queue purging"
patch apply cleanly to my current tree. I have no idea wha
On 06/08/14 22:07, David Miller wrote:
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Wed, 6 Aug 2014 19:16:13 +0100
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
Neither this nor your Small fixes around internal queue purging
patch
In the patch called xen-netback: Turn off the carrier if the guest is not able
to receive new branches were introduced to this if statement, risking that a
queue with non-zero id can reenable the disabled interface.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Signed-off-by: David Vrabel
On 06/08/14 22:01, David Miller wrote:
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Wed, 6 Aug 2014 20:20:55 +0100
The fundamental problem with netback that start_xmit place the
packet into an internal queue, and then the thread does the actual
transmission from that queue, but it doesn't
On 06/08/14 00:07, David Miller wrote:
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Mon, 4 Aug 2014 16:20:56 +0100
This series starts using carrier off as a way to purge packets when the guest is
not able (or willing) to receive them. It is a much faster way to get rid of
packets waiting
In the patch called "xen-netback: Turn off the carrier if the guest is not able
to receive" new branches were introduced to this if statement, risking that a
queue with non-zero id can reenable the disabled interface.
Signed-off-by: Zoltan Kiss
Signed-off-by: David Vrabe
On 06/08/14 00:07, David Miller wrote:
From: Zoltan Kiss
Date: Mon, 4 Aug 2014 16:20:56 +0100
This series starts using carrier off as a way to purge packets when the guest is
not able (or willing) to receive them. It is a much faster way to get rid of
packets waiting for an overwhelmed guest
On 05/08/14 13:45, Wei Liu wrote:
On Mon, Aug 04, 2014 at 04:20:58PM +0100, Zoltan Kiss wrote:
[...]
struct xenvif {
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index fbdadb3..48a55cd 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers
Ignore this series, I've pushed the wrong button. Apologies.
--
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 at
On 05/08/14 13:45, Wei Liu wrote:
On Mon, Aug 04, 2014 at 04:20:57PM +0100, Zoltan Kiss wrote:
This patch introduces a new state bit VIF_STATUS_CONNECTED to track whether the
vif is in a connected state. Using carrier will not work with the next patch
in this series, which aims to turn
the thread can check what it should do. It also disables NAPI, so the guest
can't transmit, but leaves the interrupts on, so it can resurrect.
Only the queues which brought down the interface can enable it again, the bit
QUEUE_STATUS_RX_STALLED makes sure of that.
Signed-off-by: Zoltan Kiss
Signed-off
-by: Zoltan Kiss
Signed-off-by: David Vrabel
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
---
v2:
- rename the bitshift type to "enum state_bit_shift" here, not in the next patch
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/x
rs divided by
space. The value of the number is the size of the preceding payload area. E.g.
"1 3 5 "..." 1000 1005 1010"
If the pattern is used, every frag will have its own page, unlike before, so it
needs more memory.
[1] 5837574: xen-netback: Fix grant ref resolution in RX pa
Signed-off-by: Zoltan Kiss
Signed-off-by: David Vrabel
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 5cb139a..f126920 100644
--- a/drivers/net/xen-netback
number differs
2/4: fine-grained buffer geometrics
3/4: fix UDP checksuming
4/4: sending TCP GSO packets. This is an RFC yet, as I'm not certain about all
things changed here
Signed-off-by: Zoltan Kiss
Cc: "David S. Miller"
Cc: Thomas Graf
Cc: Joe Perches
Cc: net...@vger.kernel.org
only handle 4k pages. This extension of pktgen is proven to be
useful to test that.
Signed-off-by: Zoltan Kiss
Cc: "David S. Miller"
Cc: Thomas Graf
Cc: Joe Perches
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
---
v2: allocate new compo
This is a prototype patch to enable sending IPv4 TCP packets with pktgen. The
original motivation is to test TCP GSO with xen-netback/netfront, but I'm not
sure about how the checksum should be set up, and also someone should verify the
GSO settings I'm using.
Signed-off-by: Zoltan Kiss
Cc
.
The second turns off the carrier if the guest times out on a queue, and only
turn it on again if that queue (or queues) resurrects.
Signed-off-by: Zoltan Kiss
Signed-off-by: David Vrabel
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
--
To unsubscribe
It passes port number instead of IP address for checksuming. The udp4_hwcsum()
call is also bad, but my next patch will get rid of it anyway. The IPv6 code
does it correctly already. It also changes replaces 8 with sizeof(struct
udphdr)
Signed-off-by: Zoltan Kiss
Cc: "David S. Miller
This patch adds an extra internal queue purging for xenvif_carrier_off. It makes
sense to do this when the carrier is switched off.
Also, it uses the proper helper instead of a while loop to the purging at
another place.
Signed-off-by: Zoltan Kiss
Signed-off-by: David Vrabel
Cc: net
On 05/08/14 21:09, David Miller wrote:
From: Zoltan Kiss
Date: Mon, 4 Aug 2014 14:37:14 +0100
@@ -3559,6 +3616,14 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
pkt_dev->last_pkt_size = pkt_dev->skb->len;
pkt_dev->al
On 05/08/14 21:09, David Miller wrote:
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Mon, 4 Aug 2014 14:37:14 +0100
@@ -3559,6 +3616,14 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
pkt_dev-last_pkt_size = pkt_dev-skb-len;
pkt_dev-allocated_skbs
This patch adds an extra internal queue purging for xenvif_carrier_off. It makes
sense to do this when the carrier is switched off.
Also, it uses the proper helper instead of a while loop to the purging at
another place.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Signed-off-by: David
It passes port number instead of IP address for checksuming. The udp4_hwcsum()
call is also bad, but my next patch will get rid of it anyway. The IPv6 code
does it correctly already. It also changes replaces 8 with sizeof(struct
udphdr)
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Cc
.
The second turns off the carrier if the guest times out on a queue, and only
turn it on again if that queue (or queues) resurrects.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de
This is a prototype patch to enable sending IPv4 TCP packets with pktgen. The
original motivation is to test TCP GSO with xen-netback/netfront, but I'm not
sure about how the checksum should be set up, and also someone should verify the
GSO settings I'm using.
Signed-off-by: Zoltan Kiss zoltan.k
that.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Cc: David S. Miller da...@davemloft.net
Cc: Thomas Graf tg...@suug.ch
Cc: Joe Perches j...@perches.com
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
---
v2: allocate new compound page only
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 5cb139a
number differs
2/4: fine-grained buffer geometrics
3/4: fix UDP checksuming
4/4: sending TCP GSO packets. This is an RFC yet, as I'm not certain about all
things changed here
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Cc: David S. Miller da...@davemloft.net
Cc: Thomas Graf tg...@suug.ch
Cc
-by: Zoltan Kiss zoltan.k...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
---
v2:
- rename the bitshift type to enum state_bit_shift here, not in the next patch
diff --git a/drivers/net/xen
by
space. The value of the number is the size of the preceding payload area. E.g.
1 3 5 ... 1000 1005 1010
If the pattern is used, every frag will have its own page, unlike before, so it
needs more memory.
[1] 5837574: xen-netback: Fix grant ref resolution in RX path
Signed-off-by: Zoltan Kiss
the thread can check what it should do. It also disables NAPI, so the guest
can't transmit, but leaves the interrupts on, so it can resurrect.
Only the queues which brought down the interface can enable it again, the bit
QUEUE_STATUS_RX_STALLED makes sure of that.
Signed-off-by: Zoltan Kiss zoltan.k
On 05/08/14 13:45, Wei Liu wrote:
On Mon, Aug 04, 2014 at 04:20:57PM +0100, Zoltan Kiss wrote:
This patch introduces a new state bit VIF_STATUS_CONNECTED to track whether the
vif is in a connected state. Using carrier will not work with the next patch
in this series, which aims to turn
Ignore this series, I've pushed the wrong button. Apologies.
--
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 at
On 05/08/14 13:45, Wei Liu wrote:
On Mon, Aug 04, 2014 at 04:20:58PM +0100, Zoltan Kiss wrote:
[...]
struct xenvif {
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index fbdadb3..48a55cd 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers
On 06/08/14 00:07, David Miller wrote:
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Mon, 4 Aug 2014 16:20:56 +0100
This series starts using carrier off as a way to purge packets when the guest is
not able (or willing) to receive them. It is a much faster way to get rid of
packets waiting
In the patch called xen-netback: Turn off the carrier if the guest is not able
to receive new branches were introduced to this if statement, risking that a
queue with non-zero id can reenable the disabled interface.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Signed-off-by: David Vrabel
On 04/08/14 23:24, David Miller wrote:
From: Wei Liu
Date: Sun, 3 Aug 2014 10:11:10 +0100
On Sat, Aug 02, 2014 at 03:33:37PM -0700, David Miller wrote:
From: Wei Liu
Date: Fri, 1 Aug 2014 12:02:46 +0100
On Thu, Jul 31, 2014 at 01:25:20PM -0700, David Miller wrote:
If you were to have a
On 04/08/14 23:24, David Miller wrote:
From: Wei Liu wei.l...@citrix.com
Date: Sun, 3 Aug 2014 10:11:10 +0100
On Sat, Aug 02, 2014 at 03:33:37PM -0700, David Miller wrote:
From: Wei Liu wei.l...@citrix.com
Date: Fri, 1 Aug 2014 12:02:46 +0100
On Thu, Jul 31, 2014 at 01:25:20PM -0700, David
On 31/07/14 21:25, David Miller wrote:
From: Zoltan Kiss
Date: Wed, 30 Jul 2014 14:25:30 +0100
There is a long known problem with the netfront/netback interface: if the guest
tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
it gets dropped. The reason
On 04/08/14 16:20, Zoltan Kiss wrote:
This series starts using carrier off as a way to purge packets when the guest is
not able (or willing) to receive them. It is a much faster way to get rid of
packets waiting for an overwhelmed guest.
The first patch changes current netback code where
-by: Zoltan Kiss
Signed-off-by: David Vrabel
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
v2:
- rename the bitshift type to "enum state_bit_shift" here, not in the next patch
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netbac
the thread can check what it should do. It also disables NAPI, so the guest
can't transmit, but leaves the interrupts on, so it can resurrect.
Only the queues which brought down the interface can enable it again, the bit
QUEUE_STATUS_RX_STALLED makes sure of that.
Signed-off-by: Zoltan Kiss
Signed-off
.
The second turns off the carrier if the guest times out on a queue, and only
turn it on again if that queue (or queues) resurrects.
Signed-off-by: Zoltan Kiss
Signed-off-by: David Vrabel
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
--
To unsubscribe
On 04/08/14 14:35, David Vrabel wrote:
On 30/07/14 20:50, Zoltan Kiss wrote:
Currently when the guest is not able to receive more packets, qdisc layer starts
a timer, and when it goes off, qdisc is started again to deliver a packet again.
This is a very slow way to drain the queues, consumes
On 01/08/14 11:52, Wei Liu wrote:
On Wed, Jul 30, 2014 at 08:50:49PM +0100, Zoltan Kiss wrote:
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -176,9 +176,9 @@ struct xenvif_queue { /* Per-queue data for xenvif */
struct xen_netif_rx_back_ring rx
only handle 4k pages. This extension of pktgen is proven to be
useful to test that.
Signed-off-by: Zoltan Kiss
Cc: "David S. Miller"
Cc: Thomas Graf
Cc: Joe Perches
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
---
v2: allocate new compo
rs divided by
space. The value of the number is the size of the preceding payload area. E.g.
"1 3 5 "..." 1000 1005 1010"
If the pattern is used, every frag will have its own page, unlike before, so it
needs more memory.
[1] 5837574: xen-netback: Fix grant ref resolution in RX pa
number differs
2/4: fine-grained buffer geometrics
3/4: fix UDP checksuming
4/4: sending TCP GSO packets. This is an RFC yet, as I'm not certain about all
things changed here
Signed-off-by: Zoltan Kiss
Cc: "David S. Miller"
Cc: Thomas Graf
Cc: Joe Perches
Cc: net...@vger.kernel.org
It passes port number instead of IP address for checksuming. The udp4_hwcsum()
call is also bad, but my next patch will get rid of it anyway. The IPv6 code
does it correctly already. It also changes replaces 8 with sizeof(struct
udphdr)
Signed-off-by: Zoltan Kiss
Cc: "David S. Miller
This is a prototype patch to enable sending IPv4 TCP packets with pktgen. The
original motivation is to test TCP GSO with xen-netback/netfront, but I'm not
sure about how the checksum should be set up, and also someone should verify the
GSO settings I'm using.
Signed-off-by: Zoltan Kiss
Cc
On 01/08/14 05:32, David Miller wrote:
From: Zoltan Kiss
@@ -3017,29 +3029,40 @@ static struct sk_buff *fill_packet_ipv4(struct
net_device *odev,
iph = (struct iphdr *) skb_put(skb, sizeof(struct iphdr));
skb_set_transport_header(skb, skb->len);
- udph = (struct udp
On 01/08/14 05:32, David Miller wrote:
From: Zoltan Kiss zoltan.k...@citrix.com
@@ -3017,29 +3029,40 @@ static struct sk_buff *fill_packet_ipv4(struct
net_device *odev,
iph = (struct iphdr *) skb_put(skb, sizeof(struct iphdr));
skb_set_transport_header(skb, skb-len
This is a prototype patch to enable sending IPv4 TCP packets with pktgen. The
original motivation is to test TCP GSO with xen-netback/netfront, but I'm not
sure about how the checksum should be set up, and also someone should verify the
GSO settings I'm using.
Signed-off-by: Zoltan Kiss zoltan.k
It passes port number instead of IP address for checksuming. The udp4_hwcsum()
call is also bad, but my next patch will get rid of it anyway. The IPv6 code
does it correctly already. It also changes replaces 8 with sizeof(struct
udphdr)
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Cc
number differs
2/4: fine-grained buffer geometrics
3/4: fix UDP checksuming
4/4: sending TCP GSO packets. This is an RFC yet, as I'm not certain about all
things changed here
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Cc: David S. Miller da...@davemloft.net
Cc: Thomas Graf tg...@suug.ch
Cc
by
space. The value of the number is the size of the preceding payload area. E.g.
1 3 5 ... 1000 1005 1010
If the pattern is used, every frag will have its own page, unlike before, so it
needs more memory.
[1] 5837574: xen-netback: Fix grant ref resolution in RX path
Signed-off-by: Zoltan Kiss
that.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Cc: David S. Miller da...@davemloft.net
Cc: Thomas Graf tg...@suug.ch
Cc: Joe Perches j...@perches.com
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
---
v2: allocate new compound page only
On 01/08/14 11:52, Wei Liu wrote:
On Wed, Jul 30, 2014 at 08:50:49PM +0100, Zoltan Kiss wrote:
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -176,9 +176,9 @@ struct xenvif_queue { /* Per-queue data for xenvif */
struct xen_netif_rx_back_ring rx
On 04/08/14 14:35, David Vrabel wrote:
On 30/07/14 20:50, Zoltan Kiss wrote:
Currently when the guest is not able to receive more packets, qdisc layer starts
a timer, and when it goes off, qdisc is started again to deliver a packet again.
This is a very slow way to drain the queues, consumes
.
The second turns off the carrier if the guest times out on a queue, and only
turn it on again if that queue (or queues) resurrects.
Signed-off-by: Zoltan Kiss zoltan.k...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de
the thread can check what it should do. It also disables NAPI, so the guest
can't transmit, but leaves the interrupts on, so it can resurrect.
Only the queues which brought down the interface can enable it again, the bit
QUEUE_STATUS_RX_STALLED makes sure of that.
Signed-off-by: Zoltan Kiss zoltan.k
-by: Zoltan Kiss zoltan.k...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
v2:
- rename the bitshift type to enum state_bit_shift here, not in the next patch
diff --git a/drivers/net/xen-netback
On 04/08/14 16:20, Zoltan Kiss wrote:
This series starts using carrier off as a way to purge packets when the guest is
not able (or willing) to receive them. It is a much faster way to get rid of
packets waiting for an overwhelmed guest.
The first patch changes current netback code where
On 31/07/14 21:25, David Miller wrote:
From: Zoltan Kiss zoltan.k...@citrix.com
Date: Wed, 30 Jul 2014 14:25:30 +0100
There is a long known problem with the netfront/netback interface: if the guest
tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
it gets dropped
the thread can check what it should do. It also disables NAPI, so the guest
can't transmit, but leaves the interrupts on, so it can resurrect.
Signed-off-by: Zoltan Kiss
Signed-off-by: David Vrabel
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
diff
-by: Zoltan Kiss
Signed-off-by: David Vrabel
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 28c9822..7231359 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net
It passes port number instead of IP address for checksuming. The udp4_hwcsum()
call is also bad, but my next patch will get rid of it anyway. The IPv6 code
does it correctly already. It also changes replaces 8 with sizeof(struct
udphdr)
Signed-off-by: Zoltan Kiss
Cc: "David S. Miller
This is a prototype patch to enable sending IPv4 TCP packets with pktgen. The
original motivation is to test TCP GSO with xen-netback/netfront, but I'm not
sure about how the checksum should be set up, and also someone should verify the
GSO settings I'm using.
Signed-off-by: Zoltan Kiss
Cc
1 - 100 of 700 matches
Mail list logo
