From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 01F8447D0 for ; Sun, 13 Mar 2016 23:26:58 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id p65so80696197wmp.0 for ; Sun, 13 Mar 2016 15:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=kKy5/tFE5QCeS0oY5UmMfo6dR/+wSM89ULZSaQ+KVG4=; b=0zFqP0KDMV2v9h88Gf9vS8f/hu8Z00eQUtLxepNqQBdIAebCLVmrzuKHb4edg4+zyv vHn5+FvnnLwYORPaHOWhzwVGPR3FKO7jv7y7zks3tqF9I555B/a/dQP1njJd1AywlO7b IRfR5lIVk/ypzVc9PfNkh0ZKg4kz6DX2rjTDNDFOFA8iuy3HKNLeVmAlyiS6BUlhkwFt uCxuhhw6yYgy/kej/o6M9n9xH8IeEfnssMAzmAq+ZklTOetTDxeMB7guGdUcgaJeNRZw 5GDdccJ+8AL1GL2giStcBG3equ6DIQdk3xd6w0WI4qW6R6nQWhfAanDsldg2ajUKwJVP Nepw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=kKy5/tFE5QCeS0oY5UmMfo6dR/+wSM89ULZSaQ+KVG4=; b=BUpyUmw30tpRe7Q+AJfD4Fkr1huNNB63QC7MTARlIiMOv0L4x8wB0eTmv7mmPz3qcT TJ9ChIG2AMD3S83tXAu5eQC92hWK9nM/0LoTYFLGYUFgedCLwWuoY5uoWc9WLmOZLLsU KR598HtnM0eSJHYa9gxT41WV5VeLfnkn6oSlzrWom4sk3lSGGtrjtSCwabVkfiFjWGGv 4oUTS2pkc3sMrbcfxObUiNhfenWGjMLR9A+C4s64E2rCEkI5jrTTBV9RF6P2zYdaLPwz ZOoh39EXzsn/P/EeBGW1bPfvLGR2SrgytmY7we+E1Tczn06hY3TP1Wj/QSHIeuiP18rO OBdA== X-Gm-Message-State: AD7BkJLUyYC//r9AD7+I0Wzlb6NkB9ZEFwhsVtJepNwFWhw8CPen+MPRdyF0o/Kw2GUcEURE X-Received: by 10.194.71.46 with SMTP id r14mr22929347wju.100.1457908017778; Sun, 13 Mar 2016 15:26:57 -0700 (PDT) Received: from xps13.localnet (91.111.75.86.rev.sfr.net. [86.75.111.91]) by smtp.gmail.com with ESMTPSA id t8sm19422869wjy.41.2016.03.13.15.26.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Mar 2016 15:26:56 -0700 (PDT) From: Thomas Monjalon To: "Dumitrescu, Cristian" , Stephen Hemminger Cc: dev@dpdk.org Date: Sun, 13 Mar 2016 23:25:35 +0100 Message-ID: <4107462.qD4IMYcbAE@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912647968B0C@IRSMSX108.ger.corp.intel.com> References: <1448822809-8350-1-git-send-email-stephen@networkplumber.org> <5760276.6KREI08Oct@xps13> <3EB4FA525960D640B5BDFFD6A3D8912647968B0C@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 22:26:58 -0000 2016-03-08 07:49, Dumitrescu, Cristian: > We are working on implementing an alternative solution based on 2x 64-bit multiplication, which is supported by CPUs and compilers for more than a decade now. The 32-bit solution proposed by Stephen requires truncation with some loss of precision, which can potentially lead to some corner cases which are difficult to predict, therefore I am not feeling 100% confident with it. The 32-bit arithmetic gave me a lot of headaches when developing QoS code, therefore I am very cautious of it. > > I am not sure we are able to finalize implementation and testing for release 16.4, therefore it would be fair to accept Stephen's solution for release 16.4 and consider the new safer 2x 64-bit multiplication solution which does not involve any loss of precision once it becomes available. > > Regarding Stephen's patches, I think there is a pending issue regarding the legal side of the Copyright, which is attributed to Intel, although Stephen's code is relicensed with BSD license by permission from the original code author (which also submitted the code to Linux kernel under GPL). This was already flagged. This is a legal issue and I do not feel comfortable with ack-ing this patch until the legal resolution on this is crystal clear. > > I also think the new files called rte_reciprocal.[hc] implement an algorithm that is very generic and totally independent of the QoS code, therefore it should be placed into a different folder that is globally visible to other libraries (librte_eal/common ?) just in case other usages for this algorithm are identified in the future. I suggest we break the patch into two separate patches submitted independently: one introducing the rte_reciprocal.[hc] algorithm to librte_eal/common and the second containing just the librte_sched changes, which are small. I am thinking ahead here: once we have the 2x64-bit multiplication solution in place, we should not have rte_reciprocal.[hc] hanging in librte_sched folder without being used here, while it might be used by other parts of DPDK. Let's keep the improvement as-is to test it in the first release candidate. We can move the code and/or fix the file header later. Series applied, thanks.