From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id D29DA695D for ; Mon, 18 Feb 2019 19:01:52 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Feb 2019 10:01:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,385,1544515200"; d="scan'208";a="300676274" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.114]) ([10.237.221.114]) by orsmga005.jf.intel.com with ESMTP; 18 Feb 2019 10:01:50 -0800 To: "Lam, Tiago" , Ferruh Yigit , dev@dpdk.org, linville@tuxdriver.com References: <1542707697-175836-1-git-send-email-tiago.lam@intel.com> <1542709592-215007-1-git-send-email-tiago.lam@intel.com> <1542709592-215007-3-git-send-email-tiago.lam@intel.com> <59e1bdba-331b-e337-56e7-dc4f52057d56@intel.com> From: "Yigit, Ferruh" Cc: "Stokes, Ian" , Kevin Traynor Message-ID: Date: Mon, 18 Feb 2019 18:01:49 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 3/3] net/af_packet: get 'framesz' from the iface's MTU X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 18:01:53 -0000 On 11/28/2018 1:12 PM, Lam, Tiago wrote: > On 27/11/2018 17:43, Ferruh Yigit wrote: >> On 11/20/2018 10:26 AM, Tiago Lam wrote: >>> Use the underlying MTU to calculate the framsize to be used for the mmap >>> RINGs. This is to make it more flexible on deployments with different >>> MTU requirements, instead of using a pre-defined value of 2048B. >> >> This behavior change should be documented in af_packet documentation which is >> missing unfortunately. >> Would you able to introduce the initial/basic af_packet doc to at least to >> document device argument? If not please let me know, I can work on it. >> > > Thanks for the review, Ferruh. > > Yeah, I don't mind cooking something up and submitting here for review; > I'll wait a couple of days for a reply from John W. before proceeding, > though. > > But given there's no documentation for af_packet yet, do you prefer to > wait for that to be available, and apply it all together? Or could that > be applied later as part of another patch? Unfortunately Tiago was not able to work on this task anymore. And since Tiago's af_packet doc update already merged, I was planning to complete the task and applied the comments into his patchset but had a few questions, sharing here in case there are more interested people on task, cc'ed Ian & Kevin. Code is not functioning correct when there are gaps in the block, I mean when block size is not multiple of frame size. There can be some assumption in the code that memory is continuous. Also I am not sure the benefit of the using MTU for this case. There are a few restrictions, block size should be multiple of page size, it is 4K by default. When using MTU, 1500, for frame size, instead of 2048 Bytes hardcoded value, still only 2 frames fit into blocksize and there is no benefit, (and it is not functioning with current code as I mentioned above.) So this can be required for the cases MTU is bigger than 2048, not sure if this is the concern of the patch. Also it can provide some memory optimization when MTU is 1024 bytes or less, so this provides memory optimization more than flexibility on deployment. Hi Ian, Kevin, Are you aware of any use case of this patch in OvS? Thanks, ferruh