From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AF3AB41BB2; Thu, 2 Feb 2023 20:23:52 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3F52840EDC; Thu, 2 Feb 2023 20:23:52 +0100 (CET) Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) by mails.dpdk.org (Postfix) with ESMTP id 7F8A340693 for ; Thu, 2 Feb 2023 20:23:51 +0100 (CET) Received: by mail-yb1-f180.google.com with SMTP id x4so3570659ybp.1 for ; Thu, 02 Feb 2023 11:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=WkrWpGj4spp7hxSNmkyiHp2iPkYIWMjzGvp2e1RANpY=; b=IGZ/NT12LXqJw+eIB3A5gsHVQZqAYQ/26KT3vFoFdyjiiW+de+7PFhSURcPh74NgN2 6eJUGJqez155bp/B8Ii0R27zajuhMwpflnxvTKNmIVmcVY8aVkbdfyrFw4Hsq+9+HDzp ZVhuD5b8qmoXxJd74JNo5+cPUOU/BQSwstJNvBAbojpOI+ggWS2Op4Bms6LT09pRWSgt nPRCDuHqhcHc8vpKjI/YqzEOQNLkuY9owpx7IAIz7zUtwZiidF6w4F81z9mJijDa0Vuv cj7OVWo1MOkX8MGDY+3nDLjD78qoB4tEotKV8tC2wz/gLkQwswEVQiVktjDvw1rKOxV1 63yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=WkrWpGj4spp7hxSNmkyiHp2iPkYIWMjzGvp2e1RANpY=; b=cMK9d8SZDl/aGsP4worxpk9oUjP2RgqI8uno6NFkRpDXJOw6btR14zsHo6BSvgjK4v OPBcGA0dk32u1RtZuOuARtc66iVFDgJH7g4Lr21JX2p+1xJKHZLqBjhkIxg4Gy1OdKIv GnbDUgWGl3oTR3HEFxl1JaHfs7ithqSiM7hJ3ZdMSO3bEJgRdKSlViF1UUaczDhNuPOm BucnwTdpTakHR4TzZQdXZ6aulK0x+nxbz2GxlFeXrcmmzS3o+F2EWGiFCc1FXbCpt0Gs yq4yaTelGrqLFh+cq+KCDaQqWegeFSKByaRldlmEDC0OLAio51AA4SdRooE0wQxiKXRT +hkw== X-Gm-Message-State: AO0yUKV06dngGpgZwvCrwxfYp4siccHfh7Kx7GieFr3qW5cIgbg6K5jK d2xrl1bt7cRp6frn+b8Pdb6equcpTHK5iTnchj0= X-Google-Smtp-Source: AK7set/k/VBXgWwbhL1iEicvtgJAn/j4E2GCL+W2e1o9lDr7bFzfJzxOjPHMHl0SSbwimgxSrhhPmG53h2hdDBg1EQI= X-Received: by 2002:a25:2f52:0:b0:80e:f3e3:e8f9 with SMTP id v79-20020a252f52000000b0080ef3e3e8f9mr931877ybv.115.1675365830773; Thu, 02 Feb 2023 11:23:50 -0800 (PST) MIME-Version: 1.0 From: Ben Magistro Date: Thu, 2 Feb 2023 14:23:39 -0500 Message-ID: Subject: Sign changes through function signatures To: Olivier Matz , Thomas Monjalon , ferruh.yigit@amd.com, andrew.rybchenko@oktetlabs.ru Cc: ben.magistro@trinitycyber.com, dev@dpdk.org, Stefan Baranoff Content-Type: multipart/alternative; boundary="0000000000003650a705f3bc8131" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --0000000000003650a705f3bc8131 Content-Type: text/plain; charset="UTF-8" Hello, While making some updates to our code base for 22.11.1 that were missed in our first pass through, we hit the numa node change[1]. In the process of updating our code, we noticed that a couple functions (rx/tx_queue_setup, maybe more that we aren't using) state they accept `SOCKET_ID_ANY` but the function signature then asks for an unsigned integer while `SOCKET_ID_ANY` is `-1`. Following it through the redirect to the "real" function it also asks for an unsigned integer which is then passed on to one or more functions asking for an integer. As an example using the the i40e driver -- we would call `rte_eth_tx_queue_setup` [2] which ultimately calls `i40e_dev_tx_queue_setup`[3] which finally calls `rte_zmalloc_socket`[4] and `rte_eth_dma_zone_reserve`[5]. I guess what I am looking for is clarification on if this is intentional or if this is additional cleanup that may need to be completed/be desirable so that signs are maintained through the call paths and avoid potentially producing sign-conversion warnings. From the very quick glance I took at the i40e driver, it seems these are just passed through to other functions and no direct use/manipulation occurs (at least in the mentioned functions). 1) https://patches.dpdk.org/project/dpdk/patch/20221004145850.32331-1-olivier.matz@6wind.com/ 2) https://doc.dpdk.org/api/rte__ethdev_8h.html#a796c2f20778984c6f41b271e36bae50e 3) https://github.com/DPDK/dpdk/blob/main/drivers/net/i40e/i40e_rxtx.c#L1949 4) https://doc.dpdk.org/api/rte__malloc_8h.html#a7e9f76b7e0b0921a617c6ab8b28f53b3 5) https://github.com/DPDK/dpdk/blob/1094dd940ec0cc4e3ce2c5cd94807350855a17f9/lib/ethdev/ethdev_driver.h#L1566 --0000000000003650a705f3bc8131 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

While making some updates to our= code base for 22.11.1 that were missed in our first pass through, we hit t= he numa node change[1].=C2=A0 In the process of updating our code, we notic= ed that a couple functions (rx/tx_queue_setup, maybe more that we aren'= t using) state they accept `SOCKET_ID_ANY` but the function signature then = asks for an unsigned integer while `SOCKET_ID_ANY` is `-1`.=C2=A0 Following= it through the redirect to the "real" function it also asks for = an unsigned integer which is then passed on to one or more functions asking= for an integer.=C2=A0 As an example=C2=A0using the the i40e driver -- we w= ould call `rte_eth_tx_queue_setup` [2] which ultimately calls `i40e_dev_tx_= queue_setup`[3]=C2=A0which=C2=A0finally calls `rte_zmalloc_socket`[4] and `= rte_eth_dma_zone_reserve`[5].

I guess what I am lo= oking for is clarification=C2=A0on if this is intentional or if this is add= itional cleanup that may need to be completed/be desirable so that signs ar= e maintained through the call paths and avoid potentially producing sign-co= nversion warnings.=C2=A0 From the very quick glance I took at the i40e driv= er, it seems these are just passed through to other functions and no direct= use/manipulation occurs (at least in the mentioned functions).
<= br>
= <= div>4)=C2=A0https://doc.dpdk.org/api/rte__malloc_8h.html#a7= e9f76b7e0b0921a617c6ab8b28f53b3
--0000000000003650a705f3bc8131--