From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <maxime.coquelin@redhat.com> Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 5D72211A4 for <dev@dpdk.org>; Tue, 19 Mar 2019 13:50:53 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BEF8987634; Tue, 19 Mar 2019 12:50:52 +0000 (UTC) Received: from [10.36.112.48] (ovpn-112-48.ams2.redhat.com [10.36.112.48]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 60EFF60C1D; Tue, 19 Mar 2019 12:50:49 +0000 (UTC) To: Jens Freimann <jfreimann@redhat.com>, Tiwei Bie <tiwei.bie@intel.com> Cc: zhihong.wang@intel.com, dev@dpdk.org References: <20190319064312.13743-1-tiwei.bie@intel.com> <20190319064312.13743-5-tiwei.bie@intel.com> <20190319085403.gnamedd5pz7jzwvj@jenstp.localdomain> <20190319093734.GA24818@dpdk-tbie.sh.intel.com> <20190319101154.loy5cmwbgnbnkxyg@jenstp.localdomain> From: Maxime Coquelin <maxime.coquelin@redhat.com> Message-ID: <f3fa0afa-4ba2-d116-6aca-d41d70cc98f2@redhat.com> Date: Tue, 19 Mar 2019 13:50:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190319101154.loy5cmwbgnbnkxyg@jenstp.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 19 Mar 2019 12:50:52 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 04/10] net/virtio: optimize flags update for packed ring X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Tue, 19 Mar 2019 12:50:53 -0000 On 3/19/19 11:11 AM, Jens Freimann wrote: >>> >>> same here. it's not really cached, it's pre-calculated. And here we >>> could also use a pre-calculated constand/define. >> >> For pre-calculated constant/define, do you mean VRING_DESC_F_AVAIL(1) >> and VRING_DESC_F_USED(1)? There is still little code in virtio-user >> using them without constantly passing 1. I planned to fully get rid >> of them in a separate patch later (but I can do it in this series if >> anyone wants). > > Yes, that's what I meant. And it's fine by me if you do it in a > follow-up. Agree, it can be done in a separate patch. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 5D6FCA00E6 for <public@inbox.dpdk.org>; Tue, 19 Mar 2019 13:50:55 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 381B01DBD; Tue, 19 Mar 2019 13:50:55 +0100 (CET) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 5D72211A4 for <dev@dpdk.org>; Tue, 19 Mar 2019 13:50:53 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BEF8987634; Tue, 19 Mar 2019 12:50:52 +0000 (UTC) Received: from [10.36.112.48] (ovpn-112-48.ams2.redhat.com [10.36.112.48]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 60EFF60C1D; Tue, 19 Mar 2019 12:50:49 +0000 (UTC) To: Jens Freimann <jfreimann@redhat.com>, Tiwei Bie <tiwei.bie@intel.com> Cc: zhihong.wang@intel.com, dev@dpdk.org References: <20190319064312.13743-1-tiwei.bie@intel.com> <20190319064312.13743-5-tiwei.bie@intel.com> <20190319085403.gnamedd5pz7jzwvj@jenstp.localdomain> <20190319093734.GA24818@dpdk-tbie.sh.intel.com> <20190319101154.loy5cmwbgnbnkxyg@jenstp.localdomain> From: Maxime Coquelin <maxime.coquelin@redhat.com> Message-ID: <f3fa0afa-4ba2-d116-6aca-d41d70cc98f2@redhat.com> Date: Tue, 19 Mar 2019 13:50:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190319101154.loy5cmwbgnbnkxyg@jenstp.localdomain> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 19 Mar 2019 12:50:52 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 04/10] net/virtio: optimize flags update for packed ring X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> Message-ID: <20190319125047.9D78o0IzYjqgDBw9vX0CmqNcC9OzbknAO3pm2WbU7CY@z> On 3/19/19 11:11 AM, Jens Freimann wrote: >>> >>> same here. it's not really cached, it's pre-calculated. And here we >>> could also use a pre-calculated constand/define. >> >> For pre-calculated constant/define, do you mean VRING_DESC_F_AVAIL(1) >> and VRING_DESC_F_USED(1)? There is still little code in virtio-user >> using them without constantly passing 1. I planned to fully get rid >> of them in a separate patch later (but I can do it in this series if >> anyone wants). > > Yes, that's what I meant. And it's fine by me if you do it in a > follow-up. Agree, it can be done in a separate patch.