requirements of the specification: "in-order, guaranteed,
connection-oriented delivery".
Thanks,
Stefano
>
>
> Best Wish
>
> - Original Message -
>
> Sender : Stefano Garzarella
>
> Date : 2025-02-11 00:52 (GMT+8)
>
> Title : Re: [PATCH 2/2]
On Mon, Feb 10, 2025 at 12:48:03PM +0100, leona...@redhat.com wrote:
Like for the other patch, some maintainers have not been CCd.
Yes, please use `scripts/get_maintainer.pl`.
On Fri, Feb 07, 2025 at 01:20:33PM +0800, Junnan Wu wrote:
From: Ying Gao
If suspend is executed during vsock com
On Fri, Feb 07, 2025 at 01:20:32PM +0800, Junnan Wu wrote:
From: Ying Gao
In function virtio_vsock_probe, it initializes the variables
"rx_buf_nr" and "rx_buf_max_nr",
but in function virtio_vsock_restore it doesn't.
Move the initizalition position into function virtio_vsock_vqs_start.
Once e
Like for the other patch, some maintainers have not been CCd.
On Fri, Feb 07, 2025 at 01:20:33PM +0800, Junnan Wu wrote:
From: Ying Gao
If suspend is executed during vsock communication and the
socket is reset, the original socket will be unusable after resume.
Judge the value of vdev->priv i
Hi Junnan, Ying
Thank you for the contribution!
A few minor comments on the process:
I think this series is missing a cover letter, not all the maintainers
have been CCd, and you should add the tag net (because it's a fix) to
the subject. (e.g. [PATCH net 1/2]).
Here you can find some useful
On Wed, Feb 5, 2025 at 8:57 AM Eric Dumazet wrote:
>
>
> I will squash this diff to the following iteration, and keep rcu_dereference()
>
>
I will shrink the series in V4 to only include known bug fixes, to
lower the risk of having 10 more iterations.
On Tue, Feb 4, 2025 at 10:30 PM Jakub Kicinski wrote:
>
> On Tue, 4 Feb 2025 13:17:08 -0800 Paul E. McKenney wrote:
> > > > TBH I'm slightly confused by this, and the previous warnings.
> > > >
> > > > The previous one was from a timer callback.
> > > >
> > > > This one is with BH disabled.
> > >
On Tue, Feb 04, 2025 at 01:30:25PM -0800, Jakub Kicinski wrote:
> On Tue, 4 Feb 2025 13:17:08 -0800 Paul E. McKenney wrote:
> > > > TBH I'm slightly confused by this, and the previous warnings.
> > > >
> > > > The previous one was from a timer callback.
> > > >
> > > > This one is with BH disabled.
On Tue, 4 Feb 2025 13:17:08 -0800 Paul E. McKenney wrote:
> > > TBH I'm slightly confused by this, and the previous warnings.
> > >
> > > The previous one was from a timer callback.
> > >
> > > This one is with BH disabled.
> > >
> > > I thought BH implies RCU protection. We certainly depend on tha
On Tue, Feb 04, 2025 at 10:06:15PM +0100, Eric Dumazet wrote:
> On Tue, Feb 4, 2025 at 10:00 PM Jakub Kicinski wrote:
> >
> > On Tue, 4 Feb 2025 21:10:59 +0100 Eric Dumazet wrote:
> > > > Test output:
> > > > https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/978202/61-l2tp-sh/
> > > > Decoded
On Tue, 4 Feb 2025 21:10:59 +0100 Eric Dumazet wrote:
> > Test output:
> > https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/978202/61-l2tp-sh/
> > Decoded:
> > https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/978202/vm-crash-thr2-0
> >
>
> Oh well. So many bugs.
TBH I'm slightly co
On Tue, Feb 4, 2025 at 10:00 PM Jakub Kicinski wrote:
>
> On Tue, 4 Feb 2025 21:10:59 +0100 Eric Dumazet wrote:
> > > Test output:
> > > https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/978202/61-l2tp-sh/
> > > Decoded:
> > > https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/978202/vm-c
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski :
On Tue, 28 Jan 2025 14:15:26 +0100 you wrote:
> Series deals with two issues:
> - socket reference count imbalance due to an unforgiving transport release
> (triggered by transport reassignment);
> - unintentional API f
On Tue, Jan 28, 2025 at 02:15:26PM +0100, Michal Luczaj wrote:
Series deals with two issues:
- socket reference count imbalance due to an unforgiving transport release
(triggered by transport reassignment);
- unintentional API feature, a failing connect() making the socket
impossible to use for
ingemar.s.johans...@ericsson.com;
> >mirja.kuehlew...@ericsson.com; chesh...@apple.com; rs.i...@gmx.at;
> >jason_living...@comcast.com; vidhi_g...@apple.com
> >Subject: Re: [PATCH v6 net-next 11/14] virtio_net: Accurate ECN flag in
> >virtio_net_hd
a.com; m...@redhat.com;
> > >xuanz...@linux.alibaba.com; epere...@redhat.com;
> > >virtualizat...@lists.linux.dev; i...@kernel.org; ncardw...@google.com;
> > >Koen De Schepper (Nokia) ;
> > >g.wh...@cablelabs.com; ingemar.s.johans...@ericsson.com;
> > &g
labs.com; ingemar.s.johans...@ericsson.com;
> >mirja.kuehlew...@ericsson.com; chesh...@apple.com; rs.i...@gmx.at;
> >jason_living...@comcast.com; vidhi_g...@apple.com
> >Subject: Re: [PATCH v6 net-next 11/14] virtio_net: Accurate ECN flag in
> >virtio_net_hdr
&
.alibaba.com; epere...@redhat.com;
>virtualizat...@lists.linux.dev; i...@kernel.org; ncardw...@google.com; Koen De
>Schepper (Nokia) ;
>g.wh...@cablelabs.com; ingemar.s.johans...@ericsson.com;
>mirja.kuehlew...@ericsson.com; chesh...@apple.com; rs.i...@gmx.at;
>jason_living...@comcast.com;
On Sat, Dec 28, 2024 at 3:13 AM wrote:
>
> From: Chia-Yu Chang
>
> Unlike RFC 3168 ECN, accurate ECN uses the CWR flag as part of the ACE
> field to count new packets with CE mark; however, it will be corrupted
> by the RFC 3168 ECN-aware TSO. Therefore, fallback shall be applied by
> seting NETI
On Fri, 27 Dec 2024 20:11:57 +0100 chia-yu.ch...@nokia-bell-labs.com
wrote:
> Hello
Hello.
Someone may still review, but:
## Form letter - winter-break
Networking development is suspended for winter holidays, until Jan 2nd.
We are currently accepting bug fixes only, see the announcements at:
h
On 12/20/24 11:49, Stefano Garzarella wrote:
> ...
> Note that non-NULL -> NULL should only occur before a connection is
> established, so before any data is passed. Is this a problem for BPF?
Please take a look at vsock_bpf_update_proto(). The condition is to have a
transport assigned. BPF assum
/net/vmw_vsock/vsock_bpf.c
+++ b/net/vmw_vsock/vsock_bpf.c
@@ -119,6 +119,7 @@ static void vsock_bpf_rebuild_protos(struct proto *prot,
const struct proto *bas
*prot= *base;
prot->close = sock_map_close;
prot->recvmsg = vsock_bpf_recvmsg;
+ prot->unhash
path can only be taken during vsock_connect(), where we
* have already held the sock lock. In the other cases, this
diff --git a/net/vmw_vsock/vsock_bpf.c b/net/vmw_vsock/vsock_bpf.c
index 4aa6e74ec295..80deb4d70aea 100644
--- a/net/vmw_vsock/vsock_bpf.c
+++ b/net/vmw_vsock/vsock_bpf.c
@@ -119,6 +119,7 @@ static void vsock_bpf_rebuild_protos(struct proto *prot,
const struct proto *bas
*prot= *base;
prot->close = sock_map_close;
prot->recvmsg = vsock_bpf_recvmsg;
+ prot->unhash = sock_map_unhash;
prot->sock_is_readable = sk_msg_is_readable;
}
>> Then a successful re-connect assigns
>> the transport (NULL -> non-NULL). And it's all good because all I wanted to
>> avoid (because of BPF) was non-NULL -> NULL. Anyway, that's my possibly
>> shallow understanding :)
connect() that requires a specific
> > transport, this one fails maybe because there's no peer with that cid.
> > Then the user can redo the connect() to a different cid that requires
> > a different transport.
>
> But the initial connect() failing does not change any
hange the transport.
>
> Because a user can do an initial connect() that requires a specific
> transport, this one fails maybe because there's no peer with that cid.
> Then the user can redo the connect() to a different cid that requires
> a different transport.
But the initial connect
On Thu, 19 Dec 2024 at 15:36, Michal Luczaj wrote:
>
> On 12/19/24 09:19, Stefano Garzarella wrote:
> > ...
> > I think the best thing though is to better understand how to handle
> > deassign, rather than checking everywhere that it's not null, also
> > because in some cases (like the one in virt
On 12/19/24 09:19, Stefano Garzarella wrote:
> ...
> I think the best thing though is to better understand how to handle
> deassign, rather than checking everywhere that it's not null, also
> because in some cases (like the one in virtio-vsock), it's also
> important that the transport is the sa
On Wed, Dec 18, 2024 at 08:37:38PM -0500, Hyunwoo Kim wrote:
On Thu, Dec 19, 2024 at 01:25:34AM +0100, Michal Luczaj wrote:
On 12/18/24 16:51, Hyunwoo Kim wrote:
> On Wed, Dec 18, 2024 at 04:31:03PM +0100, Stefano Garzarella wrote:
>> On Wed, Dec 18, 2024 at 03:40:40PM +0100, Stefano Garzarella
On Thu, Dec 19, 2024 at 01:25:34AM +0100, Michal Luczaj wrote:
> On 12/18/24 16:51, Hyunwoo Kim wrote:
> > On Wed, Dec 18, 2024 at 04:31:03PM +0100, Stefano Garzarella wrote:
> >> On Wed, Dec 18, 2024 at 03:40:40PM +0100, Stefano Garzarella wrote:
> >>> On Wed, Dec 18, 2024 at 09:19:08AM -0500, Hyu
On 12/18/24 16:51, Hyunwoo Kim wrote:
> On Wed, Dec 18, 2024 at 04:31:03PM +0100, Stefano Garzarella wrote:
>> On Wed, Dec 18, 2024 at 03:40:40PM +0100, Stefano Garzarella wrote:
>>> On Wed, Dec 18, 2024 at 09:19:08AM -0500, Hyunwoo Kim wrote:
At least for vsock_loopback.c, this change doesn’t
On Wed, Dec 18, 2024 at 04:31:03PM +0100, Stefano Garzarella wrote:
> On Wed, Dec 18, 2024 at 03:40:40PM +0100, Stefano Garzarella wrote:
> > On Wed, Dec 18, 2024 at 09:19:08AM -0500, Hyunwoo Kim wrote:
> > > On Wed, Dec 18, 2024 at 02:40:49PM +0100, Stefano Garzarella wrote:
> > > > On Wed, Dec 18
On Wed, Dec 18, 2024 at 03:40:40PM +0100, Stefano Garzarella wrote:
On Wed, Dec 18, 2024 at 09:19:08AM -0500, Hyunwoo Kim wrote:
On Wed, Dec 18, 2024 at 02:40:49PM +0100, Stefano Garzarella wrote:
On Wed, Dec 18, 2024 at 07:25:07AM -0500, Hyunwoo Kim wrote:
When calling connect to change the C
On Wed, Dec 18, 2024 at 09:19:08AM -0500, Hyunwoo Kim wrote:
On Wed, Dec 18, 2024 at 02:40:49PM +0100, Stefano Garzarella wrote:
On Wed, Dec 18, 2024 at 07:25:07AM -0500, Hyunwoo Kim wrote:
> When calling connect to change the CID of a vsock, the loopback
> worker for the VIRTIO_VSOCK_OP_RST com
On Wed, Dec 18, 2024 at 02:40:49PM +0100, Stefano Garzarella wrote:
> On Wed, Dec 18, 2024 at 07:25:07AM -0500, Hyunwoo Kim wrote:
> > When calling connect to change the CID of a vsock, the loopback
> > worker for the VIRTIO_VSOCK_OP_RST command is invoked.
> > During this process, vsock_stream_has
On Wed, Dec 18, 2024 at 07:25:07AM -0500, Hyunwoo Kim wrote:
When calling connect to change the CID of a vsock, the loopback
worker for the VIRTIO_VSOCK_OP_RST command is invoked.
During this process, vsock_stream_has_data() calls
vsk->transport->stream_has_data().
However, a null-ptr-deref occur
On 11/19/24 11:31, Stefano Garzarella wrote:
> Hi Michal,
>
> On Thu, Nov 07, 2024 at 09:46:11PM +0100, Michal Luczaj wrote:
>> Short series fixing some memory leaks that I've stumbled upon while
>> toying
>> with the selftests.
>
> Are these tests already upstream?
> I would like to add them to
Hi Michal,
On Thu, Nov 07, 2024 at 09:46:11PM +0100, Michal Luczaj wrote:
Short series fixing some memory leaks that I've stumbled upon while
toying
with the selftests.
Are these tests already upstream?
I would like to add them to my suite, can you tell me how to run them?
Thanks,
Stefano
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Tue, 12 Nov 2024 09:29:15 +0800 you wrote:
> v4:
> 1. rebase net-next
> 2. update the kdoc for the new APIs
>
> v3:
> 1. use sg_dma_address/length api to set the premapped sg
> 2. remove 'premappe
om; ingemar.s.johans...@ericsson.com;
>mirja.kuehlew...@ericsson.com; chesh...@apple.com; rs.i...@gmx.at;
>jason_living...@comcast.com; vidhi_g...@apple.com
>Subject: Re: [PATCH v5 net-next 09/13] gro: prevent ACE field corruption &
>better AccECN handling
>
>[You don't often ge
rja.kuehlew...@ericsson.com;
> > >chesh...@apple.com; rs.i...@gmx.at; jason_living...@comcast.com;
> > >vidhi_g...@apple.com
> > >Subject: Re: [PATCH v5 net-next 09/13] gro: prevent ACE field corruption &
> > >better AccECN handling
> > >
@netfilter.org; ncardw...@google.com; Koen De Schepper (Nokia)
> >; g.wh...@cablelabs.com;
> >ingemar.s.johans...@ericsson.com; mirja.kuehlew...@ericsson.com;
> >chesh...@apple.com; rs.i...@gmx.at; jason_living...@comcast.com;
> >vidhi_g...@apple.com
> >Subject:
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni :
On Thu, 07 Nov 2024 21:46:11 +0100 you wrote:
> Short series fixing some memory leaks that I've stumbled upon while toying
> with the selftests.
>
> Signed-off-by: Michal Luczaj
> ---
> Changes in v2:
> - Remove the refact
On Thu, 7 Nov 2024 16:54:56 +0800 Xuan Zhuo wrote:
> + * Returns zero or a negative error (ie. ENOSPC, ENOMEM, EIO).
> + * Returns zero or a negative error (ie. ENOSPC, ENOMEM, EIO).
Looks like we need a rebase, doesn't apply any more.
When you rebase please correct the kdoc, looks like the off
On 07.11.2024 23:46, Michal Luczaj wrote:
> Kernel queues MSG_ZEROCOPY completion notifications on the error queue.
> Where they remain, until explicitly recv()ed. To prevent memory leaks,
> clean up the queue when the socket is destroyed.
>
> unreferenced object 0x8881028beb00 (size 224):
On 07.11.2024 23:46, Michal Luczaj wrote:
> Add a missing kfree_skb() to prevent memory leaks.
>
> Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support")
> Reviewed-by: Stefano Garzarella
> Signed-off-by: Michal Luczaj
> ---
> net/vmw_vsock/virtio_transport_common.c | 1 +
> 1 file
On 06.11.2024 20:51, Michal Luczaj wrote:
> Add a missing kfree_skb() to prevent memory leaks.
>
> Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support")
> Signed-off-by: Michal Luczaj
> ---
> net/vmw_vsock/virtio_transport_common.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by:
On Mon, Nov 11, 2024 at 11:53 AM Xuan Zhuo wrote:
>
> On Thu, 7 Nov 2024 16:54:54 +0800, Xuan Zhuo
> wrote:
> > The subsequent commit needs to know whether every indirect buffer is
> > premapped or not. So we need to introduce an extra struct for every
> > indirect buffer to record this info.
>
On Thu, 7 Nov 2024 16:54:54 +0800, Xuan Zhuo
wrote:
> The subsequent commit needs to know whether every indirect buffer is
> premapped or not. So we need to introduce an extra struct for every
> indirect buffer to record this info.
>
> Signed-off-by: Xuan Zhuo
Hi, Jason
This also needs a rev
On Thu, Nov 7, 2024 at 4:55 PM Xuan Zhuo wrote:
>
> virtio-net rq submits premapped per-buffer by setting sg page to NULL;
>
> Signed-off-by: Xuan Zhuo
> ---
> drivers/net/virtio_net.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/v
On Thu, Nov 7, 2024 at 4:55 PM Xuan Zhuo wrote:
>
> Two APIs are introduced to submit premapped per-buffers.
>
> int virtqueue_add_inbuf_premapped(struct virtqueue *vq,
> struct scatterlist *sg, unsigned int num,
> void *data,
>
On Thu, Nov 7, 2024 at 4:55 PM Xuan Zhuo wrote:
>
> The subsequent commit needs to know whether every indirect buffer is
> premapped or not. So we need to introduce an extra struct for every
> indirect buffer to record this info.
>
> Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
Thanks
On Wed, Nov 6, 2024 at 3:42 PM Michael S. Tsirkin wrote:
>
> On Wed, Nov 06, 2024 at 09:44:39AM +0800, Jason Wang wrote:
> > > > > while (vq->split.vring.desc[i].flags & nextflag) {
> > > > > - vring_unmap_one_split(vq, i);
> > > > > + vring_unmap_one_split(vq,
On Thu, Nov 07, 2024 at 10:04:03PM +0100, Michal Luczaj wrote:
On 11/7/24 11:22, Stefano Garzarella wrote:
On Wed, Nov 06, 2024 at 06:51:21PM +0100, Michal Luczaj wrote:
Macro vsock_connected_sockets_vsk() has been unused since its introduction.
Instead of removing it, utilise it in vsock_inser
On Thu, Nov 07, 2024 at 09:46:13PM +0100, Michal Luczaj wrote:
Kernel queues MSG_ZEROCOPY completion notifications on the error queue.
Where they remain, until explicitly recv()ed. To prevent memory leaks,
clean up the queue when the socket is destroyed.
unreferenced object 0x8881028beb00 (s
On 11/7/24 11:22, Stefano Garzarella wrote:
> On Wed, Nov 06, 2024 at 06:51:21PM +0100, Michal Luczaj wrote:
>> Macro vsock_connected_sockets_vsk() has been unused since its introduction.
>> Instead of removing it, utilise it in vsock_insert_connected() where it's
>> been open-coded.
>>
>> No funct
On 11/7/24 11:17, Stefano Garzarella wrote:
> On Wed, Nov 06, 2024 at 06:51:19PM +0100, Michal Luczaj wrote:
>> Kernel queues MSG_ZEROCOPY completion notifications on the error queue.
>> Where they remain, until explicitly recv()ed. To prevent memory leaks,
>> clean up the queue when the socket is
On Wed, Nov 06, 2024 at 06:51:21PM +0100, Michal Luczaj wrote:
Macro vsock_connected_sockets_vsk() has been unused since its introduction.
Instead of removing it, utilise it in vsock_insert_connected() where it's
been open-coded.
No functional change intended.
Fixes: d021c344051a ("VSOCK: Intro
On Wed, Nov 06, 2024 at 06:51:20PM +0100, Michal Luczaj wrote:
Add a missing kfree_skb() to prevent memory leaks.
Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support")
Signed-off-by: Michal Luczaj
---
net/vmw_vsock/virtio_transport_common.c | 1 +
1 file changed, 1 insertion(+)
Revie
On Wed, Nov 06, 2024 at 06:51:19PM +0100, Michal Luczaj wrote:
Kernel queues MSG_ZEROCOPY completion notifications on the error queue.
Where they remain, until explicitly recv()ed. To prevent memory leaks,
clean up the queue when the socket is destroyed.
unreferenced object 0x8881028beb00 (s
On Wed, Nov 06, 2024 at 06:51:18PM +0100, Michal Luczaj wrote:
As the final stages of socket destruction may be delayed, it is possible
that virtio_transport_recv_listen() will be called after the accept_queue
has been flushed, but before the SOCK_DONE flag has been set. As a result,
sockets enqu
On Wed, 6 Nov 2024 04:16:07 -0500 Michael S. Tsirkin wrote:
> I thought it can but can't remember why now. OK, nm then, thanks!
FWIW (I think there was confusion in earlier discussions) we do merge
net into net-next once a week. So we can always apply stuff to net,
and then depending patches to ne
gt; > > In the last linux version, we disabled this feature to fix the
> > > > regress[1].
> > > >
> > > > The patch set is try to fix the problem and re-enable it.
> > > >
> > > > More info:
> > > > http://lore.kernel.org/al
regress[1].
> > >
> > > The patch set is try to fix the problem and re-enable it.
> > >
> > > More info:
> > > http://lore.kernel.org/all/20240820071913.68004-1-xuanz...@linux.alibaba.com
> >
> > Sorry to ping, Michael, Jason we're wa
On Wed, Nov 06, 2024 at 09:44:39AM +0800, Jason Wang wrote:
> > > > while (vq->split.vring.desc[i].flags & nextflag) {
> > > > - vring_unmap_one_split(vq, i);
> > > > + vring_unmap_one_split(vq, &extra[i]);
> > >
> > > Not sure if I've asked this before. But this
On Mon, Nov 04, 2024 at 06:46:41PM -0800, Jakub Kicinski wrote:
> On Tue, 29 Oct 2024 16:46:11 +0800 Xuan Zhuo wrote:
> > In the last linux version, we disabled this feature to fix the
> > regress[1].
> >
> > The patch set is try to fix the problem and re-enable it.
&g
On Tue, Oct 29, 2024 at 04:46:12PM +0800, Xuan Zhuo wrote:
> When the frag just got a page, then may lead to regression on VM.
> Specially if the sysctl net.core.high_order_alloc_disable value is 1,
> then the frag always get a page when do refill.
>
> Which could see reliable crashes or scp failu
On Wed, 6 Nov 2024 09:44:39 +0800, Jason Wang wrote:
> On Tue, Nov 5, 2024 at 2:53 PM Xuan Zhuo wrote:
> >
> > On Tue, 5 Nov 2024 11:42:09 +0800, Jason Wang wrote:
> > > On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo
> > > wrote:
> > > >
> > > > The subsequent commit needs to know whether every ind
On Wed, 6 Nov 2024 09:56:55 +0800, Jason Wang wrote:
> On Tue, Nov 5, 2024 at 3:23 PM Xuan Zhuo wrote:
> >
> > On Tue, 5 Nov 2024 11:23:50 +0800, Jason Wang wrote:
> > > On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo
> > > wrote:
> > > >
> > > > virtio-net rq submits premapped per-buffer by setting
On Tue, Nov 5, 2024 at 3:23 PM Xuan Zhuo wrote:
>
> On Tue, 5 Nov 2024 11:23:50 +0800, Jason Wang wrote:
> > On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo
> > wrote:
> > >
> > > virtio-net rq submits premapped per-buffer by setting sg page to NULL;
> > >
> > > Signed-off-by: Xuan Zhuo
> > > ---
>
On Tue, Nov 5, 2024 at 2:53 PM Xuan Zhuo wrote:
>
> On Tue, 5 Nov 2024 11:42:09 +0800, Jason Wang wrote:
> > On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo
> > wrote:
> > >
> > > The subsequent commit needs to know whether every indirect buffer is
> > > premapped or not. So we need to introduce an e
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni :
On Tue, 29 Oct 2024 16:46:11 +0800 you wrote:
> v1:
> 1. fix some small problems
> 2. remove commit "virtio_net: introduce vi->mode"
>
> In the last linux version, we disabled this feature to fix the
> regress[
On Tue, Oct 29, 2024 at 4:47 PM Xuan Zhuo wrote:
>
> Now, the premapped mode can be enabled unconditionally.
>
> So we can remove the failover code for merge and small mode.
>
> The virtnet_rq_xxx() helper would be only used if the mode is using pre
> mapping. A check is added to prevent misusing
On Tue, Oct 29, 2024 at 4:47 PM Xuan Zhuo wrote:
>
> When the frag just got a page, then may lead to regression on VM.
> Specially if the sysctl net.core.high_order_alloc_disable value is 1,
> then the frag always get a page when do refill.
>
> Which could see reliable crashes or scp failure (scp
On Tue, 5 Nov 2024 11:42:09 +0800, Jason Wang wrote:
> On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo wrote:
> >
> > The subsequent commit needs to know whether every indirect buffer is
> > premapped or not. So we need to introduce an extra struct for every
> > indirect buffer to record this info.
> >
On Tue, 5 Nov 2024 11:23:50 +0800, Jason Wang wrote:
> On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo wrote:
> >
> > virtio-net rq submits premapped per-buffer by setting sg page to NULL;
> >
> > Signed-off-by: Xuan Zhuo
> > ---
> > drivers/net/virtio_net.c | 24 +---
> > 1 file
Hi Jakub:
On Tue, Nov 5, 2024 at 10:46 AM Jakub Kicinski wrote:
>
> On Tue, 29 Oct 2024 16:46:11 +0800 Xuan Zhuo wrote:
> > In the last linux version, we disabled this feature to fix the
> > regress[1].
> >
> > The patch set is try to fix the problem and r
On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo wrote:
>
> Now, this API is useless. remove it.
>
> Signed-off-by: Xuan Zhuo
Acked-by: Jason Wang
Thanks
On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo wrote:
>
> Two APIs are introduced to submit premapped per-buffers.
>
> int virtqueue_add_inbuf_premapped(struct virtqueue *vq,
> struct scatterlist *sg, unsigned int num,
> void *data,
>
On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo wrote:
>
> The current configuration sets the virtqueue (vq) to premapped mode,
> implying that all buffers submitted to this queue must be mapped ahead
> of time. This presents a challenge for the virtnet send queue (sq): the
> virtnet driver would be req
On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo wrote:
>
> The subsequent commit needs to know whether every indirect buffer is
> premapped or not. So we need to introduce an extra struct for every
> indirect buffer to record this info.
>
> Signed-off-by: Xuan Zhuo
> ---
> drivers/virtio/virtio_ring.c
On Wed, Oct 30, 2024 at 4:25 PM Xuan Zhuo wrote:
>
> virtio-net rq submits premapped per-buffer by setting sg page to NULL;
>
> Signed-off-by: Xuan Zhuo
> ---
> drivers/net/virtio_net.c | 24 +---
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/ne
On Tue, 29 Oct 2024 16:46:11 +0800 Xuan Zhuo wrote:
> In the last linux version, we disabled this feature to fix the
> regress[1].
>
> The patch set is try to fix the problem and re-enable it.
>
> More info:
> http://lore.kernel.org/all/20240820071913.68004-1-xuanz...@lin
Hi Xuan,
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/Xuan-Zhuo/virtio_ring-introduce-vring_need_unmap_buffer/20241030-162739
base: net-next/main
patch link:
https://lore.kernel.or
On Fri, Oct 25, 2024 at 10:35:53AM +0800, Xuan Zhuo wrote:
> On Thu, 17 Oct 2024 15:42:59 +0200, Paolo Abeni wrote:
> >
> >
> > On 10/14/24 05:12, Xuan Zhuo wrote:
> > > When the frag just got a page, then may lead to regression on VM.
> > > Specially if the sysctl net.core.high_order_alloc_disabl
On Fri, 18 Oct 2024 15:41:41 +0800, Jason Wang wrote:
> On Mon, Oct 14, 2024 at 11:12 AM Xuan Zhuo wrote:
> >
> > When the frag just got a page, then may lead to regression on VM.
> > Specially if the sysctl net.core.high_order_alloc_disable value is 1,
> > then the frag always get a page when do
> > After | 1109316pps | 742853pps
> >
> > In the 6.11, we disabled this feature because a regress [1].
> >
> > Now, we fix the problem and re-enable it.
> >
> > [1]:
> > http://lore.kernel.org/all/8b20cc28-45a9-4643-8e87-ba164a540...@oracle.com
&
On Fri, 18 Oct 2024 15:48:38 +0800, Jason Wang wrote:
> On Mon, Oct 14, 2024 at 11:12 AM Xuan Zhuo wrote:
> >
> > Now, if we want to judge the rx work mode, we have to use such codes:
> >
> > 1. merge mode: vi->mergeable_rx_bufs
> > 2. big mode: vi->big_packets && !vi->mergeable_rx_bufs
> > 3.
On Thu, 17 Oct 2024 15:42:59 +0200, Paolo Abeni wrote:
>
>
> On 10/14/24 05:12, Xuan Zhuo wrote:
> > When the frag just got a page, then may lead to regression on VM.
> > Specially if the sysctl net.core.high_order_alloc_disable value is 1,
> > then the frag always get a page when do refill.
> >
>
On Thu, Oct 17, 2024 at 03:42:59PM +0200, Paolo Abeni wrote:
>
>
> On 10/14/24 05:12, Xuan Zhuo wrote:
> > When the frag just got a page, then may lead to regression on VM.
> > Specially if the sysctl net.core.high_order_alloc_disable value is 1,
> > then the frag always get a page when do refill
t 14, 2024 at 11:12:29AM +0800, Xuan Zhuo wrote:
> >>> In the last linux version, we disabled this feature to fix the
> >>> regress[1].
> >>>
> >>> The patch set is try to fix the problem and re-enable it.
> >>>
> >>> More i
this feature to fix the
>>> regress[1].
>>>
>>> The patch set is try to fix the problem and re-enable it.
>>>
>>> More info:
>>> http://lore.kernel.org/all/20240820071913.68004-1-xuanz...@linux.alibaba.com
>>>
>>> Thank
lloc frag. This is beneficial for the iommu device.
>
> kernel command line: intel_iommu=on iommu.passthrough=0
>
>| strict=0 | strict=1
> Before | 775496pps | 428614pps
> After | 1109316pps | 742853pps
>
> In the 6.11, we disabled this feature because a regress [1].
&g
On Mon, Oct 14, 2024 at 11:12 AM Xuan Zhuo wrote:
>
> Now, if we want to judge the rx work mode, we have to use such codes:
>
> 1. merge mode: vi->mergeable_rx_bufs
> 2. big mode: vi->big_packets && !vi->mergeable_rx_bufs
> 3. small: !vi->big_packets && !vi->mergeable_rx_bufs
>
> This is inc
On Mon, Oct 14, 2024 at 11:12 AM Xuan Zhuo wrote:
>
> Now, the premapped mode can be enabled unconditionally.
>
> So we can remove the failover code for merge and small mode.
>
> Signed-off-by: Xuan Zhuo
Let's be more verbose here. For example, the virtnet_rq_xxx() helper
would be only used if t
On Mon, Oct 14, 2024 at 11:12 AM Xuan Zhuo wrote:
>
> When the frag just got a page, then may lead to regression on VM.
> Specially if the sysctl net.core.high_order_alloc_disable value is 1,
> then the frag always get a page when do refill.
>
> Which could see reliable crashes or scp failure (scp
On 10/14/24 05:12, Xuan Zhuo wrote:
When the frag just got a page, then may lead to regression on VM.
Specially if the sysctl net.core.high_order_alloc_disable value is 1,
then the frag always get a page when do refill.
Which could see reliable crashes or scp failure (scp a file 100M in size
Hi Michael,
On Monday, 2024-10-14 at 00:57:41 -04, Michael S. Tsirkin wrote:
> On Mon, Oct 14, 2024 at 11:12:29AM +0800, Xuan Zhuo wrote:
>> In the last linux version, we disabled this feature to fix the
>> regress[1].
>>
>> The patch set is try to fix the problem an
On Mon, Oct 14, 2024 at 11:12:29AM +0800, Xuan Zhuo wrote:
> In the last linux version, we disabled this feature to fix the
> regress[1].
>
> The patch set is try to fix the problem and re-enable it.
>
> More info:
> http://lore.kernel.org/all/20240820071913.68004-1-xuanz
8-45a9-4643-8e87-ba164a540...@oracle.com
> > >
> > > I still think that the patch can fix the problem, I hope Darren can
> > > re-test it
> > > or give me more info.
> > >
> > >
> > > http://lore.kernel.org/all/20240820071913.68004-1-xuanz
an fix the problem, I hope Darren can re-test
> > it
> > or give me more info.
> >
> >
> > http://lore.kernel.org/all/20240820071913.68004-1-xuanz...@linux.alibaba.com
> >
> > If that can not work or Darren can not reply in time, Michael you can try
&g
1 - 100 of 17847 matches
Mail list logo
