From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by dpdk.org (Postfix) with ESMTP id 6E1188E92 for ; Tue, 3 Nov 2015 12:44:14 +0100 (CET) Received: by wicll6 with SMTP id ll6so9628440wic.1 for ; Tue, 03 Nov 2015 03:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro_org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Vw52j9BUfTZVOJLYZjrxCGhxNjVVYOxDQqNY3hSxbHA=; b=AHTZMSbNW+jIDL7ZtdCg4cYv3+B6SN1lNJKTHfZFFJ49Q9gh6qCImALO3M915tDpYW Fhu/0VK3Xjo8AzFD0dFg7pc6SdUmV8dj1UwRAL79BVQJvzm0hVFDCJ3VILYdluz+a0kx c+/ivO8V5qXH7zV5d2E8hKQH8O3nu9aa9C39JvLNKOKe/vg6wrBbdquL1B0IBjwJTsEi 0GWue+UPlElba+DeofUmyyqDQLjg9E0JLGYykRTCjqKMG5G/i0XW8gD+uRMdJoPqDxAW NC/kvybz8a6N22az/gtaF9w8am1jNuTvfWa8Yp3/bg33m6M4WqKSZ5zugG3TlyNm9PxL TBhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Vw52j9BUfTZVOJLYZjrxCGhxNjVVYOxDQqNY3hSxbHA=; b=gpbBkXSpg6dInMKZbr03AhwAxkcbmkHMGlnEP+O60cH5DkkghAiUSDXf/+/NzZN5sl DWrQHVqaw41zmCY6dzqGczBsHQZmHF1165eeRQb335VaBS4q6YtvdMba70/HdPhQe8/k UkKFTrGVcfecOr8cduYUrgaPzlHdaIYEJOoTTQpFPlGNEsPyhN4B+P1hqU7x6vwVtPPM 04gGGf5HgYMR45WZ4JAaX2BzhXaf8B3jl1ztW4uArMA2kDNyuRXZrw0PNY/r0HGKLRWb eZFEMJxqcwjwB8lFAZ8oeytN4Ha+q92abz3mvbYmhbpqKLpRN9LfIUGrIuCEMYKYSGjY M8Gw== X-Gm-Message-State: ALoCoQnoUqXAcKo3yiTO+1bacAHA3+IZ4PF7h7ufy53CFnUxi39Sz5PI+HJafQj8P7aXujEpfY3C X-Received: by 10.194.179.165 with SMTP id dh5mr34247324wjc.134.1446551054301; Tue, 03 Nov 2015 03:44:14 -0800 (PST) Received: from [192.168.0.101] ([90.152.119.35]) by smtp.googlemail.com with ESMTPSA id v191sm22903531wmd.24.2015.11.03.03.44.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 03:44:13 -0800 (PST) To: Bruce Richardson , Matthew Hall References: <2014794.RrzFoKiHXW@xps13> <20151103002117.GA3665@mhcomputing.net> <20151103102042.GC15320@bricha3-MOBL3> From: Zoltan Kiss Message-ID: <56389E16.4010407@linaro.org> Date: Tue, 3 Nov 2015 11:44:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151103102042.GC15320@bricha3-MOBL3> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Reshuffling of rte_mbuf structure. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 11:44:14 -0000 Also, there could be places in the code where we change a set of continuous fields in the mbuf. E.g. ixgbe vector pmd receive function takes advantage of 128 bit vector registers and fill out rx_descriptor_fields1 with one instruction. But I guess there are other places too, and they are really hard to find with code analysis. A change in the mbuf structure would probably bring a plethora of nasty bugs due to this. On 03/11/15 10:20, Bruce Richardson wrote: > On Mon, Nov 02, 2015 at 07:21:17PM -0500, Matthew Hall wrote: >> On Mon, Nov 02, 2015 at 11:51:23PM +0100, Thomas Monjalon wrote: >>> But it is simpler to say that having an API depending of some options >>> is a "no-design" which could seriously slow down the DPDK adoption. >> >> What about something similar to how Java JNI works? It needed to support >> multiple Java JRE / JDK brands, implementations etc. Upon initialization, a >> function pointer array is created, and specific slots are filled with pointers >> to the real implementation of some native API functions you can call from >> inside your library to perform operations. >> >> In the DPDK case, we need flexible data instead of flexible function >> implementations. >> >> To do this there would be some pointer slots in the mbuf that are are filled >> with pointers to metadata for required DPDK features. The data could be placed >> in the following cachelines, using some reserved tailroom between the mbuf >> control block and the packet data block. Then the prefetch could be set up to >> prefetch only the used parts of the tailroom at any given point, to prevent >> unwanted slowdowns. >> >> Matthew. > > The trouble is that a lot of the metadata comes from the receive descriptor on > the RX code path, which is extremely sensitive to cache line usage. This is why > in the 1.8 changes to the mbuf, the data used by the RX code paths were all put > on the first cacheline. > > /Bruce >