Hi Heng,
kernel test robot noticed the following build warnings:
[auto build test WARNING on net-next/main]
url:
https://github.com/intel-lab-lkp/linux/commits/Heng-Qi/virtio_net-passing-control_buf-explicitly/20240620-002212
base: net-next/main
patch link:
https://lore.kernel.org/r/20
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Tue, 18 Jun 2024 16:44:56 +0200 you wrote:
> From: Jiri Pirko
>
> Add support for Byte Queue Limits (BQL).
>
> Tested on qemu emulated virtio_net device with 1, 2 and 4 queues.
> Tested with fq_codel and pfifo_f
On Wed, Jun 19, 2024 at 10:56 AM Li RongQing wrote:
>
> This place is fetching the stats, so u64_stats_fetch_begin
> and u64_stats_fetch_retry should be used
>
> Fixes: 6208799553a8 ("virtio-net: support rx netdim")
> Signed-off-by: Li RongQing
Acked-by: Jason Wang
Thanks
On Thu, Jun 20, 2024 at 12:19:05AM +0800, Heng Qi wrote:
> @@ -5312,7 +5315,7 @@ static int virtnet_find_vqs(struct virtnet_info *vi)
>
> /* Parameters for control virtqueue, if any */
> if (vi->has_cvq) {
> - callbacks[total_vqs - 1] = NULL;
> + callbacks[tota
On Thu, Jun 20, 2024 at 12:19:03AM +0800, Heng Qi wrote:
> Ctrlq in polling mode may cause the virtual machine to hang and
> occupy additional CPU resources. Enabling the irq for ctrlq
> alleviates this problem and allows commands to be requested
> concurrently.
Any patch that is supposed to be a
Currently, control vq handles commands synchronously,
leading to increased delays for dim commands during multi-queue
VM configuration and directly impacting dim performance.
To address this, we are shifting to asynchronous processing of
ctrlq's dim commands.
Signed-off-by: Heng Qi
---
drivers/
Refactor the command handling logic by splitting
virtnet_send_command_reply into virtnet_add_command_reply
and virtnet_wait_command_response for better clarity and
subsequent use.
Signed-off-by: Heng Qi
---
drivers/net/virtio_net.c | 53
1 file changed, 3
Previously, control vq only allowed a single request to be sent,
so using virtnet_info as a global token was fine. To support
concurrent requests, the driver needs to use a command-level token
to distinguish between requests that have been sent.
Signed-off-by: Heng Qi
---
drivers/net/virtio_net.
If the device does not respond to a request for a long time,
then control vq polling elevates CPU utilization, a problem that
exacerbates with more command requests.
Enabling control vq's irq is advantageous for the guest, and
this still doesn't support concurrent requests.
Suggested-by: Jason Wa
In a later patch, the driver may send requests concurrently, in
which case each command will have its own control buffer, so we
refactor virtnet_send_command_reply() to pass the control buffer
explicitly as a parameter.
Signed-off-by: Heng Qi
---
drivers/net/virtio_net.c | 22 ---
Ctrlq in polling mode may cause the virtual machine to hang and
occupy additional CPU resources. Enabling the irq for ctrlq
alleviates this problem and allows commands to be requested
concurrently.
Changelog
=
v3->v4:
- Turn off the switch before flush the get_cvq work.
- Add interrupt
在 2024/6/19 下午11:08, Jakub Kicinski 写道:
On Wed, 19 Jun 2024 10:02:58 +0800 Heng Qi wrote:
Currently we do not allow RXCUSM to be disabled.
You don't have to disable checksuming in the device.
Yes, it is up to the device itself to decide whether to validate checksum.
What I mean is that we do
On Wed, 19 Jun 2024 10:02:58 +0800 Heng Qi wrote:
> > > Currently we do not allow RXCUSM to be disabled.
> >
> > You don't have to disable checksuming in the device.
>
> Yes, it is up to the device itself to decide whether to validate checksum.
> What I mean is that we don't allow users to di
Wed, Jun 19, 2024 at 10:23:25AM CEST, m...@redhat.com wrote:
>On Wed, Jun 19, 2024 at 10:05:41AM +0200, Jiri Pirko wrote:
>> >Oh. Right of course. Worth a comment maybe? Just to make sure
>> >we remember not to call __free_old_xmit twice in a row
>> >without reinitializing stats.
>> >Or move the in
Hello:
This series was applied to netdev/net.git (main)
by David S. Miller :
On Mon, 17 Jun 2024 21:15:22 +0800 you wrote:
> This series of patches aim to address two specific issues identified in
> the virtio_net driver related to checksum offloading and XDP processing of
> fully checksummed pac
On Wed, Jun 19, 2024 at 10:55:29AM +0800, Li RongQing wrote:
> This place is fetching the stats, so u64_stats_fetch_begin
> and u64_stats_fetch_retry should be used
>
> Fixes: 6208799553a8 ("virtio-net: support rx netdim")
> Signed-off-by: Li RongQing
Acked-by: Michael S. Tsirkin
> ---
> driv
On Wed, Jun 19, 2024 at 10:05:41AM +0200, Jiri Pirko wrote:
> >Oh. Right of course. Worth a comment maybe? Just to make sure
> >we remember not to call __free_old_xmit twice in a row
> >without reinitializing stats.
> >Or move the initialization into __free_old_xmit to make it
> >self-contained ..
On Wed, Jun 19, 2024 at 10:05:41AM +0200, Jiri Pirko wrote:
> Wed, Jun 19, 2024 at 09:26:22AM CEST, m...@redhat.com wrote:
> >On Wed, Jun 19, 2024 at 07:45:16AM +0200, Jiri Pirko wrote:
> >> Tue, Jun 18, 2024 at 08:18:12PM CEST, m...@redhat.com wrote:
> >> >This looks like a sensible way to do this
Wed, Jun 19, 2024 at 04:55:29AM CEST, lirongq...@baidu.com wrote:
>This place is fetching the stats, so u64_stats_fetch_begin
>and u64_stats_fetch_retry should be used
>
>Fixes: 6208799553a8 ("virtio-net: support rx netdim")
>Signed-off-by: Li RongQing
Reviewed-by: Jiri Pirko
Wed, Jun 19, 2024 at 09:26:22AM CEST, m...@redhat.com wrote:
>On Wed, Jun 19, 2024 at 07:45:16AM +0200, Jiri Pirko wrote:
>> Tue, Jun 18, 2024 at 08:18:12PM CEST, m...@redhat.com wrote:
>> >This looks like a sensible way to do this.
>> >Yet something to improve:
>> >
>> >
>> >On Tue, Jun 18, 2024 a
On Wed, 19 Jun 2024 10:55:29 +0800, Li RongQing wrote:
> This place is fetching the stats, so u64_stats_fetch_begin
> and u64_stats_fetch_retry should be used
Reviewed-by: Heng Qi
Thanks!
>
> Fixes: 6208799553a8 ("virtio-net: support rx netdim")
> Signed-off-by: Li RongQing
> ---
> drivers/
On Wed, Jun 19, 2024 at 07:45:16AM +0200, Jiri Pirko wrote:
> Tue, Jun 18, 2024 at 08:18:12PM CEST, m...@redhat.com wrote:
> >This looks like a sensible way to do this.
> >Yet something to improve:
> >
> >
> >On Tue, Jun 18, 2024 at 04:44:56PM +0200, Jiri Pirko wrote:
> >> From: Jiri Pirko
> >>
>
22 matches
Mail list logo
