From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by dpdk.org (Postfix) with ESMTP id C64286895 for ; Thu, 15 May 2014 11:53:34 +0200 (CEST) Received: by mail-wi0-f175.google.com with SMTP id f8so9485037wiw.8 for ; Thu, 15 May 2014 02:53:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Bb3apHNyI0bx2a4bW28xAV6VbY0MLxhj4fyW90m7Txs=; b=Z5fwOWa9114eoLhj04iLuFNuHG5RHRAQ6X3jN5HYQTTMu8nzMTM/zML4mzd8geu03e V8Tuutc86K/PqAEEzlZI0MzcQFJ+W4kAvLwkapGmvS5VhWKtx7o9c0EtbNDA98bfZW4a 0DdVFVhfDgiyYRrbsLREvLC9VguiQLMcg+zS6N1aT+Duzj75d9CFUz5ENVihosyTDYbT H8U7iQNSFuvbMB4N0d/Q00v2P1Mi7l3bROSmS8eS45mmlzHQAgx/HHqY4sxbed1mLGfd AsPexFw4V10l6NzCaDGKC5XYAKwZ3kT0rMSQpGtT1dZf0R80h2wttSg06VWUyDnnAi8U QYkQ== X-Gm-Message-State: ALoCoQlAgjjvkizkdDV2WeURBiqGBXJrifw4KYunkwqzcg5NGjK5kMXYTyF5uc1lokP+qi0Iq7eK X-Received: by 10.180.81.36 with SMTP id w4mr29909428wix.36.1400147622687; Thu, 15 May 2014 02:53:42 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id vc2sm6127103wjc.2.2014.05.15.02.53.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 02:53:41 -0700 (PDT) Message-ID: <53748EA2.4030801@6wind.com> Date: Thu, 15 May 2014 11:53:38 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: "Ananyev, Konstantin" , "Shaw, Jeffrey B" , "dev@dpdk.org" References: <1399647038-15095-1-git-send-email-olivier.matz@6wind.com> <1399647038-15095-6-git-send-email-olivier.matz@6wind.com> <4032A54B6BB5F04B8C08B6CFF08C59285542081E@FMSMSX103.amr.corp.intel.com> <536CFCEF.4080704@6wind.com> <4032A54B6BB5F04B8C08B6CFF08C59285542085B@FMSMSX103.amr.corp.intel.com> <2601191342CEEE43887BDE71AB9772580EFA666D@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772580EFA666D@IRSMSX105.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH RFC 05/11] mbuf: merge physaddr and buf_len in a bitfield 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: Thu, 15 May 2014 09:53:35 -0000 Hi Konstantin, On 05/14/2014 04:07 PM, Ananyev, Konstantin wrote: > Apart from performance impact, one more concern: > As I know, theoretical limit for PA on Intel is 52 bits. > I understand that these days no-one using more than 48 bits and it probably would stay like that for next few years. > Though if we'll occupy these (MAXPHYADDR - 48) bits now, it can become a potential problem in future. > After all the savings from that changes are not that big - only 2 bytes. > As I understand you already save extra 7 bytes with other proposed modifications of mbuf. > That's enough to add TSO related information into the mbuf. > So my suggestion would be to keep phys_addr 64bit long. I think that 2 bytes is a good save and will probably be useful in a near future, as it allows us to store more info in one cache line of 64 bytes. On the other hand, the 48 bits limit (256 Tera bytes) will probably be reached in several years (probably 10). I agree the patch is not useful today, so I'm ok to remove it if nobody feels it useful to keep 4 bytes for future use. In my opinion, these 4 bytes will soon be use for some new feature, looking at linux skb shows that there is plenty of useful information that could go in a network packet descriptor (timestamp, queue id, protocol, qos, ...). Regards, Olivier