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 92449A0577; Tue, 7 Apr 2020 12:28:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 703FB2B96; Tue, 7 Apr 2020 12:28:11 +0200 (CEST) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id C08FDFFA for ; Tue, 7 Apr 2020 12:28:09 +0200 (CEST) Received: by mail-il1-f195.google.com with SMTP id t6so2642823ilj.8 for ; Tue, 07 Apr 2020 03:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IKfOdYL5HIvTIOD2t05Otu38kdTyQgWjkkc+k+SPoO0=; b=MO5lWRKuzrzu7l+E//Zaag+AbNOu5G2GyaP1smoB8D00cuWvRQd8r7JZQBz4ILg/oC 89qbw4/Q2aMkOCOZypGhMr3pjylFpXUu09yzJdT7l2d/9aM+V/EtCDP/U3r9RzKc0fYt KadJqvZm7dwEPkMAoB0PJEAuJ68TDFt5alwm1f2djPYEG3T1xy0OjXHhZIq5/WmEf0Bz wJQogHqRXrXKYpz6FPLrl1oWSYhacKIOOxKEQzz4qx7VywpfEsWf2M15IseGHM6NtkOZ ociu5WdsVAlZysQ5nvXMIjivKz6LsuL/1MNsivj0II6IeQgDX+Hlcp4MdSg8BNQAfzSd byIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IKfOdYL5HIvTIOD2t05Otu38kdTyQgWjkkc+k+SPoO0=; b=GiyohFfWvJ7wnr1avEbllJJN94v9QKR2ASnhkLtGUHiNy7q9f5+4aq4t9YM0rfKC0r IeJ2U59/1izpw2kDVxmYqOUGwlb9WX+IhZHhiMptGe0fOmQw+vHuoJ7gicmnnzZQRIG/ E7zsO145By6h+KSyqCx+6yWSqo8lazUM4HIUYpU7kqVGrbDnL71G0vp0Zv3CmwO5EfMV QL8FaCdUWBYrUUpdAf7P+vBEXJPyjEg7iiZD3YPtwvUT+QOxPUCD9GAjntk/UsLgCOv8 cAFM2PgOAyg5OoziUXVXQj3FjXd+R4W/UrxMSI9WRkcVmPK0OVq9q7oYP5S7KKOK/QrP iAyA== X-Gm-Message-State: AGi0PuZ248GfUiF1PMGcnygm8NY0/OBI3LeZQsPSfPbl5aQx7fEflaLH WzseuehUHhGBJ7oqFSft1vN/+yPNrB+C8aLRIoNVf+krTZ4= X-Google-Smtp-Source: APiQypLWddrtI7zsfDpAo/pNYSlwigfZRJebtkXJvEh1IldERdsDfr1aHMV3P2cH3KbgozL59s6bOLZHaXttwcmWkdk= X-Received: by 2002:a92:2804:: with SMTP id l4mr1735503ilf.130.1586255289111; Tue, 07 Apr 2020 03:28:09 -0700 (PDT) MIME-Version: 1.0 References: <20200326165644.866053-1-jerinj@marvell.com> <20200331192945.2466880-1-jerinj@marvell.com> <20200331192945.2466880-2-jerinj@marvell.com> <75092d70-d1c1-832e-047f-d24d82654e4c@semihalf.com> <0c033611-8d97-47d1-ec7a-08a8b24d8b68@semihalf.com> In-Reply-To: <0c033611-8d97-47d1-ec7a-08a8b24d8b68@semihalf.com> From: Jerin Jacob Date: Tue, 7 Apr 2020 15:57:53 +0530 Message-ID: To: Andrzej Ostruszka Cc: dpdk-dev Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3 01/29] graph: define the public API for graph support 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 Mon, Apr 6, 2020 at 9:39 PM Andrzej Ostruszka wrote: > > On 4/6/20 4:59 PM, Jerin Jacob wrote: > > On Mon, Apr 6, 2020 at 6:06 PM Andrzej Ostruszka wrote: > [...] > >>> +typedef uint32_t rte_graph_off_t; /**< Graph offset type. */ > >>> +typedef uint32_t rte_node_t; /**< Node id type. */ > >>> +typedef uint16_t rte_edge_t; /**< Edge id type. */ > >>> +typedef uint16_t rte_graph_t; /**< Graph id type. */ > >> > >> I would use 'id' somewhere in the name of these typedefs - e.g. seeing > >> rte_node_t in the code (without knowing what it is) I'd be guessing this > >> is a pointer to 'struct rte_node'. > >> So maybe 'rte_node_id' or if we stick with _t convention and > >> rte_node_id_t is too long then maybe simple rte_nid_t/rte_eid_t/rte_gid_t? > > > > Considering typedef will not be pointers in Linux coding standard, I > > have chosen shorter > > name. considering eid, gid is cryptic and Since you think, rte_node_id > > better, I will change to > > that. > > If the typedef are not pointers by the coding standard then I'm fine > with current names - no need to change. Ack. > > [...] > >> [...] > >>> +/** > >>> + * @warning > >>> + * @b EXPERIMENTAL: this API may change without prior notice > >>> + * > >>> + * Get the number of edges for a node from node id. > >>> + * > >>> + * @param id > >>> + * Valid node id. > >>> + * > >>> + * @return > >>> + * Valid edge count on success, RTE_EDGE_ID_INVALID otherwise. > >>> + */ > >>> +__rte_experimental > >>> +rte_edge_t rte_node_edge_count(rte_node_t id); > >> > >> I would clarify here what edge is? Incoming nodes, next-nodes or both. > > > > It is next-node. I will update the doc. > > > >> Why edge-id typedef on return and why EDGE_ID_INVALID returned. Would > >> int/-EINVAL (for wrong 'id') be better? > > > > Edge node ID is expressed in rte_edge_id_t. SO, I think, it fine to return > > rte_edge_id_t. "This would avoid any compassion issue as well." > > Did not understand the last sentence. Could you rephrase it? Sorry. I meant signed vs unsigned comparison if needed in the variable. ie if (int < uint32_t) > > With regards > Andrzej Ostruszka