From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id A1B25A00E6 for ; Tue, 19 Mar 2019 14:16:18 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B8AA325A1; Tue, 19 Mar 2019 14:16:17 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 3578FA3 for ; Tue, 19 Mar 2019 14:16:16 +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; 19 Mar 2019 06:16:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,498,1544515200"; d="scan'208";a="308484247" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.46]) ([10.237.221.46]) by orsmga005.jf.intel.com with ESMTP; 19 Mar 2019 06:16:09 -0700 From: "Yigit, Ferruh" To: "Lam, Tiago" , Ferruh Yigit , dev@dpdk.org, linville@tuxdriver.com Cc: "Stokes, Ian" , Kevin Traynor 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> Message-ID: Date: Tue, 19 Mar 2019 13:16:09 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190319131609.VVYVhT4yKRokQAj8jVx5CCiNys6WaPzXhCPyyG2Btj4@z> On 2/18/2019 6:01 PM, Yigit, Ferruh wrote: > 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? It seems there is no follow up to this patchset, I am updating them as not applicable. For references, patches mentioned are: https://patches.dpdk.org/user/todo/dpdk/?series=2498