From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 5702F1B37E for ; Mon, 13 Nov 2017 11:56:27 +0100 (CET) Received: by mail-wm0-f67.google.com with SMTP id t139so14268862wmt.1 for ; Mon, 13 Nov 2017 02:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4OAdIizQiWhNhdHOv/d8DILC3TBE9A00WnbeBpZw28Q=; b=WrxhJgbDIgJaGpBsEvPB44UHXxMSBy9WvZzGl/HWGPE21CUn9YwST9wnqhObbUW0w5 SFC4XxwyOBuDFUrDTJMyxFsEy+u/TeP08U0DvlDfu0MXKgCNcN/sZwIXlJkMtqurV4Zf IbsH2oWiCU+fLEWPObQ7JXwYfA5otgY+KMmcBhT8C/0n7W0RyJRKLszv+jdGRUsNZ2DK pPczgVWOz04Dtz0rSzOQiHAOfb2IzbW+v9iC4HS1udq+zXSU8s5YQI1Esk0il3amSv+D QzA8FObhtJxmS86TPhjTPVnfR1V5aCJoz2T2R1L+C33GOSxv2/9aLBKqLxC8kweW4ecP AAnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4OAdIizQiWhNhdHOv/d8DILC3TBE9A00WnbeBpZw28Q=; b=R4Df25oIpBcu+oZIGWEfSyNL6s8K6y5tXw/B3WFA7rJtZUczz8TYV+8JZedC8LDblp h2+rPEyCagTU7blGMc4KfOd15/riLYKakuIjITUQLY2kWmNLPVX80VdFtkw31Ym/zkF4 RVEhrTVYqA77HIJzATrnbBh2ddJFaOrXWeetbjR2NEi8BcI9+t5Kf89dn7emBOnEtF+J Txl6P7Vmq0w8O5NfEaXGCg95rjeh19Hg/clGzGQcN0ixEr4FxJzGJ/SZ9OXFCfzCWrkX QNO7CxiWd2GHtU7ClJtmcOr3xP2CW6Xqu950w86/Uaq5uzo34O+NNGsAovx4qP+BGRX0 1H6g== X-Gm-Message-State: AJaThX43JCCB2bWk7IQKJ9Bfe+HYSbtgVcJw92sesprZaBQx52Bo4Ze+ ez9Q0XiIY88UuLRnTP+CsQDpNSHb X-Google-Smtp-Source: AGs4zMaT91WKjQ3hB2Ia5c4CuJLuX7rMD9P7cM/oGsHRa1yno2spvDH5vHh1a3icTplMLfneHekHHg== X-Received: by 10.80.149.134 with SMTP id w6mr12205236eda.102.1510570587080; Mon, 13 Nov 2017 02:56:27 -0800 (PST) Received: from [10.61.0.167] (bba193485.alshamil.net.ae. [217.165.96.191]) by smtp.gmail.com with ESMTPSA id w7sm13421514edw.65.2017.11.13.02.56.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 02:56:26 -0800 (PST) From: Ilya Matveychikov Message-Id: <5F2502C3-99CF-4BE1-9DEC-364C5E636061@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 13 Nov 2017 14:56:23 +0400 In-Reply-To: <20171113103927.GP24849@6wind.com> Cc: dev@dpdk.org To: Adrien Mazarguil References: <2259E047-80C0-40AC-AAF4-F21617605508@gmail.com> <20171113103927.GP24849@6wind.com> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] A question about (poor) rte_ethdev internal rx/tx callbacks design 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: , X-List-Received-Date: Mon, 13 Nov 2017 10:56:28 -0000 > On Nov 13, 2017, at 2:39 PM, Adrien Mazarguil = wrote: >=20 > On Sat, Nov 11, 2017 at 09:18:45PM +0400, Ilya Matveychikov wrote: >> Folks, >>=20 >> Are you serious with it: >>=20 >> typedef uint16_t (*eth_rx_burst_t)(void *rxq, >> struct rte_mbuf **rx_pkts, >> uint16_t nb_pkts); >> typedef uint16_t (*eth_tx_burst_t)(void *txq, >> struct rte_mbuf **tx_pkts, >> uint16_t nb_pkts); >>=20 >> I=E2=80=99m not surprised that every PMD stores port_id in every and = each queue as having just the queue as an argument doesn=E2=80=99t allow = to get the device. So the question is - why not to use something like: >>=20 >> typedef uint16_t (*eth_rx_burst_t)(void *dev, uint16_t queue_id, >> struct rte_mbuf **rx_pkts, >> uint16_t nb_pkts); >> typedef uint16_t (*eth_tx_burst_t)(void *dev, uint16_t queue_id, >> struct rte_mbuf **tx_pkts, >> uint16_t nb_pkts); >=20 > I assume it's since the rte_eth_[rt]x_burst() wrappers already pay the = price > for that indirection, doing it twice would be redundant. No need to do it twice, agree. We can pass dev pointer as well as queue, = not just the queue=E2=80=99s index. >=20 > Basically the cost of storing a back-pointer to dev or a queue index = in each > Rx/Tx queue structure is minor compared to saving a couple of CPU = cycles > wherever we can. Not sure about it. More data to store - more cache space to occupy. Note = that every queue has at least 4 bytes more than it actually needs. And = RTE_MAX_QUEUES_PER_PORT is defined by it=E2=80=99s default to 1024. So we may have 4k extra for each = port.... >=20 > I'm not saying its the only solution nor the right approach, it's only = one > possible explanation for this API. Thank you for your try.