Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CFAE9C74A5B for ; Tue, 21 Mar 2023 08:41:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230344AbjCUIlr (ORCPT ); Tue, 21 Mar 2023 04:41:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229635AbjCUIlm (ORCPT ); Tue, 21 Mar 2023 04:41:42 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6DB6F43936 for ; Tue, 21 Mar 2023 01:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679388010; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3ue5AFGaReKj/xnbY98VYj9OaV+WVOdpiOY5id9iIGc=; b=Dhbno0w/uBzR8s2EiaHZEcjlQsBw2xdUMzXroMYDPXcNn4yHllSx7VHKd6wm+/NcwAERXc vuVxJptjk+F1G9fOaHstNwyEtyAdg/XJNDC3NbY8D8NVFBK1frlWbsn+Udh/CeM6yDBfxq XOSWR8wgaSMCulxvRBNMRBv54SxoN/w= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-503-Xc1kjUkDNKaASZ-zAc1IDQ-1; Tue, 21 Mar 2023 04:40:08 -0400 X-MC-Unique: Xc1kjUkDNKaASZ-zAc1IDQ-1 Received: by mail-qv1-f71.google.com with SMTP id jo13-20020a056214500d00b004c6c72bf1d0so7253887qvb.9 for ; Tue, 21 Mar 2023 01:40:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679388008; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3ue5AFGaReKj/xnbY98VYj9OaV+WVOdpiOY5id9iIGc=; b=7d3KDh5KOny2jURfrFWOHJvWAzvN0Ye/fOxdcRUkj6K56iFjNI0wv1s6FDIJS2VV6S Oz/bJMusG/tHiL0sSOrCUbzmBr8CV9Zq5+hu2fCKmuuR10UP9MXzl1p0KJd1Oai7FKTv ydRFxq9ylvby6EqmqJVZ2ev6DWxqTxWrfeOUQuMtQHkpyHcbBPx3Gd1BSUgKlGgKGhgA dSjZKwAOhEnicqBUMAINaPg7DQ97roftnlEhcxSE9kOh8fCxsZFygkcSFMsiZ8KMNzsG I4VhEGW7FZ3kga5V+s/TJFYtZ9u9ghH1R26mGZy0vxaupgjw5Yog5/HmLUusu9mZmjov 8eXQ== X-Gm-Message-State: AO0yUKWb9y6yFbfBa0TwLIwXhCcorYyKeNo6mNk4NfxeFu1SRaQlizZk lgRTODav+giRMioz3Z6oOhu9fMjXdLVqhRma5UafUO+MSplcUphB0a/rkaGRZXuj002OFAQJWR0 oqWwH+6bvKeT4DfxJ2ZI95c+j X-Received: by 2002:ac8:7f82:0:b0:3b8:6ae9:b10d with SMTP id z2-20020ac87f82000000b003b86ae9b10dmr2446530qtj.2.1679388008125; Tue, 21 Mar 2023 01:40:08 -0700 (PDT) X-Google-Smtp-Source: AK7set8QDeZYCc7+c7IEn1uW0Jnl2bYqoqO+r68HTwXQ2vd7mj/LnUa34SC9AX/rzKtTfj6hGS72jQ== X-Received: by 2002:ac8:7f82:0:b0:3b8:6ae9:b10d with SMTP id z2-20020ac87f82000000b003b86ae9b10dmr2446521qtj.2.1679388007827; Tue, 21 Mar 2023 01:40:07 -0700 (PDT) Received: from sgarzare-redhat (host-82-57-51-170.retail.telecomitalia.it. [82.57.51.170]) by smtp.gmail.com with ESMTPSA id h12-20020ac8548c000000b003d58d0297e5sm8076455qtq.3.2023.03.21.01.40.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Mar 2023 01:40:07 -0700 (PDT) Date: Tue, 21 Mar 2023 09:40:02 +0100 From: Stefano Garzarella To: Arseniy Krasnov Cc: Stefan Hajnoczi , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Bobby Eshleman , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kernel@sberdevices.ru, oxffffaa@gmail.com Subject: Re: [RFC PATCH v3] virtio/vsock: allocate multiple skbuffs on tx Message-ID: <20230321084002.5anjcr3ikw3ynbse@sgarzare-redhat> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 21, 2023 at 12:31:48AM +0300, Arseniy Krasnov wrote: >This adds small optimization for tx path: instead of allocating single >skbuff on every call to transport, allocate multiple skbuff's until >credit space allows, thus trying to send as much as possible data without >return to af_vsock.c. > >Signed-off-by: Arseniy Krasnov >--- > Link to v1: > https://lore.kernel.org/netdev/2c52aa26-8181-d37a-bccd-a86bd3cbc6e1@sberdevices.ru/ > Link to v2: > https://lore.kernel.org/netdev/ea5725eb-6cb5-cf15-2938-34e335a442fa@sberdevices.ru/ > > Changelog: > v1 -> v2: > - If sent something, return number of bytes sent (even in > case of error). Return error only if failed to sent first > skbuff. > > v2 -> v3: > - Handle case when transport callback returns unexpected value which > is not equal to 'skb->len'. Break loop. > - Don't check for zero value of 'rest_len' before calling > 'virtio_transport_put_credit()'. Decided to add this check directly > to 'virtio_transport_put_credit()' in separate patch. > > net/vmw_vsock/virtio_transport_common.c | 59 +++++++++++++++++++------ > 1 file changed, 45 insertions(+), 14 deletions(-) > >diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c >index 6564192e7f20..e0b2c6ecbe22 100644 >--- a/net/vmw_vsock/virtio_transport_common.c >+++ b/net/vmw_vsock/virtio_transport_common.c >@@ -196,7 +196,8 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk, > const struct virtio_transport *t_ops; > struct virtio_vsock_sock *vvs; > u32 pkt_len = info->pkt_len; >- struct sk_buff *skb; >+ u32 rest_len; >+ int ret; > > info->type = virtio_transport_get_type(sk_vsock(vsk)); > >@@ -216,10 +217,6 @@ 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_MAX_PKT_BUF_SIZE) >- pkt_len = VIRTIO_VSOCK_MAX_PKT_BUF_SIZE; >- > /* virtio_transport_get_credit might return less than pkt_len credit */ > pkt_len = virtio_transport_get_credit(vvs, pkt_len); > >@@ -227,17 +224,51 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk, > if (pkt_len == 0 && info->op == VIRTIO_VSOCK_OP_RW) > return pkt_len; > >- skb = virtio_transport_alloc_skb(info, pkt_len, >- src_cid, src_port, >- dst_cid, dst_port); >- if (!skb) { >- virtio_transport_put_credit(vvs, pkt_len); >- return -ENOMEM; >- } >+ ret = 0; >+ rest_len = pkt_len; >+ >+ do { >+ struct sk_buff *skb; >+ size_t skb_len; >+ >+ skb_len = min_t(u32, VIRTIO_VSOCK_MAX_PKT_BUF_SIZE, rest_len); >+ >+ skb = virtio_transport_alloc_skb(info, skb_len, >+ src_cid, src_port, >+ dst_cid, dst_port); >+ if (!skb) { >+ ret = -ENOMEM; >+ break; >+ } >+ >+ virtio_transport_inc_tx_pkt(vvs, skb); > >- virtio_transport_inc_tx_pkt(vvs, skb); >+ ret = t_ops->send_pkt(skb); > >- return t_ops->send_pkt(skb); >+ if (ret < 0) >+ break; >+ >+ /* Both virtio and vhost 'send_pkt()' returns 'skb_len', >+ * but for reliability use 'ret' instead of 'skb_len'. >+ * Also if partial send happens (e.g. 'ret' != 'skb_len') >+ * somehow, we break this loop, but account such returned >+ * value in 'virtio_transport_put_credit()'. >+ */ >+ rest_len -= ret; >+ >+ if (ret != skb_len) { >+ ret = -EFAULT; Okay, but `ret` will be overwritten by the check we have before the return ... >+ break; >+ } >+ } while (rest_len); >+ >+ virtio_transport_put_credit(vvs, rest_len); >+ >+ /* Return number of bytes, if any data has been sent. */ >+ if (rest_len != pkt_len) >+ ret = pkt_len - rest_len; ... here. Since we don't expect this condition for now, perhaps we can avoid setting ret with -EFAULT, but we can add a WARN_ONCE (interrupting the loop as you did here). This way we return the partial length as we did before. Thanks, Stefano >+ >+ return ret; > } > > static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs, >-- >2.25.1 >