From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id 799355958
 for <dev@dpdk.org>; Thu, 30 Oct 2014 14:10:00 +0100 (CET)
Received: from orsmga001.jf.intel.com ([10.7.209.18])
 by orsmga103.jf.intel.com with ESMTP; 30 Oct 2014 06:17:07 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,285,1413270000"; d="scan'208";a="599026652"
Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.220.88])
 by orsmga001.jf.intel.com with SMTP; 30 Oct 2014 06:18:50 -0700
Received: by  (sSMTP sendmail emulation); Thu, 30 Oct 2014 13:18:49 +0100
Date: Thu, 30 Oct 2014 13:18:49 +0000
From: Bruce Richardson <bruce.richardson@intel.com>
To: Alex Markuze <alex@weka.io>
Message-ID: <20141030131849.GA1356@bricha3-MOBL3>
References: <CAKfHP0Up34C7r6SgrdTt+p-yV0bRkoP=hg8MR1P-C6iEg+cX2Q@mail.gmail.com>
 <20141030110956.GA8456@bricha3-MOBL3>
 <CAKfHP0Vq5ExWpEBRtehJ7_SUBhbbTP8sfEDHyc164yAjMijZOw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKfHP0Vq5ExWpEBRtehJ7_SUBhbbTP8sfEDHyc164yAjMijZOw@mail.gmail.com>
Organization: Intel Shannon Ltd.
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] segmented recv ixgbevf
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: Thu, 30 Oct 2014 13:10:01 -0000

On Thu, Oct 30, 2014 at 02:48:42PM +0200, Alex Markuze wrote:
> For posterity.
> 
> 1.When using MTU larger then 2K its advised to provide the value
> to rte_pktmbuf_pool_init.
> 2.ixgbevf rounds down the ("MBUF size" - RTE_PKTMBUF_HEADROOM) to the
> nearest 1K multiple when deciding on the receiving capabilities [buffer
> size]of the Buffers in the pool.
> The function SRRCTL register,  is considered here for some reason?

So problem is now solved, right?