From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) by dpdk.org (Postfix) with ESMTP id 7C2281B37D for ; Mon, 13 Nov 2017 18:15:25 +0100 (CET) Received: by mail-wm0-f65.google.com with SMTP id g141so16698954wmg.2 for ; Mon, 13 Nov 2017 09:15:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=igEx866TynvGL9Kria1EHTSeljXH+xLvn82dNzPQvR4=; b=uE+Hh8DRdEevN9eoLx8EqffXSb/bDKvetfHToUA/kH1cJxB4F8nwIRbmEoEkGd6wUJ QN6kgf3IhgN1tdYVuxsfYa5P28YGnM14drLurH4rcgIAta1s+3fXLBREiviITQ4ujA/G J2GkxJ9d7P5Z9aiqhHx33XYupZb9KIuJ66TJHMsshQtoOavOxZB/5U4yxe8JOFWIm0Eu YFZAEjku9jEeAFDNip2KHHWGXFba63ZGoOhSnQBXagbyr4uK9rdPYyftUIPQyfopoJO3 fm/ATo5Hq6Jyha0LkqhucC2HaqFQasGsUiA4WMZq1aQVNyZZlbLMhnRtvaWOsyE5kpAQ XFJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=igEx866TynvGL9Kria1EHTSeljXH+xLvn82dNzPQvR4=; b=EE4DIiHpsZXZKtqJvb+Ia1l6L8lO+ffUcUcDPTwO546ThAm6ViCGY9XGlvRkD/tqT2 ubDjVBEeUToGjVxea3S68dpRQuNfbhonfv8S7yqrIXOv9hyaMqzQ0wrSFtRHFiopz1pd EEAdFZCJUV17An9oxkZ11v5zrx+GFbzgQQn+Uwg6TIA5st2ApQQNS7ziuVR9T81JW+4m EyYQCmgRmIYskXUxWkgeEDTkSDHipXz92L06FxMIPz6Z/+2TMSjKu3ySz8TU7KTOm2V/ nubE+czQdJjJfAZGKTod+EitDz9k8Om8TAbOuPBFCV00T6U1rbl8lXEiW2pvqFIYbshj v+nA== X-Gm-Message-State: AJaThX7kr89CPGEq/eRNXd7DKzh246uP1OUdJsFMLVfS3RGR+iE3yGlY pfFNDgvK26OlZrioczZHDmnSmA== X-Google-Smtp-Source: AGs4zMYcUXUGVB3YCijC0kNi2BpQ7Kw8ODi+YBVtmwzA9Uwh519Dj30ABmr9vaEntChceRiK5pGVPQ== X-Received: by 10.80.143.98 with SMTP id 89mr13634355edy.273.1510593325188; Mon, 13 Nov 2017 09:15:25 -0800 (PST) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id o60sm13015045eda.48.2017.11.13.09.15.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 09:15:24 -0800 (PST) Date: Mon, 13 Nov 2017 18:15:12 +0100 From: Adrien Mazarguil To: Ilya Matveychikov Cc: dev@dpdk.org Message-ID: <20171113171512.GV24849@6wind.com> References: <2259E047-80C0-40AC-AAF4-F21617605508@gmail.com> <20171113103927.GP24849@6wind.com> <5F2502C3-99CF-4BE1-9DEC-364C5E636061@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5F2502C3-99CF-4BE1-9DEC-364C5E636061@gmail.com> 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 17:15:25 -0000 On Mon, Nov 13, 2017 at 02:56:23PM +0400, Ilya Matveychikov wrote: > > > On Nov 13, 2017, at 2:39 PM, Adrien Mazarguil wrote: > > > > On Sat, Nov 11, 2017 at 09:18:45PM +0400, Ilya Matveychikov wrote: > >> Folks, > >> > >> Are you serious with it: > >> > >> 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); > >> > >> I’m not surprised that every PMD stores port_id in every and each queue as having just the queue as an argument doesn’t allow to get the device. So the question is - why not to use something like: > >> > >> 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); > > > > 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’s > index. > > > > > 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’s default to 1024. So we may have 4k extra for each port.... Note that queues are only allocated if requested by application, there's really not much overhead involved. Also to echo Konstantin's reply and clarify mine, PMDs normally do not access this structure from their data plane. This pointer, if needed, is normally stored away from hot regions accessed during TX/RX, usually at the end of TX/RX structures and only for the convenience of management operations. It therefore has no measurable impact on the CPU cache. -- Adrien Mazarguil 6WIND