From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mhall@mhcomputing.net>
Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170])
 by dpdk.org (Postfix) with ESMTP id A3CAB8E9F
 for <dev@dpdk.org>; Tue,  3 Nov 2015 15:33:40 +0100 (CET)
Received: by mail.mhcomputing.net (Postfix, from userid 1000)
 id 2A3B734B; Tue,  3 Nov 2015 09:33:40 -0500 (EST)
Date: Tue, 3 Nov 2015 09:33:40 -0500
From: Matthew Hall <mhall@mhcomputing.net>
To: Zoltan Kiss <zoltan.kiss@linaro.org>
Message-ID: <20151103143340.GA8985@mhcomputing.net>
References: <D2599541.24CA8%shesha@cisco.com>
 <CAKy9EB2W9txt-w1MS-WUpZrefU+K9T7P3nMtnAr41EjEbzz+Pg@mail.gmail.com>
 <D25D1EA7.24E21%shesha@cisco.com> <2014794.RrzFoKiHXW@xps13>
 <20151103002117.GA3665@mhcomputing.net>
 <20151103102042.GC15320@bricha3-MOBL3>
 <56389E16.4010407@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56389E16.4010407@linaro.org>
User-Agent: Mutt/1.5.21 (2010-09-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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2015 14:33:40 -0000

On Tue, Nov 03, 2015 at 11:44:22AM +0000, Zoltan Kiss wrote:
> 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.

If the RX path is the cause of most of the issues, then it seems like we need 
to make some diagrams and a description of how this code works, so we could 
crowd-source the best proposed performance and cleanliness improvements.

Trying to solve this problem one little hack at a time isn't going to achieve 
the pretty demanding performance and flexibility constraints on the code.

Do we have some kind of plans to do bounties, specific wiki pages on known 
design problems, Google Summer of Code, or some other kind of process for 
longer-term architectural improvements?

Also, in this instance it seems like it might be wise to outsource some 
black-magic like these vector instructions, to some of the pre-optimized 
cleaner alternatives like rte_memcpy.

Matthew.