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 AC82BA0577; Mon, 6 Apr 2020 18:09:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 83D161BEE6; Mon, 6 Apr 2020 18:09:40 +0200 (CEST) Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by dpdk.org (Postfix) with ESMTP id AD90F1BEE4 for ; Mon, 6 Apr 2020 18:09:38 +0200 (CEST) Received: by mail-lf1-f66.google.com with SMTP id m2so1023049lfo.6 for ; Mon, 06 Apr 2020 09:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=e0Tqao0u4OlRnkAhaWImGk/n6RswAt/0I3dBluZXlKQ=; b=PGwImlmPdCK/Ud0UqfqiRXxDLhNzOEMspu+Z0CfBzpqNHjoN+TD+shpvWYN/8czbcO G72FkwHhbsvmAPgYhnJHOmbVSTingkivtZmTFSQRtdEmugDVqEoFRR6livWJ3xJKQLVv YiBRsvZfTeBCWIxxXA1cbYQG5HR8iYm0Tmd2IZonplAwOZUIhniVRs2jT1hWjITTeMqB 1AptPA8IwKiXdm8uVS0Za1DFDnri1luARJA/Lg7uT+BiL+OJ0PyAGOghx+REtKBA7ONG Im83Z9JBBIXPnPsfoluzSJYBCIDmiFjSplhGlg0wcBf52K/8SPjg/XGe5VCE3HQLBPdj N9Ng== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=e0Tqao0u4OlRnkAhaWImGk/n6RswAt/0I3dBluZXlKQ=; b=sQCbM1Uabav3usmZPWi1L/LpiXxmkRE29LZrf8kfgzvr68ltDQp1irTJJnJYSjchnS NSnfIfvp8yCHvwUsEylcfvJToN81plPBO42u4Rf/MrEkzinDmXJJg6tA4f8qg+DPGWCY 60qcfobcgsZ+nhu4gSPOKIcFcr/DeFzC5g6sbcvRO6Qz77OGTUglAGc+pPR6T55Rp0jm hrSk4fxFORHW6OBTyW+T7qYR4b8IVRJ8cm2pB0FFHecEOigTqxhaDixI0pgpsqaMY9Hc ZeiFpOfQRqv9IJ3W3bTg9cTvP9hl0J/O1MyM0q3Dq/Yy+IGxiWpbdUDeYRbnyAGizZ2P X7MQ== X-Gm-Message-State: AGi0PuapOR6trCiBknfzC+tuqb5TTqm47dPpPVnTcuCHtLGBq9n0LMbb 08drqbjMQJ9Nvf/cN8cNsIFDH+E/wss= X-Google-Smtp-Source: APiQypKQuUXGUE/SVzsYm9LhzqGuinRcJdCzoL4yqjkw1yq1SOah/0cyOz8r/3BV/4Uow/uAq6Qfiw== X-Received: by 2002:ac2:4473:: with SMTP id y19mr13827473lfl.23.1586189377617; Mon, 06 Apr 2020 09:09:37 -0700 (PDT) Received: from [192.168.8.100] (user-5-173-33-152.play-internet.pl. [5.173.33.152]) by smtp.gmail.com with ESMTPSA id n9sm10264030ljo.89.2020.04.06.09.09.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Apr 2020 09:09:37 -0700 (PDT) To: Jerin Jacob Cc: dpdk-dev 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> From: Andrzej Ostruszka Message-ID: <0c033611-8d97-47d1-ec7a-08a8b24d8b68@semihalf.com> Date: Mon, 6 Apr 2020 18:09:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 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. [...] >> [...] >>> +/** >>> + * @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? With regards Andrzej Ostruszka