From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by dpdk.org (Postfix) with ESMTP id 1DA227EC4 for ; Wed, 5 Nov 2014 15:39:27 +0100 (CET) Received: by mail-pd0-f179.google.com with SMTP id g10so865439pdj.24 for ; Wed, 05 Nov 2014 06:48:50 -0800 (PST) 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=PN1WidNQJWVEV9kFqqDBxYrXALiodI4QypOvkaOyX2g=; b=SUYIgn8yISw1uAXA705p7ah5Kuzu31OvqldmBtE2F2rakMYxCwG+MZMHqOjLZdys4p oct+ZSUz7v0JMHK8FLJ7Dlrgft+SZUAxuZvlSileAewqMsUbmTpZeMETT16T0oLAzPu/ /JQfykPU0TZ2RERRzq20oqPmg0F/iiSRmCu1MlJxyaA3mVgmGCUtlkGbES82MXRi+yBG Mb5DtYjfm28ezpRnAl57EedK4y7mlcVYv8253q7QXQ5A9zvU84PKOtrVqCf290lFQl9O sqfWFx5pNPas9fwdzUhFoAB3RxYsp7sM6pVkOaAVoDBfGvQkNNgXsk+IC15ypp3NPAR6 2mOA== X-Gm-Message-State: ALoCoQlIrvKiSkrkXIZR2l12M4hmyPMAgg59JtrWStZkEQ48In2Jk+Ee5bZb14xwhGPaeUAJrrAj MIME-Version: 1.0 X-Received: by 10.70.124.196 with SMTP id mk4mr15309407pdb.14.1415198930438; Wed, 05 Nov 2014 06:48:50 -0800 (PST) Received: by 10.70.41.76 with HTTP; Wed, 5 Nov 2014 06:48:50 -0800 (PST) In-Reply-To: References: <20141030110956.GA8456@bricha3-MOBL3> Date: Wed, 5 Nov 2014 08:48:50 -0600 Message-ID: From: Matt Laswell To: Alex Markuze Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:39:28 -0000 Hey Folks, I ran into the same issue that Alex is describing here, and I wanted to expand just a little bit on his comments, as the documentation isn't very clear. Per the documentation, the two arguments to rte_pktmbuf_pool_init() are a pointer to the memory pool that contains the newly-allocated mbufs and an opaque pointer. The docs are pretty vague about what the opaque pointer should point to or what it's contents mean; all of the examples I looked at just pass a NULL pointer. The docs for this function describe the opaque pointer this way: "A pointer that can be used by the user to retrieve useful information for mbuf initialization. This pointer comes from the init_arg parameter of rte_mempool_create() ." This is a little bit misleading. Under the covers, rte_pktmbuf_pool_init() doesn't threat the opaque pointer as a pointer at all. Rather, it just converts it to a uint16_t which contains the desired mbuf size. If it receives 0 (in other words, if you passed in a NULL pointer), it will use 2048 bytes + RTE_PKTMBUF_HEADROOM. Hence, incoming jumbo frames will be segmented into 2K chunks. Any chance we could get an improvement to the documentation about this parameter? It seems as though the opaque pointer isn't a pointer and probably shouldn't be opaque. Hope this helps the next person who comes across this behavior. -- Matt Laswell infinite io, inc. On Thu, Oct 30, 2014 at 7:48 AM, 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? >