From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 43FA4A00BE; Tue, 7 Jul 2020 18:26:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DBD0B1DC4B; Tue, 7 Jul 2020 18:26:00 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id DA5F41DC34 for ; Tue, 7 Jul 2020 18:25:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1594139158; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=dvLZ0+sSY5YGQlNh3v2ls0ZSpiRNAR8gYB8LdlPQ7Yw=; b=ho8fxNszlb1RNk7fJdv2JnSb6DUwGndyI9pZP6XZW3L/t6f/x/laJIEkR7QjZT+Y3tANET reguQCPbiwpUib37vv/rZakyfj4xyogpxT9hVEnIsDkrvmOIJ1bEJYy5ltBc8KpleSK+1i Jp8uNaf/imNmNyEbFlXpaynkRk1BobY= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-153-jWpD482ePimGdjopPxilmQ-1; Tue, 07 Jul 2020 12:25:57 -0400 X-MC-Unique: jWpD482ePimGdjopPxilmQ-1 Received: by mail-wm1-f70.google.com with SMTP id w25so2387278wmc.0 for ; Tue, 07 Jul 2020 09:25:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=dvLZ0+sSY5YGQlNh3v2ls0ZSpiRNAR8gYB8LdlPQ7Yw=; b=bbzKI0jTaxUx1+e2CChqcZyH5NfvsS3I5eabklCr/GwGoHEyiyYXLAkGl08vglJmRr DeJzfFnj9CHpRgm6c68HB28+1Kd785ZzYdrXYWCjqiPEupTlfADY52u1HWib0C3YaXBv gYuB0r1opQJiHqcDcn+lufoZ3KMNG/hhP6xz/DV/922BkWt8CIIGjehOazvN6+ZOIStK i/HuTJCLrp+eFoyh1lBvq/nUhFyTHpf717ubUQAiLx1tHiLKnCZxOAfUPfB/73s3A90I F9XEl2IPtfKx3/tHUDicin080QWyHh97yl+IcYNgU9mWRPqc1aMUctkXXhBpCEvEq8tJ t3NQ== X-Gm-Message-State: AOAM5329cuT5Ljkep67WGIs61LNK6hr21npW5knq2nXifqvMKORCTcW4 dsBu+UTu6l7RARQAup1xgZuio3QKLmQQUuFGfw5aevhX+wwdUuY83p19bAizKG3nk7eESDiPqkp omRo= X-Received: by 2002:a1c:4343:: with SMTP id q64mr5037813wma.20.1594139154949; Tue, 07 Jul 2020 09:25:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyI2sSjjjDLTZaUlvmyFLcH+mpHacEZ5wVO/FqcAyHS+L42U9d8TlDyDcYaq0OmKQ3g81iZ1A== X-Received: by 2002:a1c:4343:: with SMTP id q64mr5037791wma.20.1594139154754; Tue, 07 Jul 2020 09:25:54 -0700 (PDT) Received: from amorenoz.users.ipa.redhat.com ([94.73.63.18]) by smtp.gmail.com with ESMTPSA id x124sm1840696wmx.16.2020.07.07.09.25.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2020 09:25:53 -0700 (PDT) To: Joyce Kong , maxime.coquelin@redhat.com, jerinj@marvell.com, zhihong.wang@intel.com, xiaolong.ye@intel.com, honnappa.nagarahalli@arm.com, phil.yang@arm.com, ruifeng.wang@arm.com Cc: dev@dpdk.org References: <20200611033248.39049-1-joyce.kong@arm.com> <20200611033248.39049-3-joyce.kong@arm.com> From: Adrian Moreno Autocrypt: addr=amorenoz@redhat.com; prefer-encrypt=mutual; keydata= mQENBF1syNUBCADQ9dk3fDMxOZ/+OQpmbanpodYxEv8IRtDz8PXw8YX7UyGfozOpLjQ8Fftj ZxuubYNbt2QVbSgviFilFdNWu2eTnN/JaGtfhmTOLPVoakkPHZF8lbgImMoch7L0fH8wN2IM KPxQyPNlX+K9FD5brHsV1lfe1TwAxmhcvLW8yNrVq+9eDIDykxc7tH4exIqXgZroahGxMHKy c8Ti2kJka/t6pDfRaY0J+6J7I1nrn6GXXSMNA45EH8+0N/QlcXhP3rfftnoPeVmpjswzvJqY FNjf/Q5VPLx7RX0Qx+y8mMB2JcChV5Bl7D7x5EUbItj6+Sy7QfOgCtPegk9HSrBCNYaLABEB AAG0I0FkcmlhbiBNb3Jlbm8gPGFtb3Jlbm96QHJlZGhhdC5jb20+iQFUBBMBCAA+FiEEogUD gihhmbOPHy26d5C5fbYeFsUFAl1syNUCGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQd5C5fbYeFsX7qwgArGHSkX+ILNcujkVzjTG4OtkpJMPFlkn/1PxSEKD0jLuzx14B COzpg/Mqj3Re/QBuOas+ci9bsUA0/2nORtmmEBvzDOJpR5FH1jaGCx8USlY4WM6QqEDNZgTw hsy9KhjFzFjMk+oo3HyItXA+Uq9yrRBTjNBGTXxezMRcMuUZ4MIAfY0IRBglL2BufiuL43jD BvTENNFLoQ/wFV7qkFWSkv+8IjTsxr7M6XUo1QLd29Hn0dvwssN579HL1+BP46i2REpzeBEG L75iVChi+YnIQQNMJ9NYarVabZx4Y1Gn8+7B/1SNArDV+IDgnYgt7E58otoV2Ap310dmtuvE VbxGpbkBDQRdbMjVAQgAqyp9oA7WDu7/Y9T4Ommt69iZx8os7shUIfdgPEy5xrcPn6qGwN1/ HQ4j8nWfBG9uuX1X0RXUZIUEtYTxtED4yaCQMTqDUf9cBAwAA2mYxBfoiNYx8YqxM+sT0/J4 2qmDd+y+20UR4yzHE8AmIbspTzDFIJDAi+jKSR8F355z0sfW7CIMDC4ZWrPsskjEy1YN/U10 r6tRRH1kNyrCSbTG0d9MtcQO58h7DLXuzUhErB+BtG52A04t5cweIJTJC+koV5XPeilzlHnm RFoj0ncruGa9Odns21BNt3cy9wLfK+aUnWuAB1uc6bJGQPiAwjkilz7g7MBRUuIQ2Zt7HGLc SwARAQABiQE8BBgBCAAmFiEEogUDgihhmbOPHy26d5C5fbYeFsUFAl1syNUCGwwFCQHhM4AA CgkQd5C5fbYeFsUlSwf8CH+u/IXaE7WeWxwFkMaORfW8cM4q0xrL3M6yRGuQNW+kMjnrvK9U J9G+L1/5uTRbDQ/4LdoKqize8LjehA+iF6ba4t9Npikh8fLKWgaJfQ/hPhH4C3O5gWPOLTW6 ylGxiuER4CdFwQIoAMMslhFA7G+teeOKBq36E+1+zrybI6Xy1UBSlpDK9j4CtTnMQejjuSQb Qhle+l8VroaUHq869wjAhRHHhqmtJKggI+OvzgQpDIwfHIDypb1BuKydi2W6cVYEALUYyCLS dTBDhzj8zR5tPCsga8J7+TclQzkWOiI2C6ZtiWrMsL/Uym3uXk5nsoc7lSj7yLd/MrBRhYfP JQ== Message-ID: <73e2936e-18b7-43cf-d733-8ca37600b0b8@redhat.com> Date: Tue, 7 Jul 2020 18:25:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200611033248.39049-3-joyce.kong@arm.com> Content-Language: en-US Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=amorenoz@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v1 2/2] lib/vhost: restrict pointer aliasing for packed path X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 6/11/20 5:32 AM, Joyce Kong wrote: > Restrict pointer aliasing to allow the compiler to vectorize > loops more aggressively. > > With this patch, a 9.6% improvement is observed in throughput for the > packed virtio-net PVP case, and a 2.8% improvement in throughput for > the packed virtio-user PVP case. All performance data are measured > under 0.001% acceptable packet loss with 1 core on both vhost and > virtio side. Is the performance gain related solely to this patch or is it the result of the combined series? > > Signed-off-by: Joyce Kong > Reviewed-by: Phil Yang > --- > lib/librte_vhost/virtio_net.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c > index 751c1f373..39c92e7e1 100644 > --- a/lib/librte_vhost/virtio_net.c > +++ b/lib/librte_vhost/virtio_net.c > @@ -1133,8 +1133,8 @@ virtio_dev_rx_single_packed(struct virtio_net *dev, > > static __rte_noinline uint32_t > virtio_dev_rx_packed(struct virtio_net *dev, > - struct vhost_virtqueue *vq, > - struct rte_mbuf **pkts, > + struct vhost_virtqueue *__restrict vq, > + struct rte_mbuf **__restrict pkts, > uint32_t count) > { > uint32_t pkt_idx = 0; I wonder if we're extracting the full potential of "restrict" considering that the heavy lifting is done by the inner functions: (virtio_dev_rx_batch_packed and virtio_dev_rx_single_packed) > @@ -1219,7 +1219,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id, > > uint16_t > rte_vhost_enqueue_burst(int vid, uint16_t queue_id, > - struct rte_mbuf **pkts, uint16_t count) > + struct rte_mbuf **__restrict pkts, uint16_t count) > { > struct virtio_net *dev = get_device(vid); > Is this considered an api change? > @@ -2124,9 +2124,9 @@ free_zmbuf(struct vhost_virtqueue *vq) > > static __rte_noinline uint16_t > virtio_dev_tx_packed_zmbuf(struct virtio_net *dev, > - struct vhost_virtqueue *vq, > + struct vhost_virtqueue *__restrict vq, > struct rte_mempool *mbuf_pool, > - struct rte_mbuf **pkts, > + struct rte_mbuf **__restrict pkts, > uint32_t count) > { > uint32_t pkt_idx = 0; > @@ -2160,9 +2160,9 @@ virtio_dev_tx_packed_zmbuf(struct virtio_net *dev, > > static __rte_noinline uint16_t > virtio_dev_tx_packed(struct virtio_net *dev, > - struct vhost_virtqueue *vq, > + struct vhost_virtqueue *__restrict vq, > struct rte_mempool *mbuf_pool, > - struct rte_mbuf **pkts, > + struct rte_mbuf **__restrict pkts, > uint32_t count) > { > uint32_t pkt_idx = 0; > -- Adrián Moreno