Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp6525688rwl; Wed, 22 Mar 2023 11:44:20 -0700 (PDT) X-Google-Smtp-Source: AK7set9PYNUjQEd7i2v7GxVigU5VRUFxH4UoqXnv2GZU2iPjn4CPT3TwAuZSsqIPfoqZikYjW7Vf X-Received: by 2002:a62:18c1:0:b0:62a:443b:eb3 with SMTP id 184-20020a6218c1000000b0062a443b0eb3mr847907pfy.27.1679510659893; Wed, 22 Mar 2023 11:44:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679510659; cv=none; d=google.com; s=arc-20160816; b=Gj+/QW0oDx2/X/5T6Xdsmpupt2/RT6n3MZt24vKdtmh5pkSmf+ResHCrcPt+ljQ8IB S4dh01VgSmkodGgGoUb/JsB6qaLVGv/ZvBxcNCG5vi1jIatpEdHvjnzQ4PU8WZJ57riP PuMto8lVlMwn5pfY5h4ueb1xBUCwfHFyqhdt/trBnZTeLUUKH5fSgKyTXHQVqtnHFxiE weRafwCX1+CZsspYZKcKBdxZJBA1bv/VOjlSzfEIvkw2HL/0poa7cs/4r3X/RGzbdzcu cMUEbz8GMBb9vQXfXZDKW6wa9hV8Ht57OlxJsyDv608sqMMUGHzE+cgCA3Q4a4QgxBHZ ZSsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=FW8jr4pUz8iTbODmex7VnHAmCT1DPjH/4GpL+Pk/K5w=; b=fdO0wdOP3eL1FHQxG3f/jWVVWFsTGTKzEwOE7RiQwiIDyQroF6GynvaW1AvF6Ixt8P mHm7SGbx+AYLT/7CeXUbqzhzLZHKNlWFFulxZN4PrESsE5ri/kUcltHXHlifyjtKUL6Y 0YhJkuB2EOQI3dLqq6f1qocAFbnxjEdVMSSQY8+bK8wAfG7JkxOEf0ybI6EQkVuVW4tV Ap/yel4YFSOfIVfKjGSUyIGhWlc0COoIW30dXTX3r7HJlyr/wW/fqBLuqVCgV9nMH3+4 1win//oqNrvlrpHgoNe/d5lQ4JZM0Kb04Wzs8JkuFK2mOExEAiYDuTYGOpM9+Tm7xj2u qGcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=EMnTNape; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s73-20020a632c4c000000b0050bd4b86169si125916pgs.414.2023.03.22.11.44.07; Wed, 22 Mar 2023 11:44:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=EMnTNape; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229766AbjCVSmF (ORCPT + 99 others); Wed, 22 Mar 2023 14:42:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229436AbjCVSmD (ORCPT ); Wed, 22 Mar 2023 14:42:03 -0400 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6DD6E46142; Wed, 22 Mar 2023 11:42:01 -0700 (PDT) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id C13FF5FD3E; Wed, 22 Mar 2023 21:41:59 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1679510519; bh=FW8jr4pUz8iTbODmex7VnHAmCT1DPjH/4GpL+Pk/K5w=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; b=EMnTNapepoxBw+9De79Jnrf9xt9+Ww5heQcA1F5qDSdockR9CsAEwu66BsQf2iDRz MNHQj7U1ms3SmdGmHdM1wzPXHc5eX9rerFMyi4VyEi+FWISJJXmKY3pLu9vdjJuRDC 7aXZqNvcezeBlnfGVHXMbTPm1lWg76sfamAr4sx4ScDzjdmYx/eOBZ/ncZxT1Knw0B eqLekMEigPjBI4I8MQPCeliBtKQdmaYRaoG2qCCr64oLVeJjIFl8wqiAlQnbj244SC aOlmPUfpKzVdygOJ5S6pv2ifzJli8NPRPcCpeJjasFvUmso3zGngbJzivzVaMnCUIC U0t/iUw8QucIQ== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Wed, 22 Mar 2023 21:41:59 +0300 (MSK) Message-ID: <5651ac8a-db47-2462-e651-e5c6935847b9@sberdevices.ru> Date: Wed, 22 Mar 2023 21:38:44 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [RFC PATCH v4] virtio/vsock: allocate multiple skbuffs on tx Content-Language: en-US To: Stefano Garzarella CC: Stefan Hajnoczi , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Bobby Eshleman , , , , , , References: <0e0c1421-7cdc-2582-b120-cad6f42824bb@sberdevices.ru> <20230322144115.sz3icgbnhjgae2fj@sgarzare-redhat> From: Arseniy Krasnov In-Reply-To: <20230322144115.sz3icgbnhjgae2fj@sgarzare-redhat> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [172.16.1.6] X-ClientProxiedBy: S-MS-EXCH02.sberdevices.ru (172.16.1.5) To S-MS-EXCH01.sberdevices.ru (172.16.1.4) X-KSMG-Rule-ID: 4 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2023/03/22 14:20:00 #20991698 X-KSMG-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22.03.2023 17:41, Stefano Garzarella wrote: > On Tue, Mar 21, 2023 at 06:03:14PM +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/ >> Link to v3: >> https://lore.kernel.org/netdev/f33ef593-982e-2b3f-0986-6d537a3aaf08@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. >> >> v3 -> v4: >> - Use WARN_ONCE() to handle case when transport callback returns >>   unexpected value. >> - Remove useless 'ret = -EFAULT;' assignment for case above. >> >> 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..a300f25749ea 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; > > nit: this initialization seems superfluous since `ret` is > overwritten later ... > >> +    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); >> >> -    return t_ops->send_pkt(skb); >> +        ret = t_ops->send_pkt(skb); > > ... here. > >> + > > nit: we can remove this extra line > >> +        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 (WARN_ONCE(ret != skb_len, >> +                  "'send_pkt()' returns %i, but %zu expected\n", >> +                  ret, skb_len)) >> +            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; >> + >> +    return ret; >> } >> >> static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs, >> -- 2.25.1 >> > > The patch LGTM: > > Reviewed-by: Stefano Garzarella > > Anyway, feel free to include in the same series or as separate patch > also the changes to avoid useless lock in virtio_transport_put_credit() > and virtio_transport_get_credit(). > > I would include it in this series, because before these changes, we > used to call virtio_transport_put_credit() only in the error path, > while now we always call it, even when rest_len is 0. Thanks for review, done! https://lore.kernel.org/netdev/f0b283a1-cc63-dc3d-cc0c-0da7f684d4d2@sberdevices.ru/ Added it as second patch to the series Thanks, Arseniy > > Thanks, > Stefano >