Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp111380yba; Fri, 5 Apr 2019 03:08:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqzE243LUcp2sxhGrg0lcxW6omk0geOuJtlht7lDLW5dCcHKCGC75Xl20iXd6OacfA2SGn61 X-Received: by 2002:a63:3281:: with SMTP id y123mr4408123pgy.272.1554458932498; Fri, 05 Apr 2019 03:08:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554458932; cv=none; d=google.com; s=arc-20160816; b=wB2LGS1aP1Ge9rNgOA+J/beGQqBURTuxhgalqu47C0kiFVUWElz3+0fiLz9WvLL3qC XlYqJrkp8snfI+Xdw+h34YmV9MRsjS+bGeHFZIm1DKBCazjQxzX1mcQ1OrViOdOVol2z kiaBxK9MOxN8D5lV0Au6A/WhLO7ENm2co0QSwT588Yh4/3bSRnu2Oiv3IRjwBpmjfU7d Flyvw6urRQ7PTw5ssubh+hTEg/ptEPOirM3R67hd6L4Z+CvbmFFX7qnH+32jYCmm0+Ix jZzNR+9nMt+hy00zpMsvsj6DwIKyKzis3pGjzAlT3Je19ExG/GmWj3BBuFtzBQLKWi3j JE+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=+/aW/JnHthgCgmq08tiXc9L78L5w7omyhaWJ3j/podY=; b=TOnJIyQLFDo4qF+CvhqFdVpyGmQk0Kzvq5jLtWxB800h4DfjamTMVTgnNIG4SmPsRX loddv+GM3uyO+QsOaLWgV5ady8DjEmDz02vgldskNB5weEJdNA/oxJhHjjTSSd5ZDjt9 Q/A1NsPIeWDn/YqxPnOf8Ynf4v2umhd0dSIX1Kd18Zm826WydTFSwwb0QKLUZM3SrEJm 0lCaLDikVzT3HTtkgbcmTUgl1aD0QfgRTRY/KbdZj1tCuSXmwzjtZu3KQ/zINeZ2GLwx mz3Sj5RehpssLp2aU9wkJHf81HKWWRXsFcWC73nqu0t4IXGAzlTgqZg/diS3O2UXHotN s++A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f89si19218700plb.20.2019.04.05.03.08.36; Fri, 05 Apr 2019 03:08:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730762AbfDEKHy (ORCPT + 99 others); Fri, 5 Apr 2019 06:07:54 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:54828 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730565AbfDEKHw (ORCPT ); Fri, 5 Apr 2019 06:07:52 -0400 Received: by mail-wm1-f66.google.com with SMTP id c1so6024235wml.4 for ; Fri, 05 Apr 2019 03:07:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+/aW/JnHthgCgmq08tiXc9L78L5w7omyhaWJ3j/podY=; b=Qzzr3WhrdhnWHroDOXt0Adk7EmVS/YzZH+cTvj2+GwBnKg1sKYgaUOzPxZV739V3F3 aoTwL/PSy9se9aO8Z1QAki1pPX9y0DZC7lnMb77OuHJr8wN1MGRsF6YCrx9A6yC1oYPp L+KpaCPngNxATHK0oZlkA5Bnl/mvfQFQO2/3z363uMvOo3YBvM4LzlxqVk1MoFM1nc37 eVmJFRQlaz54pY1fUrdhBd1Jh3N9eI4fw5tAk6EDTFAxW1klk3bYDDfDylrdVBlUc6Xb 0G7+T+dm+47+CmChoVmoqHSkD4R6jrY1jK76jbw5oBzhykkV4fo0j3A8HvI8DqU45jkC kQiA== X-Gm-Message-State: APjAAAWL3CBK+UI3sHyGy9F1PDCr8gqUWHEX/v7+N7M92zykNbnjxldn hhO6UMSpOAS+BAcLqkjhOowL5lTmNc8= X-Received: by 2002:a1c:39d7:: with SMTP id g206mr6721658wma.99.1554458870928; Fri, 05 Apr 2019 03:07:50 -0700 (PDT) Received: from steredhat (host35-203-static.12-87-b.business.telecomitalia.it. [87.12.203.35]) by smtp.gmail.com with ESMTPSA id n11sm32222748wrt.63.2019.04.05.03.07.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 05 Apr 2019 03:07:50 -0700 (PDT) Date: Fri, 5 Apr 2019 12:07:47 +0200 From: Stefano Garzarella To: Stefan Hajnoczi Cc: netdev@vger.kernel.org, Jason Wang , "Michael S. Tsirkin" , Stefan Hajnoczi , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, "David S. Miller" Subject: Re: [PATCH RFC 3/4] vsock/virtio: change the maximum packet size allowed Message-ID: <20190405100747.dbwi3sjaudp3d2wa@steredhat> References: <20190404105838.101559-1-sgarzare@redhat.com> <20190404105838.101559-4-sgarzare@redhat.com> <20190405082447.GD25152@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190405082447.GD25152@stefanha-x1.localdomain> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 05, 2019 at 09:24:47AM +0100, Stefan Hajnoczi wrote: > On Thu, Apr 04, 2019 at 12:58:37PM +0200, Stefano Garzarella wrote: > > Since now we are able to split packets, we can avoid limiting > > their sizes to VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE. > > Instead, we can use VIRTIO_VSOCK_MAX_PKT_BUF_SIZE as the max > > packet size. > > > > Signed-off-by: Stefano Garzarella > > --- > > net/vmw_vsock/virtio_transport_common.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c > > index f32301d823f5..822e5d07a4ec 100644 > > --- a/net/vmw_vsock/virtio_transport_common.c > > +++ b/net/vmw_vsock/virtio_transport_common.c > > @@ -167,8 +167,8 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk, > > vvs = vsk->trans; > > > > /* we can send less than pkt_len bytes */ > > - if (pkt_len > VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE) > > - pkt_len = VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE; > > + if (pkt_len > VIRTIO_VSOCK_MAX_PKT_BUF_SIZE) > > + pkt_len = VIRTIO_VSOCK_MAX_PKT_BUF_SIZE; > > The next line limits pkt_len based on available credits: > > /* virtio_transport_get_credit might return less than pkt_len credit */ > pkt_len = virtio_transport_get_credit(vvs, pkt_len); > > I think drivers/vhost/vsock.c:vhost_transport_do_send_pkt() now works > correctly even with pkt_len > VIRTIO_VSOCK_MAX_PKT_BUF_SIZE. Correct. > > The other ->send_pkt() callback is > net/vmw_vsock/virtio_transport.c:virtio_transport_send_pkt_work() and it > can already send any size packet. > > Do you remember why VIRTIO_VSOCK_MAX_PKT_BUF_SIZE still needs to be the > limit? I'm wondering if we can get rid of it now and just limit packets > to the available credits. There are 2 reasons why I left this limit: 1. When the host receives a packets, it must be <= VIRTIO_VSOCK_MAX_PKT_BUF_SIZE [drivers/vhost/vsock.c:vhost_vsock_alloc_pkt()] So in this way we can limit the packets sent from the guest. 2. When the host send packets, it help us to increase the parallelism (especially if the guest has 64 KB RX buffers) because the user thread will split packets, calling multiple times transport->stream_enqueue() in net/vmw_vsock/af_vsock.c:vsock_stream_sendmsg() while the vhost_transport_send_pkt_work() send them to the guest. Do you think make sense? Thanks, Stefano