Displaying 20 results from an estimated 4000 matches similar to: "[PATCH net] virtio-net: fix the race between channels setting and refill"
2013 Jan 25
4
[PATCH V7 1/3] virtio-net: fix the set affinity bug when CPU IDs are not consecutive
As Michael mentioned, set affinity and select queue will not work very
well when CPU IDs are not consecutive, this can happen with hot unplug.
Fix this bug by traversal the online CPUs, and create a per cpu variable
to find the mapping from CPU to the preferable virtual-queue.
Cc: Rusty Russell <rusty at rustcorp.com.au>
Cc: "Michael S. Tsirkin" <mst at redhat.com>
Cc: Jason
2013 Jan 25
4
[PATCH V7 1/3] virtio-net: fix the set affinity bug when CPU IDs are not consecutive
As Michael mentioned, set affinity and select queue will not work very
well when CPU IDs are not consecutive, this can happen with hot unplug.
Fix this bug by traversal the online CPUs, and create a per cpu variable
to find the mapping from CPU to the preferable virtual-queue.
Cc: Rusty Russell <rusty at rustcorp.com.au>
Cc: "Michael S. Tsirkin" <mst at redhat.com>
Cc: Jason
2013 Oct 14
1
[PATCH net 2/2] virtio-net: refill only when device is up during setting queues
On Mon, Oct 14, 2013 at 05:56:35PM +0800, Jason Wang wrote:
> We used to schedule the refill work unconditionally after changing the
> number of queues. This may lead an issue if the device is not
> up. Since we only try to cancel the work in ndo_stop(), this may cause
> the refill work still work after removing the device. Fix this by only
> schedule the work when device is up.
2013 Oct 14
1
[PATCH net 2/2] virtio-net: refill only when device is up during setting queues
On Mon, Oct 14, 2013 at 05:56:35PM +0800, Jason Wang wrote:
> We used to schedule the refill work unconditionally after changing the
> number of queues. This may lead an issue if the device is not
> up. Since we only try to cancel the work in ndo_stop(), this may cause
> the refill work still work after removing the device. Fix this by only
> schedule the work when device is up.
2013 Oct 14
4
[PATCH net 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
We're trying to re-configure the affinity unconditionally in cpu hotplug
callback. This may lead the issue during resuming from s3/s4 since
- virt queues haven't been allocated at that time.
- it's unnecessary since thaw method will re-configure the affinity.
Fix this issue by checking the config_enable and do nothing is we're not ready.
The bug were introduced by commit
2013 Oct 14
4
[PATCH net 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
We're trying to re-configure the affinity unconditionally in cpu hotplug
callback. This may lead the issue during resuming from s3/s4 since
- virt queues haven't been allocated at that time.
- it's unnecessary since thaw method will re-configure the affinity.
Fix this issue by checking the config_enable and do nothing is we're not ready.
The bug were introduced by commit
2013 Oct 15
0
[PATCH net V2 2/2] virtio-net: refill only when device is up during setting queues
We used to schedule the refill work unconditionally after changing the
number of queues. This may lead an issue if the device is not
up. Since we only try to cancel the work in ndo_stop(), this may cause
the refill work still work after removing the device. Fix this by only
schedule the work when device is up.
The bug were introduce by commit 9b9cd8024a2882e896c65222aa421d461354e3f2.
(virtio-net:
2013 Oct 15
5
[PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
We're trying to re-configure the affinity unconditionally in cpu hotplug
callback. This may lead the issue during resuming from s3/s4 since
- virt queues haven't been allocated at that time.
- it's unnecessary since thaw method will re-configure the affinity.
Fix this issue by checking the config_enable and do nothing is we're not ready.
The bug were introduced by commit
2013 Oct 15
5
[PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
We're trying to re-configure the affinity unconditionally in cpu hotplug
callback. This may lead the issue during resuming from s3/s4 since
- virt queues haven't been allocated at that time.
- it's unnecessary since thaw method will re-configure the affinity.
Fix this issue by checking the config_enable and do nothing is we're not ready.
The bug were introduced by commit
2014 Apr 18
3
[PATCH] virtio_net: zero is an invald queue_pairs number
Execute "ethtool -L eth0 combined 0" in guest, if multiqueue
is enabled, virtnet_send_command() will return -EINVAL error,
there is a validation in QEMU.
But if multiqueue is disabled, virtnet_set_queues() will just
return zero (success). We should return error for this situation.
Signed-off-by: Amos Kong <akong at redhat.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed,
2014 Apr 18
3
[PATCH] virtio_net: zero is an invald queue_pairs number
Execute "ethtool -L eth0 combined 0" in guest, if multiqueue
is enabled, virtnet_send_command() will return -EINVAL error,
there is a validation in QEMU.
But if multiqueue is disabled, virtnet_set_queues() will just
return zero (success). We should return error for this situation.
Signed-off-by: Amos Kong <akong at redhat.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed,
2014 Apr 22
2
[PATCH] virtio_net: return error when there is no virtqueue or MQ isn't support
On Tue, Apr 22, 2014 at 11:11:50AM +0800, Jason Wang wrote:
> On 04/21/2014 11:11 PM, Amos Kong wrote:
> > Currently ethtool returns zero if there is no virtqueue or MQ isn't
> > support, we should return -ENOTSUPP to notice user.
> >
> > Signed-off-by: Amos Kong <akong at redhat.com>
> > ---
> > drivers/net/virtio_net.c | 2 +-
> > 1 file
2014 Apr 22
2
[PATCH] virtio_net: return error when there is no virtqueue or MQ isn't support
On Tue, Apr 22, 2014 at 11:11:50AM +0800, Jason Wang wrote:
> On 04/21/2014 11:11 PM, Amos Kong wrote:
> > Currently ethtool returns zero if there is no virtqueue or MQ isn't
> > support, we should return -ENOTSUPP to notice user.
> >
> > Signed-off-by: Amos Kong <akong at redhat.com>
> > ---
> > drivers/net/virtio_net.c | 2 +-
> > 1 file
2013 Oct 14
0
[PATCH net 2/2] virtio-net: refill only when device is up during setting queues
We used to schedule the refill work unconditionally after changing the
number of queues. This may lead an issue if the device is not
up. Since we only try to cancel the work in ndo_stop(), this may cause
the refill work still work after removing the device. Fix this by only
schedule the work when device is up.
The bug were introduce by commit 9b9cd8024a2882e896c65222aa421d461354e3f2.
(virtio-net:
2014 Apr 21
2
[PATCH] virtio_net: return error when there is no virtqueue or MQ isn't support
Currently ethtool returns zero if there is no virtqueue or MQ isn't
support, we should return -ENOTSUPP to notice user.
Signed-off-by: Amos Kong <akong at redhat.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 8a852b5..eaf8266 100644
--- a/drivers/net/virtio_net.c
+++
2014 Apr 21
2
[PATCH] virtio_net: return error when there is no virtqueue or MQ isn't support
Currently ethtool returns zero if there is no virtqueue or MQ isn't
support, we should return -ENOTSUPP to notice user.
Signed-off-by: Amos Kong <akong at redhat.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 8a852b5..eaf8266 100644
--- a/drivers/net/virtio_net.c
+++
2014 Apr 21
1
[PATCH] virtio_net: zero is an invald queue_pairs number
On 04/21/2014 02:32 PM, Jason Wang wrote:
> On 04/18/2014 01:45 PM, Amos Kong wrote:
>> Execute "ethtool -L eth0 combined 0" in guest, if multiqueue
>> is enabled, virtnet_send_command() will return -EINVAL error,
>> there is a validation in QEMU.
>>
>> But if multiqueue is disabled, virtnet_set_queues() will just
>> return zero (success). We should
2014 Apr 21
1
[PATCH] virtio_net: zero is an invald queue_pairs number
On 04/21/2014 02:32 PM, Jason Wang wrote:
> On 04/18/2014 01:45 PM, Amos Kong wrote:
>> Execute "ethtool -L eth0 combined 0" in guest, if multiqueue
>> is enabled, virtnet_send_command() will return -EINVAL error,
>> there is a validation in QEMU.
>>
>> But if multiqueue is disabled, virtnet_set_queues() will just
>> return zero (success). We should
2012 Dec 05
3
[PATCH net-next v2 0/3] Multiqueue support in virtio-net
Hi all:
This series is an update version of multiqueue virtio-net driver based on
Krishna Kumar's work to let virtio-net use multiple rx/tx queues to do the
packets reception and transmission. Please review and comments.
A protype implementation of qemu-kvm support could by found in
git://github.com/jasowang/qemu-kvm-mq.git. To start a guest with two queues, you
could specify the queues
2012 Dec 05
3
[PATCH net-next v2 0/3] Multiqueue support in virtio-net
Hi all:
This series is an update version of multiqueue virtio-net driver based on
Krishna Kumar's work to let virtio-net use multiple rx/tx queues to do the
packets reception and transmission. Please review and comments.
A protype implementation of qemu-kvm support could by found in
git://github.com/jasowang/qemu-kvm-mq.git. To start a guest with two queues, you
could specify the queues