From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by dpdk.org (Postfix) with ESMTP id 536F1595A for ; Mon, 2 Nov 2015 19:35:17 +0100 (CET) Received: by obdgf3 with SMTP id gf3so37767564obd.3 for ; Mon, 02 Nov 2015 10:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/akRmafm/Iv333SYwRlaO5ZJQ/33VWPTmA/oBxXrZCk=; b=B0ZV6OGwrR9Ketb2byuDtVxtVl3UHE1Vu5VDLReHXwHOpLVXyWFi+U0g12OiXkDZUb Y1Fsl4UgieaOSJKBOKkWyRDRa+4FsXv4x8sKggA/yDkeJ9oeLfuRsIPmgQ9/KlZ1eQxH jQ3Q/s6wTnCqpzkP7zQILfJTZ3Vx0IuIe9LeiY4c0iaGYTP8T3upSxLVaaFtXk+7u06v usaUS/0FV0T5vFEDMjbaK2tLF0jECUDSWAFit6jJK4M0eQoIJ1yLJ6W/bw/CdN+I85Lb Nsa00wxHaz8tPSAUeghoAH2Iaf+8SVHzoajx4TB5cHRK0yibs8s9AYtpnrlqUJ0fLLXm htdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/akRmafm/Iv333SYwRlaO5ZJQ/33VWPTmA/oBxXrZCk=; b=EDA9m7ca8clWlRnYEjV41cDG+AinXGBsi1LEXO34+wTAAy5fZl51W+i3vnUqp7w1H2 nDESicMolShejbyc5BZo8A7u+zS/WGGURQBym00M1wcUgrIwWliOg7mzki+Wi+YnJR4j 8Za38LDzZTTFZxmTuDzE71TN5Zw30Er/9YkMtIYfGaGBSmuSaURI0MfQwcyM1QtqJwB7 oMGzFyw83bCVfFEEQWguAmnu6eBK2SywIwSQhlRqY7VCB3RvolHCXCDmVkQlyMmOFnrM ITc+87yD0BSX//Op/nZ7yNps+cyMO4HqD4DKjRQCGxfIVdBaB+wJBGPiIzXHeXgRO0sY thEQ== X-Gm-Message-State: ALoCoQlAg5U/PZmHhngOxb1cLXZcS1yCNVxCxwYE8uLn/l779GMQ4TSy4+kxhZc262RzrNTgUwNj MIME-Version: 1.0 X-Received: by 10.182.111.131 with SMTP id ii3mr12387513obb.6.1446489316751; Mon, 02 Nov 2015 10:35:16 -0800 (PST) Received: by 10.202.104.210 with HTTP; Mon, 2 Nov 2015 10:35:16 -0800 (PST) In-Reply-To: References: <20151102082420.768aea4a@xeon-e3> Date: Mon, 2 Nov 2015 20:35:16 +0200 Message-ID: From: Arnon Warshavsky To: "shesha Sreenivasamurthy (shesha)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Mon, 02 Nov 2015 18:35:17 -0000 If NO_TX_OFFLOAD only changes the layout in terms of relative field location in cache lines, and does not eliminate the fields themselves why should the using code be affected? On Mon, Nov 2, 2015 at 8:30 PM, shesha Sreenivasamurthy (shesha) < shesha@cisco.com> wrote: > One issue I see with optimization config options such as NO_TX_OFFLOAD, > NO_MULTISEG, NO_REFCOUNT is: It is not sufficient to have those =E2=80=9C= Ifdefs=E2=80=9D > inside mbuf structure, but should be sprinkled all over the code where > corresponding fields are used. This may make the code messier. > > -- > *- Thanks* > *char * (*shesha) (uint64_t cache, uint8_t F00D)* > *{ return 0x0000C0DE; } * > > From: Stephen Hemminger > Date: Monday, November 2, 2015 at 8:24 AM > To: Arnon Warshavsky > Cc: Cisco Employee , "dev@dpdk.org" > Subject: Re: [dpdk-dev] Reshuffling of rte_mbuf structure. > > On Sun, 1 Nov 2015 06:45:31 +0200 > Arnon Warshavsky wrote: > > My 2 cents, > This was brought up in the recent user space summit, and it seems that > indeed there is no one cache lines arrangement that fits all. > OTOH multiple compile time options to suffice all flavors, would make it > unpleasant to read maintain test and debug. > (I think there was quiet a consensus in favor of reducing compile options > in general) > Currently I manage similar deviations via our own source control which I > admit to be quite a pain. > I would prefer an option of code manipulation/generation by some script > during dpdk install, > which takes the default version of rte_mbuf.h, > along with an optional user file (json,xml,elvish,whatever) defining the > structure replacements, > creating your custom version, and placing it instead of the installed cop= y > of rte_mbuf.h. > Maybe the only facility required from dpdk is just the ability to registe= r > calls to such user scripts at some install stage(s), providing the mean > along with responsibility to the user. > /Arnon > On Sat, Oct 31, 2015 at 6:44 AM, shesha Sreenivasamurthy (shesha) < > shesha@cisco.com> wrote: > > In Cisco, we are using DPDK for a very high speed packet processor > > application. We don't use NIC TCP offload / RSS hashing. Putting those > > fields in the first cache-line - and the obligatory mb->next datum in t= he > > second cache line - causes significant LSU pressure and performance > > degradation. If it does not affect other applications, I would like to > > propose reshuffling of fields so that the obligator "next" field falls = in > > first cache line and RSS hashing goes to next. If this re-shuffling > indeed > > hurts other applications, another idea is to make it compile time > > configurable. Please provide feedback. > > > > -- > > - Thanks > > char * (*shesha) (uint64_t cache, uint8_t F00D) > > { return 0x0000C0DE; } > > > > > Having different layouts will be a disaster for distro's they have to > choose one. > And I hate to introduce more configuration! > > But we see the same issue. It would make sense if there were configuratio= n > options > for some common optimizations NO_TX_OFFLOAD, NO_MULTISEG, NO_REFCOUNT and > then > the mbuf got optimized for those combinations. Seems better than config > options > like LAYOUT1, LAYOUT2, ... > > In this specific case, I think lots of driver could be check nb_segs =3D= =3D 1 > and avoiding > the next field for simple packets. > > Long term, I think this will be losing battle. As DPDK grows more > features, the current > mbuf structure will grow there is really nothing stopping the bloat of > meta data. > > --=20 *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon@qwilt.com *